8 ms·

> 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 profess

by nvarsj 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y ago
    If you care about the packing of your struct, then you should probably be using compiler-specific packing attributes.
- DeathArrow 7y 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 7y 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 7y 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 7y 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 7y 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 7y ago
  It's slower but generally will not trap unless the processor is set to do so.
grishka 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y ago
      Those companies aren't around anymore. There's no one left to update the software, and like vintage gear, it's irreplaceable.
jonplackett 7y 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 7y ago
  Xcode is not doing much in this direction at all.
  - jonplackett 7y ago
    how can you be so sure what they're working on?

by nvarsj 7y ago

morganvachon 7y 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 7y 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 7y 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 7y 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 7y 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 7y ago
  If you care about the packing of your struct, then you should probably be using compiler-specific packing attributes.
DeathArrow 7y 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 7y 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 7y 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 7y 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 7y 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 7y ago
It's slower but generally will not trap unless the processor is set to do so.

grishka 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y ago
    Those companies aren't around anymore. There's no one left to update the software, and like vintage gear, it's irreplaceable.

jonplackett 7y 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 7y ago
Xcode is not doing much in this direction at all.
- jonplackett 7y ago
  how can you be so sure what they're working on?