SPEC CPU 2006 : Skylake Core M vs Broadwell Core M vs Apple A9X

[Arachnotronic]

Intel is doing something wrong if they let any company catch up to their performance this quick.

Because Intel is no small company and can also grab all the talent they want with their deep pockets. This also proves Intel's internal competition between their 2 bigger design teams isnt really usefull if they can only bring 5-7% (averaged between ticks and tocks) IPC increases between new CPUs and having sloppy developments like removing FIVR from Skylake, getting it back for Cannonlake, linking Core and Uncore speeds on Sandy Bridge, rollbacking on Haswell onwards, etc.

CPU design for Intel is a lot bigger of a commitment that it is for Apple, at least right now. If Apple starts being ahead of Intel in performance and perf/watt with their Ax SoCs, they will start to see less and less reasons to even use Intel's products. Because as deep as their pockets are for bringing CPU talent, they are too for having a fast transition to a ARM based OSX ecosystem.

CPU design is a gigantic commitment within Apple, you would probably be surprised. The stories I hear from industry insiders about the kinds of $ that Apple will pay to grab top CPU/SoC/GPU talent (i.e. Apple offering well paid employees at other top semis ~2x their previous salaries to hop on board...as you may know, good chip engineers aren't cheap to begin with) tells me that they are very committed.

And if you take a look at this from a business lens, it makes a whole pile of sense. The Ax SoC is the heart of Apple's iPhone, a $150B+/year business. To protect/grow this business, Apple needs to continually innovate here and stay as far ahead of the competition as possible.

Apple is bigger, richer, and more powerful than Intel so it's of little surprise to me that they are investing big time in CPUs/SoCs and are actually doing a great job.

 

[waffleironhead]

How come you manage to misinterpret me, despite me having mentioned several times in this very thread that SPEC is fine if you use the same compiler with same options?
At least we currently have no indication that something with SPEC is flawed to the same extend that Antutu was flawed.

One could almost wonder if it was intentional.

 

[beginner99]

I am not talking about compiler optimizations Apple would have to do or not. I am saying if you want to compare the microarchitectures you would have to use the same compiler with the same options. The options used by Anandtech for different compilers enable vastly different optimizations.

Otherwise you cannot possibly draw any conclusions and the result is use-less. This is a perfect example of how Spec CPU benchmark should not be used. It is not even worth discussing the results.

By that logic you would also need the device to run the same OS because for sure iOS is better optimized for a specific hardware than Android. The conclusion is you can't fairly compare them because there will always be someone which thinks it's unfair for whatever reason.

In the end battery life tests and JavaScript benches aren't that bad. Because what does the average Joe do with his Smartphone? Yeah surf the web and most will do it with the stock browser.

Apple will look good here because they can optimize the browser and OS to their hardware. Does it measure real CPU performance and power use so you can compare uArch? No but it measures real-world device performance. I think we agree Apple wins here (People on this forum that have read my post know I'm anything but an apple fan) . But then you also pay double $$$ for an Apple-Smartphone compared to mid range Android which offers more half the performance and usability. I rather get the cheaper phone then.

 

[Exophase]

There's actually a presentation out there of exactly what LLVM/CLang need. They really aren't benchmark breakers and have real general purpose value. The major thing that LLVM/CLang lacks wrt libquantum is AoS<>SoA conversion. That conversion capability is what opens up all the parallelism in libquantum and applies to whole classes of code as well. Many of the things that ICC is doing are just very complex transforms of code to unlock/unblock things (another one is loop fusion which merges multiple loops into 1 loop).

If llvm or any other open source compiler implements general optimizations that dramatically improve libquantum's score I will admit that Intel isn't breaking the benchmark.

On the other hand, from what I can see (the slides that you're probably referring to) it is specifically loop fusing that has potential for a really huge uplift in the libquantum score; I don't see mention of AoS->SoS reordering for anything. If this is all it takes to have such a dramatic impact on a score I think that makes the benchmark look far too trivial. Especially if these are optimizations that wouldn't apply to a serious library that had better code.

There are other arguments for that as well, like quantum computing operations not actually being very generally useful for much outside of a sliver of academic research, and not being much of an obvious proxy for anything. I've seen a report that under x86-64 (vs 32-bit x86) the benchmark gets a much better score despite suffering from much higher cache misses, because it uses a lot of 64-bit arithmetic. That would also throw it in the "not very representative" bucket - how many real programs today are simply dominated by 64-bit throughput?

Now there could be some cases where this is true for HPC systems and maybe SPEC is more applicable here, but for mobile? Not really. You need much more comprehensive tests. Geekbench isn't very comprehensive either but at least almost all of the integer tests represent things done in some capacity on mobile platforms, and even for ones that are generally I/O limited there's still a power consumption interest in CPU efficiency.

 

[Edrick]

II am saying if you want to compare the microarchitectures you would have to use the same compiler with the same options.

Wait, what?

One of the biggest differences between microarchitectures is the instructions that require different compiler options to take full advantage of. That can also be said for different generations of the same microarchitecture products. Reducing the compiler options to the lowest common denominator is not going to tell you much.

 

[Exophase]

Wait, what?

One of the biggest differences between microarchitectures is the instructions that require different compiler options to take full advantage of. That can also be said for different generations of the same microarchitecture products. Reducing the compiler options to the lowest common denominator is not going to tell you much.

Different instructions would be a difference in architecture, not microarchitecture.

Generally speaking the only microarchitecture specific flag that makes any real difference in compiler output is specifying what microarchitecture that is, and even then that doesn't make that much of a difference anymore.

I wouldn't take Thala's "same options" recommendation literally. I took that comment to mean issuing the "same" flags for targeting a specific arch and uarch where the actual target varies based the platform.

But it's worth noting that none of the compiler flags used in this review specified uarch, although ICC could be using -xCORE-AVX2 as a hint to optimize for Haswell.

 

[Thala]

One of the biggest differences between microarchitectures is the instructions that require different compiler options to take full advantage of. That can also be said for different generations of the same microarchitecture products. Reducing the compiler options to the lowest common denominator is not going to tell you much.

I should have been more specific, of course i mean the same options except the options, which specify the target architecture.
I mean who would expect to generate code for x86 when invoking "gcc -march=armv8.1-a"?

I wouldn't take Thala's "same options" recommendation literally.

Precisely. Thanks!

 

[witeken]

Die area of SKL-Y is ~98mm^2; A9X is a 147mm^2 die. Note that the A9X includes the Southbridge on the die whereas SKL-Y requires a separate PCH on package.

It's extremely annoying that AT is always talking about "sweet spot" for Apple SoCs...

Like apple commits itself to some random mm² number.

Also, this doesn't take into account the "inflation": wafer cost increases/difference.

And never mind yield variability, and while I'm at it, the foundry tax.