Devs need to optimise the M1 to get the most out of it!

[Kung gu]

This video shows the M1 beating Ryzen 9 5900HX ASUS ROG Strix SCAR 15 at opening Photoshop.
The M1 starts photoshop (M1 native) faster than a Ryzen 9 5900HX. Just look at the speed.

Note This M1 Native photoshop.

This shows that if Devs put in the effort like Adobe did. The M1 will be faster at opening apps.

AMD Ryzen 9 5800HX is AMDs best APU and should have the best single core pref of any AMD's laptop CPU.

 

[ArPe]

Who cares how fast apps open anymore? Photoshop took 10-15 secs to open back in the PowerPC days and that was when it had less features and power.

 

[thekev]

Loading times are not that big of a deal with this kind of software. They're one of the few places where you will really notice differences in ssd performance. The rest of it is not that different. On playback, he mentions that using either the gpu or an intel cpu due to quicksync would even it out.

As for optimization, low level stuff becomes impractical as the number of architectures you must support grows. I would say they should stick to Apple's interfaces (eg Accelerate) where possible. Aside from this, Clang and LLVM have gotten exceptionally good at optimizing a number of inner loop patterns. It's amazing how far it has come over the last couple releases. I'm much more against low level manual optimization than I used to be, just because it's becoming less tenable for diminishing benefit.

 

[leman]

There are very few situations where it pays of to “optimize for M1” specifically. If you use GPU for example you might achieve better efficiency by utilizing certain Apple Silicon features explicitly.

Most of the time, “optimizing” means simply following Apple guidelines and using appropriate frameworks where required. In other words, optimizing for M1 is no different than optimizing for Intel. Especially if you talk about app load time (and really people, that’s not a measure of system performance - that’s a measure of app behavior).

 

[NotTooLate]

There are very few situations where it pays of to “optimize for M1” specifically. If you use GPU for example you might achieve better efficiency by utilizing certain Apple Silicon features explicitly.

Most of the time, “optimizing” means simply following Apple guidelines and using appropriate frameworks where required. In other words, optimizing for M1 is no different than optimizing for Intel. Especially if you talk about app load time (and really people, that’s not a measure of system performance - that’s a measure of app behavior).

This is an important point to make , there is a difference between "Native support" and optimization , "Native support" means they no longer need Rosetta to work (usually simple enough to do) , optimization on the other hand is usually harder to accomplish , as you need a better understanding of the frameworks and API`s , but that takes time and money and the ROI may not be that big (depending on the application).

regarding app load time being a measure of system performance , most def there is an aspect of performance there , mainly SSD & DRAM BW & Cache speeds (I suspect that in App loading we mostly bottlenecked by our SSD speed)

 

[leman]

regarding app load time being a measure of system performance , most def there is an aspect of performance there , mainly SSD & DRAM BW & Cache speeds (I suspect that in App loading we mostly bottlenecked by our SSD speed)

Aspect of performance, sure, but a fairly insignificant one. A modern SSD can load a multi-megabyte application image and data faster than you can blink. That's not the bottleneck. Now, verification, relocation, linking, registration, initialization, app-specific behavior — those are potentially expensive things that can impact loading times a lot. You can try to compare aspects of two otherwise identically configured machines by timing how long it takes them to start certain software, but you can never be sure what exactly are you measuring. Does the certificate on one of the machines need to be refreshed? Is the app on the other one randomly checking for updates on startup? Did the internal clock on one machine hit a magic number that makes the copy of the app invalidate it's caches? There are so many things that cannot be controlled reasonably...

 

[NotTooLate]

Aspect of performance, sure, but a fairly insignificant one. A modern SSD can load a multi-megabyte application image and data faster than you can blink. That's not the bottleneck. Now, verification, relocation, linking, registration, initialization, app-specific behavior — those are potentially expensive things that can impact loading times a lot. You can try to compare aspects of two otherwise identically configured machines by timing how long it takes them to start certain software, but you can never be sure what exactly are you measuring. Does the certificate on one of the machines need to be refreshed? Is the app on the other one randomly checking for updates on startup? Did the internal clock on one machine hit a magic number that makes the copy of the app invalidate it's caches? There are so many things that cannot be controlled reasonably...

I guess the better way is to run this "test" on MacOS , Intel vs M1 and see the difference , that should eliminate most of the things you've listed , I will disregard the internal clock reason as being 1 in a lifetime occurrence , the rest make sense (I am a HW engineer , so ill give you the credit as a poster I like to read in the different threads that your points make more sense from a SW POV ).

Just to make sure I understand your underlying point , you suggest that app opening/loading (unlike the actual app performance) will not vary between different HW`s and the differences will be due to SW implementation of both OS and App ?

 

[leman]

I guess the better way is to run this "test" on MacOS , Intel vs M1 and see the difference , that should eliminate most of the things you've listed

It still won't eliminate factors like certificate caches etc. but I agree that it might be a relevant way to compare the platforms (if done properly, e.g. multiple measures with regression).

Just to make sure I understand your underlying point , you suggest that app opening/loading (unlike the actual app performance) will not vary between different HW`s and the differences will be due to SW implementation of both OS and App ?

No, what I am trying to say that there are so many factors in how fast the app loads that it is very difficult to disentangle between the hardware and software. I also think that software implementation plays a much larger role here.

A simple exercise: time how long it takes to load a large file into memory and time how long it takes to load an application of a similar size — then look at the software overhead. Linux people for example like to boast that spawning a process is extremely fast on their platform (which is true), but Linux has to do significantly less work to load an app (no validation, no sandboxing, no always-on filesystem monitoring etc.)

 

[jerryk]

Not too worried about startup time and that can be gamed easily, just only load minimal features initially load the rest in the background.

 

[Gnattu]

No, what I am trying to say that there are so many factors in how fast the app loads that it is very difficult to disentangle between the hardware and software.

Exactly. Application startup time could be significantly impacted solely by different type of filesystems on the same machine. A better filesystem may make your app to launch more than 10 times faster on a fast SSD, and filesystem is, of cause, a software factor.

This is also an example that there are so many behaviors that the app developers cannot control as most applications runs in a highly abstracted environment already. There are some extreme cases the optimization is feasible on lower-level, but "app start-up time" is not one of them. Crypto algorithms implemented in assembly, databases using the raw disk without a filesystem, these are the correct usage of lower-level optimization.