By: Sylvain Collange (full.name.delete.delete@this.this.gmail.com), July 12, 2013 2:29 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 11, 2013 11:20 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.
Even that is likely a bad idea. NEON's floating-point is not IEEE-754-1985-compliant (no subnormals). Enabling NEON on your own code when you know what you are doing is probably fine, but JITing existing code to an ISA that follows a non-standard FP model is just asking for trouble.
NEON is still fine for integer workloads, but are there that many vectorizable integer loops in high-level code?
Sylvain
> > 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.
Even that is likely a bad idea. NEON's floating-point is not IEEE-754-1985-compliant (no subnormals). Enabling NEON on your own code when you know what you are doing is probably fine, but JITing existing code to an ISA that follows a non-standard FP model is just asking for trouble.
NEON is still fine for integer workloads, but are there that many vectorizable integer loops in high-level code?
Sylvain