Geekbench 3 Sandy Bridge v.s. Apple Cyclone IPC comparison

[Arachnotronic]

Thought this might be something that interests people here...

Apple's done a mighty fine job with its Cyclone, that's for damn sure.

 

[Phynaz]

Yeah, they've designed one killer CPU.

 

[Accord99]

Or maybe it's the compiler.

In Geekbench, Sandy Bridge can only do 2.7 flops/cycle single-precison and 1.4 flops/cycle in GEMM. Optimized versions of DGEMM should easily get close to 4 double-precision flops/cycle without using AVX.

 

[postmortemIA]

riiight, last time I checked SB does not run at 1.6GHz. Show me high IPC CPU with high operating frequency.

 

[Ventanni]

riiight, last time I checked SB does not run at 1.6GHz. Show me high IPC CPU with high operating frequency.

I agree, but it's not about how you'll never run SB run at 1.6ghz, but a near clock-for-clock comparison of the two architectures.

Cyclone is one sick chip, but we [all] also have to remember that SB is two generations old too. One thing I've started to learn lately with CPU comparisons is that unless the compiler is written to take advantage of the latest instruction sets, it's not always applicable to compare two architectures.

Even still, SB and Cyclone are two very differently designed chips for two very different markets. One works in a phone and tablet, and one works in your laptop, desktop, and server. We can compare all we want, but they will never directly compete with each other.

Also, I don't want to take Anand's words out of context, but I think this is his opinion on the cross-comparison from his latest Tweet:

"anandshimpi: @AshrafEassa you can't do cross OS comparisons with geekbench very well, which is why we don't. Desktop workloads are different than mobile."

He's got a point.

 

[mavere]

Or maybe it's the compiler.

Maybe, but if we're going to bring compilation and optimization into this, you'd have a hard time convincing many that a 2.5 years old Intel x86 architecture running on Windows is anything less than favored.

I might even argue that Cyclone, being on an entirely new ISA, is being disadvantaged here and might need another year of compiler work to catch up.

 

[mikk]

I'm sceptical if Geekbench v3 ARM results are comparable to Intel or x86. It looks to me ARM is favoured in this benchmark. Or maybe the microbenches are in favour of ARM. I would expect in real world benchmarks Intels more robust architecture pulls aways.

 

[ChronoReverse]

All the encryption bits aren't useful either since the Cyclone uses dedicated hardware for that.

 

[Vesku]

All the encryption bits aren't useful either since the Cyclone uses dedicated hardware for that.

Sandybridge has hardware AES on many SKUs doesn't it?

 

[Exophase]

Personally, I'm not ready to accept 1.3GHz for Cyclone as fact just yet. There's a little more on this here:

http://www.realworldtech.com/forum/?threadid=136274&curpostid=136378

Don't read this as me saying that I deny it's 1.3GHz, I just want stronger evidence.

 

[tempestglen]

We need spec2000/2006, that's all.

 

[BallaTheFeared]

Now let see them scale it up to 5GHz SB :|

 

[Blitzvogel]

Isn't SB equipped with 256 bit wide SIMD and the A7 128 bit?

 

[ChronoReverse]

Sandybridge has hardware AES on many SKUs doesn't it?

Maybe for AES (see how much faster the Sandy Bridge result is for AES).

I'm thinking SHA doesn't though because the Sandy Bridge result is only a bit better (per clock) than the result for a Q6700.

 

[beginner99]

I agree, but it's not about how you'll never run SB run at 1.6ghz, but a near clock-for-clock comparison of the two architectures.

I think he meant to say it's much easier to create a high IPC CPU at low frequencies than at high ones. As we all know SB easily scales up to above 4 Ghz.

 

[NTMBK]

riiight, last time I checked SB does not run at 1.6GHz. Show me high IPC CPU with high operating frequency.

To try to fit it into the TDP of the A7? You'd be closer to 800MHz, like the Celeron Chromebook.

 

[BrightCandle]

A few of these numbers for the Sandy Bridge processor look very unexpectedly low. Take for example the SHA-2 encryption test, I have seen results for that before in tools like SiSoft Sandra where the result is measured in 10's GB/s. Sandy Bridge in raw floating point without AVX can push about 5GFlop/s per thread at that clock speed.

These benchmarks with geekbench are garbage compared to what we have seen before. Its likely they are very poorly written and not designed for Intel CPUs at all well.

 

[Idontcare]

I wouldn't mind if Apple steps in to fill the competitive void that AMD has created. Anything to keep the MPU business' feet to the fire.

I wonder how much of the A7 was Jim Keller's handiwork (in terms of project management), and if so then I wonder how much of it might bleed over into future AMD chips?

 

[jfpoole]

A few of these numbers for the Sandy Bridge processor look very unexpectedly low. Take for example the SHA-2 encryption test, I have seen results for that before in tools like SiSoft Sandra where the result is measured in 10's GB/s. Sandy Bridge in raw floating point without AVX can push about 5GFlop/s per thread at that clock speed.

These benchmarks with geekbench are garbage compared to what we have seen before. Its likely they are very poorly written and not designed for Intel CPUs at all well.

The Geekbench 3 SHA-2 workload only operates on a single buffer of data, while some of the SiSoft Sandra SHA-2 workloads operate on multiple buffers of data at the same time using vector instructions. I don't have a copy of SiSoft Sandra handy, but according to this page their "single-buffer" implementation achieves 440MB/sec at 2.5GHz.

 

[Nothingness]

These benchmarks with geekbench are garbage compared to what we have seen before. Its likely they are very poorly written and not designed for Intel CPUs at all well.

Yes that's the issue: people are so used to benchmarks designed to make Intel CPU shine that they can't believe such results :whiste:

Joke aside, Intel17 these are very interesting figures. I have a few questions:
- did you clock down memory too? If not then your CPU will benefit from larger bandwidth and lower latency.
- what OS did you use? Linux 64-bit would be the better choice as it uses clang/llvm which also is what is used for iOS.

Also note that as others said, when you design with "low" clocks in mind it's easier to have higher IPC. But this nonetheless are impressive results from Apple!

 

[Arachnotronic]

Yes that's the issue: people are so used to benchmarks designed to make Intel CPU shine that they can't believe such results :whiste:

Joke aside, Intel17 these are very interesting figures. I have a few questions:
- did you clock down memory too? If not then your CPU will benefit from larger bandwidth and lower latency.
- what OS did you use? Linux 64-bit would be the better choice as it uses clang/llvm which also is what is used for iOS.

Also note that as others said, when you design with "low" clocks in mind it's easier to have higher IPC. But this nonetheless are impressive results from Apple!

I ran the memory @ 1066MHz.

 

[Nothingness]

I ran the memory @ 1066MHz.

Good!

And what was the OS? Windows? Again running with Linux would help make a better comparison, as that would slightly even out compiler differences.

 

[meloz]

While 'Cyclone' is impressive enough as a mobile part, these type of comparision between such vastly different architectures designs do not really tell anything.

SNB was not designed for 1.6 GHz. It was primarily designed to operate at twice that speed. Of course when you restrict it to lower speeds and TDPs a whole lot of lesser powered architectures become competitive.

But while a SNB can always clock down to 1.6 GHz, can a 'Cyclone' clock up to 3.2 GHz? Operating at lower frequencies is easy for a CPU that is designed for higher ones, but vice versa might not be possible and -even if possible- might not yield expected linear performance gains with frequency since there might be architectural bottlenecks fundamental to the design.

Aside, you were wise to not benchmark Cyclone against Haswell running software compiled with AVX2 support. Even at 1.6 GHz Haswell would utterly destroy the Cyclone.

 

[Face2Face]

I am very impressed with the performance, I mean Qualcomm and Samsung gotta be pissed..

For a Dual-Core 1.3GHz to be faster than a Snapdragon 800 2.3Ghz quad-core. Even faster than than Baytrail. But Sandy..... come on.

 

[meloz]

I am very impressed with the performance, I mean Qualcomm and Samsung gotta be pissed..

For a Dual-Core 1.3GHz to be faster than a Snapdragon 800 2.3Ghz quad-core. Even faster than than Baytrail. But Sandy..... come on.

There is not enough information here.

We do not know which programs were used to run these benchmarks in two different platforms, how those programs were compiled and which compiler and compiler version was used. Those variations alone can easily swing performance ± 100%, if not more.

Look at Anandtech's own benchmarks of A7. In most cases A7 performs similar to Baytrail and Qualcomm products. In many cases Intel's Atom is quicker. If 'Cyclone' is impressive then Intel and Qualcomm are not far behind.

Intel's biggest challenge is their inability to accept a lower profit margin rather than anything Apple or Qualcomm are selling. Qualcomm might be a bit behind but they have their own chips coming, so this game of leapfrog will continue until tablets and smartphones reach the 'good enough' plateau, like PCs.

Most ARM players have gone the wrong way in pursuing core count rather than IPC. Does it not remind you of the megapixel race in cheap plastic toy cameras we saw during the 2005-2010 era? Apple -at least- are fighting against the core count stupidity, good for them. Hopefully this gives other companies the balls to do the right thing rather than appease the lowest common denominator.

As for Samsung and their home grown Exynos....meh. It is not performant enough to snatch high-end customers and delight the enthusiast crowd. It is not cheap enough to substitute Mediatek junk. Maybe they can buy nvidia when the latter go bankrupt and something good can emerge from the combined efforts.