tougenkyou

The Xeon-W 2175 has avx-512. Threadrippers cannot compete in numbering work relative to price point on well optimized code. sgemm on 5000x5000 matrices takes about 600ms on a Threadrippers 1950x, but only around 150ms on the comparatively priced i9 7900x. Vector libraries for special functions, eg Intel VML or SLEEF also provide a similar performance advantage there.

If you're mostly crunching numbers, and either compiling the code you run with avx512 enabled (eg, -mprefer-vector-width=512 on gcc, otherwise it's disabled) or using explicitly vectorized libraries, you will see dramatically better performance from avx512, regardless of any thermal throttling. Number crunching is what it's made for.

Granted, you should be offloading most of those computations to the GPU, which will be many times faster. But I'd you're in the business of ML or statistics, I'd still way that more heavily than the difference in how long it takes them to compile code.

https://old.reddit.com/r/buildapc/comments/doclv5/cheapest_way_to_build_a_machine_with_avx512/

M1 Vector Instructions (AMX)

https://yro.slashdot.org/story/23/05/03/216218/finnish-newspaper-uses-secret-room-in-counter-strike-to-bypass-russian-censorship

簡体字のすすめ

So if I care about performance, I would use the JVM? No. If you use the JVM you might well care about performance. If you care about performance, you should consider the JVM.

I spent years as a performance engineer on HFT trading systems tuning JVMs.

The JVM is not designed to give you 100% performance (of the ideal offered by the hardware). It's designed to give you the easiest means of achieving ~95%, provided you're OK with some nondeterminism.

I’d use a language like golang with reasonable default GC behavior and allocation patterns - where I know the daemon I write won’t use more than 100-200Mb, and probably even less, and will typically have sub-ms pauses.

You'd be wrong, because JDK 14 will most likely give you substantially better performance than Go out of the box; JDK 15 and 16 even more so.

BTW, the footprint and performance profile of JDK 14 is worlds apart from JDK 8. The JVM has been undergoing some very big changes in the last couple of years.