|
发布时间: 2024-6-26 00:17
正文摘要:多核心的测试cpu还是能跑满的，单核心的只是开始几秒跑满，后面就跑不满了，应该是以后得cpu架构都要学苹果m芯片搞专门模块处理渲染这些需要长期占用cpu的应用吧。不过单核心测试跑分还是跟开始几秒钟cpu 100%时候的 ... |
| cinebench 2024还没娱乐大师靠谱。 |
本帖最后由 yoyofuture 于 2024-6-29 05:18 编辑 hsshhssh 发表于 2024-6-28 14:54 我知道这个意思，我手动设置cpu0就可以跑满一个线程，但是测试分数依然是刚开始几秒钟最高，后面只是60-100pts之间浮动。问题是amd全部大核心，如果是不断切线程调度，难道是后面线程调度导致性能损失这么多？还是说软件本来就是后面跑不满大核心？你看下楼上我回复的图片就知道了。 |
yoyofuture 发表于 2024-6-28 11:17 我说的是cpuz在自己的程序源码里写死了单核测试时跑在cpu0上，操作系统优先按程序自己的写法去调度。cinebench没这么做，是交给Windows调度的了，Windows就自动让它在多个核心之间切换。写死的好处是保证能在一个核心上一直运行，缺点是不是所有cpu的cpu0都是大核，这个时候就会出问题。如果是liunx系统可以用taskset命令强行让某个程序跑在某个指定核心而不是让系统自动调度，Windows也有类似的第三方软件，你把cinebench绑定在单个核心上再测试单核就能得到你想要的调度负载结果（即全程跑满同一个核心） |
yoyofuture 发表于 2024-6-28 11:21 那你手动把cb2024改成指定在第一个核心，它还跳不跳？跑完全程能不能分数变高？ 另外这跳不跳和果子的处理器怎么设计又有什么联系，想象也要按照基本法啊 |
|
手里有颗amd epyc 7551P,超频到3.8GHz,cpu-z多核19000+ 跑R23正常，但跑cinebench 2024，多核才400多分， 还没我手里的11代笔记本高。 这是怎么回事，有知道的兄弟吗 |
af_x_if 发表于 2024-6-28 11:18 没指定的，都是默认设置。不是跳，而是一个跑得满一个跑满几秒钟后就跑不满，因为两个软件都有实时显示跑分，明显cinebench几秒钟后跑分变成60%左右了，软件开发问题。  |
yoyofuture 发表于 2024-6-28 11:17 cpuz自己指定了呀，接受windows调度那就是会跳的。 |
hsshhssh 发表于 2024-6-28 10:24 我看了cpu核心设置，cpuz和cinebench都是勾选了全部cpu核心的。没有指定cpu0的哈。你翻看下我前面的评论回复，有我发布的图。 |
dcl2009 发表于 2024-6-28 09:10 CB在arm跑分不高了，就现在的m3pro跑分还不如8845hs这些一两千块的cpu。苹果的cpu价格是两三倍吧。但是arm必须堆模块进去cpu，否则通用计算很多性能非常差。 |
dcl2009 发表于 2024-6-28 08:55 我的用cpuz测试不会切来切去哦，都是稳定一个线程框100%。所以我说是软件开发不同导致。 |
本帖最后由 hsshhssh 于 2024-6-28 10:26 编辑 yoyofuture 发表于 2024-6-28 01:23 程序代码里是可以设置让自己跑在哪个核心上的，cpuz自己限定了必须跑在cpu0上，所以像测8cxgen3那种cpu0不是大核的cpu时单核测试永远跑在小核上，得分就不正常。原生windows arm64版的cpuz应该是修复了跑不到大核的这个问题 |
yoyofuture 发表于 2024-6-28 02:57 堆了啥模块？  你知道为啥CB在ARM上跑分那么高吗？明明通用性能稀烂，也不能说稀烂吧，没特定软件那么夸张的性能。 |
本帖最后由 dcl2009 于 2024-6-28 08:59 编辑 yoyofuture 发表于 2024-6-28 01:23 你说的是一个线程的压力测试吧，那是因为cpuz限制了CPU0当第一个线程，同理，两个线程限制CPU0+2以此类推，你要是只是跑下分你会发现单线程也是切来切去 至于为什么CB不限定某一核心，这个问题跟CPUZ跑分测试单线程不限定某个核心是同一个问题，你猜猜为啥不限制到某一核心？大概20年前有过讨论。 来个图吧，点跑分测试，首先全部核心满载，然后单线程有两个核心4个HT切来切去，从第一代双核Windows就是这个策略，Linux更极端，可以所有核心乱跑 
|
richienie 发表于 2024-6-28 01:36 cinebench 2024对比测试得分，都是跟苹果M芯片对比的了。你自己安装个看看，arm要提高pc应用成绩，都是靠堆相应模块才能有那么高成绩，否则不可能。当然苹果可能整合到主核心里面，没有专门说明，否则你可以用a系列核心搞个虚拟机跑下cinebench 看看得分多少？ |
看到“苹果m芯片”，是来搞笑的吗 |
dcl2009 发表于 2024-6-27 11:45 cpuz不会这样啊，cpuz一直有一个线程100%，而且测试得分不会差非常多，但是cinebench 就开始几秒钟100%一个线程，后面就只是跑不满一个线程。所以实时显示开始得分114pts，后面都是60-100pts浮动，但是最后的测试结果分数也是按照114pts显示的。所以这个是cinebench软件就这样开发的。不是系统问题了。我意思是他这个测试软件跟其他的不同。 |
wwwyj 发表于 2024-6-26 02:02 民科的套路就是这样的 |
gavinzyf 发表于 2024-6-25 20:13 甚至还是转译x86跑的 |
yoyofuture 发表于 2024-6-27 11:20 就是这样，你测试的没问题，操作系统会随机切核心，线程起来以后会有短暂的独占时间，你要是懂点Linux内核就很清楚了，有相关设置 切核心本意是分散压力，但是这年头核心太多，切来切去非常影响性能。你要是从核心A切到核心B，会经过这么几个步骤：1、保护现场 2、从A搬l2到B，3、清理三缓，有的会把链接直接给B核心，这里面就花费好长时间，再加上睿频从基频到满睿频，有需要好多ms 更恐怖的是，切核心会切来切去，频繁在某些核心之间切，有时候睿频都没来及起来就切走了，导致性能很差，不止cinebench，cpuz之类的软件也有类似情况 |
本帖最后由 yoyofuture 于 2024-6-27 11:23 编辑 dcl2009 发表于 2024-6-27 08:49 看看我前面的回复吧：我发现2024刚开始几秒钟就一个核心100%，然后pts就是114pts，跟最后测试结果差1-2pts这样吧，后面cpu占不满一个核心，实时显示的pts只有60-100pts之间，如果是分时导致，那后面跑不满一个框的时候，测试成绩就不应该是100%时候的6成左右变成60-100pts左右了，而且最终的单核心跑分成绩也是前面几秒钟有一个核心100%测出的114pts左右的成绩，分时会导致跑分从114pts下降到60-100pts，然后最终单核心跑分成绩是114pts差个1-2pts？  而且严格说起来，我跑分测试单核心性能，你tm分时切换核心测试，很多测试软件都不会这样设计的。而且cinebench 也不是分时测试，而且就开始几秒钟单个cpu核心会100%，后面大部分时间都是占不满单个核心的cpu性能的。所以变成60-100pts左右跑。 |
|
这是小白占领论坛了？上面楼层已经给出解释了，为了平衡每个核心，操作系统会时间分片，每个核心运行这个程序的概率差不多，所以你会看到A核心占了百分之40，B核心占了百分之60，他俩的和是百分百。 这个时候就出来个问题，缓存一致性和睿频上升时间，处理不好单核性能达不到标称，需要强制软件到某一核心。 话说这点知识不应该是常识吗？ |
| 你把cinebench进程设置相关性挂到只有cpu0看看是不是能吃满 |
| 怎么说呢...系统不一样 架构不一样软件版本也不一样，得出的结果最多就是个参考，就一个测试软件你这下这样的结论没什么意义啊！ |
zhjook 发表于 2024-6-27 02:07 我有运行其他程序的，当然不排除是测试软件占用。一般来说测试软件单核心测试期间都会占满一个线程框。cinebench 是例外。 |
银月 发表于 2024-6-27 01:47 还不能让人家 线程打个酱油 |
本帖最后由 yoyofuture 于 2024-6-27 02:07 编辑 银月 发表于 2024-6-27 01:47 我意思是，为什么不在同一个线程满负荷，跟cpuz一样？cpuz的第二排负荷是cpuz的第二排那个图吗？还是说前面的cinebench 2024单核心跑分的图？结论就是他软件设计就是这样。。。 |
yoyofuture 发表于 2024-6-27 01:14 那你回答我啊，二排前两个线程在干啥 |
银月 发表于 2024-6-27 01:09 确定啊，我也没改过进程调用哪个cpu核心设置，就默认运行。不过我发现cinebench 2023也是一样的。而且我发现2024刚开始几秒钟就一个核心100%，然后pts就是114pts，跟最后测试结果差1-2pts这样吧，后面cpu占不满一个核心，实时显示的pts只有60-100pts之间，应该是这个软件就是这样测试cpu的。cpuz呢设置1线程就占满一个框，2线程就占满两个框。我还以为cinebench 2023会占满1个框，刚才测试了下跟2024版本是一样的，都占不满。  |
Archiver|手机版|小黑屋|Chiphell
( 沪ICP备12027953号-5 )
310112100042806
GMT+8, 2025-6-21 20:18 , Processed in 0.012782 second(s), 9 queries , Gzip On, Redis On.
Powered by Discuz! X3.5 Licensed
© 2007-2024 Chiphell.com All rights reserved.
