By: bakaneko (nyan.delete@this.hyan.wan), July 12, 2013 2:28 am
Room: Moderated Discussions
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.
Then just turn the JIT/virtual machine/whatever
into a full blown compiler backend already. GPU
drivers have one built in, no excuse for the
java sandbox not to do it.
Vectorization is hard either way. The only
reason not to do it at runtime is because you
never trusted a compiler to do a proper job and
needed to test the vectorized code before
deploying it.
> 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.
Then just turn the JIT/virtual machine/whatever
into a full blown compiler backend already. GPU
drivers have one built in, no excuse for the
java sandbox not to do it.
Vectorization is hard either way. The only
reason not to do it at runtime is because you
never trusted a compiler to do a proper job and
needed to test the vectorized code before
deploying it.