The Intel Atom Thread

[witeken]

If it has the right price, Samsung will probably even put a quadCore i7 into their phones with 3GHz+ clock speeds, just to have the fastest phone. I'm wondering if Samsung would then still cheat the benchmarks by locking the phone at 3GHz, though .

Edit: What annoys me is that while people are saying that Intel's MWC was a fail, I've actually seen zero interesting announcement from other companies. In that respect, I think Intel ruled MWC with important announcements that are a groundwork for their future dominance in mobile.

 

[Homeles]

No 805 in GS5 may be rather telling. I wouldn't be surprised if it ends up a tablet only chip. I think Qualcomm might be running out of room on 28 nm HPM. (Or it could just be some other delay.)

The 805 just isn't ready yet. It's sampling right now... just a bit too early for devices to launch at MWC.

 

[Khato]

GPU is 450MHz for iPad vs. 533MHz for Merrifield. Merrifield doesn't compete with S805 as far as I know. In terms of performance it will, and it will be far superior on efficiency (the ~2x efficiency of Silvermont should compensate 2x less cores in multithreaded and thermal bound scenarios), but with only 2 cores it isn't meant for phones like the Samsung Galaxy S5 (marketing). I'd like to see cheap mid-end phones with Merrifield though.

I'd agree if there were usage cases in smartphones where more than 2 cores were necessary, but there aren't yet. The 'core wars' in the mobile space really are the equivalent of the 'GHz wars' back in the P4 era - marketing can't figure out any other way to quantify performance so they latch onto a meaningless number. Which earns them the title of morons in my opinion for the simple fact that they likely could legitimately claim that a device with Merrifield is faster than the Apple equivalents. And we all know how much the A7 being a dual core has hurt Apple's marketing. Not to mention it could probably be called, 'The dual core that beats the competition's quad core.' There's all manner of opportunity to throw dirt on the stupidity that is the 'core wars' here...

I'm also rather surprised by the lack of high-end 64 bit SoCs from all the other players thus far. Samsung failed to deliver on the Galaxy S5 and all we have from Qualcomm are announcements for the budget cores.

 

[bullzz]

@jdubs03 - samsung usually reserves exynos for its international version. im expecting europe and asia to have it

 

[witeken]

I think you mean "I'd disagree if..."? BTW, I think there is still a GHz race going on. In a few years clock speeds went from 1.2GHz to 2.5GHz, all while making the cores bigger and adding more of them.

 

[Exophase]

I'd agree if there were usage cases in smartphones where more than 2 cores were necessary, but there aren't yet.

Do you have any kind of research to support this claim? Games have been able to utilize more than two cores for years, especially on the consoles, and phones have received a growing number of cross-platform games. And anyone arguing against the relevance of high end mobile games should be staunchly against the GPUs in these SoCs before they start opposing quad cores.

Even my emulator can gets a good performance boost going from two to three cores, so that's at least one thing.

Also, what would you consider the particular set of software that justifies more cores in tablets but not phones? I've seen this argument a lot, and I assume you hold this position since you specifically mentioned phones and I haven't seen you claim BayTrail-T has too many cores, but I'd like to hear some examples. Or is it more a matter of which OS is running?

 

[Sweepr]

They should have released both Medfield and Moorefield in H1/2014. Intel could score some interesting design wins with four 64-bit capable Silvermont cores @ up to 2.3GHz, PowerVR G6430 GPU and XMM7260. The new wave of high-end Android are still 32-bit ARMv7 designs.
Regarding the apparent lack of design wins, perhaps we should wait and see? I'm not extremely confident though.

Based on Intel's 22nm Silvermont microarchitecture, the new processor also features a PowerVR* Series 6 Graphics IP core from Imagination Technologies* and is designed for simple pairing with the Intel® XMM™ 7160 LTE platform. Merrifield is the first Intel Atom SoC to feature the new Intel® Integrated Sensor Solution, which efficiently manages sensor data to keep applications smart and contextually aware even when the device is in a low-power state. Intel expects Merrifield-based devices from multiple OEMs to launch beginning in the second quarter.

 

[Khato]

I think you mean "I'd disagree if..."? BTW, I think there is still a GHz race going on. In a few years clock speeds went from 1.2GHz to 2.5GHz, all while making the cores bigger and adding more of them.

Nope, I said what I meant. Though I see where the confusion comes in as I probably should have cut down the quote to only "but with only 2 cores it isn't meant for phones like the Samsung Galaxy S5 (marketing)".

Far as I can tell, the only reason why Merrifield isn't going to be in top-tier phones is that it's paired with the XMM7160. If it was instead being launched right now with XMM7260, well, why wouldn't it be a candidate for every top-tier phone out there? For a change Intel seems to have both the CPU and GPU performance where they should be, and likely with better power figures to boot.

 

[Khato]

Do you have any kind of research to support this claim? Games have been able to utilize more than two cores for years, especially on the consoles, and phones have received a growing number of cross-platform games. And anyone arguing against the relevance of high end mobile games should be staunchly against the GPUs in these SoCs before they start opposing quad cores.

Even my emulator can gets a good performance boost going from two to three cores, so that's at least one thing.

Also, what would you consider the particular set of software that justifies more cores in tablets but not phones? I've seen this argument a lot, and I assume you hold this position since you specifically mentioned phones and I haven't seen you claim BayTrail-T has too many cores, but I'd like to hear some examples. Or is it more a matter of which OS is running?

Fair enough. I'll preface this with the disclaimer that I've only looked into this with respect to windows directx gaming - if anything I'd expect Android to require less driver overhead on gaming. Going from dual core to quad core for some the majority of games can increase performance by single/low double digit percentages due to overhead/background tasks. There are a few games that are actually making use of multiple cores now, but they're still in the minority and who knows how long it'll be before they show up in the mobile space. But yeah, the only reason you typically see slight gains going from dual core to quad core in gaming is that you have two primary threads - one for the game logic and another for the graphics driver. If both of them can pretty much use up an entire core then performance has to drop slightly on a dual core due to remaining system tasks having to slip in somewhere whereas on a quad core they can keep one of the other two cores at 5-10% load. Regardless, a minimal performance increase at the cost of doubling die area used for the CPU cores is a pretty pathetic trade-off, even moreso when considering the power implications. You're far better off increasing frequency/single threaded performance to compensate when dealing with that kind of workload. Two cores that can run at max turbo frequency are going to run that workload faster than a quad core running at 80% of that same max frequency. (As a side note, it actually is rather interesting to do performance profiling of computer games - it's too bad I don't have an AMD card capable of running mantle as I'm quite curious to see how that actually changes the driver thread CPU usage.)

As for tablets versus phones, for typical tablet usage? Nope, there really isn't a need for quad core parts there either. Baytrail-T does venture into the realm of productivity tablets and there are more potential use cases for a quad core SoC there... though I still wouldn't try to claim it's necessary. Really, about the only time I notice a dual core machine to be more slow than a quad core in normal usage is when initially opening up Chrome - the dual core takes that much longer to re-open the 50+ tabs I have open compared to quad core... dunno how applicable that manner of browsing is to a tablet though.

I'd definitely be curious as to your thoughts on the matter though - what workloads on smartphones and tablets actually make use of more than two CPU cores? Especially on Android since there Intel's x86 compatibility doesn't have the potential to have a tablet being used to run typical notebook/desktop tasks.

 

[bullzz]

chromeOS coming to bay trail?
http://www.phoronix.com/scan.php?page=news_item&px=MTYxMzg

 

[Homeles]

You'd be hard-pressed to find a better match for Chromebooks. You'd also be hard-pressed to find a use for them.

 

[Sweepr]

Merrifield could find its way into tablets, there were quite a few Medfield-based tablets. Dual-core would hurt marketing but 2C Silvermont + PowerVR Rogue would allow some nice and cheap 64-bit capable Android tablets. I'd like to see a picture of Merrifield's die, I bet its quite small.

The fact that Qualcomm didnt announce a 64-bit successor to S800 is good for Moorefield. It should be interesting to see how it fares against Tegra K1 ''Project Denver'' later this year and which of them launches first.

 

[Nothingness]

What will 64-bit bring to Android now? Exactly nothing except for marketing, so why are you expecting it?

 

[Homeles]

What will 64-bit bring to Android now? Exactly nothing except for marketing, so why are you expecting it?

Come on, we've proven this wrong time and time again. There are more benefits to 64-bit than increased address space, both for x64 and 64-bit ARM.

 

[witeken]

If OEMs really want 64-bit, than Intel has a higher chance of selling their SoCs since they're the only one that can sell those.

@Homeles, you mean that 10% speed increase?

 

[Sweepr]

Exactly nothing except for marketing, so why are you expecting it?

Moorefield is Intel's first quad-core, 64-bit capable phone/tablet SoC that packs a competent LTE modem. I'm not saying I care about having +2 cores in phones, but for marketing purposes, quad-core + 64-bit would be an interesting way to differentiate themselves from Tegra K1 ''Denver'' (dual-core, 64-bit) and S805 (quad-core, 32-bit).

 

[Nothingness]

Come on, we've proven this wrong time and time again. There are more benefits to 64-bit than increased address space, both for x64 and 64-bit ARM.

I am specifically talking about Android at this time. 64-bit is even less useful than silly ARM octocores. Of course in the future 64-bit will be mandatory, but in the coming months it will be completely useless except for marketing.

Again 64-bit won't bring any significant speed advantage. Just look at SPEC2000 and SPEC2006 results and see how compilers are forced into 32-bit code generation for some tests, except of course Crafty which Intel selected as an example of how good 64-bit is (Crafy is using 64-bit bitboard data structure so it benefits a lot from 64-bit integer instructions).

Let's pick some recent SPEC2006 entry:
http://www.spec.org/cpu2006/results/res2014q1/cpu2006-20140107-27910.html

Peak Compiler Invocation
C benchmarks (except as noted below):
      icc -m64 
400.perlbench:  icc -m32 
445.gobmk:      icc -m32 
464.h264ref:    icc -m32 
C++ benchmarks (except as noted below):
     icpc -m32 
473.astar:      icpc -m64

So out of 12 sb-benches, 5 were forced into 32-bit only mode. And *all* benchmarks were compiled with the -auto-p32 flag which tells Intel compiler to try as hard as possible to reduce pointer sizes to 32-bit (an option gcc lacks, which means most Android programs won't benefit from that nice trick).

In fact, 64-bit will probably help more ARM than Intel, given that ARM can vectorize floating-point instructions only when using the 64-bit ISA (something that was shown by Anand when comparing 32-bit vs 64-bit Geekbench on iPhone).

@Sweepr: I definitely agree with you. 64-bit is good for marketing

 

[mikk]

I'd like to see a picture of Merrifield's die, I bet its quite small.

According to the die picture Merrifield is ~72mm² big.

 

[podspi]

Aren't there speed benefits from the ISA updates? The 64-bit ISA > 32-bit ISA, although backwards compatibility exists.

I do agree that it is going to be a looong time before 64-bit matters, because unless Google has a mechanism to distribute multiple APKs depending on hardware version, everybody is going to compile for 32-bit anyway.

 

[Nothingness]

Aren't there speed benefits from the ISA updates? The 64-bit ISA > 32-bit ISA, although backwards compatibility exists.

For x86 not that much: the main benefit is that there are twice as many registers, but many advanced microarchitectures are not that sensitive to that. On the other hand addresses are twice larger which means more cache is used to store them (this is the reason why, as I wrote above, many SPEC200x benchmarks are compiled for 32-bit x86 ISA).

For ARM, the switch has a big benefit: SIMD instructions use IEEE floating point in 64-bit mode.

 

[witeken]

But ISA improvements have nothing to do with 64-bit.

 

[Nothingness]

But ISA improvements have nothing to do with 64-bit.

I don't understand what you mean.

 

[Nothingness]

To clear things up, I decided to get some numbers for 32-bit vs 64-bit, so I tried on an ASUS T100 running 64-bit Ubuntu.

nbench: http://www.tux.org/~mayer/linux/bmark.html
Compiler: gcc 4.8.1

./nbench-64
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          861.92  :      22.10  :       7.26
STRING SORT         :          308.16  :     137.69  :      21.31
BITFIELD            :      2.9275e+08  :      50.22  :      10.49
FP EMULATION        :           217.8  :     104.51  :      24.12
FOURIER             :           13853  :      15.75  :       8.85
ASSIGNMENT          :          23.129  :      88.01  :      22.83
IDEA                :            3717  :      56.85  :      16.88
HUFFMAN             :          1536.3  :      42.60  :      13.60
NEURAL NET          :          20.335  :      32.67  :      13.74
LU DECOMPOSITION    :           822.4  :      42.60  :      30.76
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 61.702
FLOATING-POINT INDEX: 27.988
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : 4 CPU GenuineIntel Intel(R) Atom(TM) CPU  Z3740  @ 1.33GHz 1331MHz
L2 Cache            : 1024 KB
OS                  : Linux 3.11.0-12-generic
C compiler          : gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9) 
libc                : libc-2.17.so
MEMORY INDEX        : 17.216
INTEGER INDEX       : 14.160
FLOATING-POINT INDEX: 15.523
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

./nbench-32
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          836.04  :      21.44  :       7.04
STRING SORT         :          323.88  :     144.72  :      22.40
BITFIELD            :      3.6238e+08  :      62.16  :      12.98
FP EMULATION        :          180.16  :      86.45  :      19.95
FOURIER             :          6675.7  :       7.59  :       4.26
ASSIGNMENT          :          24.142  :      91.87  :      23.83
IDEA                :          3302.7  :      50.51  :      15.00
HUFFMAN             :            1480  :      41.04  :      13.11
NEURAL NET          :          18.755  :      30.13  :      12.67
LU DECOMPOSITION    :          945.96  :      49.01  :      35.39
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 61.090
FLOATING-POINT INDEX: 22.380
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : 4 CPU GenuineIntel Intel(R) Atom(TM) CPU  Z3740  @ 1.33GHz 532MHz
L2 Cache            : 1024 KB
OS                  : Linux 3.11.0-12-generic
C compiler          : gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9) 
libc                : libc-2.17.so
MEMORY INDEX        : 19.065
INTEGER INDEX       : 12.890
FLOATING-POINT INDEX: 12.412
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

64-bit memory index is ~10% worse, integer is ~10% better, FP is ~25% better.

 

[NTMBK]

But ISA improvements have nothing to do with 64-bit.

x64 brings several changes other than just 64-bit addressing. It doubles the number of SSE registers, for a start.

 

[witeken]

I don't understand what you mean.

Homeles states that their are more improvements to 64-bit than just more address space. But as far as I know, that isn't true. 64-bit address space is just that: the ability to use more RAM (+ about 10% performance boost).

x64 brings several changes other than just 64-bit addressing. It doubles the number of SSE registers, for a start.

Sure, but what has that to do with "64-bit"?