We believe that JS can run significantly faster than V8 runs it right
now, and are actively working on that.
>> PNaCL will have very similar restrictions if it ever happens. That's just life if you actually want to create portable code.
>> OK, what makes you think that they can be done via PNaCL without such porting?
> 1. but it would be open source by the start
But not open contribution and not open control. So you can fork it, but
good luck getting your changes into it, given how other such projects
seem to work...
>- likely to be more innovative and in many ways better.
Permit me my doubts.
> 2. this - http://www.ogre3d.org/forums/viewtopic.php?f=4&t=66394 - man said
> "The idea is to compile c and c++ and in a special way, a protected
> way, a cross platform way.
> Google released an SDK for NaCl that includes a compiler, "c run time"
> h files and libraries –in a form that is similar to Linux gcc and its
> accompanied files, so compiling existing project that already compile
> for Linux is not that hard."
That's not talking about PNaCl.
I already pointed out the major problem with NaCl from a web point of
That's not actually obvious.
For example, "native assembly code" does not always run faster than Java
runs on the JVM...
performance than compiling it to native code directly, but the gap is
already only 2x for a number of programs (comparing to gcc -O3). And
that's with today's SpiderMonkey. We can do better, and plan to.
Again, what's shipping right now is bad for the web. The
architecture-independent part is vaporware so far; we'll see whether it
ever happens and if so how well it works.
> and in the meantime avoid the spread of instruction set architecture dependent apps on the
> BTW the hardware emulation is very good now as i'v seen that last
> time.. but i'd rather - suggest latter to Mozilla, as it is what uses
> their direct competitor.
I don't follow. What competitor.
> Sure, i'm with you for interoperability, please read about that "next
> milestone for Native Client" above
I know about it. I also know that it's a very hard problem and they
don't know how to solve it yet.
>> It's not better, because it still fails the basic "does not create lock-in" test.
> they are open source
So? So is Android. Supposedly. Good luck upstreaming patches.
> i consider the CSS 3D transformations as the
> lock-in currently as they work on iOS but not on Mozilla Mobile.
We're shipping them on Mozilla Mobile in a few months.
> And otherwise WebGL works on Mozilla Mobile but not in iOS..
There's nothing preventing it from working on iOS a priori.
That's not the same situation as x86-compiled NaCl. Try running that on
an ARM chip.
> You could always wait for the better solution or some JS compilers magic but i
> don't want to..
You're waiting for PNaCl right now! Why do you think that wait time
(for what is at the moment a "we have no idea how to really make it
work" research project, as far as I can tell) will be smaller than the
wait time for in-progress JS compiler work that's well understood and
happening right this second?
> but do you agree that if that pain would eventually be the lesser pain
> than to learn JS for someone who loves C++ that tool -- would be right
> for the job?