4 ms·

Yet nobody in the Windows/Mac world was ready (if you think they should have to care which maybe they shouldn't).

by wmf 3y ago

xcv123 3y ago
On Mac they have used the Grand Central Dispatch library since 2009. So if developers already used that, they were ready for M1 https://en.wikipedia.org/wiki/Grand_Central_Dispatch https://en.wikipedia.org/wiki/Grand_Central_Dispatch
- astrange 3y ago
  GCD was actually not designed for this scenario and it's easy to mess up with it. It was designed for a large number of equal cores (aka SMP), meaning people did dispatch_async to the default concurrent queues all over the place, which is a bad pattern when you have to shrink down to phone size. Also, dispatch_semaphore has priority inversions and a lot of other features (like dispatch_group) are semaphores in disguise. It does work if you use it carefully, but Swift concurrency is a different design for a reason.
  - xcv123 3y ago
    According to Apple developer documentation GCD is currently designed for this scenario https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon#Execute-Tasks-Using-Grand-Central-Dispatch https://developer.apple.com/documentation/apple-silicon/tuni... "On a Mac with Apple silicon, GCD takes into account the differences in core types, distributing tasks to the appropriate core type to get the needed performance or efficiency."
    - astrange 3y ago
      It is now, but that's mostly from evolution in the iOS era. But like I said, it's not perfect.
    - krackers 3y ago
      that's probably assuming you set the qos correctly.
      - astrange 3y ago
        And dispatch_async loses QoS while dispatch_sync keeps it, but people often used to async unnecessarily.
        krackers 3y ago
        >dispatch_async loses QoS Wait really? Where can I read more about this, this goes against what I would assume. Edit: Or do you mean that when dispatch_async the block is run with the QoS of target queue instead of source? That is what I would normally expect, if you want to "inherit priority" then dispatch_sync would do that, at the expense of blocking.
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 ago
  If 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.

Yet nobody in the Windows/Mac world was ready (if you think they should have to care which maybe they shouldn't).

by wmf 3y ago

Yet nobody in the Windows/Mac world was ready (if you think they should have to care which maybe they shouldn't).

On Mac they have used the Grand Central Dispatch library since 2009. So if developers already used that, they were ready for M1 https://en.wikipedia.org/wiki/Grand_Central_Dispatch https://en.wikipedia.org/wiki/Grand_Central_Dispatch

astrange 3y ago
GCD was actually not designed for this scenario and it's easy to mess up with it. It was designed for a large number of equal cores (aka SMP), meaning people did dispatch_async to the default concurrent queues all over the place, which is a bad pattern when you have to shrink down to phone size. Also, dispatch_semaphore has priority inversions and a lot of other features (like dispatch_group) are semaphores in disguise. It does work if you use it carefully, but Swift concurrency is a different design for a reason.
- xcv123 3y ago
  According to Apple developer documentation GCD is currently designed for this scenario https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon#Execute-Tasks-Using-Grand-Central-Dispatch https://developer.apple.com/documentation/apple-silicon/tuni... "On a Mac with Apple silicon, GCD takes into account the differences in core types, distributing tasks to the appropriate core type to get the needed performance or efficiency."
  - astrange 3y ago
    It is now, but that's mostly from evolution in the iOS era. But like I said, it's not perfect.
  - krackers 3y ago
    that's probably assuming you set the qos correctly.
    - astrange 3y ago
      And dispatch_async loses QoS while dispatch_sync keeps it, but people often used to async unnecessarily.
      - krackers 3y ago
        >dispatch_async loses QoS Wait really? Where can I read more about this, this goes against what I would assume. Edit: Or do you mean that when dispatch_async the block is run with the QoS of target queue instead of source? That is what I would normally expect, if you want to "inherit priority" then dispatch_sync would do that, at the expense of blocking.

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 ago
If 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.