By: Wilco (Wilco.Dijkstra.delete@this.ntlworld.com), July 12, 2013 2:51 am
Room: Moderated Discussions
Sylvain Collange (full.name.delete.delete@this.this.gmail.com) on July 12, 2013 2:29 am wrote:
> 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.
Denormals are rarely used in FP code, but like most RISCs, the default setting for ARM is flush-to-zero, so it won't make a difference in the results even if you do encounter them. Compilers typically default to a non-IEEE compatible mode as well, so IEEE compliance of denormals is not really relevant.
Compared to a compiler, a JIT has to be fairly conservative with optimizations, especially with FP optimizations in order to avoid producing different results during a single run. Denormals are not really an issue here, it's whether to use multiple accumulators during unrolling etc.
Wilco
> 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.
Denormals are rarely used in FP code, but like most RISCs, the default setting for ARM is flush-to-zero, so it won't make a difference in the results even if you do encounter them. Compilers typically default to a non-IEEE compatible mode as well, so IEEE compliance of denormals is not really relevant.
Compared to a compiler, a JIT has to be fairly conservative with optimizations, especially with FP optimizations in order to avoid producing different results during a single run. Denormals are not really an issue here, it's whether to use multiple accumulators during unrolling etc.
Wilco