none (none.delete@this.none.com) on July 11, 2013 4:44 am wrote:
> Klimax (danklima.delete@this.gmail.com) on July 11, 2013 3:00 am wrote:
> > none (none.delete@this.none.com) on July 11, 2013 1:49 am wrote:
> > > Klimax (danklima.delete@this.gmail.com) on July 11, 2013 12:28 am wrote:
> > > [...]
> > > > Are there any Java/Dalvik benchmarks for Android?
> > >
> > > Yes, and some are looking bad for Intel CT+.
> > >
> > > For instance for AndEBench Java the K900 (dual Saltwell + HT @ 2.0 GHz) gets 222 while A15 and
> > > Krait based Galaxy S4 get close to 600. And if you insist on dual core, Nexus 10 (dual A15) gets
> > > 379, while Samsung Galaxy Note (a device more than a year old, dual A9 @ 1.4GHz) gets 213.
> > >
> > > http://www.eembc.org/andebench/
> > >
> > > Of course that's a single point and no conclusion should be drawn on these results alone.
> > >
> > > > Anyway it is trivial to write bad benchmark. (And that's before
> > > > vendors get interested like with ScienceMark or AIDA...)
> > >
> > > And that's all that matters in the end: this particular benchmark has now been proven to heavily
> > > favor Intel, so it has become useless for comparing micro-architecture performance.
> > >
> > > I now wait for evidence that Geekbench favors ARM, and I somehow think
> > > nothing as obvious as what was found with AnTuTu will be uncovered.
> > >
> > So far:
> > http://forums.anandtech.com/showpost.php?p=35246412&postcount=13
> > from http://investorshub.advfn.com/boards/read_msg.aspx?message_id=88008447
> > Similar case as absence of NEON instructions. (Conservative or unusual compiler settings...)
> >
> > I'll run it through Intel VTune Amplifier and will see how it does. (Note that often dataset
> > from tool is in range of gigabytes of data) Only on 3930k, because I don't have currently
> > Atom PC online, but denormals IIRC are handled by microcode in precise situation.
>
> Similar as absence of NEON? Unless you show that the ARM version isn't
> also handling denormals this doesn't prove Geekbench favors ARM.
>
> I will save you some time: the x86 Android version uses SSE(2), not x87.
> Just look at the disassembly of _ZN10DotProduct12workerScalarEi
>
> Now if you can also explain with denormals why CT+ is beaten by A15 and
> Krait even for single threaded integer tasks, I'm very interested :-)
>

So why Geekbench is dominantly composed of x87 opcodes and x87 fp assists measured by VTune? (SSE is found in few bursts, which would point at few hand vectorized functions most likely located in libraries)
Note: A single instance is not indicative of overall...
Note 2: It is looking more like conservative 32 bit binary without much of optimizations enabled.
Note 3: It is very black box benchmark, where not much is known nor obtainable.