By: Ian Ameline (ian.ameline.delete@this.gmail.elidethis.com), July 11, 2013 3:20 pm
Room: Moderated Discussions
I'd love to see a comparison of spec int. Not rate -- just spec int -- and of those, gcc is probably the most important benchmark. It would be very enlightening to see it compared across A9, A15, Apples's Swift, nVidias'a latest Tegra, Qualcoms's Krait, and Intel's Saltwell.
And for FP, of course SpecFP -- all these dhrystone/whetstone numbers are complete and total meaningless bullshit.
As for using NEON, on iOS, you can depend on it being there. Autodesk Sketchbook mobile for iOS uses NEON -- and actually won't run if it is not there. (I wrote the NEON code in it -- it's almost all fixed point pixel blending / interpolation math)
-- Ian.
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 11, 2013 11:20 am wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 11, 2013 10:57 am wrote:
> >
> > No sane person uses NEON, because NEON isn't available in most ARM implementations.
>
> Side note: this is where virtual machines can help: JIT'ing to whatever is the underlying
> hardware model. At the same time, JITs are particularly bad at things like vectorization
> for anything but the simplest possible case unless the VM itself has some kind of vector
> model. It's just really hard to vectorize things without lots of contextual information.
>
> But for a "native code" benchmark, I still claim that disabling NEON is actually
> the sane thing to do given the current (and near-future) ARM situation.
>
> In contrast, using SSE on x86 makes sense, because it's universally available.
> So the people here screaming "x86 uses SSE, but ARM doesn't use NEON - unfair"
> don't really understand the issues, and are just making braying noises.
>
> None of that makes AnTuTu a better benchmark, though. Microbenchmarks that don't do real work are universally
> crap. Of course, the ARM people shouldn't really complain - they've been using those kinds of pointless
> benchmarks for decades, and continue to do so (google for "dhrystone MIPS" - there are ARM people who
> use that crap still, and Wilco used to quote it religiously not that long ago)
>
> Linus
And for FP, of course SpecFP -- all these dhrystone/whetstone numbers are complete and total meaningless bullshit.
As for using NEON, on iOS, you can depend on it being there. Autodesk Sketchbook mobile for iOS uses NEON -- and actually won't run if it is not there. (I wrote the NEON code in it -- it's almost all fixed point pixel blending / interpolation math)
-- Ian.
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 11, 2013 11:20 am wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 11, 2013 10:57 am wrote:
> >
> > No sane person uses NEON, because NEON isn't available in most ARM implementations.
>
> Side note: this is where virtual machines can help: JIT'ing to whatever is the underlying
> hardware model. At the same time, JITs are particularly bad at things like vectorization
> for anything but the simplest possible case unless the VM itself has some kind of vector
> model. It's just really hard to vectorize things without lots of contextual information.
>
> But for a "native code" benchmark, I still claim that disabling NEON is actually
> the sane thing to do given the current (and near-future) ARM situation.
>
> In contrast, using SSE on x86 makes sense, because it's universally available.
> So the people here screaming "x86 uses SSE, but ARM doesn't use NEON - unfair"
> don't really understand the issues, and are just making braying noises.
>
> None of that makes AnTuTu a better benchmark, though. Microbenchmarks that don't do real work are universally
> crap. Of course, the ARM people shouldn't really complain - they've been using those kinds of pointless
> benchmarks for decades, and continue to do so (google for "dhrystone MIPS" - there are ARM people who
> use that crap still, and Wilco used to quote it religiously not that long ago)
>
> Linus
