Hacker News Reader

Comment by daemin | Hacker News Reader

Supporting only 64 processors in a group on a 64bit operating system seems like a reasonable and sane technical solution. It means you can use a single 64bit variable as a bitmask for various processor related functions in a process.

I would bet that many other bits of software also have this limitation because they too thought that using a 64bit value for a processor mask would be sufficient.

View on HN

The marketing folks will be overjoyed -- We're going to need a 128-bit operating system soon.

Ahhh, I don't think so. We're already in the place where memory bandwidth is the big killer so I can't imagine any enthusiasm for making our pointers twice as large.

Unlikely and if that's the case, trivial to fix. We're talking about masking against N potential bitmasks instead of one, which is still stupid easy and people do it all the time.

A 6-bit variable would be enough to hold 64 values.

That doesn’t allow you to use it as a bit mask, which is what OP was saying.

Another way to express this is that a 64-bit value can express every combination of processors, so if you want to say something like "this process should run on these 12 specific processors" you can do so in a single 64-bit value.

There are loads of places where it’s more convenient to test a bit vector than compare a scalar value. It’s just cheaper at runtime. Of course it may be possible to cheaply extend the bit vector scheme to 128 bits or even 256 fairly easily, using the native vector registers. But I bet Windows still supports some pretty old models of CPUs.

But you need 64-bits to represent affinity masks and scheduling. IE: Which of the 64-cores are available for a thread to schedule into.

----------

Furthermore, your Threadripper 3990x should ONLY really be pushing affinities for across a 8c / 16-thread die anyway, at least as far as the Windows scheduler is concerned.

Windows programmers should use multiple thread groups for different 16-thread CCX. Because its extremely costly to move all of your local state from one die's L3 cache into another.

https://images.anandtech.com/doci/15318/amd_rome-678_678x452...

Look at the chip, like physically look at it. AMD has 9x chips here (1x I/O die for memory, and 8x compute chips, each with 8x cores). You really only want to be moving threads within those 8x cores, because moving a thread across chips is less efficient.

So the ideal world, people would understand Windows's scheduler and work around it. Instead of complaining about how it is different from Linux's. Windows's Thread groups being 64-sized is reasonable for the job it wants to do... and there are other parts of the API that allow you to work across Window's 64-sized processor groups. In particular, to increase your affinities across to a 2nd processor group.

It isn't sane, it is an artificial limitation and poor design. At best it was an pre-mature code optimization.

It should be fixed by a professional coder who doesn't impose limitations, especially in an OS, based on wanting to fit bit flags into a single variable.

Windows should fix this -- there should be nearly unlimited cores per group. They can still have limitations per Windows version so they can price segment their market.

Reply on news.ycombinator.com