Is software going to ruin the advantage the M1 chip has?

[sracer]

We all agree that the M1 chip is amazing. But, objectively speaking, the 7th gen i5 on my work PC should be plenty good enough to run Office and one bespoke piece of software which is, ultimately, a front end to a SQL database. Office and this software run like dogs.

With the M1 giving all this processing headroom will Apple with macOS and other developers just get lazy and in a few years we will end up exactly where we were a year ago, with tremendously powerful machines that are just a bit laggy and sluggish?

Well... as an old dog software developer I'll say that the only reason for the hardware to exist is so that the software can run.

It has been DECADES since software was well designed and tightly written. As hardware became faster and cheaper, there was less justification for taking the extra time needed in improving design and coding. It is easier (and therefore cheaper) to simply cobble code together that works and get it out the door.

Standard frameworks allowed for developers to produce software that was "above their weight" at the expense of performance.

and... err... excuse me a moment... "hey you kids! Get off my keypunch machine!" ?

 

[ADGrant]

Compilers certainly got much better, but no compiler can save you if you are trashing your cache with fragmented allocations and linked lists or using stack unwinding to return a value (yes, people do it). Besides, the question is: what are you optimizing for? Swift is probably the only mainstream language I know that is deliberately optimized for amortized user-facing performance on a shared system — it attempts to reduce pressure on the I-cache by type-erasing generics and optimizing for code size. Basically, your app might run slower, but it will steal less system resources from the rest of the system, meaning the the overall experience is better. Also, Apple's Grand Central Dispatch is a way to do "sane" shared concurrency — you can take advantage of multiple cores without stealing resources from other applications.

In contrast, most "system programming languages" (C++, Rust) monomorphise everything, resulting in huge, greedy apps that run fast but trash the system. The ecosystem of these languages also generally assumes that it's the only important ap running on the system, so they will try to grab everything they can (looking at you Rust async runtimes).

If you want your generics type erased, Java is the language for you (other JVM based languages too). What really kills performance is heap allocation. Both Swift and C++ allow you to use the stack instead. Java (and other JVM languages) not so much. C# is better than Java in this regard but that is a low bar.

However, compared with Javascript they are all good. Unfortunately more and more client applications are being delivered as Web or Electron apps (e.g. MS Teams, Slack, WhatsApp, Skype, Discord, VS Code). What fat bloated pigs those apps are.

 

[827538]

Lots of open source app there isn’t a developers maintain , most Mac apps compiled 10 years ago can not run in latest macOS,
Most 15 years ago windows app still run in win10,

While Windows 10 has some great qualities and its' backwards compatibility is impressive, it's also a bit of a mess of an OS, with a patchwork of code going back decades and supporting an instruction set from the 1970's (x86).
I actually like Apple for the fact they ditch legacy code and instructions so they can make a lean, focused, secure and extremely fast OS. I regularly update my tech and I'm looking forward to the day when it's purely 64bit ARM. I honestly only use Windows for gaming anymore.

64 bit ARM Macs, iPhones, iPads all running Swift based apps built to the latest programming standards and using the best hardware, not chips that still have circuitry dedicated to running ancient software.

 

[827538]

If you want your generics type erased, Java is the language for you (other JVM based languages too). What really kills performance is heap allocation. Both Swift and C++ allow you to use the stack instead. Java (and other JVM languages) not so much. C# is better than Java in this regard but that is a low bar.

However, compared with Javascript they are all good. Unfortunately more and more client applications are being delivered as Web or Electron apps (e.g. MS Teams, Slack, WhatsApp, Skype, Discord, VS Code). What fat bloated pigs those apps are.

Electron is a plague, I love VS Code though, I just wish it was native Swift.

 

[827538]

Dumb thread.....

So far M1 is a screamer even when running Rosetta 2 interpreted software. It has nothing to worry about, and the big programs that matter are rapidly releasing their Universal recompiles (Office, Adobe).

I won't have my own M1 based MacBook until the 14" comes out this year, but even now every single app/program I use on my Mac already has native support for it, it also helped convince me to ditch Photoshop for Affinity.

 

[leman]

If you want your generics type erased, Java is the language for you (other JVM based languages too). What really kills performance is heap allocation. Both Swift and C++ allow you to use the stack instead. Java (and other JVM languages) not so much. C# is better than Java in this regard but that is a low bar.

True. The reason I didn't mention Java is because it's not a compiled language in the strict sense and because it boxes everything. Swift is fairly unique AFAIK in that it's compiled but manages to avoid boxing (at a cost of additional indirections) and does not monomorphize everywhere. C++ and Rust suffer from extreme monomorphization.

However, compared with Javascript they are all good. Unfortunately more and more client applications are being delivered as Web or Electron apps (e.g. MS Teams, Slack, WhatsApp, Skype, Discord, VS Code). What fat bloated pigs those apps are.

Yeah, you and @Krevnik make a good point about Electron. I tend to forget about these technologies because I find them personally offensive

 

[Gerdi]

Swift is fairly unique AFAIK in that it's compiled but manages to avoid boxing (at a cost of additional indirections) and does not monomorphize everywhere. C++ and Rust suffer from extreme monomorphization.

It is totally debatable if something "suffers" from monomorphization - as it is a feature to increase performance in the first place at the expense of code footprint. As long as the programmer has sufficient control - and knows what he is doing - its all fine. This applies in particular to C++.

 

[leman]

It is totally debatable if something "suffers" from monomorphization - as it is a feature to increase performance in the first place at the expense of code footprint.

Sorry, I should have been more careful in my choice of words. Monomorphisation is obviously a great way to maximize performance and it is relatively easy to do. But things become more complicated if we are talking about typical user-facing applications in a multitasking scenario — here one usually cares more about amortized "average" performance and responsiveness more than about peak performance of a single app. Swift optimizes generics for the shared environment (e.g. all apps will use the same sorting function no matter the data type — it is going to be slower, but there will be less I-cache contention -> amortized performance improves). C++ and Rust optimize for a single application instead (which makes them a great choice for high-performance applications among other things).

As long as the programmer has sufficient control - and knows what he is doing - its all fine. This applies in particular to C++.

I completely agree with you — programmer should have he control. Unfortunately, C++ does not give one much control in this particular area. It's either monomorphisation all the way or you have to design your way around it. To be perfectly clear: I am not saying that Swift is better, it's problem is exactly the opposite.

 

[Krevnik]

The “have to design your way around it” is something I’ve seen in a real life. I’ve seen projects that wind up with megabytes of code generated from templates. It’s not pretty, and generally the ones with enough C++ compiler knowledge to sidestep the issues aren’t working on this sort of code, but rather the thornier issues plaguing the project as a whole.

It’s only when you realize templated code is a good fraction of your TEXT segment that someone like that gets brought in to help fix things.

For my part, I like language features and frameworks that let me use more of my mental energy on the app itself, and less on understanding the underlying behaviors of the language/framework. Not having to “design my way around it” is a benefit in itself, IMO. Especially when trying to build stable, consistently performant applications on macOS/iOS.

 

[JMacHack]

We all agree that the M1 chip is amazing. But, objectively speaking, the 7th gen i5 on my work PC should be plenty good enough to run Office and one bespoke piece of software which is, ultimately, a front end to a SQL database. Office and this software run like dogs.

With the M1 giving all this processing headroom will Apple with macOS and other developers just get lazy and in a few years we will end up exactly where we were a year ago, with tremendously powerful machines that are just a bit laggy and sluggish?

Hasn’t this been true for 20 years now?

I don’t see it getting any better anytime soon, regardless of platform. The popular trend is making everything run on electron and not fixing bugs in favor of adding new (useless) features.

 

[Ethosik]

are you running a super-outdated release? Don't forget to pay M$ thousands of dollars to renew your license

Nope! Latest release is still 32 bit!

 

[xraydoc]

We all agree that the M1 chip is amazing. But, objectively speaking, the 7th gen i5 on my work PC should be plenty good enough to run Office and one bespoke piece of software which is, ultimately, a front end to a SQL database. Office and this software run like dogs.

With the M1 giving all this processing headroom will Apple with macOS and other developers just get lazy and in a few years we will end up exactly where we were a year ago, with tremendously powerful machines that are just a bit laggy and sluggish?

I know there's a lot more to this thread, but one could make the argument for every single generation of CPU that comes out. Nothing special about the M1 in this regard. It just happens to be a good amount more efficient than the previous generation but, either way, there's a lot of CPU cycles being wasted on inefficient programming. One could also say the same thing about ever-more-dazzling UI special effects.

 

[dmccloud]

Apple policy made software hard difficult, Apple abandon 32bit app , that’s stupid move, lot of old apps abandoned, macOS is more like iOS, that isn’t right direction,

Not a stupid move at all. Look at all of the issues still affecting Windows because of their continued support of older software. WoA is an even bigger example of why continuing to support older standards can cause more problems than it solves, so that's something to keep in mind as well. Blame the developers who chose not to update their apps despite having years' advance notice, rather than Apple (who gave developers more than sufficient lead time to recompile their apps, and also provided XCode to simplify that process).

 

[ADGrant]

Electron is a plague, I love VS Code though, I just wish it was native Swift.

For light weight editing tasks I prefer Sublime. When I am willing to commit huge quantities of RAM I prefer JetBrains IDEs though I do use Xcode for Apple specific development.

 

[Mac... nificent]

I’m not sure why the OP mentions Office - on my base model M1 MBA it flies like a rocket.

Yep, I don't understand that either. Like yours. mine works perfectly fine.

 

[Andropov]

We all agree that the M1 chip is amazing. But, objectively speaking, the 7th gen i5 on my work PC should be plenty good enough to run Office and one bespoke piece of software which is, ultimately, a front end to a SQL database. Office and this software run like dogs.

With the M1 giving all this processing headroom will Apple with macOS and other developers just get lazy and in a few years we will end up exactly where we were a year ago, with tremendously powerful machines that are just a bit laggy and sluggish?

Developers might have started writing less performant code either way. As of now, the greatest threat to the ecosystem are Electron apps. A lot of big desktop apps are switching to Electron (Spotify, Slack, Outlook...) which means worse performance, a a lot of non-native UI elements and behaviours and atrocious RAM usage. Sometimes by an order of magnitude.

In fact, I remember Microsoft hinting that they were going to switch the entire Office suite to Electron, as if it was a feature, but I can't find the source.

I suspect (although I've been outside the Windows ecosystem for long) that Microsoft knows an ARM transition might be on the near horizon wether they are prepared for it or not. Their past efforts to offer Windows on ARM (Windows RT) failed due to lack of apps built for the platform, despite the push for UWP (Universal Windows Platform) apps to try to make the transition easier. Their emulation software for x64 apps also appears to be inferior to Rosetta. And they are still dragging along the 32-bit support, which makes the transition for native apps even more difficult.

Electron apps solve this problem, since they are essentially web apps and can be ported to any platform with minimal effort, so if most developers switched to Electron apps they would have solved their lack-of-apps for the ARM transition problem, at the expense of 'just' terrible performance and non-native UX. But since this would happen for both x86 and ARM, the transition would be seemingly flawless. So maybe their recent push for Electron apps is just their idea of how to make a transition happen.

(Obviously there are other considerations, like the fact that developing Electron apps is cheaper due to shared code between platforms, but Microsoft is a big corporation, they shouldn't be pushing for 'cheap and mostly OK' apps otherwise).

The bad thing about this is that this idiocy of developing Electron apps will likely spill into the Mac ecosystem.

 

[xraydoc]

Developers might have started writing less performant code either way. As of now, the greatest threat to the ecosystem are Electron apps. A lot of big desktop apps are switching to Electron (Spotify, Slack, Outlook...) which means worse performance, a a lot of non-native UI elements and behaviours and atrocious RAM usage. Sometimes by an order of magnitude.

In fact, I remember Microsoft hinting that they were going to switch the entire Office suite to Electron, as if it was a feature, but I can't find the source.

I suspect (although I've been outside the Windows ecosystem for long) that Microsoft knows an ARM transition might be on the near horizon wether they are prepared for it or not. Their past efforts to offer Windows on ARM (Windows RT) failed due to lack of apps built for the platform, despite the push for UWP (Universal Windows Platform) apps to try to make the transition easier. Their emulation software for x64 apps also appears to be inferior to Rosetta. And they are still dragging along the 32-bit support, which makes the transition for native apps even more difficult.

Electron apps solve this problem, since they are essentially web apps and can be ported to any platform with minimal effort, so if most developers switched to Electron apps they would have solved their lack-of-apps for the ARM transition problem, at the expense of 'just' terrible performance and non-native UX. But since this would happen for both x86 and ARM, the transition would be seemingly flawless. So maybe their recent push for Electron apps is just their idea of how to make a transition happen.

(Obviously there are other considerations, like the fact that developing Electron apps is cheaper due to shared code between platforms, but Microsoft is a big corporation, they shouldn't be pushing for 'cheap and mostly OK' apps otherwise).

The bad thing about this is that this idiocy of developing Electron apps will likely spill into the Mac ecosystem.

While you're right about Electron apps being easy to port to any platform, I gotta think that Microsoft would know how terribly they will perform on their Windows-on-ARM platforms. I can't imagine they'd want to encourage this. Well, then again, it's Microsoft, so thinking things through isn't one of their strengths.

 

[Andropov]

While you're right about Electron apps being easy to port to any platform, I gotta think that Microsoft would know how terribly they will perform on their Windows-on-ARM platforms. I can't imagine they'd want to encourage this. Well, then again, it's Microsoft, so thinking things through isn't one of their strengths.

Well, they sure know, as they have been using Electron for a ton of their own apps. And they don't seem to care, seeing how their selection of Electron apps is growing by the day. If they didn't want to encourage 3rd party devs developing electron apps they wouldn't have used it for so many of their own apps.

 

[satcomer]

Well to me Mac developers over time (especially Shareware developers) are a bunch of scammers! You don’t know how to-get over the fact you just need buy a Mac Mini and download X-Code on it, recompile your code and fix bugs and release it for Big Sur!

 

[Joelist]

Actually their selection of Electron is not growing by the day. They did not do Office in Electron, the M1 version is a properly written and compiled Universal application (and runs beautifully). Also there are rumblings of Apple may be cracking down in the future on Electron and other such tools if they do not output proper Universal code.

 

[jdb8167]

Actually their selection of Electron is not growing by the day. They did not do Office in Electron, the M1 version is a properly written and compiled Universal application (and runs beautifully). Also there are rumblings of Apple may be cracking down in the future on Electron and other such tools if they do not output proper Universal code.

Apple has no real way of “cracking down” on Mac apps unless they are delivered through the Mac App Store. I don’t know if Electron apps are available on the App Store right now.

 

[FNH15]

Apple has no real way of “cracking down” on Mac apps unless they are delivered through the Mac App Store. I don’t know if Electron apps are available on the App Store right now.

Trello is an Electron app, as is Slack, and they’re both on the App Store.
With the advent of AS Macs, however, there are a number of situations where the iOS app is better than it’s “Mac” / Electron counterpart...

 

[Toutou]

you just need buy a Mac Mini and download X-Code on it, recompile your code and fix bugs and release it for Big Sur!

I can tell with absolute certainty that you're not a developer.

 

[Joelist]

Trello is an Electron app, as is Slack, and they’re both on the App Store.
With the advent of AS Macs, however, there are a number of situations where the iOS app is better than it’s “Mac” / Electron counterpart...

Not sure I would still count Slack, as they pretty much rebuilt it from the ground up to fix the memory and performance issues.