Hacker News Reader

Comment by zamalek | Hacker News Reader

Gaming workloads are strict superset of almost any other workload (because they are extremely taxing on almost any metric a platform can have). Game benchmarks are abundant and reproducible. They are a good indicator of how a platform will deal with almost any other software.

AMD did have a CAD benchmark thrown in.

> Threadripper

Not a bad choice at all (wait for that 5000 TR announcement), however, a *950X comes close to TR for much less. My 3950X has made a striking difference for Rust compilation times and I'm strongly considering a 5950X.

View on HN

Indeed. And for rust compilation, good single threaded performance can have a significant impact on that last annoyingly slow linking step (at least when building executables).

I've noticed the same thing on EC2 instances, compiling, e.g. Alacritty, there wasn't a lot of difference between 8 vs 16 vCPUs since the last step took a significant portion of time and was single-threaded. It's fun watching 16 (or 32) CPUs maxed out though.

Have you noticed an actual improvement? I couldn't pinpoint what was the bottleneck in the last Rust program compilation step at all. I have two machines with extremely fast NVMe SSDs and an incremental compilation improvement from i7-8565U (laptop, 24s) to Xeon W-2150B (iMac Pro, 12s) was extremely disappointing.

I'm pondering a Threadripper workstation but I'm very worried if I'll gain any actual incremental compilation speed at all.

Do you have any observations?

I'm also having a 3950x for Rust work and it has been the fastest CPU I've ever used. It just flies every day and makes rust compilation times not an issue anymore.

That means, I really don't know do I want to have the trouble of finding the 5950x and the work of replacing the CPU. I really don't feel like I need more CPU power at this point.

But replacing my 2080ti with a new fast Radeon, that would be something...

Did it help with the final compilation step which seems to be single-core-bound?

Did it improve the final step though? That seems to be single core and I still can't pinpoint how to accelerate it (written a down-thread comment here: https://news.ycombinator.com/item?id=24739796)

Can gaming workloads simulate the 100% of all cores that a parallel large scale native C++ compilation will generate?

Modern game engines can, yes

Games are typically written in C++, so that's a yes. As for the threading, older (2yr or so back) games tend to assume 4 cores and don't scale past that (thanks, Intel!). More recent games tend to aim at arbitrary horizontal scaling.

You do still get major titles that are completely single-threaded.

written in C++ not means it's compatible workload. Gaming performance is just gaming. For gaming, realtimeness is important and normally single thread perf is important even though some process is multithreaded.

? no

The parent was talking about c++ compilation.

A c++ compiler is very different from a game engine written in c++.

uh what??? No most games do no scale like compilation does. For instances when compiling a large program GNU make lets me the following: make -j 16

That will create 16 instances of the compiler each compiling different compilation units. I could even do the following: make -j 128 and that will spawn a 128 processes, and still scale. I can keep scaling this assuming I have enough compilation units (aka files)

Games use threads.

Compilation parallelism is generally bounded roughly the number of independent compilation units. For my main codebase, that is in excess of 1200. That is, on a system with 1200 cores, I could use all 1200 cores productively, at full capacity (ignoring disk i/o waits) [1]

My impression is that few games (if any) can ever approach this level of potential parallelism. There are not many tasks in computing with this level of "embarrassing parallelism".

[1] somebody actually did this with Ardour once, on a system with 1024 cores. The current normal-system compile time record for the software is a little under 5min (Ryzen Threadripper 2950X + 64GB of RAM). The k-core system completed the build in less than 10 seconds :)

> My impression is that few games (if any) can ever approach this level of potential parallelism.

Which is embedded in my first comment on game multithreading: "older" games assume 4 cores, some are single-threaded.

This has no bearing on how new the engine is. The workloads scale much differently when it comes to parallelism. While it might possible to get a little more parallelism and concurrency with a newer engine. The ability to scale is much more limited for games.

Surprised that the record doesn't belong to a 32-core CPU, hmm. Quite interesting.

Any data on the precise machine specs that did the record? I'm talking about the TR 2950x one, not the custom-built many-core machine.

I'd be interested mostly in motherboard and RAM speed.

Just because a game uses threads does not mean it can magically get rid of Amdahl's law. The CPU workload of games does not scale anything like compilation.

> does not mean it can magically get rid of Amdahl's law.

Neither can compilation.

I never claimed it did. Compilation is an embarrassingly parallel task. This means you can increase the number of threads by a much much larger amount before you hit Amdahl's law. That is not true for video games unless you count what runs on GPUs. Not only can it be less obvious on what to parallelize in a game engine. You quickly start to see the parallel slowdown/diminishing returns in game engines. Further, not every thread in video game is going to use the CPU at 100%, a lot them will be waiting on IO, and not using any time slices till that IO task is finished.

Games do not scale like compilation, it does not matter what engine or how new that engine is.

https://en.wikipedia.org/wiki/Embarrassingly_parallel https://en.wikipedia.org/wiki/Parallel_slowdown

> Further, not every thread in video game is going to use the CPU at 100%

Modern game engines do not segregate work according to threads, they use thread pools. If one green thread is busy with I/O, work can be scheduled on its OS thread.

https://en.wikipedia.org/wiki/Work_stealing

If the game has a CPU bounded work load that scales well across multiple threads/processes. Honestly, most games do not, and are likely gonna run into Amdahl's law much quicker than compilation.

Gaming doesn't really have SIMD or FP at all though, does it?

Plenty of it. Going trough the transform hierarchy (tons of 4x4 matrix multiplications which definitely are vectorized) and then the physics simulations, and that’s just part of it.

Couldn't be further from the truth. Rasterization is all linear algebra. That being said, you don't really see games with the likes of AVX-512.

That all happens on the GPU. There's a tiny (trivial) amount of linalg on the CPU and the rest is punted to shaders.

It's not always trivial, especially if any computational geometry is being done (read: any game with a landscape).

Physics are still often CPU, though I guess sometimes on compute shaders by now?

Then there's bad engines, e.g. Fallout 4 seems like it might be calculating some part of the shadows on the CPU…

Floating point yes, but SIMD depends.

Reply on news.ycombinator.com