Announcement

Collapse
No announcement yet.

A Fresh Look At The Asahi Linux Performance On Apple's M2

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Chol
    replied
    Originally posted by ostree shill View Post
    People leaving Twitter for Mastodon because Twitter is too toxic ... only to make toxic accusations on Mastodon.
    @[email protected] So, #Phoronix still doesn't know how to benchmark properly and still publishes half-assed articles just for the sake of a good headline... Nothing new here, but still disappointing.

    Leave a comment:


  • ostree shill
    replied
    Hector Martin commented for this:
    So Phoronix put out an article saying Asahi Linux got slower over the past few months, but I tried a few tests that supposedly regressed and I cannot reproduce it. For example, on ALS movie lens, his results are 7581 and 12132. I got 7615 on my M2 Air (less is better). On zstd comp L3 long, he got 265 -> 245, I got 278 (more is better). L3 short, 3620 -> 3420, I got 3567 (more is better). GIMP unsharp-mask, 14.97 -> 18.97, I got 14.93 (less is better). I'm not sure where the variance comes from, but I don't have a whole lot of confidence in his results. If you identify a specific regression traceable to e.g. specific kernel versions, please let us know - but otherwise take Phoronix' results with a grain of salt. I did notice that a lot of the tests I was running (that supposedly regressed) were ostensibly CPU tests and were spawning >8 threads but then not able to use all 8 CPUs fully (sometimes only 50% or less), which is unexpected for a well-designed CPU-bound test. That tells me there are synchronization issues or other problems that prevent the tests from fully utilizing the hardware. This is even more important on big.LITTLE platforms, since you can end up with the OS scheduling critical threads on the efficiency cores that end up blocking the performance cores (the OS has no way of knowing which threads will take more time or are the critical ones, to put them on the faster cores). When you have stuff like that going on, it can add a lot of uncertainty and noise to your measurements. Also remember that the M2 Air is a fanless machine and therefore affected by ambient temperature, surface, and surrounding airflow, since it can throttle when fully utilized. Edit: I could repro the cryptsetup PBKDF2-sha512 post-regression results. That one uses system cryptsetup, so it's likely a code/compiler change that legitimately regressed performance of that binary in Arch Linux ARM, nothing to do with our kernels or anything Asahi-specific.

    Leave a comment:


  • Alexmitter
    replied
    Originally posted by anarki2 View Post

    Not in the slightest, the dude just mentioned earlier that there's a generic regression trend in current Linux kernel releases, so it has nothing to do with Apple. I'm sorry it won't fit your narrative this time
    You misunderstood him, he did not doubt the regression in Linux, he just pointed out that there is also a performance regression on new OSX versions. But that is nothing new for apple, it also effected MacOS, 9.2 was very slow on my G3.

    Leave a comment:


  • elatllat
    replied
    > arguably most interesting once there is working mainline graphics acceleration support

    > Video Decoder TBA
    ​​

    Leave a comment:


  • sarmad
    replied
    Originally posted by ferry View Post
    They should rewrite everything in Rust.
    You forgot to add /s

    Leave a comment:


  • anarki2
    replied
    Originally posted by spiral_23 View Post
    seems - linux has the same problems on apple hardware like apple has - with every software-update it gets slower! - this is no joke for apple users - but for linux there is hope - the asahi - linux developers will find the glitch which lead to this regression soon - i think - if they not allready had - when they saw your performance analyse. so i am looking forward on this cool project on apple - arm - hardware!
    Not in the slightest, the dude just mentioned earlier that there's a generic regression trend in current Linux kernel releases, so it has nothing to do with Apple. I'm sorry it won't fit your narrative this time

    Leave a comment:


  • vegabook
    replied
    Would be interesting to see the benchmarks vs MacOS; I'm assuming the Test Suite would (mostly) work given the Posix compliance, but even a subset would be very interesting.

    Leave a comment:


  • dragorth
    replied
    Honestly, this is to be expected. You first get things to run, then make it work as expected, then you optimize. When you get things to run, you are usually doing this so wrong that high variable performance is to be expected. Once you start fixing those things, the likelihood your first pass is going to be faster than broken is very low. It does happen, but rarely. Then you can start optimizing for performance.

    Leave a comment:


  • spiral_23
    replied
    seems - linux has the same problems on apple hardware like apple has - with every software-update it gets slower! - this is no joke for apple users - but for linux there is hope - the asahi - linux developers will find the glitch which lead to this regression soon - i think - if they not allready had - when they saw your performance analyse. so i am looking forward on this cool project on apple - arm - hardware!

    Leave a comment:


  • ferry
    replied
    They should rewrite everything in Rust.

    Leave a comment:

Working...
X