For the second benchmark I am going to explore the performance of .NET rendering using an Uno Platform benchmark. As I wrote in this previous post I’m doing a series of benchmarks of .NET and JVM on Apple Silicon. While there are impressive native benchmarks the fact it will be some time before these two runtimes natively support it, I have to factor in the potential hit and problems with Rosetta. How much of a performance hit is there and will it be enough that applications targeting it will have problems? All code and results are published here .
The Uno Platform is a cross platform .NET UI system that allows developers to write cross platform UIs in .NET. It lets you target all desktops (Windows, Mac, and Linux) as well as iOS and Android mobile platforms. There is a performance benchmark called “Dope Test” that was originally created for showing off Flutter performance on various platforms. It’s now been ported to other systems to show off their own performance. The Uno project implemented their own here . It’s pretty simple really. It just blits out a whole bunch of text entries set to “dope” as it can, or modifies it etc. A screenshot of the app is below.
There are three specific tests that it performs in the creation or modification of “dope” screen elements. One tests the building performance, the other tests the binding performance, and the last tests the modification performance. We ran each test for a total of sixty seconds to get an average performance rate for the two platforms. The results are below (longer bars are better):
The full results with tabular data can be found here . As we can see the performance on the M1 MBP system even with it running under Rosetta blows the doors off of the Intel MBP. It’s not even close. It’s literally a 1.5 to 3 times performance improvement. How can that be, especially under emulation? We saw in the JavaFX benchmark that we had a 20-30 percentage point speed hit by running on M1 under Rosetta. I believe this comes down to the fact that the Uno code may be leveraging native components and JavaFX is not. Therefore the Uno code is actually able to leverage the better GPU capabilities of the M1 architecture compared to the Intel graphics chipset in the 2018 laptop. It’s therefore still calling native GPU code rather than running that in emulation. There are some other graphics benchmarks running under Rosetta that have had similar speed improvements because of this factor. This therefore bodes well for native performance .NET on M1 as well as the pure power of the M1 chip from a GPU perspective.
So in conclusion, while there was a slight performance penalty with JavaFX under Rosetta, the Apple Silicon MBP hardware positively screams in comparison to the Intel MBP. The story isn’t all positive when it comes to .NET, as I will get to in another post.