PHPor 的Blog

1. 如果使用 OllamaSetup.exe ，那么默认安装位置为：~\AppData\Local\Programs\Ollama ，安装过程中没法选择别的安装位置; 我是因为这个安装文件比zip安装包小很多，就选择了这种安装方式
2. 如果C盘目录不足的话，安装后将该目录移动到D盘，然后创建一个软连接就行了
3. 安装后的Ollama大约5GB，为啥这么大呢？主要大文件有如下几个：
   1. Ollama\lib\ollama目录下的三个目录：
   2. cuda_v11  1.1G   我安装的是V1.28的驱动，所以这个也用不着
   3. cuda_v12  1.95G
   4. rocm  1.93G    这个是AMD CPU才用得着的，我的inter CPU NVIDIA显卡，用不着

1. GPU不能像CPU那样通过时间分片实现伪并行
   1. CPU 的上线文切换只需要保存几个寄存器就可以了，切换成本相对较低
   2. GPU计算通常都有很多计算单元和数据的，显存数据量通常GB级别，强行切换的成本很高
2. GPU也能多任务并行
   1. 相比CPU，GPU的是真正意义上的多任务并行
   2. 应用程序只需要提交任务给GPU，GPU自己来安排任务到合适的核心上

CPU的超线程本质上是硬件层面的虚拟化，把原本的4个CPU核心伪装成8个CPU核心，真正干活的还是4个CPU核心，这不是骗人吗？

这个没有骗人，只是骗操作系统内核而已；这样能提高效率吗？

加入现在系统中有4个线程在工作，刚好有4个CPU核心，每个进程用完自己的CPU分片之后，发现没人跟自己抢CPU，接着运行就行，不需要上线文切换，跑的很好；

过了一段时间，又来了4个线程，于是出现8个线程使用4个CPU的情况，每个时间片用完之后都需要保存寄存器、切换上下文操作，都不产生实际价值。

管理员意识到这个问题之后，开启了CPU的超线程模式；对于内核来讲，就是8个线程使用8个CPU，不需要上线文切换了，这种不产生实际价值的操作就不用做了。

话说还是8个线程争抢4个物理CPU啊？

确实如此，但是现在的争抢是发生在CPU内部的，不需要太多的寄存器内容保存到内存的操作，效率会高一些。

举例说明：

银行柜台有4个服务员，每个服务员一个窗口，每个窗口前面一把椅子，客户听到叫号之后，做到对应的椅子上，开始办理业务，偶尔服务员进行操作，用户闲着，偶尔服务员让客户提供材料或输入密码，服务员等着；

经理看到这种现象，就想能不能让客户找材料的时候让服务员处理下一个人的业务？（这个经理大概率以前是搞计算机的）

然后，经理就让服务员在等用户找东西的时候，让用户离开座位回去找，接着叫下一个客户。

问题就出现了，一方面客户离开的时候要把自己的东西都拿走，服务员手里的关于该客户的东西也要正确收纳起来，效率反而下降了。另一方面客户贼不高兴。

经理肯定能看出这样搞不行了，经理就回想起来了计算机中的超线程，使用超线程的方法进行优化方案如下：

1. 每个服务员都开两个窗口，4个服务员（物理CPU），共8个窗口（超线程）

客户在办理完业务之前，是不需要离开自己座位的，只有服务员在幕后自动切换位置，每个客户提交给服务员的资料也都在各自窗口的办公桌上放着，每个办公桌上也都有自己单独的电脑。

经过优化之后，任务的吞吐量提高了10%，经理获得了一个创新奖，服务员的显然比以前更累了，经理当然也看得见，于是每个服务员加薪15%。

超线程的不适用场景：

1. 当系统线程数量小于物理CPU数量时，超线程发挥不了作用

AI答案：

对于8个线程CPU满载的情况下，4核心物理CPU在开启超线程的情况下，是否能体现出超线程的优势？

1. 超线程的硬件设计本质

• • 每个物理核心通过超线程模拟出 2 个逻辑核心，但共享执行单元（如 ALU、FPU）、缓存、内存控制器等关键资源。例如：

• • • 4 核 CPU 开启超线程后有 8 个逻辑核心，但实际执行计算的硬件单元仍为 4 组。

• • 逻辑线程的 “并行” 本质是分时复用物理核心的资源，而非真正的独立硬件并行。

2. 资源竞争的关键场景

• • 当 8 个线程全部满载时，每个物理核心的 2 个逻辑线程会同时争夺同一组执行单元、缓存带宽等资源。例如：

• • • 逻辑线程 A 正在执行浮点运算（占用 FPU），逻辑线程 B 也需要执行浮点运算时，必须等待 A 完成，导致流水线停顿。

1. 理想情况（理论上的 “优势”）

• • 若 8 个线程的指令类型完全不冲突（如线程 A 用 ALU，线程 B 用 FPU），超线程可能通过资源分时复用提升利用率。

• • 但这种场景在实际应用中极为罕见，尤其是计算密集型任务（如科学计算、渲染）中，线程通常需要大量同类运算资源。

2. 现实情况（性能瓶颈）

• • 执行单元竞争：当两个逻辑线程同时需要使用同一类型的执行单元（如整数运算、浮点运算），会产生 “资源冲突”，导致其中一个线程被迫等待，实际吞吐量接近单线程性能的 2 倍（而非理想的 2 倍）。

• • 缓存一致性开销：两个逻辑线程共享 L1/L2 缓存，频繁的数据读写会增加缓存一致性协议（如 MESI）的开销，降低缓存效率。

• • 内存带宽瓶颈：8 个线程同时访问内存时，内存控制器的带宽可能成为瓶颈（尤其在双通道内存配置下），导致整体性能下降。

• 测试环境：4 核 8 线程 CPU（如 Intel i5-1135G7），运行 8 个计算密集型线程（如 Prime95 烤机）。

• 性能对比：

• • 开启超线程：CPU 利用率 100%，但单核性能因资源竞争可能下降约 10%~20%，整体多线程性能接近 4 核物理核心的 1.2~1.5 倍（而非 2 倍）。

• • 关闭超线程：8 个线程被调度到 4 个物理核心，每个核心运行 2 个线程（操作系统级上下文切换），此时单核性能更稳定，但多线程吞吐量可能与开启超线程时相近或略低（取决于任务调度效率）。

• 结论：在极端满载的计算密集型任务中，超线程的优势微弱，甚至可能因资源竞争导致性能低于预期。

1. 线程数少于逻辑核心数：如 4 线程运行在 8 逻辑核心上，此时物理核心的资源未被占满，超线程可利用空闲资源并行处理。

2. 任务混合 IO 与计算：部分线程因 IO 等待（如读写硬盘、网络）处于空闲状态，超线程可让物理核心切换到其他计算线程，减少资源浪费。

3. 轻负载多任务场景：如同时运行浏览器、文档编辑、后台程序等，各任务对 CPU 资源的占用不均，超线程可提升整体响应速度。

• 核心结论：4 核 8 线程 CPU 在 8 线程满载时，超线程的优势难以体现，甚至可能因资源竞争导致性能下降。

• 本质原因：超线程的设计目标是 “利用空闲资源提升利用率”，而非 “为完全满载的任务提供额外算力”。当物理核心的资源被完全占用时，逻辑线程的并行会退化为 “资源争夺”，抵消超线程的优势。

• 建议：若任务长期处于 8 线程满载且为计算密集型，关闭超线程（使系统仅识别 4 个核心）可能让每个物理核心专注处理 1 个线程，减少资源竞争，获得更稳定的性能。

在settings.json中添加：

https://cloud.tencent.com/developer/article/1548672

这个目录太大了

使用C盘的“磁盘空间清理”功能试试

点击“清理系统文件”

C盘空闲8.4G,清理后应空闲12G

执行后（winsys目录减小了约3GB，清理约1.5万个文件，还是太多）：

因为dmg文件是一个磁盘镜像文件，需要挂载到文件系统上，才能把里面的内容copy到/Applications目录中,比如，Chrome浏览器的安装dmg文件在安装时，会挂载到目录/Volumes/Google Chrome，具体挂载到哪个目录在dmg文件里面已经定义好了，挂载后的文件目录如下：

[junjie20@Mac: 05-30 14:28:59 Google Chrome]$ ll
total 4
lrwxr-xr-x@ 1 junjie20 staff 13 5 6 10:10 -> /Applications
drwxr-xr-x@ 3 junjie20 staff 102 5 6 07:54 Google Chrome.app

里面有一个/Applications的软连接，这大概就是我们打开这个dmg后，就可以看到两个图标，一个是应用程序，一个是Applications目录，拖进去就行了。

安装完成后，我们会把dmg文件删除掉，此时并不影响我们进入目录/Volumes/Google Chrome ，因为文件引用还在，就没有真正释放；此时，执行下面命令，空间就会被释放：

hdiutil detach /Volumes/Google\ Chrome

更多请参考文章: https://phpor.net/blog/post/19146

DMG文件基础概念

1. 定义与特性
   DMG(Disk Image)是macOS专属的磁盘映像格式，采用HFS+/APFS文件系统封装，支持压缩(AES-128/256加密)、分卷和校验功能。其本质是将文件系统结构+数据打包为单一文件，通过虚拟设备节点(/dev/disk*)挂载访问。
2. 核心用途
   • 软件分发：78%的macOS第三方应用通过DMG分发
   • 数据备份：可创建加密的磁盘映像
   • 系统恢复：部分恢复工具使用DMG存储

macOS选择DMG的技术动因

1. 完整性保障
   校验和机制确保安装包传输无损，双击时自动验证
2. 安装流程标准化
   允许开发者自定义安装界面(背景图/协议文档)
3. 文件系统兼容性
   完美支持macOS特性如资源派生(Resource Fork)

APP安装流程与底层机制

1. 用户可见操作
   
   # 典型安装流程 hdiutil attach example.dmg # 挂载DMG cp -r /Volumes/Example/App.app /Applications # 拖动安装

   1 2 3

   # 典型安装流程 hdiutil attach example.dmg  # 挂载DMG cp -r /Volumes/Example/App.app /Applications  # 拖动安装

2. 底层执行过程
   • 内核将DMG映射为虚拟设备(如/dev/disk5s1)
   • 挂载到/Volumes/临时目录，文件系统驱动解析元数据
   • 复制操作触发APFS写时复制(CoW)机制

关键问题解析

1. 挂载点溯源
   
   hdiutil info | grep -B 5 "/Volumes/Target" # 查找挂载点对应DMG mount | grep "/Volumes/Target" # 查看设备节点

   1 2	hdiutil info | grep -B 5 "/Volumes/Target"  # 查找挂载点对应DMG mount | grep "/Volumes/Target"  # 查看设备节点

2. 大小差异原因
   • DMG压缩存储 vs 挂载后解压状态
   • 文件系统元数据(如HFS+目录B-tree)占用额外空间
3. 废纸篓仍可访问
   文件句柄保留机制：DMG挂载后系统保持对原始文件的引用，移动至~/.Trash不影响已打开句柄
4. 不自动卸载的设计考量
   • 用户体验：避免中断用户可能的二次安装
   • 性能优化：减少重复挂载开销
5. 影响
   • 我们为了节省空间，安装完APP后，就会把安装文件(*.dmg)删掉，由于该文件安装后没有自动卸载，即使删除了，磁盘空间也不会被释放，此时，需要参考下面的手动卸载操作，手动卸载后，磁盘空间理解释放（很爽）

实用操作指南

1. 手动卸载
   
   hdiutil detach /Volumes/Target # 标准卸载 hdiutil detach -force /dev/disk5s1 # 强制卸载

   1 2	hdiutil detach /Volumes/Target  # 标准卸载 hdiutil detach -force /dev/disk5s1  # 强制卸载

2. 工具差异
   • hdiutil专管磁盘映像，可追溯DMG关联
   • diskutil侧重物理设备管理，无DMG元数据接口
3. DMG制作示例
   
   hdiutil create -srcfolder ./App -fs HFS+ -volname "MyApp" -encryption AES-256 MyApp.dmg

   1	hdiutil create -srcfolder ./App -fs HFS+ -volname "MyApp" -encryption AES-256 MyApp.dmg

   
   支持参数：
   • -format UDZO：压缩映像
   • -size 100m：预分配空间
4. 访达中操作
   • 访达中的“位置”里面也可以看到挂载的dmg文件，也可以点击“推出”进行卸载

篡改猴脚本可以在不同时机执行：

如果我们需要通过修改window对象来模拟一些特殊情况，就可能需要在页面加载的第一时间来设置window对象，就需要让篡改猴脚本第一时间执行，修改方式如下：

更新前：

更新后：

结论：

1. 浏览器版本会变
2. navigator.userAgent 不会变, 锁死在了 135.0.0.0