Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 11, 2013 10:57 am wrote:
> bakaneko (nyan.delete@this.hyan.wan) on July 11, 2013 12:02 am wrote:
> >
> > 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.
>
> Any sane person will agree that AnTuTu is crap, and that using icc is odd.
>
> But that last statement of yours is laughably incorrect.
>
> No sane person uses NEON, because NEON isn't available in most ARM implementations. In
> fact, even if you only look at higher-end ARM ("They all have NEON, right?"), it turns
> out that NEON is an optional feature (idiotic ARM waffling, even for Cortex-A9), and
> isn't available in some reasonably common chips (ie Tegra 2 or the SPEAr chips).

So what! If you care about using SIMD
optimized code so much that you leave
the java sandbox you either need to
write all of it by hand or you need
to trust gcc that it has runtime checks.

This isn't a matter of ARM doing it
wrong, its if you can trust your
compiler/runtime.

It boils down to gcc not generating
NEON code by default and the OS
not patching the code at load time.

(And to be honest, I don't care much
for people who hand optimize SIMD code
for microarchitecture X using
assembler, at that point your software
group has already turned into a slave
labour camp. And 2-3 microarchitectures
later all their work will be outdated
anyway, so backward compatibilty my
ass if that is your reason.)

> [...] many sane implementations
> simply cannot use them, or have to use them exclusively behind a library interface (which in
> turn tends to defeat all performance advantages except for very specific cases).

Inside Java the existence of NEON doesn't
matter to the programmer. There are only
library interfaces.