3 ms·

Without PNaCl, this feels nothing but regressive, for at least three reasons: 1) JS is awesome precisely because of the common denominator. But because Chrome

by Animus7 15y ago

Without PNaCl, this feels nothing but regressive, for at least three reasons: 1) JS is awesome precisely because of the common denominator. But because Chrome said so, devs should go back to triple-testing everything and dusting off their assembly debugger toolchains? 2) With more and more happening on cloud servers, JS engines being mature, and clients just getting faster, the need for that ultimate level of performance feels ever more irrelevant. 3) ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. And even if Google manages to keep their implementation airtight and standards-conforming, what happens when NaCl takes off and Microsoft takes a crack at it?

yid 15y ago
So what you're saying is that you want a JS-to-NaCl JIT compiler (presuming NaCl is faster than V8).
- Animus7 15y ago
  No, I don't see how JITting JS to NaCl would address any of those issues.
  - yid 15y ago
    > 1) JS is awesome precisely because of the common denominator. But because Chrome said so, devs should go back to triple-testing everything and dusting off their assembly debugger toolchains? If you absolutely need the flexibility or speed that NaCl offers, then by definition you can't get by with just V8 and HTML5. If you can get by with V8+HTML5, and NaCl offers a speed advantage, a JIT compiler will allow you to have the common denominator as well as the improved speed. If you can get by with V8+HTML5 and NaCl isn't a speed advantage, well.... > 2) With more and more happening on cloud servers, JS engines being mature, and clients just getting faster, the need for that ultimate level of performance feels ever more irrelevant. But it's always nice to have more speed anywhere. If NaCl is faster than V8, a JIT compiler will allow you -- again -- to have your common denominator and a higher level of performance. 3) ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. And even if Google manages to keep their implementation airtight and standards-conforming, what happens when NaCl takes off and Microsoft takes a crack at it? Lets assume that implementations can be made secure with enough time and money, two things that this project is endowed with. I presume you're implying that Microsoft would mess up the implementation, making it a nightmare for devs everywhere. With browser shares being as egalitarian as they are, a JIT compiler would put the onus of a correct implementation on the vendor.
    - davej 15y ago
      > If you absolutely need the flexibility or speed that NaCl offers, then by definition you can't get by with just V8 and HTML5. Yes, and in that case perhaps you should not be creating a web app anymore. The web is not the only platform for software development and nor should it be in my opinion.
      - mindcrime 15y ago
        I find it a bit amusing, albeit rather sad, that you got downvoted for saying that. You're exactly right, of course... the web (that is, html/css/js over http) is NOT the only way to distribute apps, and it isn't appropriate for everything. Unfortunately, this war has been lost, in the minds of developers in general. Nearly everyone seems to think that the web-browser is a modern day X server, and that it's The One True Way to remote out UIs or to distribute apps. I do wish people would look beyond this and consider some other options and invest some time and energy on some of the other choices, but it just ain't happening for the most part.
    - ootachi 15y ago
      You really want every web page to be shipping their own JIT (or forcing users to grab it from a CDN)? JavaScript JITs are huge. Also, the idea that you can just ship a JIT in Native Client and have the performance not hugely regress is unproven. Modern JavaScript JITs are fundamentally based around self-modifying code (look up how PICs work). NaCl penalizes self-modifying code by requiring that it run through a verifier. It would require a lot of engineering effort just to avoid huge JS regressions (like this 2.5x slowdown from a year ago [1]); why not spend that manpower to improve JS engines? [1]: http://code.google.com/p/nativeclient/issues/detail?id=731 http://code.google.com/p/nativeclient/issues/detail?id=731
tomjen3 15y ago
1) Only if speeds matters. There are a lot of cases where it dosen't. You can now do this when it does. Also we are talking C/C++ (but really anything that can be compiled to binary code) which is not even close to assembly. 2) For the problems we have today you may be right, but you forget the class of problems that couldn't be done the old way. We can now do them. 3) People will learn not to use MS products? But in all seriousness that will be MS problem. Anyway it is open source, I doubt Google has chosen a license which MS would object to.
abecedarius 15y ago
On point 3, it's not obvious to me that a high-performance Javascript engine can be expected to be safer than NaCl. Which is more complex?
leon_ 15y ago
> the need for that ultimate level of performance feels ever more irrelevant Nah, I don't know. As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog. > ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. It's not much different to downloading and running JS. Heap Spraying attacks are the simplest you can run against a JS vm. Then there's more advanced attacks that abuse the JITs nowadays found in VMs to generate malicious native code. And I bet not many JS VMs check their generated code for sanity - which NaCl on the other hand does.
- davej 15y ago
  > Nah, I don't know. As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog. That's due to shitty coding by the front-end developer of the blog. With power comes responsibility; writing in C is a lot of power but there are far more opportunities to write shitty code.
- mike-cardwell 15y ago
  "As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog" You should try NoScript and/or RequestPolicy for that.
- ootachi 15y ago
  You don't want JavaScript VMs to be running NaCl's verifier on all the code that they generate. That would be a significant performance loss. Remember that JavaScript engines are fundamentally built around self-modifying code, so the verifier would be running all the time.
aufreak3 15y ago
You don't _have_ to use NaCl just because it is available. If you find performance like an order of magnitude away from where you need it to be, NaCl could be one technology to consider. Demanding games come to mind, harvesting spare computing power is another possibility, I'm personally interested in high performance programmable audio (think Max/MSP/Jitter within the browser), etc.
Roritharr 15y ago
For gaming this is a big thing. One thing that limits cool 3D Games on the Web is the lack of good engine technology that can be used without plugins. Unity 3D has shown in cooperation with google that they could run without a plugin through NaCl. I'm really looking forward to this possibility, making the Chrome Webstore as a sales platform even more interesting in the long run.
- kayoone 15y ago
  absolutely, we are working on a Unity browsergame and Native Client is a big thing for us as well.

by Animus7 15y ago

yid 15y ago

So what you're saying is that you want a JS-to-NaCl JIT compiler (presuming NaCl is faster than V8).

Animus7 15y ago
No, I don't see how JITting JS to NaCl would address any of those issues.
- yid 15y ago
  > 1) JS is awesome precisely because of the common denominator. But because Chrome said so, devs should go back to triple-testing everything and dusting off their assembly debugger toolchains? If you absolutely need the flexibility or speed that NaCl offers, then by definition you can't get by with just V8 and HTML5. If you can get by with V8+HTML5, and NaCl offers a speed advantage, a JIT compiler will allow you to have the common denominator as well as the improved speed. If you can get by with V8+HTML5 and NaCl isn't a speed advantage, well.... > 2) With more and more happening on cloud servers, JS engines being mature, and clients just getting faster, the need for that ultimate level of performance feels ever more irrelevant. But it's always nice to have more speed anywhere. If NaCl is faster than V8, a JIT compiler will allow you -- again -- to have your common denominator and a higher level of performance. 3) ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. And even if Google manages to keep their implementation airtight and standards-conforming, what happens when NaCl takes off and Microsoft takes a crack at it? Lets assume that implementations can be made secure with enough time and money, two things that this project is endowed with. I presume you're implying that Microsoft would mess up the implementation, making it a nightmare for devs everywhere. With browser shares being as egalitarian as they are, a JIT compiler would put the onus of a correct implementation on the vendor.
  - davej 15y ago
    > If you absolutely need the flexibility or speed that NaCl offers, then by definition you can't get by with just V8 and HTML5. Yes, and in that case perhaps you should not be creating a web app anymore. The web is not the only platform for software development and nor should it be in my opinion.
    - mindcrime 15y ago
      I find it a bit amusing, albeit rather sad, that you got downvoted for saying that. You're exactly right, of course... the web (that is, html/css/js over http) is NOT the only way to distribute apps, and it isn't appropriate for everything. Unfortunately, this war has been lost, in the minds of developers in general. Nearly everyone seems to think that the web-browser is a modern day X server, and that it's The One True Way to remote out UIs or to distribute apps. I do wish people would look beyond this and consider some other options and invest some time and energy on some of the other choices, but it just ain't happening for the most part.
  - ootachi 15y ago
    You really want every web page to be shipping their own JIT (or forcing users to grab it from a CDN)? JavaScript JITs are huge. Also, the idea that you can just ship a JIT in Native Client and have the performance not hugely regress is unproven. Modern JavaScript JITs are fundamentally based around self-modifying code (look up how PICs work). NaCl penalizes self-modifying code by requiring that it run through a verifier. It would require a lot of engineering effort just to avoid huge JS regressions (like this 2.5x slowdown from a year ago [1]); why not spend that manpower to improve JS engines? [1]: http://code.google.com/p/nativeclient/issues/detail?id=731 http://code.google.com/p/nativeclient/issues/detail?id=731

tomjen3 15y ago

1) Only if speeds matters. There are a lot of cases where it dosen't. You can now do this when it does. Also we are talking C/C++ (but really anything that can be compiled to binary code) which is not even close to assembly. 2) For the problems we have today you may be right, but you forget the class of problems that couldn't be done the old way. We can now do them. 3) People will learn not to use MS products? But in all seriousness that will be MS problem. Anyway it is open source, I doubt Google has chosen a license which MS would object to.

abecedarius 15y ago

On point 3, it's not obvious to me that a high-performance Javascript engine can be expected to be safer than NaCl. Which is more complex?

leon_ 15y ago

> the need for that ultimate level of performance feels ever more irrelevant Nah, I don't know. As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog. > ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. It's not much different to downloading and running JS. Heap Spraying attacks are the simplest you can run against a JS vm. Then there's more advanced attacks that abuse the JITs nowadays found in VMs to generate malicious native code. And I bet not many JS VMs check their generated code for sanity - which NaCl on the other hand does.

davej 15y ago
> Nah, I don't know. As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog. That's due to shitty coding by the front-end developer of the blog. With power comes responsibility; writing in C is a lot of power but there are far more opportunities to write shitty code.
mike-cardwell 15y ago
"As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog" You should try NoScript and/or RequestPolicy for that.
ootachi 15y ago
You don't want JavaScript VMs to be running NaCl's verifier on all the code that they generate. That would be a significant performance loss. Remember that JavaScript engines are fundamentally built around self-modifying code, so the verifier would be running all the time.

aufreak3 15y ago

You don't _have_ to use NaCl just because it is available. If you find performance like an order of magnitude away from where you need it to be, NaCl could be one technology to consider. Demanding games come to mind, harvesting spare computing power is another possibility, I'm personally interested in high performance programmable audio (think Max/MSP/Jitter within the browser), etc.

Roritharr 15y ago

For gaming this is a big thing. One thing that limits cool 3D Games on the Web is the lack of good engine technology that can be used without plugins. Unity 3D has shown in cooperation with google that they could run without a plugin through NaCl. I'm really looking forward to this possibility, making the Chrome Webstore as a sales platform even more interesting in the long run.

kayoone 15y ago
absolutely, we are working on a Unity browsergame and Native Client is a big thing for us as well.