By: bakaneko (nyan.delete@this.hyan.wan), July 11, 2013 12:02 am
Room: Moderated Discussions
Klimax (danklima.delete@this.gmail.com) on July 10, 2013 10:03 pm wrote:
> Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on July 10, 2013 7:59 pm wrote:
> > none (none.delete@this.none.com) on July 10, 2013 11:46 am wrote:
> > > none (none.delete@this.none.com) on June 9, 2013 3:11 pm wrote:
> > > > tarlinian (tarlinian.delete@this.gmail.com) on June 9, 2013 2:00 pm wrote:
> > > > > Kevin G (kevin.delete@this.cubitdesigns.com) on June 8, 2013 2:18 pm wrote:
> > > > > > John (Jngu14.delete@this.gmail.com) on June 8, 2013 6:28 am wrote:
> > > > > > > Jason (oxkct.delete@this.7tags.com) on June 7, 2013 1:56 pm wrote:
> > > > > > > > I guess this explains why Samsung went with Intel over their own Exynos on the Galaxy
> > > > > > > > Tab. Look at how the Lenovo K800 (Atom) compared to Galaxy S4 (Exynos/SnapDragon) :
> > > > >
> > > > > > A bit of Google-fu points toward any relevant information being behind a paywall at
> > > > > > ABI Research. Everywhere else seems to be parroting the same Business Wire story.
> > > > >
> > > > > If anyone's interested, the ABI post acting as advertising for this work can
> > > > > be found here. It has some interesting comment I'm not really sure why they
> > > > > talk about current draw instead of power...it's a rather odd story.
> > > >
> > > > And I bet most of their benchmarks are from AnTuTu which seems to be the only CPU benchmark favoring Intel.
> > >
> > > It seems that indeed AnTuTu has a heavy bias towards Intel and that Abi Research used it:
> > >
> > > http://www.eetimes.com/author.asp?section_id=36&itc=eetimes_sitedefault&doc_id=1318857
> >
> > And Exophase figured out how Intel cheated AnTuTu.
> >
> > Wilco
>
> Proper optimization. If a loop or similar construct can be replaced, then problem is in benchmark
> and its code and not in compiler. Same type of optimization as code elimination, because it
> will never execute or is never used. Or memcpy/memset, which are often inlined for smaller
> variable/array. (Interestingly, similar problems but the other way can be found in Geekbench
> and likely other benchmarks penalizing Atom. See later post in your own link.)
>
> Intel can't be held responsible that ARM's compilers suck at optimizations.
The benchmark is pointless however way you
look at it.
Android is built using gcc, and this benchmark
doesn't compare the builds of the system
software directly.
It doesn't matter for application developers,
because native code is only recommended for
isolated routines called from Java code. And
the last thing any programmer would do is
disable NEON.
And as you said, the benchmark can't even
produce proper assembler code which allows one
to see the speed of certain instruction mixes
or memory access patterns. So its useless for
writing optimized assembler, too.
A lot of hot air, no meat.
> Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on July 10, 2013 7:59 pm wrote:
> > none (none.delete@this.none.com) on July 10, 2013 11:46 am wrote:
> > > none (none.delete@this.none.com) on June 9, 2013 3:11 pm wrote:
> > > > tarlinian (tarlinian.delete@this.gmail.com) on June 9, 2013 2:00 pm wrote:
> > > > > Kevin G (kevin.delete@this.cubitdesigns.com) on June 8, 2013 2:18 pm wrote:
> > > > > > John (Jngu14.delete@this.gmail.com) on June 8, 2013 6:28 am wrote:
> > > > > > > Jason (oxkct.delete@this.7tags.com) on June 7, 2013 1:56 pm wrote:
> > > > > > > > I guess this explains why Samsung went with Intel over their own Exynos on the Galaxy
> > > > > > > > Tab. Look at how the Lenovo K800 (Atom) compared to Galaxy S4 (Exynos/SnapDragon) :
> > > > >
> > > > > > A bit of Google-fu points toward any relevant information being behind a paywall at
> > > > > > ABI Research. Everywhere else seems to be parroting the same Business Wire story.
> > > > >
> > > > > If anyone's interested, the ABI post acting as advertising for this work can
> > > > > be found here. It has some interesting comment I'm not really sure why they
> > > > > talk about current draw instead of power...it's a rather odd story.
> > > >
> > > > And I bet most of their benchmarks are from AnTuTu which seems to be the only CPU benchmark favoring Intel.
> > >
> > > It seems that indeed AnTuTu has a heavy bias towards Intel and that Abi Research used it:
> > >
> > > http://www.eetimes.com/author.asp?section_id=36&itc=eetimes_sitedefault&doc_id=1318857
> >
> > And Exophase figured out how Intel cheated AnTuTu.
> >
> > Wilco
>
> Proper optimization. If a loop or similar construct can be replaced, then problem is in benchmark
> and its code and not in compiler. Same type of optimization as code elimination, because it
> will never execute or is never used. Or memcpy/memset, which are often inlined for smaller
> variable/array. (Interestingly, similar problems but the other way can be found in Geekbench
> and likely other benchmarks penalizing Atom. See later post in your own link.)
>
> Intel can't be held responsible that ARM's compilers suck at optimizations.
The benchmark is pointless however way you
look at it.
Android is built using gcc, and this benchmark
doesn't compare the builds of the system
software directly.
It doesn't matter for application developers,
because native code is only recommended for
isolated routines called from Java code. And
the last thing any programmer would do is
disable NEON.
And as you said, the benchmark can't even
produce proper assembler code which allows one
to see the speed of certain instruction mixes
or memory access patterns. So its useless for
writing optimized assembler, too.
A lot of hot air, no meat.