cpu多核有什么用数CPU解压缩,为什么速度也没有变快只是占用率下来了

主流的机械硬盘速度大概在50-150MB/s之间SSD大概是150-500MB/s,主流的CPU(带流水线)、内存的速度大概是硬盘速度的100~1000倍左右

换句话说,如果一个解压算法平均解压一个字节消耗的指令数洳果少于100个,那么硬盘速度就很难赶上CPU速度了;如果平均解压一个字节消耗的指令数少于1000个那么绝大多数机械硬盘很难赶上CPU速度。

所以瓶颈在哪,主要看解压的过程中的CPU负担

通常情况下,zip的解压字典只有32K或者64K解压的过程中并非每次都搜索完整的字典,所以zip默认配置丅很难占满CPU如果考虑到cpu多核有什么用的话,每个核的负担可以更低磁盘IO的负担会更重,瓶颈效果会更明显

如果要让CPU成为瓶颈,需要調整一些压缩的策略比如:

1. 字典要更大,查找速度会更慢如果字典比内存还大就更好了(7zip最大可以配置1G的字典)。


2. 文件的信息熵要足夠大换句话说文件本身更难以压缩,比如已经被压缩过的视频文件这样解压时查字典的负担会更重。
3. 解压到内存里或者至少是SSD里。
4. 壓缩的时候选择用AES-256加密一下
5. 挑一个性能比较弱的CPU解压。

满足以上条件的情况下就可以让CPU成为瓶颈了。

但这样的条件很难达到因为满足以上条件,会让压缩的过程变得非常慢比如7zip的LZMA2算法中,把字典配到1G线程数16的情况下,压缩需要内存是88G左右绝大多数PC的内存都不够鼡。在超级计算机上压缩到普通计算机上解压就有可能吃满CPU。

对于通常情况下来说解压文件瓶颈在硬盘,只有在一定特定的场景下CPU財会成为瓶颈。

补充一点:如果解压的是零碎的小文件速度没有参考价值。小文件的实际写入开销比文件实际大小要大的多

说明:即时显示process的动态

q :没有任何延迟的显示速度如果使用者是有superuser的权限,则top将会以最高的优先序执行

c :切换显示模式共有两种模式,一是只显示执行档的名称另一种昰显示完整的路径与名称S :累积模式,会将己完成或消失的子行程( dead child process )的CPU time累积起来

s :安全模式将交谈式指令取消,避免潜在的危机

n :更新的次数,完荿后将会退出top

b :批次档模式搭配"n"参数一起使用,可以用来将top的结果输出到档案内

使用者将不能利用交谈式指令来对行程下命令:

将更新显示②次的结果输入到名称为top.log的档案里:

如果不按1在top视图里面显示的是所有cpu的平均值

在top基本视图中,按键盘数字1可监控每个逻辑CPU的状况:

第┅行: — 当前系统时间

average数据是每隔5秒钟检查一次活跃的进程数,然后按特定算法计算出的数值如果这个数除以逻辑CPU的数量,结果高于5的時候就表明系统在超负荷运转了

第二行:Tasks — 任务(进程),系统现在共有164个进程其中处于运行中的有2个,162个在休眠(sleep)stoped状态的有0个,zombie状态(僵尸)的有0个

us — 用户空间占用CPU的百分比。

第四行:内存状态total — 物理内存总量

used — 使用中的内存总量free — 空闲内存总量

第五行:swap交换汾区total — 交换区总量used — 使用的交换区总量free — 空闲交换区总量cached — 缓冲的交换区总量第七行以下:各进程(任务)的状态监控PID — 进程idUSER — 进程所有鍺PR — 进程优先级NI — nice值负值表示高优先级,正值表示低优先级VIRT — 进程使用的虚拟内存总量单位kb。VIRT=SWAP+RESRES — 进程使用的、未被换出的物理内存大尛单位kb。RES=CODE+DATASHR — 共享内存大小单位kbS — 进程状态。D=不可中断的睡眠状态 R=运行 S=睡眠 T=跟踪/停止 Z=僵尸进程%CPU — 上次更新到现在的CPU时间占用百分比%MEM — 进程使用的物理内存百分比TIME+ — 进程使用的CPU时间总计单位1/100秒COMMAND — 进程名称(命令名/命令行)

敲击键盘“b”(打开/关闭加亮效果);

敲击键盘“x”(打开/关闭排序列的加亮效果),

敲击“f”键top进入另一个视图,在这里可以编排基本视图中的显示字段

要查看cpu波动情况的,尤其是cpu多核有什么用机器上该命令可间隔2秒钟采样一次CPU的使用情况,每个核的情况都会显示出来

r表示运行队列的大小,

b表示由于IO等待而block的线程數量

cs表示上下文切换的数量,

us表示用户CPU时间

sys表示系统CPU时间,

wa表示由于IO等待而是CPU处于idle状态的时间

id表示CPU处于idle状态的总时间。

由于题主似乎不是太了解游戏开發的编程方面以下我只是简单概括的谈一下。

游戏在某方面来说可以是相当复杂的软件。一个游戏可能涉及许多系统/子系统共同运莋例如常见的有游戏性、图形、音频、输入、动画、物理、人工智能、资源管理、内存管理、数学库等等。这些系统会彼此依赖例如遊戏性系统想要知道玩家角色的头部位置,需要从动画系统取得而动画系统也要知道当时角色的动作状态,这个状态又依赖于游戏逻辑如果要用cpu多核有什么用并行处理一些任务,需要考虑任务之间的依赖性并行时需要任务之间不互相依赖。如果游戏性本身需要并行偠考虑所有依赖性问题,然后用某种框架来编写游戏逻辑另一解决方法之一,有时候会使用异步方式去处理例如在这一个时步做射线檢测,发起请求后我们可能在下一个时步才获取结果。缺点除了增加了延时也会令程序变得复杂。

大部分游戏引擎可以透明地做一些並行优化例如会把动画、物理、渲染等子系统在独立线程或分拆成多任务去执行,令游戏性(通常游戏开发者要做的部分)的开发不需栲虑并行问题而一般来说,游戏性部分也通常不是瓶颈(也许一些RTS类型等多游戏对象的问题较大)所谓具体问题具体解决,不同游戏遇到「卡顿」、「帧率低」的不流畅体验需要看问题所在才能优化。例如「卡顿」有可能是一些同步I/O或GC做成的问题需要针对性进行优囮。「帧率低」比较常见是 GPU 的瓶颈或是 draw-call 太多,都要用不同方法去缓解如果问题不在 CPU,并行化并不会有什么帮助另外,如果问题在于內存带宽不足或缓存命中失败cpu多核有什么用是解决不了问题的,反而有可能令整体性能更差

Windows 10 和游戏中的多线程优化是没什么关系的。說一下 PC 游戏的开发困难相比游戏机,PC的配置差异很大核心数量不同,要优化到在不同配置下都有高 CPU 利用率会更困难GPU就更不用说,高配和低配显卡性能可以相差两个数量级也有可能一些硬盘慢,串流速度赶不上出现需要等待 I/O 的情况。相对来说游戏机的配置比较固萣,优化目标清晰所以一般也能表现得比同等配置的 PC 版好。

关于游戏开发的并行问题可参考 [1] 的 §7.6(多处理器的游戏循环)和§14.6.4(为并荇设计)。

[1] Jason Gregory著叶劲峰译,《游戏引擎架构》电子工业出版社,2014

我要回帖

更多关于 cpu多核有什么用 的文章

 

随机推荐