121–130 of 175 posts
Truly mind boggling scale. Twenty years ago we had just 1-2 cores per CPU, so we were lucky to have 4 cores in a dual socket server. A single server can now have almost 400 cores. Yes, we can have even more ARM cores but they don't perform as well as these do, at least for now.
At least for now.
Truly mind boggling scale. Twenty years ago we had just 1-2 cores per CPU, so we were lucky to have 4 cores in a dual socket server. A single server can now have almost 400 cores. Yes, we can have even more ARM cores but they don't perform as well as these do, at least for now.
Earlier quoted context omitted.
Also, I raised the question at https://retrocomputing.stackexchange.com/q/30743/3722 and one of the answers points out the 1984 Rockwell R65C29 Dual CMOS Microprocessor. It was two standard 6502 on the same die using the same bus to access the same memory... and of course IBM mainframes did it decades before.
If we're going that direction, National Semiconductor had a 2 'core' COPS4 processor in 1981[1]. I have some in a tube somewhere (unused). [1] https://www.cpushack.com/2014/08/25/national-semiconductor-c...
Earlier quoted context omitted.
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?
I wonder if you can boot it without populating any DRAM sockets.
Truly mind boggling scale. Twenty years ago we had just 1-2 cores per CPU, so we were lucky to have 4 cores in a dual socket server. A single server can now have almost 400 cores. Yes, we can have even more ARM cores but they don't perform as well as these do, at least for now.
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
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, very large/complex objects being passed) you'd see big gains.
Truly mind boggling scale. Twenty years ago we had just 1-2 cores per CPU, so we were lucky to have 4 cores in a dual socket server. A single server can now have almost 400 cores. Yes, we can have even more ARM cores but they don't perform as well as these do, at least for now.
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 weirdest one of the bunch is the AMD EPYC 9175F: 16 cores with 512MB of L3 cache! Presumably this is for customers trying to minimize software costs that are based on "per-core" licensing. It really doesn't make much sense to have so few cores at such an expense, otherwise. Does Oracle still use this style of licensing? If so, they need to knock it off. The only other thing I can think of is some purpose like HFT…
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?
Zen 4 also had 96 MB per CCD variants like the 9184X, so 768 MB per, and they are dual socket so you can end up with a 1.5 GB of total L3 cache single machine! The downside being now beyond CCDCCD latencies you have socketsocket latencies.
The weirdest one of the bunch is the AMD EPYC 9175F: 16 cores with 512MB of L3 cache! Presumably this is for customers trying to minimize software costs that are based on "per-core" licensing. It really doesn't make much sense to have so few cores at such an expense, otherwise. Does Oracle still use this style of licensing? If so, they need to knock it off. The only other thing I can think of is some purpose like HFT…
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.
Earlier quoted context omitted.
If we're going that direction, National Semiconductor had a 2 'core' COPS4 processor in 1981[1]. I have some in a tube somewhere (unused). [1] https://www.cpushack.com/2014/08/25/national-semiconductor-c...
Yes, Retro SE also points out the Intel 8271 from 1977 was a dual core microcontroller.