Article: Medfield, Intel's x86 Phone Chip
By: Wilco (Wilco.Dijkstra.delete@this.ntlworld.com), January 25, 2012 4:30 am
Room: Moderated Discussions
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/24/12 wrote:
>>---------------------------
>>>Wilco (Wilco.Dijkstra@ntlworld.com) on 1/24/12 wrote:
>>>---------------------------
>>>>David Kanter (dkanter@realworldtech.com) on 1/23/12 wrote:
>>>>---------------------------
>>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.
I'd be happy to see public SpecInt results. But I question whether they do translate to real world performance on a mobile.
>>Also it can't run indefinitely at 1.6GHz.
>
>Which I scrupulously noted : )
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).
There is not much lag between the first Medfield and Krait products. OMAP5 appears at around the same time as the Motorola Medfield phones. Even if A15 or Krait SoCs slip, there will be faster A9 SoCs such as Tegra3+ and OMAP4470. So Medfield will have to compete with much faster and efficient SoCs from day one.
>>>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.
Compilers and options used matter as much as the micro architecture. The bodged Phoronix results prove that beyond any doubt!
>>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.
For example use GCC or LLVM for both, or VC++ and armcc. Intel's compiler tricks to get good Spec results don't translate into real-world performance, so it is best to use production compilers as those are used in actual products.
>>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.
NV's numbers were measured on a reference design according to the link. Tegra3 isn't binned. Obviously there is a chance parts were cherry picked, but that applies to Intel too. Running micro benchmarks like Dhrystone/CoreMark gives close to maximum power consumption.
>>>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%.
A recent GF/ARM press release about 20nm states: "The 20nm TQV is based on GLOBALFOUNDRIES’ next-generation 20nm platform, which is designed to improve performance by up to 35% and nearly halve power consumption when compared to 28nm technologies.". That shows large improvement are being made.
Wilco
---------------------------
>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:
>>>>---------------------------
>>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.
I'd be happy to see public SpecInt results. But I question whether they do translate to real world performance on a mobile.
>>Also it can't run indefinitely at 1.6GHz.
>
>Which I scrupulously noted : )
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).
There is not much lag between the first Medfield and Krait products. OMAP5 appears at around the same time as the Motorola Medfield phones. Even if A15 or Krait SoCs slip, there will be faster A9 SoCs such as Tegra3+ and OMAP4470. So Medfield will have to compete with much faster and efficient SoCs from day one.
>>>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.
Compilers and options used matter as much as the micro architecture. The bodged Phoronix results prove that beyond any doubt!
>>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.
For example use GCC or LLVM for both, or VC++ and armcc. Intel's compiler tricks to get good Spec results don't translate into real-world performance, so it is best to use production compilers as those are used in actual products.
>>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.
NV's numbers were measured on a reference design according to the link. Tegra3 isn't binned. Obviously there is a chance parts were cherry picked, but that applies to Intel too. Running micro benchmarks like Dhrystone/CoreMark gives close to maximum power consumption.
>>>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%.
A recent GF/ARM press release about 20nm states: "The 20nm TQV is based on GLOBALFOUNDRIES’ next-generation 20nm platform, which is designed to improve performance by up to 35% and nearly halve power consumption when compared to 28nm technologies.". That shows large improvement are being made.
Wilco
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 |