3 ms·
> Databases, particularly any database which benefits from more than 16MB of L3 cache. Yes but have you seen this actually measured, as being a net performance
by gameswithgo 7y ago
> Databases, particularly any database which benefits from more than 16MB of L3 cache.
Yes but have you seen this actually measured, as being a net performance problem for AMD as compared to Intel, yet? I understand the theoretical concern.
- dragontamer 7y agohttps://www.phoronix.com/scan.php?page=article&item=amd-epyc-7551&num=3 https://www.phoronix.com/scan.php?page=article&item=amd-epyc... Older (Zen 1), but you can see how even a AMD EPYC 7601 (32-core) is far slower than Intel Xeon Gold 6138 (20-core) in Postgres. Apparently Java-benchmarks are also L3 cache heavy or something, because the Xeon Gold is faster in Java as well (at least, whatever Java benchmark Phoronix was running)
- gameswithgo 7y agoThanks, perfect! I'll keep an eye on these to see how the new epycs do.
- arantius 7y agoWhat I see there is that the EPYC 7601 (first graph, second from the bottom) is much faster than the Xeon 6138 -- it's only slower than /two/ Xeons ("the much more expensive dual Xeon Gold 6138 configuration"). The 32-core EPYC scores 30% more than the 20-core Xeon.
- dragontamer 7y agoThere's a lot of different benchmarks there. Look at PostgreSQL, where the split-L3 cache hampers the EPYC 7601's design. As I stated earlier: in many workloads, the split-cache of EPYC seems to be a benfit. But in DATABASES, which is one major workload for any modern business, EPYC loses to a much weaker system.