5 ms·

I know it won't be exactly the same thing as the 68k and PPC eras, but I'm excited nonetheless. I'm a sucker for stories of going against the mainstream and pul

I know it won't be exactly the same thing as the 68k and PPC eras, but I'm excited nonetheless. I'm a sucker for stories of going against the mainstream and pulling it off. I remember being wholly underwhelmed when Apple switched to Intel in the mid 2000s; my PPC Mac mini was more performant than the first Intel mini by far, especially the GPU. Given how powerful the A series mobile processors are (the new iPhone SE makes my Galaxy Note 10+ look like a slouch in benchmarks), I have a feeling the new Macs will be worth a look for anyone without hard requirements for Windows 10.

nvarsj 6y ago
> I have a feeling the new Macs will be worth a look for anyone without hard requirements for Windows 10 Not just that - but the many, many legacy apps professionals rely on. The 64-bit move already decimated the professional audio space. The cynic in me can't help but see this as a move towards pure consumer device. As a development machine it will be all but useless as you find things that won't compile or work correctly on the new CPU arch.
- morganvachon 6y ago
  > As a development machine it will be all but useless as you find things that won't compile or work correctly on the new CPU arch. I'm not a developer so forgive my ignorance, but isn't this what cross-compiling is for? I get that compiling natively can increase performance and find obscure hardware issues, but it's my understanding that, for example, ARM builds of GNU/Linux binaries are just cross-compiled by server farms that are also natively compiling the AMD64 builds. Also, fat binaries and JIT emulation have been a thing forever, especially for Apple who has dealt with these changes twice now (68k -> PPC -> x86-64). I just don't see this being any different than current multi-platform efforts like Debian, NetBSD, etc., except it's a for-profit company with billions of dollars and thousands of expert employees behind it.
  - bluedino 6y ago
    There are bugs that will show up on certain x86 that won't show up on ARM. Plus you've got things like code that is already built that you'll have to emulate in some way or another.
  - ryanong 6y ago
    pro audio tends to be a lot more low level to prevent any kind of stuttering or delay, so it may not always be compatible across stacks. It also tends to not get updated very often. You create 1 plugin for ableton, then the creator has moved on to the next project.
  - dx034 6y ago
    Cross compiling is more for supporting more platforms with minimal or no code changes. If you develop applications that will always just run on x86, developing and testing them on another platform doesn't make much sense in my opinion. You might have to compromise just because of your development environment and errors could be caught too late.
  - drewg123 6y ago
    There can be subtle bugs, especially if you have code which has to adhere to a strict on-disk or on-network format. I recently committed a change to FreeBSD's kernel (written in C) which I'd tested on amd64 and x86. Much to my surprise, when I did the cross-build for all platforms, I had a compile-time assert fail on 32-bit arm because the size of a struct was too large. It turns out that 32-bit arm (at least on FreeBSD) naturally aligns 8 byte data types to 8 byte boundaries, whereas x86 packs them and allows them to straddle the 8 byte boundary. This left a 4-byte hole in my struct, and caused it to be 4 byte too large. These are the sorts of things that bite you when moving from x86/x86_64 to a risc platform, even when its the same endian.
    - saagarjha 6y ago
      If you care about the packing of your struct, then you should probably be using compiler-specific packing attributes.
  - DeathArrow 6y ago
    Here is Linus Torvalds explaining why cross-development isn't great: https://www.realworldtech.com/forum/?threadid=183440&curpostid=183486 https://www.realworldtech.com/forum/?threadid=183440&curpost...
- rsynnott 6y ago
  > As a development machine it will be all but useless as you find things that won't compile or work correctly on the new CPU arch. I mean, I suppose it depends on what sort of development you're doing, but in 2020 most libraries do work on ARM. There'll no doubt be a painful period (as there was with the death of PPC), but it shouldn't be that dramatic.
  - dx034 6y ago
    Still, wouldn't you want to test it on the same architecture? It's fine if you just compile on a server but then you can as well have a cheap client with only a web interface.
    - saagarjha 6y ago
      Mobile developers have done this for years; I don't really see how testing it on your local machine can really tell you much other than "it compiles and seems to run" if you're actually going to run it on completely different hardware.
- Unklejoe 6y ago
  I feel like this will be an easier migration from a software perspective. At least both architectures are 64 bit little endian, so all those buggy C programs that do illegal type casting might still work. One issue might be that X86 is pretty relaxed when it comes to unaligned memory accesses. I'm not sure how ARM64 handles it.
  - saagarjha 6y ago
    It's slower but generally will not trap unless the processor is set to do so.
- grishka 6y ago
  Also virtual machines. Depending on what kind of development you do, those are indispensable in some cases. Does ARM have the same kind of hardware virtualization x86 has?
- whywhywhywhy 6y ago
  > The 64-bit move already decimated the professional audio space Every architecture switch has casualties, what I feel might be shortsighted by Apple this time is the x86 Cocoa apps that die this time are not going to be replaced by Catalyst iPad ports or ARM builds, they'll be replaced with Electron apps.
  - ben-schaaf 6y ago
    Apps that die from these kinds of switches tend to keep users that don't have a choice from upgrading at all. There's still people running PPC macs.
- mark_l_watson 6y ago
  I worry about legacy apps also, specifically the professional version of LispWorks. I expect a version for Apple’s new systems will be available, but that will be another $3k for a new license. Oh well.
- Corrado 6y ago
  I have a hard time feeling sorry for companies that are still churning out 32-bit software. The move to 64-bit wasn't a surprise to anyone that was paying attention. If the pro audio space is really decimated then I'm not sure they were that hardy to begin with. Granted, the move to ARM is a bit more work, but again I don't think anyone should be especially surprised by it. As soon as the "A" processors started posting real, positive benchmark numbers I figured that Apple would move to them and away from Intel. In my minds eye I can see Apple differentiating machines depending on how many ARM chips it has. MacBook Air - 2 A15; MacBook - 4 A15X; MacBook Pro - 12 A15X; Mac - 128 A16X (or something like that)
  - mikestew 6y ago
    I have a hard time feeling sorry for companies that are still churning out 32-bit software. A lack of sympathy does not make my audio software work, however. And I believe what parent is driving at is that should the ARM transition take place, even more stuff isn't going to work for the end-user. So a little empathy for the user, eh?
    - Corrado 6y ago
      I meant no offense to the user and have myself been the victim of using old, unsupported software (ie. I play TF2). The point I was trying to make is that companies can't expect the world to stop changing and advancing just because they don't want to build new things. AFAIK there is no computational reason that any software can't be made 64-bit (within reason). We've moved on from 8-bit and 16-bit software; what's stopping them from leaving 32-bit behind? When I hear that some group (ie. pro audio software makers) won't update their offerings I have to believe it's because they don't want to or they just don't want to serve the market anymore. In either case it seems like there is an opportunity for someone to create an alternative, and possibly make some great money.
      - qppo 6y ago
        Those companies aren't around anymore. There's no one left to update the software, and like vintage gear, it's irreplaceable.
- jonplackett 6y ago
  I'll bet there's a lot happening under the hood with xcode that means any app in the Appstore today is going to 'just work' with an arm chip without the dev having to do a thing. Anything external will suffer, and apple probably aren't gonna cry about that.
  - saagarjha 6y ago
    Xcode is not doing much in this direction at all.
    - jonplackett 6y ago
      how can you be so sure what they're working on?
Finnucane 6y ago
At that time, it probably made more strategic sense for Apple to move to 'commodity' hardware and away from relying on Motorola. The success of iphone, ipad, etc., and Apple's huge cash pile puts them in a completely different position now. They aren't going against the mainstream; they are the mainstream.
markdog12 6y ago
Windows 10 runs on ARM https://docs.microsoft.com/en-us/windows/arm/ https://docs.microsoft.com/en-us/windows/arm/
DeathArrow 6y ago
>my PPC Mac mini was more performant than the first Intel mini by far That's true only if "Apple using CPU I deem cool" counts as performance. Otherwise, benchmarks say that first Intel Mac Mini was almost twice as fast than the latest Mac Mini with PowerPC. https://www.geekbench.com/blog/2009/01/mac-performance-january-2009/ https://www.geekbench.com/blog/2009/01/mac-performance-janua...
- morganvachon 6y ago
  CPU speed alone doesn't indicate overall system performance, nor do synthetic benchmarks. The PPC mini had a discrete GPU with dedicated RAM, and OS X at that time was mature on the platform and very performant. The first Intel mini was a Core Solo machine that was horribly underpowered, had Intel GMA 950 graphics not even powerful enough to properly render QE/CI without stuttering, and was hobbled by a very slow system bus. Intel Macs didn't start performing better than their PPC counterparts until Lion was released and the second generation of Core 2 CPUs with faster system bus and higher clock speeds came about. I get the point you're trying to make, but unless you owned both the last PPC mini and the first Intel mini at the same time, as I did in 2006 (and still do), you have no idea what you're talking about.

nvarsj 6y ago

> I have a feeling the new Macs will be worth a look for anyone without hard requirements for Windows 10 Not just that - but the many, many legacy apps professionals rely on. The 64-bit move already decimated the professional audio space. The cynic in me can't help but see this as a move towards pure consumer device. As a development machine it will be all but useless as you find things that won't compile or work correctly on the new CPU arch.

morganvachon 6y ago
> As a development machine it will be all but useless as you find things that won't compile or work correctly on the new CPU arch. I'm not a developer so forgive my ignorance, but isn't this what cross-compiling is for? I get that compiling natively can increase performance and find obscure hardware issues, but it's my understanding that, for example, ARM builds of GNU/Linux binaries are just cross-compiled by server farms that are also natively compiling the AMD64 builds. Also, fat binaries and JIT emulation have been a thing forever, especially for Apple who has dealt with these changes twice now (68k -> PPC -> x86-64). I just don't see this being any different than current multi-platform efforts like Debian, NetBSD, etc., except it's a for-profit company with billions of dollars and thousands of expert employees behind it.
- bluedino 6y ago
  There are bugs that will show up on certain x86 that won't show up on ARM. Plus you've got things like code that is already built that you'll have to emulate in some way or another.
- ryanong 6y ago
  pro audio tends to be a lot more low level to prevent any kind of stuttering or delay, so it may not always be compatible across stacks. It also tends to not get updated very often. You create 1 plugin for ableton, then the creator has moved on to the next project.
- dx034 6y ago
  Cross compiling is more for supporting more platforms with minimal or no code changes. If you develop applications that will always just run on x86, developing and testing them on another platform doesn't make much sense in my opinion. You might have to compromise just because of your development environment and errors could be caught too late.
- drewg123 6y ago
  There can be subtle bugs, especially if you have code which has to adhere to a strict on-disk or on-network format. I recently committed a change to FreeBSD's kernel (written in C) which I'd tested on amd64 and x86. Much to my surprise, when I did the cross-build for all platforms, I had a compile-time assert fail on 32-bit arm because the size of a struct was too large. It turns out that 32-bit arm (at least on FreeBSD) naturally aligns 8 byte data types to 8 byte boundaries, whereas x86 packs them and allows them to straddle the 8 byte boundary. This left a 4-byte hole in my struct, and caused it to be 4 byte too large. These are the sorts of things that bite you when moving from x86/x86_64 to a risc platform, even when its the same endian.
  - saagarjha 6y ago
    If you care about the packing of your struct, then you should probably be using compiler-specific packing attributes.
- DeathArrow 6y ago
  Here is Linus Torvalds explaining why cross-development isn't great: https://www.realworldtech.com/forum/?threadid=183440&curpostid=183486 https://www.realworldtech.com/forum/?threadid=183440&curpost...
rsynnott 6y ago
> As a development machine it will be all but useless as you find things that won't compile or work correctly on the new CPU arch. I mean, I suppose it depends on what sort of development you're doing, but in 2020 most libraries do work on ARM. There'll no doubt be a painful period (as there was with the death of PPC), but it shouldn't be that dramatic.
- dx034 6y ago
  Still, wouldn't you want to test it on the same architecture? It's fine if you just compile on a server but then you can as well have a cheap client with only a web interface.
  - saagarjha 6y ago
    Mobile developers have done this for years; I don't really see how testing it on your local machine can really tell you much other than "it compiles and seems to run" if you're actually going to run it on completely different hardware.
Unklejoe 6y ago
I feel like this will be an easier migration from a software perspective. At least both architectures are 64 bit little endian, so all those buggy C programs that do illegal type casting might still work. One issue might be that X86 is pretty relaxed when it comes to unaligned memory accesses. I'm not sure how ARM64 handles it.
- saagarjha 6y ago
  It's slower but generally will not trap unless the processor is set to do so.
grishka 6y ago
Also virtual machines. Depending on what kind of development you do, those are indispensable in some cases. Does ARM have the same kind of hardware virtualization x86 has?
whywhywhywhy 6y ago
> The 64-bit move already decimated the professional audio space Every architecture switch has casualties, what I feel might be shortsighted by Apple this time is the x86 Cocoa apps that die this time are not going to be replaced by Catalyst iPad ports or ARM builds, they'll be replaced with Electron apps.
- ben-schaaf 6y ago
  Apps that die from these kinds of switches tend to keep users that don't have a choice from upgrading at all. There's still people running PPC macs.
mark_l_watson 6y ago
I worry about legacy apps also, specifically the professional version of LispWorks. I expect a version for Apple’s new systems will be available, but that will be another $3k for a new license. Oh well.
Corrado 6y ago
I have a hard time feeling sorry for companies that are still churning out 32-bit software. The move to 64-bit wasn't a surprise to anyone that was paying attention. If the pro audio space is really decimated then I'm not sure they were that hardy to begin with. Granted, the move to ARM is a bit more work, but again I don't think anyone should be especially surprised by it. As soon as the "A" processors started posting real, positive benchmark numbers I figured that Apple would move to them and away from Intel. In my minds eye I can see Apple differentiating machines depending on how many ARM chips it has. MacBook Air - 2 A15; MacBook - 4 A15X; MacBook Pro - 12 A15X; Mac - 128 A16X (or something like that)
- mikestew 6y ago
  I have a hard time feeling sorry for companies that are still churning out 32-bit software. A lack of sympathy does not make my audio software work, however. And I believe what parent is driving at is that should the ARM transition take place, even more stuff isn't going to work for the end-user. So a little empathy for the user, eh?
  - Corrado 6y ago
    I meant no offense to the user and have myself been the victim of using old, unsupported software (ie. I play TF2). The point I was trying to make is that companies can't expect the world to stop changing and advancing just because they don't want to build new things. AFAIK there is no computational reason that any software can't be made 64-bit (within reason). We've moved on from 8-bit and 16-bit software; what's stopping them from leaving 32-bit behind? When I hear that some group (ie. pro audio software makers) won't update their offerings I have to believe it's because they don't want to or they just don't want to serve the market anymore. In either case it seems like there is an opportunity for someone to create an alternative, and possibly make some great money.
    - qppo 6y ago
      Those companies aren't around anymore. There's no one left to update the software, and like vintage gear, it's irreplaceable.
jonplackett 6y ago
I'll bet there's a lot happening under the hood with xcode that means any app in the Appstore today is going to 'just work' with an arm chip without the dev having to do a thing. Anything external will suffer, and apple probably aren't gonna cry about that.
- saagarjha 6y ago
  Xcode is not doing much in this direction at all.
  - jonplackett 6y ago
    how can you be so sure what they're working on?

Finnucane 6y ago

At that time, it probably made more strategic sense for Apple to move to 'commodity' hardware and away from relying on Motorola. The success of iphone, ipad, etc., and Apple's huge cash pile puts them in a completely different position now. They aren't going against the mainstream; they are the mainstream.

markdog12 6y ago

Windows 10 runs on ARM https://docs.microsoft.com/en-us/windows/arm/ https://docs.microsoft.com/en-us/windows/arm/

DeathArrow 6y ago

>my PPC Mac mini was more performant than the first Intel mini by far That's true only if "Apple using CPU I deem cool" counts as performance. Otherwise, benchmarks say that first Intel Mac Mini was almost twice as fast than the latest Mac Mini with PowerPC. https://www.geekbench.com/blog/2009/01/mac-performance-january-2009/ https://www.geekbench.com/blog/2009/01/mac-performance-janua...

morganvachon 6y ago
CPU speed alone doesn't indicate overall system performance, nor do synthetic benchmarks. The PPC mini had a discrete GPU with dedicated RAM, and OS X at that time was mature on the platform and very performant. The first Intel mini was a Core Solo machine that was horribly underpowered, had Intel GMA 950 graphics not even powerful enough to properly render QE/CI without stuttering, and was hobbled by a very slow system bus. Intel Macs didn't start performing better than their PPC counterparts until Lion was released and the second generation of Core 2 CPUs with faster system bus and higher clock speeds came about. I get the point you're trying to make, but unless you owned both the last PPC mini and the first Intel mini at the same time, as I did in 2006 (and still do), you have no idea what you're talking about.