Article: Medfield, Intel's x86 Phone Chip
By: David Kanter (dkanter.delete@this.realworldtech.com), January 24, 2012 10:13 pm
Room: Moderated Discussions
Wilco (Wilco.Dijkstra@ntlworld.com) on 1/24/12 wrote:
---------------------------
>David Kanter (dkanter@realworldtech.com) on 1/24/12 wrote:
>---------------------------
>>Wilco (Wilco.Dijkstra@ntlworld.com) on 1/24/12 wrote:
>>---------------------------
>>>David Kanter (dkanter@realworldtech.com) on 1/23/12 wrote:
>>>---------------------------
>>>
>>>"Realistically, Medfield will not have a decisive performance advantage over platforms
>>>like TI’s OMAP5 or the Snapdragon S4. At best, Medfield will be slightly ahead of
>>>the competition; but in many cases Intel’s performance may >lag by 10-30%."
>>
>>Actually, I updated the article...the new language you might find more reasonable.
>
>The new version is more accurate, but still suggests that Medfield could be faster
>than an A15 or Krait. There is no way Medfield would be close, whether you compare
>at max frequency, equal frequency or equal watts. Unless of course you're talking
>about Intel marketing numbers, not actual products.
>
>>>I can't believe how anyone could seriously suggest that Medfield will be competitive
>>>or even have a performance advantage over 1.5-2GHz dual core Krait or A15, especially
>>>given the fact that a 1GHz A9 outperforms an 1.6GHz Atom.
>>
>>We've been over this before...there's no way that an A9 has a 30-40% advantage
>>in terms of effective IPC. Most A9s have a crappy memory hierarchy and lose in a variety of benchmarks.
>
>We've seen a few benchmarks showing how well the A9 does vs >1.6GHz netbook Atoms,
I would hesitate to call them benchmarks.
>which may not be perfect, but they tell a different story than what Intel claims.
>Unless Medfield has significantly improved IPC, I'd expect it to be a little slower
>than the netbook variants due to a slower memory system in >mobiles.
Again, I place far greater stock in SPECint than the other benchmarks I've seen. You obviously differ in that regard.
>Also it can't run indefinitely at 1.6GHz.
Which I scrupulously noted : )
>If anything, I expect Medfield running at lower frequencies, having lower memory
>bandwidth, and using smaller L2 caches than the 28nm SoCs >coming out this year.
You're probably right, but we'll see. Also remember that Medfield has been sampling for a while, while 28nm designs are just starting. So there's a bit of a time skew between them (e.g. in comparison to OMAP5 and S4, which are a much cleaner comparison).
>>>Even in the few cases where x86 software is more finetuned, ie. JIT compilation, the unreleased Medfield shows no advantage over shipping mobiles: http://androidandme.com/2012/01/news/intel-medfield-vs-nvidia-tegra-3-performance-preview/
>>
>>>Assuming there are no further JIT improvements on the ARM side (unlikely), at the
>>>end of 2012 Medfield will be 50% slower on Caffeinemark. And that is Intel's best
>>>benchmark... Medfield will do far worse on everything else, >especially on mulithreading.
>>
>>So what is your estimate for the performance of Medfield on SPECint2000 relative to say, OMAP5, Tegra3 or S4?
>
>Are we comparing compiler tricks or micro architectures?
Do you compile your code? Of course you take the compiler into account, but I think it's fair to stipulate both estimates.
>Assuming similar compiler
>technology, I'd estimate A9 to be 20-30% faster, and A15/Krait to be 60-100% faster
>at the same frequency - obviously varying considerably with >the L2 size and memory of the SoC.
What does similar compiler technology mean? For the purposes of SPEC, I'd assume the optimal compiler for each platform, and base submission rules.
>>>So how could you possibly justify the claim that a 1.6GHz ?2-way in-order single
>>>core is faster or only a little slower than a 2GHz 3-way >OoO dual core?
>>
>>Because the performance gains for ARM licensees are limited by power consumption.
>
>Sure, but the efficiency (performance per Watt) isn't the same. Eg. Tegra3 can
>run 2 cores at 1GHz using less power than Medfield at 1.6GHz (http://www.nvidia.com/content/PDF/tegra_white_papers/Variable-SMP-A-Multi-Core-CPU-Architecture-for-Low-Power-and-High-Performance.pdf).
>That's approximately twice the perf/Watt despite being 1 process node behind. Obviously
>these are NVidia vs Intel marketing numbers, so not necessarily reliable, but it gives an idea where things >stand.
NV's estimated numbers are not really comparable to Intel's measured numbers, they were measured in different ways on totally different workloads. NV's estimates are using coremark (again, rubbish benchmarks and what SKU/bin?), while Intel's numbers are measured for median bin and a worse case single threaded workload. There are a lot of differences to factor out.
>>You don't get 70% more performance while still having something recognizable as a cell phone.
>
>A process node change can give that kind of improvement due >to faster and lower power transistors.
No it's can't. You might get 20-30%.
>>I'm willing to accept 30% higher performance at the same power consumption, although that sounds generous.
>
>There aren't any numbers available for 28nm, but I don't >think things will change
>in Medfields favour - overall performance/Watt will improve >further in the next generation ARM SoCs.
There are numbers available for 28nm from IEDM, and you can see how it compares to prior generations.
David
---------------------------
>David Kanter (dkanter@realworldtech.com) on 1/24/12 wrote:
>---------------------------
>>Wilco (Wilco.Dijkstra@ntlworld.com) on 1/24/12 wrote:
>>---------------------------
>>>David Kanter (dkanter@realworldtech.com) on 1/23/12 wrote:
>>>---------------------------
>>>
>>>"Realistically, Medfield will not have a decisive performance advantage over platforms
>>>like TI’s OMAP5 or the Snapdragon S4. At best, Medfield will be slightly ahead of
>>>the competition; but in many cases Intel’s performance may >lag by 10-30%."
>>
>>Actually, I updated the article...the new language you might find more reasonable.
>
>The new version is more accurate, but still suggests that Medfield could be faster
>than an A15 or Krait. There is no way Medfield would be close, whether you compare
>at max frequency, equal frequency or equal watts. Unless of course you're talking
>about Intel marketing numbers, not actual products.
>
>>>I can't believe how anyone could seriously suggest that Medfield will be competitive
>>>or even have a performance advantage over 1.5-2GHz dual core Krait or A15, especially
>>>given the fact that a 1GHz A9 outperforms an 1.6GHz Atom.
>>
>>We've been over this before...there's no way that an A9 has a 30-40% advantage
>>in terms of effective IPC. Most A9s have a crappy memory hierarchy and lose in a variety of benchmarks.
>
>We've seen a few benchmarks showing how well the A9 does vs >1.6GHz netbook Atoms,
I would hesitate to call them benchmarks.
>which may not be perfect, but they tell a different story than what Intel claims.
>Unless Medfield has significantly improved IPC, I'd expect it to be a little slower
>than the netbook variants due to a slower memory system in >mobiles.
Again, I place far greater stock in SPECint than the other benchmarks I've seen. You obviously differ in that regard.
>Also it can't run indefinitely at 1.6GHz.
Which I scrupulously noted : )
>If anything, I expect Medfield running at lower frequencies, having lower memory
>bandwidth, and using smaller L2 caches than the 28nm SoCs >coming out this year.
You're probably right, but we'll see. Also remember that Medfield has been sampling for a while, while 28nm designs are just starting. So there's a bit of a time skew between them (e.g. in comparison to OMAP5 and S4, which are a much cleaner comparison).
>>>Even in the few cases where x86 software is more finetuned, ie. JIT compilation, the unreleased Medfield shows no advantage over shipping mobiles: http://androidandme.com/2012/01/news/intel-medfield-vs-nvidia-tegra-3-performance-preview/
>>
>>>Assuming there are no further JIT improvements on the ARM side (unlikely), at the
>>>end of 2012 Medfield will be 50% slower on Caffeinemark. And that is Intel's best
>>>benchmark... Medfield will do far worse on everything else, >especially on mulithreading.
>>
>>So what is your estimate for the performance of Medfield on SPECint2000 relative to say, OMAP5, Tegra3 or S4?
>
>Are we comparing compiler tricks or micro architectures?
Do you compile your code? Of course you take the compiler into account, but I think it's fair to stipulate both estimates.
>Assuming similar compiler
>technology, I'd estimate A9 to be 20-30% faster, and A15/Krait to be 60-100% faster
>at the same frequency - obviously varying considerably with >the L2 size and memory of the SoC.
What does similar compiler technology mean? For the purposes of SPEC, I'd assume the optimal compiler for each platform, and base submission rules.
>>>So how could you possibly justify the claim that a 1.6GHz ?2-way in-order single
>>>core is faster or only a little slower than a 2GHz 3-way >OoO dual core?
>>
>>Because the performance gains for ARM licensees are limited by power consumption.
>
>Sure, but the efficiency (performance per Watt) isn't the same. Eg. Tegra3 can
>run 2 cores at 1GHz using less power than Medfield at 1.6GHz (http://www.nvidia.com/content/PDF/tegra_white_papers/Variable-SMP-A-Multi-Core-CPU-Architecture-for-Low-Power-and-High-Performance.pdf).
>That's approximately twice the perf/Watt despite being 1 process node behind. Obviously
>these are NVidia vs Intel marketing numbers, so not necessarily reliable, but it gives an idea where things >stand.
NV's estimated numbers are not really comparable to Intel's measured numbers, they were measured in different ways on totally different workloads. NV's estimates are using coremark (again, rubbish benchmarks and what SKU/bin?), while Intel's numbers are measured for median bin and a worse case single threaded workload. There are a lot of differences to factor out.
>>You don't get 70% more performance while still having something recognizable as a cell phone.
>
>A process node change can give that kind of improvement due >to faster and lower power transistors.
No it's can't. You might get 20-30%.
>>I'm willing to accept 30% higher performance at the same power consumption, although that sounds generous.
>
>There aren't any numbers available for 28nm, but I don't >think things will change
>in Medfields favour - overall performance/Watt will improve >further in the next generation ARM SoCs.
There are numbers available for 28nm from IEDM, and you can see how it compares to prior generations.
David
Topic | Posted By | Date |
---|---|---|
Medfield article online | David Kanter | 2012/01/23 01:51 PM |
server error | bakaneko | 2012/01/24 03:00 AM |
Fixed | David Kanter | 2012/01/24 04:02 AM |
Fixed | Joel | 2012/01/24 07:43 AM |
Fixed | Ricardo B | 2012/01/24 11:25 AM |
Fixed | David Kanter | 2012/01/24 05:29 PM |
Fixed | Gabriele Svelto | 2012/01/24 01:07 PM |
Fixed | David Kanter | 2012/01/24 05:30 PM |
Reference platform battery life | Doug Siebert | 2012/01/24 02:03 PM |
standby time | Foo_ | 2012/01/25 06:58 AM |
standby time | Anon | 2012/01/26 03:42 AM |
standby time | Foo_ | 2012/01/26 04:02 AM |
standby time | Doug Siebert | 2012/01/26 12:39 PM |
standby time | Anon | 2012/01/26 01:22 PM |
standby time | anon | 2012/01/26 02:08 PM |
standby time | Anon | 2012/01/26 06:03 PM |
standby time | anon | 2012/01/26 08:57 PM |
standby time | anon | 2012/01/26 09:01 PM |
standby time | Anon | 2012/01/27 09:32 PM |
standby time | Doug Siebert | 2012/01/27 02:15 PM |
standby time | anon | 2012/01/27 02:41 PM |
Reference platform battery life | David Kanter | 2012/01/27 10:09 AM |
Performance analysis laughable | Wilco | 2012/01/24 03:23 PM |
Performance analysis laughable | David Kanter | 2012/01/24 05:19 PM |
Performance analysis laughable | IntelUser2000 | 2012/01/24 07:30 PM |
Performance analysis laughable | IntelUser2000 | 2012/01/24 07:32 PM |
Performance analysis laughable | David Kanter | 2012/01/24 11:34 PM |
Performance analysis laughable | IntelUser2000 | 2012/01/24 11:56 PM |
Performance analysis laughable | David Kanter | 2012/01/25 02:07 AM |
Performance analysis laughable | Alberto | 2012/01/25 12:54 PM |
Atom HT gain | Wilco | 2012/01/25 05:43 AM |
Atom HT gain | IntelUser2000 | 2012/01/25 06:53 AM |
Atom HT gain | none | 2012/01/25 07:04 AM |
Atom HT gain | IntelUser2000 | 2012/01/25 07:35 AM |
Atom HT gain | Foo_ | 2012/01/25 07:06 AM |
Performance analysis laughable | Wilco | 2012/01/24 08:21 PM |
Performance analysis laughable | David Kanter | 2012/01/24 10:13 PM |
Performance analysis laughable | Wilco | 2012/01/25 04:30 AM |
Performance analysis laughable | none | 2012/01/25 06:14 AM |
Performance analysis laughable | Wilco | 2012/01/25 07:18 AM |
Performance analysis laughable | observer | 2012/01/26 04:17 AM |
Performance analysis laughable | Wilco | 2012/01/26 06:25 AM |
Process numbers | Alberto | 2012/01/26 09:29 AM |
Performance analysis laughable | David Kanter | 2012/02/02 12:38 AM |
Performance analysis laughable | tupper | 2012/01/25 04:27 PM |
Performance analysis laughable | Linus Torvalds | 2012/01/25 08:37 PM |
Performance analysis laughable | Doug Siebert | 2012/01/26 02:12 PM |
Medfield article online | Andreas | 2012/01/25 03:10 AM |
Medfield article online | Alberto | 2012/01/25 09:44 AM |
Medfield article online | IntelUser2000 | 2012/01/25 10:24 AM |
Medfield article online | David Kanter | 2012/01/25 09:58 PM |
Medfield article online | Doug Siebert | 2012/01/26 01:20 PM |
Medfield article online | Eric | 2012/01/26 06:10 PM |
Medfield article online | Doug Siebert | 2012/01/27 02:40 PM |
64-bit | Ingeneer | 2012/01/25 09:28 AM |
64-bit | Foo_ | 2012/01/25 10:23 AM |
64-bit | Ingeneer | 2012/01/25 02:34 PM |
64-bit | Ungo | 2012/01/25 04:08 PM |
64-bit | EduardoS | 2012/01/26 12:55 PM |
Saltwell memcpy | SHK | 2012/01/26 02:41 AM |
Medfield WiFi & Bluetooth | Rob Thorpe | 2012/01/26 03:09 AM |
Medfield WiFi & Bluetooth | David Kanter | 2012/01/27 05:54 PM |
Medfield WiFi & Bluetooth | Rob Thorpe | 2012/01/28 02:22 PM |
Medfield article online (NT) | Anil | 2012/01/26 05:57 PM |
Medfield article online | Anil | 2012/01/26 06:11 PM |
Medfield article online | Mr. Camel | 2012/01/26 06:26 PM |
Medfield article online | none | 2012/01/27 01:41 AM |