10 best mechanical keyboards for gaming, typing, and working (2021)

they are worse natively than in versions for Intel



One of the things that was assumed when Apple announced its transition from Intel x86 processors to Apple Silicon ARM64 is that some performance in unadapted applications would be lost along the way. Thanks to Rosetta's translation layer, the loss is relatively small, a 20% compared to native code.



However, in addition to slower performance, non-native applications on Apple's M1 chip they may malfunction or may not work at all, so it is always appreciated that they are updated with support for Apple silicon. Adobe with Lightroom and the developers at Handbrake (with a beta) have been in a rush to have important applications ready for new machines, but to our surprise, they have done so with less performance.





Disappointing results in two of our tests




Apple M1 Revolution



In general, the results of the M1 with native code are spectacular, but when we tested the optimized version of Lightroom we experienced something very strange: the M1 performed much less than Intel Macs with dual-core processors of years ago.



So I opted to open Lighroom with Rosetta, which is something that can be done with the "Obtain information" option on the executable, so that the code to be executed would be the one intended for Intel and not for the new ones. What Rosetta does is translate the code from Intel to Apple silicon, and automatically, it has managed to do it better than Adobe developers.







Apple M1: anatomy of a revolution





After comparing how long the native version and the Intel version took to generate a panorama with Rosetta, the result left no doubt that something was poorly optimized: the native version is more than twice as slow as Intel. And that slowness feels extreme because, as we said, the performance is worse than that of quite old equipment.




Lighroom



In Handbrake, when converting a video from H.264 to H.265, the experience was similar. Although the time difference between both processes is much less time, better with Intel code in Rosetta mode tells us that something is wrong, because as we said at the beginning, there should be a difference of 20% in favor of the native code, as it happens in many other use cases.




Handbrake 1



What could cause this difference in performance



To understand how it is possible that something like this is possible, we have spoken with Julio César Fernández Muñoz, fellow contributor at Applesfera, Apple-centric developer and Apple Coding trainer.



This is the explanation that Julio gave us about this strange "phenomenon":




When an app is translated with Rosetta (such as Lightroom or HandBrake), the instructions that the system understands to be used for tasks that the M1 solves with its specific chips (such as video encoding) are derived by CPU to this chip. The M1 has a machine learning (ML) based process controller that recognizes the types of instructions coming to it and routes them to the specific chip even if the correct API is not being used. That does very well with the Rosetta translation that is already correctly derived.



The same one that the Intel have and that Adobe repeats: using their own APIs in C ++ for everything, instead of not using the system APIs with process acceleration. Either Adobe imposes it, or it will give us native apps on Apple Silicon that will be slower than translating with Rosetta, ironically.




We hope that, whatever the cause, it is not the trend for the future in applications adapted to Apple silicon. In many others that we have tested, such as browsers or Office, the optimization is great. In other words, this is not an Apple Developer Tools issue, and no developer has ever complained about that particular issue.