#[cfg(windows)]
const MAX_THREADS: usize = 16;
#[cfg(not(windows))]
const MAX_THREADS: usize = 128;
the limit to 16 threads under windows was added in a commit named "refactor imports".
If somebody in the future tries to find out why the threads are limited to 16 under windows, they will eventually end up at that commit and if the committer isn't around any more (or doesn't remember), nobody will ever know the reasoning.
For projects that have even the slightest chance of staying around, be mindful about your commit messages and explain why you are doing something, not what you are doing - that's what the code itself is for.
It's sad to see how many experienced programmers do not understand this. Of course, it takes a little more effort, but without this type of thinking you might as well skip the commit message completely. I am a very junior programmer and it was one of the first thing I was corrected for not doing, and rightly so.
And if you screw something up, there's always `git commit --amend` or the sledgehammer of `git rebase -i`.
Note: I'm not advocating doing this to public history, but I'm saying: Use these tools in order to create self-contained changes on your end before committing them to public history.
When I'm doing archeology trying to find out why Foo is doing Bar instead of Baz, I don't want to know that back then, 10 years ago, you fixed a typo or added a "forgotten file".
for the hn h8rz: you don't deserve performance bwahahhahaha maybe this should actually be dropped to 0 olololololololol
https://github.com/spacejam/sled/commit/b7a5d14399540daa433a...
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/pr...
https://www.anandtech.com/show/15483/amd-threadripper-3990x-...
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.
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%.
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.
For one, SQL Server spanks most other databases for complex ad-hoc queries.
Don't get me wrong, PostgreSQL is getting a lot better these days, and I'm sure that for a lot of basic workloads its very competitive, but the query planner in SQL Server is basically black magic.
There are very few (any?) database engines out there that can, in a single query, combine in-memory tables, remote tables, functions, materalised views, columnar data, and recursive joins then run that query in parallel and efficiently.
I think Oracle has most of those checkbox features, and perhaps a couple of others do too (DB2 perhaps?), but as far as I know MS SQL Server still outperforms them for this type of thing.
Mind you, Oracle scales to bigger clusters, and DB2 runs on bigger iron, but that's not my use-case. I have one Intel box.
For sure. If you can't choose, then I don't blame you.
> there's real reasons to use Windows for performance
I can't really think of any reason though. You gave the example of SQLServer, but that also runs on Linux. Does SQL Server perform better on Windows than Linux?
Edit: found a benchmark here: https://www.dbbest.com/blog/running-sql-server-on-linux/
Turns out you get better performance for SQL Server on Linux compared to windows. I am not surprised by this at all.