cageymaru

Fully [H]
Joined
Apr 10, 2003
Messages
22,060
Michael Larabel of Phoronix has conducted a test of Linux application scaling on up to 128 threads. He chose a Dell PowerEdge R7425 server featuring two AMD EPYC 7601 processors for a total of 64 cores and 128 threads, 512GB of RAM (16 x 32GB DDR4), and 20 x 500GB Samsung 860 EVO SSDs. He ran the server through a battery of testing to see how Linux applications and benchmarks scaled from 2 threads to 128 threads. He has even more results here. If you are curious about how much AMD EPYC processors cost in relation to Intel Xeon processors, the AMD EPYC Processor Selector Tool is found here.

This Dell PowerEdge server packing two AMD EPYC 7601 processors can build the Linux kernel in just 25 seconds!
 
Those NAMD scores are almost perfect, but they should be since charm is all about threading. But NAMD is such a "which came first, the chicken or the egg?" piece of software because you almost need an advanced degree just to learn how to use it.
 
This Dell PowerEdge server packing two AMD EPYC 7601 processors can build the Linux kernel in just 25 seconds!

And I thought my Ryzen 2700 was quick at that compared to the E3 Xeons I have at work..

Being a Gentoo user I have done several thousand kernel compiles.
 
Crysis isn't multi threaded so no.

Yes, it is.

It was added in patch 1.2, iirc.

It still won't play with every eyecandy turned on any faster than ~60fps, on most systems today.

I still play Crysis, and CrysisWars.

And yes, you Can play online without Gamespy.
 
Yawn... wake me up when they test 2^32-1 thread scaling. Still waiting for that as my primes number program supports that many threads.

I'll change one variable to make it be able to do 2^64-1 threads once we get that high.. heh.
 
Will WOW not be CPU bound?

Nope.. because even though WoW is multithreaded, it still does a majority of the work on 1 thread as far as I know.

Have they even changed the default threading support or do you still have to manually configure it in a configuration file? If not, then they are being dumb. Changing the default over 10 years ago helped immensely. I don't see why they wouldn't have changed it by now.
 
Nope.. because even though WoW is multithreaded, it still does a majority of the work on 1 thread as far as I know.

Have they even changed the default threading support or do you still have to manually configure it in a configuration file? If not, then they are being dumb. Changing the default over 10 years ago helped immensely. I don't see why they wouldn't have changed it by now.

You always have a master thread....
 
You always have a master thread....

I know that. But I would think they could break it apart more than they do. Maybe breaking it apart more than they do has negative effects due to threads having to sync up.
 
How many cores does it saturate?

That depends on what you're doing.

But, at least 6.

Video card makes the most difference; 2x7970's will go wild trying to keep up. :)

When the Vega's get cheap, I'll see if two of those helps. :D
 
Nope.. because even though WoW is multithreaded, it still does a majority of the work on 1 thread as far as I know.

Have they even changed the default threading support or do you still have to manually configure it in a configuration file? If not, then they are being dumb. Changing the default over 10 years ago helped immensely. I don't see why they wouldn't have changed it by now.

I think it auto-configures now but I don't think it does a good job. I have a gaming VM (8c/16t from a 1950x, GTX1070) that I play WOW on. On Windows 10 it will use multiple cores but 1 core is always 90%+. On a OSX VM running on the same machine (VM with 8c/16t, GTX1070) I see much more even core usage, 25-35% on each core. Frame rate wise I get higher lows in the new BFA capitals on the OSX VM but higher highs in the open world on the windows one. Running at 1440p, settings at 7 I am seeing 30-45 in the Alliance town and 130+ in the open world on the windows VM and 35-50 and 100 max on the osx vm (frame limiter off)
 
No, not always, just for now. Otherwise, let gets real, things will not move forward at some point and that is a bad thing.

Well.. yeah, I hope it changes for games. Some tasks are just serial by nature.

Some tasks, such as a primes number generator are very easy to split out so the work load is pretty much exactly even over all the threads.. and without ANY syncing having to go on in between threads. No thread locks except for the one thread that only does monitoring of the other threads to detect when all of the other threads are finished before it spits out the results.
 
Well.. yeah, I hope it changes for games. Some tasks are just serial by nature.

Some tasks, such as a primes number generator are very easy to split out so the work load is pretty much exactly even over all the threads.. and without ANY syncing having to go on in between threads. No thread locks except for the one thread that only does monitoring of the other threads to detect when all of the other threads are finished before it spits out the results.

Gaming itself is not serial in nature, it is that it has been that way out of nessecity. Most gaming machines had single core CPUs for at least 20 years and therefore, the code base was built with that in mind.
 
Games, for the most part, are a poor application for threading, simply due to how games work. They are event driven. Sure, you can create a hundred threads, but then if they are all waiting on a single event to start a cascade of events, then what is the point?

The game loop already runs asynchronously in any decent game. Sound is already threaded at the OS driver level. Inputs are all threaded. You can thread artwork all you like, but there is only one bus to shove the data down, or one memory path to store the data so each thread would be locked waiting for others to finish. Those context switches add more overhead, by the way.

Most of the things that need to be threaded are al ready threaded. Sure, you can have a couple more threads, but nothing like a video editor/compilier could have.
 
So all these tests, 2 4 8 16 32 64, are all real cores and then for 128 they turn SMT on? Did I understand that correctly?
 
Not surprised here. The Linux kernel is literally written to handle thousands of cores due to the HPC/Super Computers it's used in. We just happen to be able to leverage that work because it's open sourced ;)
 
Vulkan's threaded utilization is actually quite impressive. Here's HTOP running Doom, older DX11 titles look nothing like that:

LguvZJE.png


Here's an article by Nvidia outlining how Vulkan implements multi threading, thanks to Juanrga for the link:

https://developer.nvidia.com/sites/...log/munich/mschott_vulkan_multi_threading.pdf
 

Attachments

  • LguvZJEh.jpg
    LguvZJEh.jpg
    111.2 KB · Views: 61
Last edited:
Morowind is still 1 thread.

Who is up for updating the engine?

Wish Bethesda would remaster it.

Will the new Elder Scrolls finally be fully threaded?

Games, for the most part, are a poor application for threading, simply due to how games work. They are event driven. Sure, you can create a hundred threads, but then if they are all waiting on a single event to start a cascade of events, then what is the point?

The game loop already runs asynchronously in any decent game. Sound is already threaded at the OS driver level. Inputs are all threaded. You can thread artwork all you like, but there is only one bus to shove the data down, or one memory path to store the data so each thread would be locked waiting for others to finish. Those context switches add more overhead, by the way.

Most of the things that need to be threaded are al ready threaded. Sure, you can have a couple more threads, but nothing like a video editor/compilier could have.

I have wondered, but dont know enough about coding to think it out myself, if the initial game load could be better managed or threaded. My experiance, which matches things I have read on [H] and elsewhere, is that games on NVMEx4 storage barely load faster then SATA based fast storage. In game, after the initial load I see much better performance with NVME vs SATA 3 flash storage, in game teleports, moving quickly to an area with a crap ton of textures to be loaded etc.

I dont think till NVME these was a reason to improve game load times or do anything different.
 
Morowind is still 1 thread.

Who is up for updating the engine?

Wish Bethesda would remaster it.

Will the new Elder Scrolls finally be fully threaded?



I have wondered, but dont know enough about coding to think it out myself, if the initial game load could be better managed or threaded. My experiance, which matches things I have read on [H] and elsewhere, is that games on NVMEx4 storage barely load faster then SATA based fast storage. In game, after the initial load I see much better performance with NVME vs SATA 3 flash storage, in game teleports, moving quickly to an area with a crap ton of textures to be loaded etc.

I dont think till NVME these was a reason to improve game load times or do anything different.

The problem with most initial game loads are the developer got lazy and took the cheap way out by mallocing space for each resource instead of one maloc for all of it and them managing the resources themselves. That one thing can speed the game load time by many factors.

The only reason game performance would be better from an SSD vs a hard disk is the coding is sloppy. Sloppy in terms of managing its resources. What they should be doing is running a thread which preloads what is going to be needed, rather than waiting to load it when they need it. Then the performance would not be tied to a storage system. Not hard to do, but takes some time to do it right.
 
Back
Top