4 ms·

It's been around since 2011 on Android. Nothing new. https://en.wikipedia.org/wiki/ARM_big.LITTLE https://en.wikipedia.org/wiki/ARM_big.LITTLE

• 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).
  • 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.
• astrange 3y ago
  General term is asymmetric multiprocessing, which goes back a few more decades: https://en.wikipedia.org/wiki/Asymmetric_multiprocessing https://en.wikipedia.org/wiki/Asymmetric_multiprocessing IIRC big.LITTLE implementations tended to have cores that didn't support the same instruction sets, meaning you couldn't migrate tasks between them if you needed to. Kind of like how laptops could switch between integrated and discrete GPUs, but some users would need to switch to the discrete GPU to use an external monitor even if they didn't want the power hit. Also, "big.LITTLE" is a pretty strange brand name.
  • reanimus 3y ago
    I think the term you're going for here is heterogeneous multi-processing/computing, not asymmetric multiprocessing: https://en.wikipedia.org/wiki/ARM_big.LITTLE#Heterogeneous_multi-processing_(global_task_scheduling) https://en.wikipedia.org/wiki/ARM_big.LITTLE#Heterogeneous_m... https://en.wikipedia.org/wiki/Heterogeneous_computing https://en.wikipedia.org/wiki/Heterogeneous_computing It even lists big.LITTLE there as a typical example in the second article. big.LITTLE itself never had different ISAs as far as I could tell, just scheduling caveats that lead to efficiency tradeoffs, like the first article mentions.
    • astrange 3y ago
      My understanding of "heterogenous computing" is that it's more about splitting a task across a CPU and coprocessors, or writing the same code to target both. Asymmetric means there's multiple CPU cores but they're not equally performant.
  • repiret 3y ago
    big.LITTLE is typically cores with the same architectural features, just different performance due to different microarchitecture. A7/A15/A17, or A53/A57/A72, or A55/A76. This let them run the same code, even the same system level code. The scheduler only had to optimize performance, without tasks being pinned to one core or another for correctness.
  • jasonjayr 3y ago
• m3kw9 3y ago
  Android likes to do things to check off boxes and in mediocre ways