No new MacBook Pro Leaks?

[catportal]

A whole host of reports came out showing that the iPhone 7 is faster than Mac Pro at single core tasks I thought. Get a few of those chips in a MBP and that'd be fantastic.

Also, aren't all apps getting submitted to the app store compatible with both Intel and ARM?

I really hope they switch. Very annoyed by the constantly delayed Intel 3% improvements

Irrelevant comparison. The software stack on an iPhone doesn't compare to the software stack on a Mac Pro. If I ran a benchmark on an ASIC designed for that benchmark specifically it would get better results but would still be a poor computer. If you want to compare "raw performance" which is actually a bad metric as well, you should look at throughput of compute instructions in the form of flops.

 

[Macintosh IIcx]

Hmmmm, if something really mind blowing had to happen regarding a move to ARM AX on the MacOS, Adobe would have move most of their apps to MacOS ARM. That would be a game changer for sure. Microsoft already have Office for iOS, so that could suffice until they get the full suite to MacOS ARM.

It would be a massive undertaking, but with the popularity of iOS devices it could make sense for the big companies. Note that we would want a proper file system interface, but no reason you couldn't merge MacOS and iOS on a lot of levels.
[doublepost=1477121208][/doublepost]Note that I don't think Apple or others are ready for this move just yet, but they have to be contemplating it.

 

[leman]

It's not going to be solely ARM powered. Think A10 CPU in an always-on state like the iPhone, handling light tasks and browsing instantly while sipping the massive battery. The A10 controls the system-level hardware and wakes the usual x64 CPU and GPU when an app is opened that calls for it.

That would be ridiculously difficult to pull off. The complexity of context switch between architectures like that is insane. Even if - very hypothetically speaking - they manage to do something like that, the performance and stability would be horrible. For it to work more reliably, the cores would need to share the memory controller/caches, and I don't see Intel letting Apple borrow their IP
[doublepost=1477124485][/doublepost]

The only way to make it "fully compatible" is if they virtualized x86/AMD64 on ARM which would have terrible performance causing the Macbook Pro to be Macbook Pos.

They could recompile x86 instructions on the fly to ARM. Apple has LLVM, which can pull this with ease. The 64bit instruction sets have the same alignment and basic data type sizes, so its really just about translating the code.
[doublepost=1477124592][/doublepost]

A whole host of reports came out showing that the iPhone 7 is faster than Mac Pro at single core tasks I thought. Get a few of those chips in a MBP and that'd be fantastic.

Those results are highly misleading. The fact is that Apple's Hurricane is slightly slower than a Core M in the MB 12". Which is very impressive in itself, but still very far to the levels of performance in the higher-tier laptops and desktop computers.
[doublepost=1477124702][/doublepost]

Hmmmm, if something really mind blowing had to happen regarding a move to ARM AX on the MacOS, Adobe would have move most of their apps to MacOS ARM. That would be a game changer for sure. Microsoft already have Office for iOS, so that could suffice until they get the full suite to MacOS ARM.

If Apple pulls this off right, moving apps to ARM would be as easy as clicking 'build' in Xcode. If there needs to be active developer effort to port stuff to ARM, I am very sceptical.

 

[meduzarija]

If it's fully compatible with the current OS + better performance + no heat, why not?

And next summer we are sending humans to Mars!

What you listed is great, but it doesn't go like that! We are years away from custom ARM CPU that will be also able to run programs that are wrote for x86, plus no heat, and PLUS better performance. That is just insane to put in same sentence (at the same time at least).

 

[UltimateSyn]

Bear in mind that a lot of the most important apps for businesses and professionals (e.g. Microsoft Office and all the Adobe apps ) don't get delivered through the App Store and also the fact that x86 compatibility is needed for boot camp and fusion/parallels.

If they did do this they would lose a lot of sales IMO and would relegate the Mac line to being little more than iPads with built in keyboards.

I haven't got into my architecture courses yet, so I'm not sure on this, but would it be possible for the A10 Fusion chip to be a quad-core chip with two custom ARM-based cores and two Intel x86 cores?

 

[maflynn]

Because of lower interest, its easier for Apple keep a lid on things, but there have been other leaks, such as a thinner MBP using USB-C.

IT doesn't really matter at this point because we will all find out come thursday

 

[UltimateSyn]

And next summer we are sending humans to Mars!

What you listed is great, but it doesn't go like that! We are years away from custom ARM CPU that will be also able to run programs that are wrote for x86, plus no heat, and PLUS better performance. That is just insane to put in same sentence (at the same time at least).

http://www.theverge.com/2016/9/16/12939310/iphone-7-a10-fusion-processor-apple-intel-future

 

[flyinmac]

And next summer we are sending humans to Mars!

What you listed is great, but it doesn't go like that! We are years away from custom ARM CPU that will be also able to run programs that are wrote for x86, plus no heat, and PLUS better performance. That is just insane to put in same sentence (at the same time at least).

Depends on who "we" is. The U.S. Isn't getting anywhere near Mars without hitching a ride with the Russians.

 

[leman]

I haven't got into my architecture courses yet, so I'm not sure on this, but would it be possible for the A10 Fusion chip to be a quad-core chip with two custom ARM-based cores and two Intel x86 cores?

That wouldn't make much sense. The cost of licensing and stuff would make it pointless.

 

[bjet767]

You ARM fans don't understand how programs are compiled for a machine.

The ARM instruction set is not compatible with the Intel one.

As an Apple developer the answer is, no xCode does not compile dual, Intel and ARM, compatibility programs at this time for OS X.

This idea has been explored over and over again in other threads.

 

[Traverse]

I can't wait for Thursday just to put an end to this ARM speculation. I just don't see it. At least, not for anything other than the MacBook or Mac Mini.

Apple is NOT going to pull the rug out from under users and developers and suddenly announce that Macs are moving to ARM. No x86 apps (with decent performance), no Windows Bootcamp, barebones support. Many people hate Tim, but he isn't stupid.

And before someone tells me that apps in the MAS should be "easily compiled to ARM" allow me to remind you that there is a thriving ecosystem of software that exists outside the MAS because developers don't want to pay Apple 30%. Do you really see Adobe and Microsoft and specialized music software houses moving their entire software lineup to ARM very rapidly or at all?

Adobe? Maybe. Microsoft? Perhaps 5 years after ARM becomes mainstream. Others? Doubtful.

 

[zhenya]

I think we have seen the leaks. We are fairly certain it's a similar unibody construction, probably with 4 usb-c ports and no magsafe, 'magic' toolbar replacing the top row of fn keys. There's just a lot less interest in Macs compared to iPhones, and the parts are large enough that they can't as easily be smuggled out of the factory.

 

[EnesM]

I think we have seen the leaks. We are fairly certain it's a similar unibody construction, probably with 4 usb-c ports and no magsafe, 'magic' toolbar replacing the top row of fn keys. There's just a lot less interest in Macs compared to iPhones, and the parts are large enough that they can't as easily be smuggled out of the factory.

Macs rarely leak don't they? I don't recall seeing any leaks for redesigned Mac Pro and iMac some years ago

 

[Macalway]

You might as well just send me your money in that case.
Macbook pro with ARM processor = $0.00 in sales.

Yes, this would cause a riot (and not a good kind). Lots of boos, and stuff thrown at Tim.

 

[catportal]

That would be ridiculously difficult to pull off. The complexity of context switch between architectures like that is insane. Even if - very hypothetically speaking - they manage to do something like that, the performance and stability would be horrible. For it to work more reliably, the cores would need to share the memory controller/caches, and I don't see Intel letting Apple borrow their IP
[doublepost=1477124485][/doublepost]

It actually wouldn't be that insane because both use RISC microops but Apple wouldn't be able to do it. It would have to be Intel that decides to do it and there is no reason Intel would ever do that because its practically suicide for their main business. Basically it would work similar to how ARM implements thumb, you would just have different mode for ARM ISA decode but everything would eventually just be Intel's microarch ops.

They could recompile x86 instructions on the fly to ARM. Apple has LLVM, which can pull this with ease. The 64bit instruction sets have the same alignment and basic data type sizes, so its really just about translating the code.
[doublepost=1477124592][/doublepost]

No they couldn't. The x86/AMD64 that Intel implements is not actually real x86, they use RISC micro ops, which is the source of their performance gains. Intel's microarchitecture is not open source and they don't license it so there is no way Apple could JIT x86 to ARM without massive performance issues. Not to mention, a JIT compiler is technically a VM (same as .net IL or JVM bytecode) and is orders of magnitude slower than native.

 

[leman]

No they couldn't. The x86/AMD64 that Intel implements is not actually real x86, they use RISC micro ops, which is the source of their performance gains. Intel's microarchitecture is not open source and they don't license it so there is no way Apple could JIT x86 to ARM without massive performance issues. Not to mention, a JIT compiler is technically a VM (same as .net IL or JVM bytecode) and is orders of magnitude slower than native.

First, I wouldn't be so sure before someone tries. This topic doesn't have anything to do with the tricks how Intel implements the instruction set in hardware. Its about compiling x86 binary into ARM64 binary which is very doable. The performance hit is a different story. Yes, I would expect some loss of performance compared to direct compilation, but certainly not 'an order of magnitude'.

Second, you usage of term 'JIT compiler' is confusing. What kind of JIT technique are you talking about? I was not even talking about JIT, just straightforward compilation of the entire code. Not to mention that your 'order of magnitude doesn't apply here either'. Modern JIT can produce some very decent numeric code. Taking your logic further, everything is technically a VM because the apps you run were written in a higher-level language instead of binary. To make things more confusing, these languages usually go through two or more intermediate IR (what you call bytecode) stages before they get converted to the final CPU-specific binary.

 

[jjiangweilan]

I believe you will see them next week. After all if you see it on Thursday, it's not a leak anymore

 

[catportal]

First, I wouldn't be so sure before someone tries. This topic doesn't have anything to do with the tricks how Intel implements the instruction set in hardware. Its about compiling x86 binary into ARM64 binary which is very doable. The performance hit is a different story. Yes, I would expect some loss of performance compared to direct compilation, but certainly not 'an order of magnitude'.

Second, you usage of term 'JIT compiler' is confusing. What kind of JIT technique are you talking about? I was not even talking about JIT, just straightforward compilation of the entire code. Not to mention that your 'order of magnitude doesn't apply here either'. Modern JIT can produce some very decent numeric code. Taking your logic further, everything is technically a VM because the apps you run were written in a higher-level language instead of binary. To make things more confusing, these languages usually go through two or more intermediate IR (what you call bytecode) stages before they get converted to the final CPU-specific binary.

You can't "recompile" a binary from x86 to ARM, for example, suppose the original binary is utilizing vector/superscalar instructions that don't have a direct map in the new architecture, sure you could try to change the instruction but now you are introducing new behavior to the software and can't guarantee consistent execute let alone some apps would totally break (imagine something like matlab, your performance hit would be devastating). You can try to emulate it in something like QEMU but like I said previously it would be slow. You would have to have the format of the original binary in some form of intermediary language that can be used by LLVM or any other kind of compiler, which would shift the burden to an app developer.

The reason I mentioned the type of micro arch Intel uses is because I assumed you meant hardware dynamic binary translation (DBT), which technically would be very fast compared to any software emulation, but very unlikely for Intel's arch because it is not open.

 

[eroslws]

Maybe they are planning to produce it in the US, as in case of Mac Pros? This would explain no leaks...

This. It also means the prices are going back to what they were when Retina was first introduced. The base 13" would be $1699.

 

[leman]

You can't "recompile" a binary from x86 to ARM, for example, suppose the original binary is utilizing vector/superscalar instructions that don't have a direct map in the new architecture, sure you could try to change the instruction but now you are introducing new behavior to the software and can't guarantee consistent execute let alone some apps would totally break (imagine something like matlab, your performance hit would be devastating). You can try to emulate it in something like QEMU but like I said previously it would be slow. You would have to have the format of the original binary in some form of intermediary language that can be used by LLVM or any other kind of compiler, which would shift the burden to an app developer.

I don't see any theoretical or practical reason why this should not be doable. You take x86 binary, translate it to LLVM IR, then let LLVM optimise and output the ARM binary. This challenge is equivalent to "classical" compiling and optimising (sans of course type meta information you have in a high-level language). AFAIK, there are projects that attempt to do just that (I don't know how successful they are though). As to vector instructions, they might be slightly different between the architecture sets, but NEON and SSE/AVX are quite similar in spirit — as far as I know (has been some time since I last done any hand-coded vector assembly) they have comparable types of instructions — and I see no fundamental problems into mapping one to another. Now, stuff like AVX-512 with its mask registers etc. is another beast altogether and emulating those would probably be very slow, but thats not a problem one has to deal within the next few years I guess.

To sum it up, I am quite optimistic about binary recompilation of this sort. Again, this is purely theoretic. I am not advocating that Apple moves to ARM. I am merely interested in discussing if/how this could be accomplished and what the practical implications of such a move might be.

 

[Spudlicious]

I am a bit concern that the only true leak for the MacBook Pro was the picture of it which showed an empty hole for the magic function keys.

I am worried that the production and distribution chains are far from ready (so no leaks because nothing to show) and we are gonna to have to wait a couple more months before seeing anything in the stores.

Am I the only one?
[doublepost=1477074207][/doublepost]In comparison, a month before the iphone 7 event, we had countless of pictures, both from the final product and several hardware components plus the full final specs pages...

Here's the latest photo out of China.

 

[jerryk]

It's not going to be solely ARM powered. Think A10 CPU in an always-on state like the iPhone, handling light tasks and browsing instantly while sipping the massive battery.

Browsing these days is anything but a light task. With a lot of client side scripting, ads, and video windows on each page I regularly see 30-50% CPU utilization. I see 20% or less when I run apps like Word or Powerpoint.

 

[TheSteves]

Timmy's really doubled down on this one.

No leaked benchmarks. No more leaked photos. No leaked packaging with the specs on. No leaked hints on Apple's website.

There's going to be a MacBook Pro update next week, absolutely no doubt. But the sheer secrecy makes me think it's going to be something properly special.

My money's on ditching Intel.

Mine too

 

[bjet767]

If Intel is to be ditched the world would have heard about it already, the Chinese who make these machines for Apple couldn't keep a secret.

Even switching to an AMD with the same instruction set as Intel would have been leaked. No the new MBP will still be an Intel based machine.

 

[EnesM]

If Intel is to be ditched the world would have heard about it already, the Chinese who make these machines for Apple couldn't keep a secret.

Even switching to an AMD with the same instruction set as Intel would have been leaked. No the new MBP will still be an Intel based machine.

I remember a report from Israel facility which mentioned Arm based Mac Minis