Article: Medfield, Intel's x86 Phone Chip
By: Doug Siebert (foo.delete@this.bar.bar), January 26, 2012 2:12 pm
Room: Moderated Discussions
Linus Torvalds (torvalds@linux-foundation.org) on 1/25/12 wrote:
>
>Graphical applications end up doing several layers of
>indirection through libraries - something that you never
>see in Spec. In fact, most Spec runs are outright lying,
>in that they tend to flatten out even the one layer of
>libraries there is - inlining a ton, and usually statically
>linking the rest.
I fully agree, GUIs are the most visible and important performance component every daily user of any computing device encounters, but are essentially absent from all benchmarking. It is hit obliquely here and there within some Windows benchmarks that test "office" performance by having macros perform a given list of MS Office functions, but it is lost in the noise against stuff like disk I/O and calculations (Excel) and text searching/filtering (Word)
Perhaps this could be rectified to some extent by creating a benchmark to test the GUI, while eliminating other variables as much as possible. To wit, create an iso version of Linux that boots into a RAMdisk like the 'Live' versions do. Have it able to run a test using an xorg driver that's basically a /dev/null. Feed in a pregenerated sequence of mouse events to exercise GNOME and all the lower level libraries by running a few big nasty programs like GIMP, Firefox and Open Office through some simple paces that don't require any heavy computation on their own. Just starting up these applications, opening menus and moving windows around is probably sufficient.
This would exercise the hell out of the icache, branch predictors and so on by running through all the GUI layers, plus the various kernel memory management and I/O layers (but running off a RAMdisk, the disk I/O itself would be abstracted out) While the Windows OS is very different, I think the relative results between two different systems under this test on Linux would be fairly comparable to that which one would find if the same type of test could be legally constructed using Windows.
It may even be possible to create a mostly comparable version using the Android version of Linux as the kernel but the same userspace to give a halfway decent idea of how far apart the ARM CPUs used in Android phones are from the Intel CPUs used in laptops and desktops. It wouldn't be exact but it would be way better than the synthetic benchmarks we have now or the SPEC results we don't have.
>
>Graphical applications end up doing several layers of
>indirection through libraries - something that you never
>see in Spec. In fact, most Spec runs are outright lying,
>in that they tend to flatten out even the one layer of
>libraries there is - inlining a ton, and usually statically
>linking the rest.
I fully agree, GUIs are the most visible and important performance component every daily user of any computing device encounters, but are essentially absent from all benchmarking. It is hit obliquely here and there within some Windows benchmarks that test "office" performance by having macros perform a given list of MS Office functions, but it is lost in the noise against stuff like disk I/O and calculations (Excel) and text searching/filtering (Word)
Perhaps this could be rectified to some extent by creating a benchmark to test the GUI, while eliminating other variables as much as possible. To wit, create an iso version of Linux that boots into a RAMdisk like the 'Live' versions do. Have it able to run a test using an xorg driver that's basically a /dev/null. Feed in a pregenerated sequence of mouse events to exercise GNOME and all the lower level libraries by running a few big nasty programs like GIMP, Firefox and Open Office through some simple paces that don't require any heavy computation on their own. Just starting up these applications, opening menus and moving windows around is probably sufficient.
This would exercise the hell out of the icache, branch predictors and so on by running through all the GUI layers, plus the various kernel memory management and I/O layers (but running off a RAMdisk, the disk I/O itself would be abstracted out) While the Windows OS is very different, I think the relative results between two different systems under this test on Linux would be fairly comparable to that which one would find if the same type of test could be legally constructed using Windows.
It may even be possible to create a mostly comparable version using the Android version of Linux as the kernel but the same userspace to give a halfway decent idea of how far apart the ARM CPUs used in Android phones are from the Intel CPUs used in laptops and desktops. It wouldn't be exact but it would be way better than the synthetic benchmarks we have now or the SPEC results we don't have.
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 |