分Die是不是已经到了尽头

8owd8wan · 发表于 2024-8-19 23:19

赫敏发表于 2024-8-19 23:17
mysql，oracle，sql server，db2这些本身不是分布式所以用numa连起来。但numa本身超过2路也就求个自我安 ...

为何说是自我安慰？求解？
单体应用部署在多路机器本来就是为了最大并行化啊。
只不过说，现在EPYC计算密度高了，双路足够而已。但十几年前，16路Power7上部署DB2，就是要比双路P7的吞吐量高数倍呀

8owd8wan · 发表于 2024-8-19 23:23

赫敏发表于 2024-8-19 23:17
mysql，oracle，sql server，db2这些本身不是分布式所以用numa连起来。但numa本身超过2路也就求个自我安 ...

如果是谈分布式，谈微服务，那单个容器更不用多大了。
这样的话，EPYC的簇间延迟更无所谓了，反正都是一个个容器跑在一个个VM里。VM的cpu core，更不会跨簇

alieshex · 发表于 2024-8-19 23:23

本帖最后由 alieshex 于 2024-8-19 23:25 编辑

8owd8wan 发表于 2024-8-19 23:15
何以见得卡在 CPU 内？就为了那点延迟……不理解，真不理解那些喊延迟高的人，到底是何等需求🤔 （除了游 ...

？？？我没说延时。
典型传统多线程不是完全分割互不干扰的吗。内存总带宽比cpu带宽都高，这场面我还是第一次见。颠覆了我cpu卡在带宽上的传统印象。

8owd8wan · 发表于 2024-8-19 23:27

本帖最后由 8owd8wan 于 2024-8-19 23:30 编辑

alieshex 发表于 2024-8-19 23:23
？？？我没说延时。
典型传统多线程不是完全分割互不干扰的吗。内存总带宽比cpu带宽都高，这场面我还是第 ...

这。。实际情况很复杂，比如说，我开了个thread pool，task扔进去，多线程并行计算，folk-join，最后还是要await，主线程里继续往下走。。。真不一定说是完全分割互不干扰

那么在这种情况下，理想状态，是可以分辨出本numa节点的可用core's, 然后底层尽可能帮我malloc 近端内存。内存总带宽大部分情况下，对我来说意义不大（因为我只要近端内存）。

当然，现在都微服务了，根本不在意这些破事儿

alieshex · 发表于 2024-8-19 23:35

本帖最后由 alieshex 于 2024-8-19 23:41 编辑

8owd8wan 发表于 2024-8-19 23:27
这。。实际情况很复杂，比如说，我开了个thread pool，task扔进去，多线程并行计算，folk-join，最后还是 ...

不考虑实际情况，实际这类东西都跑gpu上去了，或者超算，这东西不清楚。只是个理论讨论，内存带宽都超过cpu内部带宽，如果发生了话，这情况我确实第一次见。

emmm，你之后提及的都是需要维持缓存一致性的多线程，这类要么基本带宽不敏感，因为卡在一致性上消耗更严重

8owd8wan · 发表于 2024-8-19 23:37

本帖最后由 8owd8wan 于 2024-8-19 23:40 编辑

alieshex 发表于 2024-8-19 23:35
不考虑实际情况，实际这类东西都跑gpu上去了，或者超算，这东西不清楚。只是个理论讨论，内存带宽都超过c ...

没有，目前我们大部分程序，还是跑CPU的。GPU计算麻烦的要死，内存拷贝来拷贝去，还要用专门的，恶心的框架和API（CUDA，说的就是你）
再说了，大部分业务逻辑，if else then居多，咋可能凑成一堆堆向量往GPU塞？或者。。服务器上咋可能有GPU？又不是人人都搞AI。

大部分服务端程序就那回事儿，谁要是通用业务程序里提议用GPU加速，我们会觉得。。。他是外星人吧？
退一万步，就算AI，小规模部署的图片分类，双塔召回这些常用AI，哪怕用Pytorch或TS，大家都会图省事儿，用CPU推理。。。真的足够了

darkness66201 · 发表于 2024-8-19 23:38

alieshex 发表于 2024-8-19 23:01
sp5都加大面积了，布线咋还不是问题，总不可能供电线才是吧
卡带宽不是卡内存而是卡cpu内部。。现在至少1 ...

哎呀怎么有绕回去了，我不是已经说了嘛，现在EPYC里面就有wide mode，现有的CCD上面有两个GMI 接口，可以给单个CCD提供翻倍的IF带宽，但是只有在48核心或者以下的型号中才能提供，这是因为IOD上面只有12个GMI接口，所以超过48核心就只能使用narrow mode，只启用单个GMI接口连接，这就意味着现有的CCD和IOD之间的物理布线可以提供翻倍的IF总线带宽且现有CCD本身就已经有提供双倍IF带宽的能力。如果按照16核心单个CCD，搭配4个GMI接口，完全可以提供足够的IF带宽，你会发现CCD的改动只是单纯的把两个CCD粘起来罢了。唯一问题IOD，按照我上面的思路全部都是现成技术，就是单纯把IOD做大一点就是完事了。当然了，唯一要求是把IOD上面的12个GMI接口变成48个，多了非常多，但是也不是不可能，像MI300X上面互联的IF总线接口也已经提供了896GB/s的带宽了，这也不是个问题。还是那句话，用新技术新总线当然可以，但是现有的思路拓展一下是不是不能用，显然也还不至于，zen7那是后面的事情......

Mufasa · 发表于 2024-8-19 23:44

alieshex 发表于 2024-8-19 23:23
？？？我没说延时。
典型传统多线程不是完全分割互不干扰的吗。内存总带宽比cpu带宽都高，这场面我还是第 ...

胶水CPU，内存带宽比CCD高，很正常吧。

3代EPYC在特定应用的机器上还可以开UMA模式。

4代已经弄到12通道内存了，那么多内存带宽显然是为并行使用，而不是单给哪一颗芯片。

alieshex · 发表于 2024-8-19 23:54

darkness66201 发表于 2024-8-19 23:38
哎呀怎么有绕回去了，我不是已经说了嘛，现在EPYC里面就有wide mode，现有的CCD上面有两个GMI 接口，可以 ...

两类基板不能共用。
多出来的线，在6ccd上可以放下，但是12ccd上还能放下吗？
设计上肯定是放在砍掉的那6个ccd的线的位置上吧

Mufasa · 发表于 2024-8-19 23:59

8owd8wan 发表于 2024-8-19 23:19
为何说是自我安慰？求解？
单体应用部署在多路机器本来就是为了最大并行化啊。
只不过说，现在EPYC计算密 ...

DB2我也学过，那个和MySQL根本不是一类产品。

特别是IBM自己机器上运行的DB2，硬件优化相当变态的。

MySQL也分两个引擎，MyISAM和InnoDB
但以我实际使用的情况来看，EPYC跑数据库的性能很强，别管它是什么引擎。
即使是4节点NUMA的初代EPYC，跑数据库也比核心数较少的Xeon快很多。

至于虚拟机就更随意了，EPYC在虚拟机方面的优势太大。

alieshex · 发表于 2024-8-19 23:59

本帖最后由 alieshex 于 2024-8-20 00:15 编辑

Mufasa 发表于 2024-8-19 23:44
胶水CPU，内存带宽比CCD高，很正常吧。

3代EPYC在特定应用的机器上还可以开UMA模式。

哪正常了。

传统cpu都是自己卡住等内存数据。

到你这，cpu卡住，“嘿，我带宽不够，我不拿内存数据了”

打个正常的比方吧。你设计一个cpu，前端解码能力比后端处理能力弱，你还觉得这正常吗。现在就是这趋势，zen处理能力超过if提供带宽，甚至内存提供的带宽都快超过if了。
别变成笑话，两代u比较性能差距等价于fclk提升就行

darkness66201 · 发表于 2024-8-20 00:22

本帖最后由 darkness66201 于 2024-8-20 00:36 编辑

alieshex 发表于 2024-8-19 23:54
两类基板不能共用。
多出来的线，在6ccd上可以放下，但是12ccd上还能放下吗？
设计上肯定是放在砍掉的那6 ...

噢，不对，说错了，按照12个CCD单个CCD16个核心分配16通道DDR5来计算的话，应该只需要24个GMI接口才对，单个CCD一共16个核心给两个GMI接口，提供96/64 GB/s带宽，甚至连wide mode都用不上。当然了，这样分配和现在一样受制于IF带宽，多一个接口，3*12=36个GMI接口，给到144/96 GB/s给单个CCD 16个核心，什么都足够了。如果24路GMI接口，IF总线总带宽已经有1152/768 GB/s了，如果36路更是1728/1152 GB/s ，如果只给16通道内存的话，看样子也用不着......

实际上算下来会发现，受制于IF or 内存带宽的问题，其实也只有桌面端存在，EPYC上面根本都不叫个事，本身单CCD频率不高也没那么多算力。内存通道数又有限，还有wide mode和少核心数的以及 X3D兜底........

啊，我知道了，一个CCD同样给四个接口，维持现状不变，EPYC给16通道，narrow mode给双GMI，wide mode给四GMI，桌面端IOD提供三个or 四个GMI接口，反正也就连接一个CCD，搞定，只需要小改桌面端IOD即可。至于桌面端32核心？再说吧

Mufasa · 发表于 2024-8-20 00:33

alieshex 发表于 2024-8-19 23:59
哪正常了。

传统cpu都是自己卡住等内存数据。

原来你纠结的是这个啊。

Zen5C的处理能力不会超过IF带宽的，因为它跑不了大核心那种高频。
丁点大的硅片放16个计算核心，积热非常严重，频率必须大幅降低。
为了降低功耗使用高密度低功耗库，频率也是降低。

AMD也知道自己IF访问内存延迟高，所以搞X3D

软件应用多种多样，根据应用选择CPU，才是正确的做法。
EPYC型号一大堆，也是为了迎合这种市场趋势。

至于那个胶水基板，只要愿意加钱，增加互联层数就好了。

现在还用老的IOD，是因为现在还没成为瓶颈。
等IOD带不动了，AMD自然会设计一个新的来换掉它。

8owd8wan · 发表于 2024-8-20 00:34

alieshex 发表于 2024-8-19 23:59
哪正常了。

传统cpu都是自己卡住等内存数据。

感觉可以对比一下其他典型的多核处理器的情况。比如早期的 PA-RISC， ultrasparc, power ，现在的 m3 max, 看看是否如你说的，这是一个问题

Mufasa · 发表于 2024-8-20 00:45

darkness66201 发表于 2024-8-20 00:22
噢，不对，说错了，按照12个CCD单个CCD16个核心分配16通道DDR5来计算的话，应该只需要24个GMI接口才对， ...

下一代应该搞不出16通道内存，主板布线没法做。
强行加PCB层数，搞16通道，主板成本上天。。。。
不如给IODie边上加一坨HBM内存。

12通道的内存全部插满已经是烤炉了，内存比CPU还烫。
继续榨取内存频率面临更高的发热，非常困难。

内存通道数再往上加，就是XeonE7和以前多路服务器常用的，内存又整一个串行总线来跑，服务器里面单独插内存板，内存板上面再插内存条。

alieshex · 发表于 2024-8-20 01:06

8owd8wan 发表于 2024-8-20 00:34
感觉可以对比一下其他典型的多核处理器的情况。比如早期的 PA-RISC， ultrasparc, power ，现在的 m3 max ...

？？？？？？？？？？？？

m3算半个显存，有啥可比性。
早期情况我不清楚，但是应该不可能出现总线速度比存储慢

8owd8wan · 发表于 2024-8-20 01:24

alieshex 发表于 2024-8-20 01:06
？？？？？？？？？？？？

m3算半个显存，有啥可比性。

不能因为人家是统一内存，而否定是内存啊……
多核处理器还是要仔细看一下，这样的设计会不会真的在实际生产中，产生巨大的障碍。如果是，那就是严重缺陷，如果这样严重的缺陷，厂家都看不到……

8owd8wan · 发表于 2024-8-20 01:27

Mufasa 发表于 2024-8-20 00:45
下一代应该搞不出16通道内存，主板布线没法做。
强行加PCB层数，搞16通道，主板成本上天。。。。
不如给I ...

加 HBM 做存储的分级，是符合历史趋势的。不可能既要又要什么都要，只能不得不去折中和妥协

alieshex · 发表于 2024-8-20 01:29

Mufasa 发表于 2024-8-20 00:33
原来你纠结的是这个啊。

Zen5C的处理能力不会超过IF带宽的，因为它跑不了大核心那种高频。

按yc作者的话，zen5 单ccd avx512实际上已经超过60GB/s了

现状我都理解。实际没专门优化也不可能跑满。但是只是感叹情况确实变了。一直都是cpu快过内存，现在可以内存快过cpu了。（if fclk2000 理论60/30GB/s，单通道ddr5已经能摸到了）
emmm，大概中间有点跑题，在讨论如何改进if，然后不知道为啥被扭到解释为啥，啥情况之类的上面

alieshex · 发表于 2024-8-20 01:33

8owd8wan 发表于 2024-8-20 01:24
不能因为人家是统一内存，而否定是内存啊……
多核处理器还是要仔细看一下，这样的设计会不会真的在实际 ...

不是，你gpu带宽要和cpu比？
我没否定
现状就是，yc作者实测，zen5卡带宽严重。

8owd8wan · 发表于 2024-8-20 01:36

alieshex 发表于 2024-8-20 01:33
不是，你gpu带宽要和cpu比？
我没否定
现状就是，yc作者实测，zen5卡带宽严重。 ...

那么，什么场景下，跑什么应用，会出现这种瓶颈？如果这种情况日常大家都能碰到，zen5 岂不是直接作废？……

8owd8wan · 发表于 2024-8-20 01:39

alieshex 发表于 2024-8-20 01:29
按yc作者的话，zen5 单ccd avx512实际上已经超过60GB/s了

现状我都理解。实际没专门优化也不可能跑满。 ...

用 avx512 来跑满才能出现问题？那我倒是无所谓了，反正我不挖矿。跑不到这种极限……

赫敏 · 发表于 2024-8-20 02:10

8owd8wan 发表于 2024-8-19 10:19
为何说是自我安慰？求解？
单体应用部署在多路机器本来就是为了最大并行化啊。
只不过说，现在EPYC计算密 ...

16路能提升很多倍也是因为数据本身有没有需要远端partition。你要是join到一个在每个节点上均匀分布的列你看还成倍提升不，越多路越慢

多路连接本身效率就相对本地要低很多，而且保持全连接代价太大。当然分布式自身的缺点也很明显就是warm up时间长数据加载慢，尤其在云上用serverless就更卡。只是单纯讲扩展性那只能这样

赫敏 · 发表于 2024-8-20 02:14

alieshex 发表于 2024-8-19 12:29
按yc作者的话，zen5 单ccd avx512实际上已经超过60GB/s了

现状我都理解。实际没专门优化也不可能跑满。 ...

单ccd avx512的吞吐量是以TB/s计算，不是啥60GB/s然后你把总线弄快点能解决的

shawnwinton · 发表于 2024-8-20 09:12

Mufasa 发表于 2024-8-19 19:35
所以我觉得AMD现在的搭配是正确的。

芯片内用Ring，芯片外用普通总线。

AMD的路线绝对是先进且正确的，但是现在瓶颈了，ZEN5已经是典型代表

8owd8wan · 发表于 2024-8-20 09:37

赫敏发表于 2024-8-20 02:10
16路能提升很多倍也是因为数据本身有没有需要远端partition。你要是join到一个在每个节点上均匀分布的列 ...

所以我一直强调，实际生产情况，实际使用情况。
抛开实际情况，空谈极端，那就真没意思了

alieshex · 发表于 2024-8-20 09:48

8owd8wan 发表于 2024-8-20 01:39
用 avx512 来跑满才能出现问题？那我倒是无所谓了，反正我不挖矿。跑不到这种极限…… ...

也只有simd吃的满，不然我一直问epyc咋办干啥。桌面应付一下够了，60G应付够了。顶多面子难看，打不过intel，苏妈又不会care拿9950来干hpc的人，就像老黄不care4090一样。（不过intel avx卡实现，amd卡带宽，属于匹配机制了）
但是你拿epyc弄吃不满，这可是会出问题的

8owd8wan · 发表于 2024-8-20 09:51

alieshex 发表于 2024-8-20 09:48
也只有simd吃的满，不然我一直问epyc咋办干啥。桌面应付一下够了，60G应付够了。顶多面子难看，打不过int ...

我们数据中心里面，实际情况是一个个 vm, 跑着一个个增删改查的容器，还真影响不大。你不会以为程序员们都能调用 avx512？或者以为业务逻辑增删改查，还需要用到向量并行？
还是那句话，实际情况，实际情况。脱离实际空谈理论，意义不大

alieshex · 发表于 2024-8-20 09:55

赫敏发表于 2024-8-20 02:14
单ccd avx512的吞吐量是以TB/s计算，不是啥60GB/s然后你把总线弄快点能解决的

到不了tb。tb是咋算出来的
按yc作者说法，单ccd，zen4 avx256能到60g， zen5 avx512 翻倍了，超if是一定的

Mufasa · 发表于 2024-8-20 09:57

alieshex 发表于 2024-8-20 01:29
按yc作者的话，zen5 单ccd avx512实际上已经超过60GB/s了

现状我都理解。实际没专门优化也不可能跑满。 ...

IF改进很简单啊，单通道不够用双通道，双通道不够用四通道。
这种互联总线可以简单粗暴堆数量，代价是那个胶水基板要提高成本。

按之前的帖子讨论，CCD芯片本来就带两个接口，IOdie不够用而已。
9000系列还沿用7000系列的IOdie，确实有点偷懒。
但现在牙膏厂这鬼样子，农企没有动力去升级。

APU那边还停留在5xxx系列呢，等哪天农企把APU迭代到9xxx系列。
内存控制器和核心运算做在同一个硅片，内部带宽问题就不存在了。

账号		自动登录	找回密码
密码			加入我们

[CPU] 分Die是不是已经到了尽头

评分

评分

浏览过的版块