6 ms·
Nobody in the Windows/Mac world writing software should have to care about the change, or even know about it. That's the beauty of an OS scheduler, it is optimi
by wutwutwat 3y ago
Nobody in the Windows/Mac world writing software should have to care about the change, or even know about it. That's the beauty of an OS scheduler, it is optimized to execute your instructions where it sees fit, and higher level programs don't need to know how it works, where it executes your instructions, or that it even exists. Sometimes abstraction and separation of concerns can be beautiful thing. I'd argue that most programs shouldn't make any decisions about where to run, I know I don't want random engineers for some mac app controlling my power consumption or setting priority above anything else I run. The kernel developers with the data stream of health and performance info from the intimately connected hardware (on apple) is who I want to make the call on where to run. In the very few situations where E or P core assignment matters (games and VMs are all that I can think of and even that is arguable imo), there has been the ability to inform the OS scheduler where to run for a very long time.
Tangent: With today's insanely powerful hardware you should not ever be constrained in your programs to ever have to consider setting core affinity and if you go down that road you might want to reevaluate what you're doing, because you're probably doing something wrong and blaming it on the OS scheduler. Even constrained to the E cores (which are still plenty fast), your programs should perform well. I think more developers need to start writing software on slow machines on purpose because too many apps are written on machines that cost $4000+ with the newest chip and gpu innovations and then are never tested on slower more commonly used hardware, and things end up being dog slow on those machines and get no attention. If more apps were built on slow hardware and were still fast, they'd be even more so on the $4k machines. The macbook air was great for this because it was fanless and every core was essentially an "E" core, forcing you to optimize the code you wrote for the selfish reason of it not being annoying to run the code you were writing. Even if selfish, the net result was production code that was blazing fast once deployed on server grade hardware.
- dwattttt 3y agoIf instructions don't run the same between heterogenous cores, i.e. one core supports instructions the other doesn't, unless this information is available to the scheduler, there's no way it can make that decision. AVX512 was such an example, and sadly it ended up getting locked off from the P cores.
- wutwutwat 3y agoSomething made the decision if it got "locked off from the P cores", what was it if not the OS scheduler?
- wtallis 3y agoWhat got locked off was the P-core's AVX512 instruction support, not some process's core affinity. Intel didn't have an E-core design ready to support AVX512 in Alder Lake. They initially allowed AVX512 to be enabled on the P-cores if all the E-cores were disabled at boot, but they later switched to fusing off AVX512 support permanently.
- wutwutwat 3y agoInteresting, but what does this have to do with what my original comment was about?
- yjftsjthsd-h 3y agoAbstractions leak. Many devs don't need to care, but anyone particularly concerned with performance or power consumption will want to know the details. (Just like many devs don't need to know about CPU cache, how GPUs work, etc.)
- adev_ 3y ago> today's insanely powerful hardware you should not ever be constrained in your programs to ever have to consider setting core affinity That is wrong in HPC environment. Most programs tailored for HPC will set core affinity manually. And they have very good reason to do so (cache affinity, memory bindings). The correct abstraction depend of your domain. There were indeed very little incentive up to know to play with core affinity and the scheduler in a classical desktop environment. The story is different on systems with strong constraints on efficiency.
- wutwutwat 3y agoI don't want you to determine where my programs on my computer run though. I want my operating system, which has much more context about the hardware available, a very smart scheduler in place, and honors my user preferences for how to operate on AC or battery power, and takes into account my scheduling overrides I want via AppTamer or similar. You as the developer of the application I'm running shouldn't mess with what cores it runs on, you should just make sure your program is able to be used across all of them, and that's where your reach should end. That's where my reach should end if I am writing a program you will run. The execution of the process is up to the user running the process and the OS, not the person who wrote the program. Maybe that's not an opinion may people share with me though
- xcv123 3y agoYep but that has nothing to do with HPC. Those are super computing applications and you're not running those on your laptop or desktop. In HPC scenarios the developer knows more than the operating system.