A11 Bionic Chip vs MBP/ Intel?

Discussion in 'MacBook Pro' started by MBX, Sep 16, 2017.

  1. MBX macrumors 68000

    Joined:
    Sep 14, 2006
    #1
    Hi there

    Apparently iPhone X's A11 Bionic CPU is more powerful than the 13'' MBP CPU from Intel. Or is that just on single core benchmark? Any idea?

    If it is more powerful what's stopping Apple to put in the 'Bionic' chip in MacBook's in near future?
     
  2. Adamantoise macrumors 6502a

    Joined:
    Aug 1, 2011
    #2
    Compatibility with Win32/x86 programs?

    You cannot sell a MacBook (or any laptop for that matter) without the ability to run x86 applications, it'll be dead on arrival.
     
  3. MBX thread starter macrumors 68000

    Joined:
    Sep 14, 2006
    #3
    Oh ok.

    I thought maybe Apple could somehow adjust it but I guess too complicated.

    What if Apple includes their own 'Bionic' chip next to Intel's and it would switch like the graphics cards do (integrated vs discrete)?

    Maybe too much.
     
  4. Hippocrates macrumors member

    Joined:
    Jun 12, 2012
    #4
    If the chip made by Apple will exceed the capability of Intel CPU + AMD/NVIDIA GPU some time in the future, the most likely scenario is that people will start to move to iPad Pro (or any suitable future iOS devices) as a productive machine. More professional softwares will be developed for iOS to fully replace the need of MacOS.

    So my guess is Macbook will still be using Intel processor in the interim.
     
  5. Adamantoise macrumors 6502a

    Joined:
    Aug 1, 2011
    #5
    Just to be clear, Apple's A11 chip may not outperform Intel's 45W TDP Kaby Lake processors in real world use cases.
    Synthetic benchmarks paint a very different picture than real world sustained loads where heat robs you of performance.

    Furthermore, to my knowledge, that's not how computing works. You cannot just have an Operating System running on two processors with very different ISAs (instruction set architectures) ... Even if you could, the A11 chip would need to support x86 emulation, at which point any alleged performance gains would probably be lost.

    Long story short, it's all just hype. Laptops are designed with a very different workload in mind.
     
  6. Macalicious2011 macrumors 6502a

    Joined:
    May 15, 2011
    Location:
    London
    #6
    That's a very distant future. I don't think that there are many desk-based workplaces where IT buys iPad instead of laptop/desktops for staff to use for 8 hours.
     
  7. leman macrumors G3

    Joined:
    Oct 14, 2008
    #7
    If Apple's CPU prove to be competitive, the current macOS applications can be potentially recompiled from Intel/AMD ISA to ARM ISA. Since basic type sizes and alignment are identical between the architectures, one is left with a relative straightforward instruction recompilation.

    Also, Apple already took some steps which would make it even simpler. With app thinning, devs can submit their apps compiled to LLVM bytecode, and the user gets a final tailored binary build. With this tech already in place, one could extend this to macOS as well. Maybe even do the compilation on the host machine.

    Of course, all this assumes that the app code doesn't use any CPU-specific behaviour... And this assumption is problematic, especially where performance-critical code is concerned.
     
  8. HiRez macrumors 603

    HiRez

    Joined:
    Jan 6, 2004
    Location:
    Western US
    #8
    Personally I would love to see it. Intel's roadmap has become problematic at times for Apple and has led to product delays/stagnation, and probably some sub-par performance, since Intel provides generalized processors. macOS on ARM would allow Apple to optimize for whatever they need at the time and speed/efficiency would likely skyrocket, much as they have for Apple's i-device chips since they started designing their own (they just got started designing their own GPUs too).

    But yeah, unless you have great support for third-party apps like Adobe CC, Office, Chrome, etc., it'll be a tough sell.
     
  9. old-wiz macrumors G3

    Joined:
    Mar 26, 2008
    Location:
    West Suburban Boston Ma
    #9
    While it would not be a huge problem for Apple to migrate OSx itself and their applications (mostly done in C), how would you deal with applications written for Intel? You could not recompile since you do not own the source code.
     
  10. leman macrumors G3

    Joined:
    Oct 14, 2008
    #10
    As I said above, you can recompile the binary code itself. Basic data types and endianness are the same, so the biggest issue is already dealt with.
     
  11. shansoft macrumors 6502

    Joined:
    Apr 24, 2011
    #11
    Benchmark is done for very specific thing. It does not generalize what the performance is as a whole.

    ARM chip is far behind what X86_X64 is capable.

    The news about how A11 is more powerful than a MBP CPU is complete misleading and junk news.
    These editor need some basic engineering background before they make any of these stupid statements.
     
  12. polbit macrumors 6502

    polbit

    Joined:
    Sep 18, 2002
    Location:
    South Carolina
    #12
    100% this. I cannot believe how this FUD gets spread around. Yes, A11 is a marvel of engineering for a $40 very low power RISC CPU. It is NOT however in the same league as a modern CISC Intel laptop-class or above CPU. All these silly benchmarks being run on completely different OSes, different workloads, thermal constraints, etc. are misleading at best.

    And no, you cannot simply take an A11, and increase core count and TPW. That's part of the design complexity.
     
  13. flurffmeister macrumors member

    Joined:
    Dec 3, 2008
    #13
    I've always been curious about the difference between the architectures, especially with regard to performance and power saving. I'd appreciate some insight into this. How is ARM still vastly more power efficient than x64 (if it is)? What are strengths and weaknesses of each? I only know a few, like x64 is much better at emulation..but then there's things like running Windows 10 on a Qualcomm Snapdragon with emulation of x64, so maybe I'm wrong by now.
     
  14. thizisweird macrumors member

    thizisweird

    Joined:
    Jul 20, 2017
    Location:
    Phoenix, AZ
    #14
    I think this will explain the basics- http://www.walkerb.net/blog/x64-vs-arm/

    Going farther than that would be mean we're starting to go to class again.... but I don't mind that, myself. Personally, I'm just in love with x86/x64 and just how little power we're using now. My first laptop purchase was ~10 years ago; and while I expected advancements in those 10 years, I never would have thought x86/x64 would be this efficient. While ARM chips have progressed as well, you're limited by the instruction set (as slightly explained in the link). Either you need a chip that does basic tasks, or you need one that will do complex tasks without needing to wait for each individual instruction. Both are implemented differently...... but I could be talking from elsewheres...... someone correct me if I'm wrong here :)
     
  15. flurffmeister macrumors member

    Joined:
    Dec 3, 2008
    #15
    I love a good deep dive into things like that. I worked on automotive software on M3 and M4 micro controllers and while I never got to the point of hand-optimizing, I did see some pretty cool tricks done for audio decoding in assembly to save over 50% of the cycles of the reference C implementation. Many days were spent shaving off another 30 kB of RAM needed by the AAC buffer :)
     
  16. leman macrumors G3

    Joined:
    Oct 14, 2008
    #16
    This blog post operates with outdated notions and barely applies to modern CPUs. The terms RISC and CISC don't mean much these days. Intel CPUs use a CISC-style instruction set, which gets split into RISC-style microcode ops on the CPU (actually, modern Intel CPU's are as RISC as it gets, and thats why they achieve their performance). ARM uses RISC-style instruction set (I'm not sure whether its even true for the 64bit ARM anymore, didn't look into it in detail) but supports superscalar execution and SIMD. In fact, both modern x64 and ARM are superscalar architectures. Also, what do you mean "limited by instruction set"? Intel's instruction set is a terrible mess of legacy nonsense which is expensive to decode...

    I would be very curious to seeing more careful performance analysis between the new A11 and Intel's CPUs. I have difficulty believing that Apple can achieve Intel-like performance at so much lower power consumption.
     
  17. sparkie7 macrumors 68020

    sparkie7

    Joined:
    Oct 17, 2008
    #17
    Screw compatibility with Windoze. Once you go Mac you'll never go back
     
  18. thizisweird macrumors member

    thizisweird

    Joined:
    Jul 20, 2017
    Location:
    Phoenix, AZ
    #18
    I think you're taking what I said a little too literally... but I can also see how you arrived there, given that the link I posted was out of date. I was using "limited" as a loose translation of the difference in capabilities between the two instruction sets according to that link. My understanding of instruction sets is limited to my personal research, hence the disclaimer towards the end of my post. If forum posting is supposed to be similar to StackExchange, where posts are rewarded on objective merit in the answer, then I guess I'll just prod them for answers instead lol. If anyone takes that as getting defensive, notice the use of "lol" at the end. I know this topic is very technical, but without proper direction it quickly evolves into mass speculation v students/engineers/et al. correcting small pieces at a time... which makes me scratch my head and wonder if we're using the forums correctly? I see I've been corrected, but I have learned nothing in the process :/ but I digress.

    I also never said the word Intel in my previous post.... which makes me wonder why you felt the need to mention their instruction set being a mess. I'm aware of some "legacy nonsense" from my years of personal experience, but without context I'm completely lost with that statement. Explain please? Or feel free to elaborate on anything from that post? If it's over my head, I mean... I get that, but don't be afraid to dumb it down for me.

    OR: anyone just have a book I could look up that covers the modern differences in the architectures? Or a handful of reference books we could make a sticky about? Would probably prevent a lot of misinformation from floating around. Plus, I don't mind going to a library if it means I will learn something.
     
  19. leman macrumors G3

    Joined:
    Oct 14, 2008
    #19
    Sorry if my post came over a bit crass, I guess my reply was addressed not just to you but also to others in this thread, and so things got mixed up somehow. I'll try to explain in more detail. Disclaimer: I am by no means a CPU design expert, and it has been over a decade that I did some real low-level programming, but I did spent majority of my teenager time with assembler and machine code and I still like to be informed about how stuff works. I don't claim to have full internal knowledge of ARM or Intel/AMD CPUs though.

    The problem with terms RISC and CISC is that people throw them around, but they usually fail to distinguish between the messenger and the message. RISC and CISC first and foremost are design principles behind instruction sets — languages which are used to control the CPU execution. The question is though how the CPU implements these instruction sets. And here we come to a very important point which almost inevitably gets lost in discussions lie this ones: there are no high-performance mainstream CISC CPUs, because its very difficult to build one. Let me try to explain why.

    CISC has more complex instructions, which can do more. For example, a common staple of CISC is the ability to fetch data from memory and do an operation on this data in the same instruction. In contrast, RISC usually don't have such instructions. There are instructions that can load data from memory to local file (registers), and then there are instructions that operate on that. So do do a load+op, you'd need two RISC instructions while only one CISC instruction.

    Easily CISC CPU designs implemented the instructions in a straightforward manner. The CPU would check the next instruction and do what it says. If it said "load data from memory", it would do just that, if it said "load data from register", it would do that instead. The problem is that this model simply doesn't scale. Its extremely inefficient. You need to implement dedicated CPU logic for every instruction in your set, which is a lot of transistors, parts of the CPU are assertively stalled (e.g. your compute unit needs to wait for the memory read) and so on. This wasn't a big issue back in the day, where everything was rather slow, but it quickly became a serious performance problem for Intel. So this is why modern Intel CPUS are CISC on the surface only.

    The way it actually works is that every CISC instruction is encoded as a series of much simple microcode operations (which is essentially an internal CPU-specific RISC instruction set). A part of the CPU is responsible for fetching x86 instructions and translating them to "real" machine code, which the CPU can then execute. And these simpler operations get reordered on the fly to enable better resource utilisation. This is instruction-level parallelism (or superscalarity) — the CPU can execute parts of different CISC instructions at the same time. For example, going back to the load+operation example — the CPU could start loading the data, and while it travels from memory, it could use the compute unit to perform some other operation. This way there is no waiting, no stalling, and all the computational resources are utilised.

    So to sum this up, both current ARM and Intel/AMD CPUs are essentially RISC. The Intel/AMD simply use a more complex "richer" instruction set which they decompose to RISC instructions on the fly (there are also microcodes in ARM CPUs, but AFAIK, the complexity is on a different level). While you still need two instructions in ARM to do load+operation, both of these instructions have constant execution times. And Intel's single load+operation insnruction can take variable time, depending on whether you are loading from a register or from memory. So there is not much practical difference here. Furthermore, both ARM and Intel/AMD use superscalar execution model and have multiple compute/execution units per CPU core, which allows them to execute multiple instructions at the same time, on a single thread.

    Now to the second part: what do I mean with "legacy" in regards to Intel CISC instruction set? Well, that system has its origins in dark ages of computing and contains some very weird instructions. Not to mention that the encoding scheme of Intel instruction set is a bit of a mess. Instructions have different lengths, they can have different types of operands, sometimes there are weird limitations. With 64bit ARM, every instruction is 32bit, the coding scheme is transparent and the instruction decoder on the CPU can be much simpler. Also, the instruction set itself is very symmetrical — as put by a LLVM developer (I saw it on a presentation somewhere, can't find it anymore) — 64bit ARM is as friendly to compiler developer as it gets.

    So no, I don't see how ARM is limited by its instruction set. Sure, it sometimes needs several instructions to express what Intel x86 can do in one instruction, but I don't see why this should be a disadvantage in practice. There are pro's and contra's to both approaches: ARM needs more instructions sometimes, but the instruction set is lean and easy to decode and the instruction flow is arguably simpler to analyse. Intel can save on instructions, but pays with vastly more complex instruction encoding scheme.

    In the end, the most important thing (as I mentioned in the beginning of this ridiculously long post) is to understand the difference between the instruction set and how its implemented. Modern Intel CPUs might use same register names as the CPUs in the 90ties, but it doesn't mean that they even have these registers. CPU instructions is just a programming language, and it gets translated to other internal representations just as every other programming language.

    Hope this was at least remotely useful.

    The best source I am aware of are Intel and ARM technical documentation, as well as the incredible work done by Agner Fong: http://www.agner.org/optimize/ He has a very detailed description of Intel-compatible CPU architecture
     
  20. thizisweird macrumors member

    thizisweird

    Joined:
    Jul 20, 2017
    Location:
    Phoenix, AZ
    #20
    I seriously owe you a beer for that. No, a case of beer. You overachiever, you. I did not expect that. You actually made that sensible for me. Let's just wait for me to earn that beer money first lol. Seriously, that's the best explanation I've come across over the last few years without attempting to annoy really smart people. Thank you :)

    I'll also be looking around at Agner's work. Might go over my head, but I enjoy that kind of thing. If I can enjoy watching full length, in-depth hacking convention talks while barely able to manage my own network, I can power through this. Much thanks, mate. I owe ya one for that little lesson.

    I'm going to laugh, though, if someone wants a shorter version.
     
  21. leman macrumors G3

    Joined:
    Oct 14, 2008
    #21
    Thanks for the kind words! But please, take what I wrote with a healthy dose of scepticism. I might have messed up some technical details and it is entirely possible that an actual expert has some good arguments why Intel's instruction set is inherently better than the ARM's one.
     
  22. polbit macrumors 6502

    polbit

    Joined:
    Sep 18, 2002
    Location:
    South Carolina
    #22
    To add a bit to the discussion - x86 instruction set complexity is not only due to the legacy support, but also because it has variable length instructions. If implemented correctly, that gives it an advantage over ARM where all instructions are fixed 32-bits, as it does not waste precious cache memory, amongst others. That implementation also dictates complex branching prediction, etc. To put it in laymen's terms, ARM relies on compilers a lot, whereas x86 takes matters in its own hands when it comes to execution efficiency. That is also why x86 is referred to as a CISC processor, while ARM is a RISC processor, even if those lines have been blurred as of late.

    Seeing how fast ARM architecture is catching up to x86, if that level can be sustained, ARM will pass x86, but we are not there yet. ARM is not a player in the higher TPD right now, so you can't really compare a 5W TPD with a 28W TPD or even the 15W TPD.

    It would be very interesting to see what somebody like Apple can do with ARM at those TPDs, but I don't see Apple pushing in that direction.
     
  23. leman, Sep 24, 2017
    Last edited: Sep 24, 2017

    leman macrumors G3

    Joined:
    Oct 14, 2008
    #23
    This is a very good point! But there is also some complexity here as well. For instance, ARM has more registers, so it might actually be easier to encode more complex algorithms with fewer opcodes there, when on x86-64, you'd also need to juggle some sort of external buffer (stack etc.). I'm curious whether someone did actual research on this, there must be papers out there comparing ARM and x86-64 compiler outputs...

    I'm not sure that I agree with you here. I'd argue that Intel is just as reliant on good compiler, since its compiler's responsibility to emit shorter and cache-friendlier sequence of opcodes, as well as make sure not to use any opcodes that happen to be slow on the mainstream CPUs (e.g. ENTER). I'd speculate that the load-process-store design (and more registers) of ARM instructions would make it easier to write a good compiler.
     
  24. kevink2 macrumors 65816

    Joined:
    Nov 2, 2008
    #24
    It is not just windows, but compatibility with older mac software. The times in the past Apple changed architecture it was when the replacement was enough faster than the old platform that they could still run the old software at reasonable speed in emulation. So it takes more than a chip that is comparable, but it must be faster. And not just the lower/midrange models.
     
  25. sparkie7 macrumors 68020

    sparkie7

    Joined:
    Oct 17, 2008
    #25
    True dat. I still like running Macromedia (Aldus) Freehand. And MAME games.. Also why I love OSX 10.6.8
     

Share This Page

39 September 16, 2017