I often think about huge, fancy cloud setups literally costing silly money to run, being replaced by a single beast of a machine powered by a modern, high core count CPU (say 48+), lots of RAM and lots of high performance enterprise-grade SSD storage.
(Oftentimes part of the reason the huge, fancy cloud setup costs more is that any component can fail, all the way down to the region-level, without loss of service.)
And often times that loss of service, if temporary is not all that painful -- it really depends on the exact needs/use case/scenario.
Naples, Rome, Milan, Genoa, and Turin are just cities in Italy; I'm not sure what's childish about that. They have to use something for codenames.
The criticism is about "EPYC" not about the codenames. That brand name has been used since 2017 but if you don't know that, it sounds quite gamery nowadays. Admittedly I also have no idea why Intel calls theirs Xeon, which sounds like misspelled xenon. But then it might be a proper Greek word?
> The criticism is about "EPYC" not about the codenames.
The criticism above says "Turin, Epyc and lord knows what else". That clearly includes the codenames.
Yes. It keeps the board from booting if the firmware is replaced with a version not signed by the board manufacturer (i.e. so an attacker can’t replace it with a version that does nefarious things). Preventing CPU reuse in other boards is just an (unintentional?) side effect.
The cynic would say the security implications are the side effect, since selling more, new chips is the goal.
If that was the goal then the CPU would fuse on first boot for any manufacturer’s board, rather than being fused only by Dell boards.
I wonder what percentage of 'big data' jobs that run in clusters would now be far faster on a single big machine with e.g. duckdb rather than spark
The difference in throughput for local versus distributed orchestration would mainly come from serdes, networking, switching. Serdes can be substantial. Networking and switching has been aggressively offloaded from CPU through better hardware support. Individual tasks would definitely have better latency, but I'd suspect the impact on throughput/CPU usage might be muted. Of course at the extremes (very small jobs, ve…
By way of a single example, we've been migrating recently from spark to duckdb. Our jobs are not huge, but too big for a single 'normal' machine. We've gone from a 2.5 hour runtime on a cluster of 10 machines (40,vCPU total) to a 15 minute runtime on a 32vCPU single machine. I don't know for sure, but I think this is largely because it eliminates expensive shuffles and serde. Obviously results vary hugely depending on workload, and some jobs are simply too big even for a 192 core machine. But I suspect a high proportion of workloads would be better run on single large machines nowadays
This is lazy criticism and honestly, I'll take a name like Epyc over Intel Core Ultra 7 258V or Ryzen AI 9 HX 370. > Looks like the folks downvoting me are massive, massive fans of that THREADRIPPER architecture. Yes, it must be everybody else, not your comment, which is the pinnacle of deep analysis. Get real, dude.
> I'll take a name like Epyc over Intel Core Ultra 7 258V or Ryzen AI 9 HX 370.
Well no, the comparison to "Epyc" is "Intel Core" and "Ryzen"
And if you gave each SKU its own name I think that would very quickly get worse than the stupid numbering schemes.
I would be pretty curious about such a system. Or, maybe more practically, it might be interesting to have a system pretends the L3 cache is ram, and the ram is the hard drive (in particular, ram could disguise itself as the swap partition, to so the OS would treat is as basically a chunk of ram that it would rather not use).
Philip Machanick's RAMpage! (ca. 2000) > The RAMpage memory hierarchy is an alternative to a conventional cache-based hierarchy, in which the lowest-level cache is managed as a paged memory, and DRAM becomes a paging device.
So, essentially, you're just doing cache eviction in software. That's obviously a lot of overhead, but at least it gives you eviction control. However, there is very little to do when it comes to cache eviction. The algorithms are all well known and there is little innovation in that space. So baking that into the hardware is always better, for now.
Many algorithms are limited by memory bandwidth. On my 16-core workstation I’ve run several workloads that have peak performance with less than 16 threads. It’s common practice to test algorithms with different numbers of threads and then use the optimal number of threads. For memory-intensive algorithms the peak performance frequently comes in at a relatively small number of cores.
Is this because of NUMA or is it L2 cache or something entirely different? I worked on high perf around 10 years ago and at that point I would pin the OS and interrupt handling to a specific core so I’d always lose one core. Testing led me to disable hyperthreading in our particular use case, so that was “cores” (really threads) halfed. A colleague had a nifty trick built on top of solarflare zero copy but at that ti…
NUMA gives you more bandwidth at the expense of higher latency (if not managed properly).
Civilization VII won't run smoothly. Only recently I managed to build a PC that will run Civ 6 smoothly during late game on huge map
What are the specs? Tangentially related, but I need to go check a18 civ 6benchmarks. The experience on my a15 with small map sizes was surprisingly good.
It's not latest and greatest, 12900K + 64GB DDR4. But even when 12900K came out(2021) Civ 6 was already 5 years old
512 MB of cache, wow. A couple years ago I noticed that some Xeons I was using had a much cache as the ram in the systems I had growing up (millennial, so, we’re not talking about ancient commodores or whatever; real usable computers that could play Quake and everything). But 512MB? That’s roomy. Could Puppy Linux just be held entirely in L3 cache?
CCDs can't access each other's L3 cache as their own (fabric penalty is too high to do that directly). Assuming it's anything like the 9174F that means it's really 8 groups of 2 cores that each have 64 MB of L3 cache. Still enormous, and you can still access data over the infinity fabric with penalties, but not quite a block of 512 MB of cache on a single 16 core block that it might sound like at first. Zen 4 also ha…
It's actually 16 CCDs with a single core and 32MB each.
I wonder if you can boot it without populating any DRAM sockets.
I would be pretty curious about such a system. Or, maybe more practically, it might be interesting to have a system pretends the L3 cache is ram, and the ram is the hard drive (in particular, ram could disguise itself as the swap partition, to so the OS would treat is as basically a chunk of ram that it would rather not use).
Intel has such a CPU with the previous gen called the xeon AMX with up to 64gb of HBM on chip. It could use it a cache or just memory.