AMD Launches EPYC 9004 “Genoa” Processors – Up to 96 Cores, Zen 4, AVX-512 | Hacker News Reader

AMD Launches EPYC 9004 “Genoa” Processors – Up to 96 Cores, Zen 4, AVX-512

phoronix.com

72 pointsmfiguiere18 comments

Looks like an absolute beast.

Also makes me optimistic for lower end...this is eventually going to trickle down to VPS space...i.e. make those 1core/1GB utility VPS much cheaper

agree, cloud services are way too expensive, especially when you can get an 8 core mac mini for $700.

I'm not sure the comparison here. I could get 8 t3a.micros (16 cores total) for ~$700 reserved for 3 years, including power costs. And I don't have to maintain it, or the network connection etc.

But you do have to pay network usage by the gigabyte, right? And 8 full "hyperthreaded" cores in one machine are more useful than 16 machines with a core each, though I admit I don't know how much such a machine would cost on AWS.

It’s amazing how far we’ve come in 16 years - dual core dual socket processors to behemoths like this, which are faster per clock, faster per core and so dense as to make what would have been a rack’s worth of x86 compute possible in 1U

I know it’s incredibly unlikely I’ll see one of those in person, but hopefully these will result in serious cost improvements for low power cloud vms.

The CXL implementation is exciting! A shared memory bank that's concurrently-accessible in a cache-coherent manner? The possibilities are enormous! This is huge for distributed computation where the biggest bottleneck is oftentimes just copying data to and from nodes over the network, not to mention the potential for high-availability systems and how this could be used in database servers.

I wish I could get my hands on some of these systems.

These core counts are insane. I’m curious about any programming languages that are designed to be easily to parallelize and how they will work on these 96 core chips

C++ has been used on machines with very high CPU core counts for a long time. By now, things like std::async for spawning tasks on a different core are even part of the standard library.

Go is also really good at saturating many cores with its low-overhead goroutines.

make -j works pretty darn well in my experience.

Honestly, the #1 programming language for parallelization, in practice, is bash scripting. you can convert any single-threaded program into a background thread with the & on the end, and then start running something else.

Yeah yeah yeah, people wanna be complicated with pthreads or async or other features. But... bash's "background" processing (&) gets a surprising amount of things done in my experience. Just spin up a program 300+ times with a & to make them all process in the background, and you're set.

I've found make -j doesn't actually scale very well when you have a ridiculous number of cores and less than, e.g., 2 GB RAM/core.

ram bandwidth matters in some cases, check for arrow/wide GMI3 in Genoa slides

Rust is very good for parallelizing code, especially if used with libraries like https://crates.io/crates/rayon

Fortran is very well suited for highly parallalized workloads, given that all HPC tasks are basically parallelized matrix manipulations.

For some reason people have the notion that Fortran is still the punch-card days, but Fortran 08 is in fact widely used and quite friendly nowadays. If you're building a very-parallel application that could use something like MPI, you should very seriously consider Fortran.

Go can utilize the full CPU with ease :)

All languages implemented with llvm-mlir.

Others languages such Chapel, Halide probably will do fine

I'd use all of them for 3D! And MSVC supports parallel compilation since, like, 2009..?

Doing that in C is not that hard with OpenMP, you don't even have to fiddle with threads and/or manually parallelize your code. Just an example: https://tildesites.bowdoin.edu/~ltoma/teaching/cs3225-GIS/fa...

You won't fool me with your tempting PSP-bugged stones, AMD! )

Reply on news.ycombinator.com