4 ms·

What? They're not uncommon for servers or high-performance workstations - Xeon dual/quad socket are very common. I've seen close to 250% speed increases with N

by berkut 13y ago

What? They're not uncommon for servers or high-performance workstations - Xeon dual/quad socket are very common. I've seen close to 250% speed increases with NUMA-aware code (and tying thread affinity down) - writing things so the code's aware of where the memory is and targets thread jobs to cores on sockets that have that memory already can significantly reduces memory traffic over the QPI links, which if you don't do (with AVX instructions trying to do 8 floats per clock with IB) systems tend to just be memory-starved, as they can't feed data to processors fast enough from main memory. Especially with Xeons, as the pre-fetchers are so aggressive.

fulafel 13y ago
You moved the goalposts - I said they're uncommon in general. Though even most servers are single socket these days. Most high performance parallelized code runs in game engines, media codecs, and things like that. I can believe you can see speed increases like you cite with bandwidth-bound code, but would doubt this kind of optimization is good bang for the buck for most perf critical code.
- berkut 13y ago
  What? Not if they're CPU-bound they're not. Look at Dell/HP workstation/servers: Z600/800 | Z620/Z820 range - dual sockets, all of them. The cheaper configs might only come with one CPU, but they've got two sockets. I'm talking highly-parallelisable code like in renders/raytracers, fluid simulations, image processing. All that stuff needs huge amounts of memory bandwidth. And it's generally parallisable in both threads and with SIMD with SSE/AVX, so you're literally up against the cache/memory throughput limits of the system. Game engines aren't that parallel actually - even job queue based ones which are in theory very scalable have dependencies which means that generally there's a limit to the number of threads they can run at once. The above examples I gave can generally scale linearly, given memory bandwidth.
  - fulafel 13y ago
    Most servers are doing pedestrian things like VMware, Exchange, web etc. and people buy server hardware for the RAS features. I'm saying apps and hardware you reference are uncommon. games was an example perf critical code that seldom benefits from numa optimization.

by berkut 13y ago

fulafel 13y ago

You moved the goalposts - I said they're uncommon in general. Though even most servers are single socket these days. Most high performance parallelized code runs in game engines, media codecs, and things like that. I can believe you can see speed increases like you cite with bandwidth-bound code, but would doubt this kind of optimization is good bang for the buck for most perf critical code.

berkut 13y ago
What? Not if they're CPU-bound they're not. Look at Dell/HP workstation/servers: Z600/800 | Z620/Z820 range - dual sockets, all of them. The cheaper configs might only come with one CPU, but they've got two sockets. I'm talking highly-parallelisable code like in renders/raytracers, fluid simulations, image processing. All that stuff needs huge amounts of memory bandwidth. And it's generally parallisable in both threads and with SIMD with SSE/AVX, so you're literally up against the cache/memory throughput limits of the system. Game engines aren't that parallel actually - even job queue based ones which are in theory very scalable have dependencies which means that generally there's a limit to the number of threads they can run at once. The above examples I gave can generally scale linearly, given memory bandwidth.
- fulafel 13y ago
  Most servers are doing pedestrian things like VMware, Exchange, web etc. and people buy server hardware for the RAS features. I'm saying apps and hardware you reference are uncommon. games was an example perf critical code that seldom benefits from numa optimization.