3 ms·

Well threadripper tests showed windows does not scale that high.

by rapsey 7y ago

jiggawatts 7y ago
It does, but the client code needs NUMA support, which Rust does not currently have. It doesn't help that the default behaviour in Windows is just stupid: "By default, an application is constrained to a single group, which should provide ample processing capability for the typical application." This is the new "640KB should be enough for everybody", except now it is "64 threads should be enough". See: https://docs.microsoft.com/en-us/windows/win32/procthread/processor-groups https://docs.microsoft.com/en-us/windows/win32/procthread/pr... https://www.anandtech.com/show/15483/amd-threadripper-3990x-review/3 https://www.anandtech.com/show/15483/amd-threadripper-3990x-...
- tjoff 7y ago
  Sounds like a really sensible default to me.
- hinkley 7y ago
  Which surprises me, because formal object ownership and read/write access sound like exactly the sorts of things you’d like to have for a NUMA machine.
- hinkley 7y ago
  > 64 threads should be enough. It’s more that if you have a purely sequential workflow, you get access to less than 2% of the CPU on a 64 core machine. And even if you’re a bit parallel, Amdahl’s law smacks you pretty hard here.
  - jfkebwjsbx 7y ago
    The L3 cache is shared and has a mindblowing size, let's not forget that. Plus you get way more thermal room. Plus you can disable SMT. And there is always more than 1 process running if you take into account kernel threads. So I would say way quite a lot more than 2%. More like 10%.
    - hinkley 7y ago
      > a lot more than 2%. More like 10%. That's still essentially single digit percentages. And if is really in the low double digits, you're back to single digits when you go to 80 cores. On the positive side, I don't think multi-user systems would be where they are today if we hadn't been staring at a future full of hardware that can only be fully utilized by embarrassingly parallel tasks.

Well threadripper tests showed windows does not scale that high.

by rapsey 7y ago

Well threadripper tests showed windows does not scale that high.

It does, but the client code needs NUMA support, which Rust does not currently have. It doesn't help that the default behaviour in Windows is just stupid: "By default, an application is constrained to a single group, which should provide ample processing capability for the typical application." This is the new "640KB should be enough for everybody", except now it is "64 threads should be enough". See: https://docs.microsoft.com/en-us/windows/win32/procthread/processor-groups https://docs.microsoft.com/en-us/windows/win32/procthread/pr... https://www.anandtech.com/show/15483/amd-threadripper-3990x-review/3 https://www.anandtech.com/show/15483/amd-threadripper-3990x-...

tjoff 7y ago
Sounds like a really sensible default to me.
hinkley 7y ago
Which surprises me, because formal object ownership and read/write access sound like exactly the sorts of things you’d like to have for a NUMA machine.
hinkley 7y ago
> 64 threads should be enough. It’s more that if you have a purely sequential workflow, you get access to less than 2% of the CPU on a 64 core machine. And even if you’re a bit parallel, Amdahl’s law smacks you pretty hard here.
- jfkebwjsbx 7y ago
  The L3 cache is shared and has a mindblowing size, let's not forget that. Plus you get way more thermal room. Plus you can disable SMT. And there is always more than 1 process running if you take into account kernel threads. So I would say way quite a lot more than 2%. More like 10%.
  - hinkley 7y ago
    > a lot more than 2%. More like 10%. That's still essentially single digit percentages. And if is really in the low double digits, you're back to single digits when you go to 80 cores. On the positive side, I don't think multi-user systems would be where they are today if we hadn't been staring at a future full of hardware that can only be fully utilized by embarrassingly parallel tasks.