10 ms·

Here's one data point: a WebKit compile took 25min on the Air vs 20min on the Mini/Pro. That 25min is still a bit faster than the Intel 16-inch Pro, which took

• tonyhb 6y ago
  This is insane perf/watt. x86 backwards compatibility may have gotten us to where we are, but it's certainly holding it back. Arm is looking great, and maybe it's time for x86 to die.
  • JAlexoid 6y ago
    It's time for Intel and x86 to die. But I would also be a little wary, because ARM systems are way more locked down than x86 systems today.
    • comeonseriously 6y ago
      Why does Intel need to die? Sure they're not exactly the company they used to be, but would it be enough for them to just move away from x86? I'm just thinking I don't want just one or two or three companies doing procs.
      • ashtonkem 6y ago
        They don't need to die, but if they don't begin to compete they simple will die.
      • JAlexoid 6y ago
        Resource allocation. Intel dying would free up resources for development by other companies.
      • AmericanChopper 6y ago
        Intel stagnated and at the same time started implementing some rather anti-consumer practices. This allowed AMD to take the performance lead off them with their latest generation of products. It’s fantastic that the market for processors is so competitive. I’ve grown to not like Intel very much recently, but I’m glad they’re here. They’ll keep the pressure on for further innovation, so AMD will either need to keep up or be overtaken again. Either of which is a good outcome for consumers.
    • vmception 6y ago
      Is some of this because of those processor level flaws/exploits where the fixes resulted in disabling some processor commands making them slower and less efficient With only a completely new/different architecture getting those advances back?
    • StreamBright 6y ago
      Absolutely not. We need more competition because the #1 reason we got to this situation is mono culture and a single platform (x86). We need Apple to succeed of creating an alternative ARM based desktop/laptop platform and for more competition we could add in Mips64 from China to the mix. I am really hoping that by 2025 we are going to have 3 major platforms available for end customers, so that there is real competition.
      • Hamuko 6y ago
        Isn't having a whole bunch of different processor architectures at the same time kind of bad for end-users?
        • spijdar 6y ago
          This really depends. Once-upon-a-time, at least in the UNIX (tm) world, there were a plethora of ISAs, and this was the environment where ideas like Java really made sense. Write once, run anywhere. Most OSes are still pretty well situated to handle this. Java remains, and is easily cross platform. I can run Java-based proprietary games like Minecraft on my POWER9 desktop, despite no-one involved probably ever considering ppc64le a valid target. The CLR on Windows is also pretty easily cross-platform, although it won't help legacy x86 PE executables. Apple has solved this for ages on the tooling side, encouraging production of "fat" binaries with many arches since OS X was NeXT, and your .app packages needed to run on x86 + m68k + SPARC + PA-RISC. Emulators like Rosetta (and qemu's usermode emulation) can fill the gap of legacy executables, while these other technologies can make the end-user experience good. Of course, that's only if a) someone writes your platform's equivalent of Rosetta, and b) developers write crossplatform apps. So, the answer depends on how cynical or optimistic you are :-)
        • pabs3 6y ago
          The experience in Linux distros is that extra arches surface bugs that other arches paper over, leading to higher quality software. For example unaligned memory access is slower on some arches but causes crashes on other ones.
      • JAlexoid 6y ago
    • totalZero 6y ago
      It's time for tick-tock to die and Moore's Law to stop being the guiding light of Intel management. Instead, they should set up two groups: one to generate new architectures for desktop and server, and another to take the best features of those architectures and make them thermally efficient for use in laptops. The development of these two products should be unconstrained by time, because as we have seen, impossible deadlines delay the possible. In the past 10 years, most of the chips that amaze me have simply done what was already possible, just with enough thermal efficiency that they can be placed in mobile devices. Intel dying would be horrible for the world. They have so much institutional knowledge...
  • Wowfunhappy 6y ago
    And that backwards compatibility may not even be necessary, given Rosetta's performance. Sure Apple is using lots of tricks, but if Microsoft or any Linux project could get even somewhat close...
    • romanoderoma 6y ago
      Just as testimony, it probably doesn't mean much, but bakcwards compatibility you either have it or you don't, there's no middle ground Apple is one of the most capitalistic companies out there, they want you to buy new stuff and they'll try everything they can to force users to upgrade sooner or later The story is this: a friend of mine is a well respected illustrator and he has been a long time Mac user (at least since I remember) Few days ago he asked me advices about a new laptop and he asked for a PC because "new Mac OS will not work with my Photoshop version" He owns a license for Photoshop 6, payed for it and has no need to uograde, especially to the new subscription based licensing MacOS Sierra doesn't even work with Photoshop CS6 The only option he had to keep using something he owned was to switch platform (Adobe allows platform change upon request) End of story. Backwards compatibility has no value until you need it. Just like an ambulance or a pacemaker.
      • Wowfunhappy 6y ago
        I've used Photoshop CS6 on both Sierra and High Sierra. It's ever-so-slightly more crash-prone than on older OS's, but totally usable. It launches on Mojave as well, so I'm pretty sure it works, but I haven't personally used it for any length of time. Catalina is what killed it. IMO, backwards compatibility in OSX/macOS was perfectly decent for a long time. Most software compiled for Intel that wasn't doing something weird continued to chug on, frequently with significant glitches but not to the point where the software was unusable. Then in Catalina Apple just gave up or something.
        • klelatti 6y ago
          It's odd isn't it because if they invested a little bit in Catalina and Rosetta they could probably have had a great backwards compatibility story even in a few years time - but it's just not in the DNA I guess.
  • asimpletune 6y ago
    Honest question. Does the ISA, as a language, really matter? Or is it more a by product of who owns the ISA, eg intel sucks, arm is more liberally licensed. I used to work at intel, and no one I knew there thought ISA mattered at all. That’s just a few people though, so I’m curious if people think there’s something better or worse about the different ISAs as a technology in their own right, or if it’s more about the business interests behind them that matters.
    • sudosysgen 6y ago
      It really doesn't. AMD has essentially the same perf/watt coming in a few months. ISA doesn't change anything nowadays because it all gets decoded into a per-CPU specific actual instruction set anyways.
      • spear 6y ago
        Exactly right. With today's transistor budgets, the x86 ISA decoder/translator is just noise. This is not the difference between x86 and ARM -- it's the difference between Intel's team and Apple's (also AMD's). You don't see Qualcomm being competitive even though they also use ARM.
      • SomeoneFromCA 6y ago
        This is not correct actually. Simpler ISA often requires bigger instruction caches, but consumes less energy because of simpler decoding logic. VLIW theoretically can be super efficient, because it discards decoding stage altogether.
        • sudosysgen 6y ago
          In theory, yes. This is the case when you have small cores, which is why a lot of GPUs used VLIW. But in practice the whole decoder stage is basically a rounding error because cores got so big.
      • headeffects 6y ago
        What does AMD have coming in a few months?
• nwlieb 6y ago
  Is this a 1-1 comparison? If the ARM compile is compiling to ARM binaries then there might be less work/optimizations since it is a newer architecture. Seems like a test with two variables that changed. Would be interesting to see them both cross-compile to their respective opposite archs.
  • attractivechaos 6y ago
    Apple has been optimizing the compiler for a decade for iOS.
  • mlyle 6y ago
    Maybe not, but A) it's close-- most of the work of compiling is not microarchitecture-level optimizations or emitting code, and B) if you're a developer, even if some of the advantage is being on an architecture that it's easier to emit code for... that's still a benefit you realize. It's worth noting that cross-compiling is definitely harder in many ways, because you can't always evaluate constant expressions easily at compile-time in the same way your runtime code will, etc, too, and have to jump through hoops.
    • throwaway894345 6y ago
      As someone who knows relatively little about this, I'm very curious why this is downvoted. It seems like a rebuttal would be enlightening.
    • marmaduke 6y ago
      Hm my experience was that compiling C on arm was always super fast compared to x86, because the latter had much more work to do.
      • mlyle 6y ago
        This doesn't align with my experience. Clang is about the same, but GCC often seems much slower emitting cross-ARM code. jar% time x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I 0.97s user 0.02s system 99% cpu 0.992 total jar% time x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I 0.93s user 0.03s system 99% cpu 0.965 total jar% time x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I 0.94s user 0.01s system 99% cpu 0.947 total jar% time x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I 0.92s user 0.04s system 99% cpu 0.955 total jar% time arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I 1.43s user 0.03s system 99% cpu 1.458 total jar% time arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I 1.46s user 0.03s system 99% cpu 1.486 total jar% time arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I 1.55s user 0.04s system 99% cpu 1.587 total jar% time arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I 1.44s user 0.03s system 99% cpu 1.471 total
• tpetry 6y ago
  The interesting information after which time the air was throttled and how much performance is lost when throttling.
  • ch_sm 6y ago
    Several tests seem to show it throttling after the 8.5-9 minute mark.
• zaroth 6y ago
  How is that anything less than mind blowing? Twice as fast, using 1/10th the battery life.... and that’s for a part that costs Apple $70 instead of, what, $400?
  • bengale 6y ago
    Can you imagine how frustrating it must have been at Apple knowing what you had and having to deal with intel’s crap over the last year or two.