Article: Medfield, Intel's x86 Phone Chip
By: David Kanter (dkanter.delete@this.realworldtech.com), February 2, 2012 12:38 am
Room: Moderated Discussions
Wilco (Wilco.Dijkstra@ntlworld.com) on 1/25/12 wrote:
>>>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.
When will Tegra3+ and OMAP4470 phones be available?
>>>>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!
So provide your performance estimates for tuned code and 'baseline optimization' (and let us know what those represent)...
>>>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.
Intel's compiler is used in production, for extremely large and complex projects such as Oracle's database. If you're going to compare armcc, then frankly icc is just as reasonable.
>>>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.
No. Intel's numbers are for a median bin. I have no idea what bin Nvidia was using. MOREOVER THEY ARE DIFFERENT WORKLOADS.
> Running micro benchmarks like
>Dhrystone/CoreMark gives close to maximum power >consumption.
I sincerely doubt that, since Dhrystone uses no FP. Do you have any evidence to support that notion?
>>>>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.
No that shows nothing. That's marketing brochures, not peer reviewed papers like those shown at IEDM. What is the comparison to? 28nm SiON, or 28nm HKMG and with what types of enhancement? At what PVT? You cannot infer anything based on what is stated.
David
>>>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.
When will Tegra3+ and OMAP4470 phones be available?
>>>>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!
So provide your performance estimates for tuned code and 'baseline optimization' (and let us know what those represent)...
>>>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.
Intel's compiler is used in production, for extremely large and complex projects such as Oracle's database. If you're going to compare armcc, then frankly icc is just as reasonable.
>>>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.
No. Intel's numbers are for a median bin. I have no idea what bin Nvidia was using. MOREOVER THEY ARE DIFFERENT WORKLOADS.
> Running micro benchmarks like
>Dhrystone/CoreMark gives close to maximum power >consumption.
I sincerely doubt that, since Dhrystone uses no FP. Do you have any evidence to support that notion?
>>>>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.
No that shows nothing. That's marketing brochures, not peer reviewed papers like those shown at IEDM. What is the comparison to? 28nm SiON, or 28nm HKMG and with what types of enhancement? At what PVT? You cannot infer anything based on what is stated.
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 |