Hacker News Reader

Comment by crazygringo | Hacker News Reader

This is the first I've heard of Portable Native Client (PNaCl), which sounds very interesting.

I think ASM is a great idea for "hacking", but the thing that doesn't make a lot of sense to me, is that you're usually only going to bother compiling to ASM for things which need the performance. The idea that they'll "still work" in non-optimized browsers doesn't seem too convincing -- games would probably be unplayable, and you'd see messages saying "This game only supports Firefox" etc.

And I don't see there being that many things written in C, etc., that one would want to port to the web, that aren't particularly processor-intensive.

Presumably PNaCl would be close to native code speed, a big improvement over ASM. And it seems like what's needed is cross-platform fast execution -- not backwards compatibility with JavaScript that will still run, but run much more slowly.

But nevertheless, it's super-interesting watching what's going on with ASM.

View on HN

PNaCl sounded interesting — I was really excited when I heard about it — but it's been pretty much dead for a long time now. Even normal NaCl got a lot more attention, and NaCl has not exactly been heartily embraced.

People are only recently starting to talk about PNaCl because it's the only alternative to asm.js, and for some reason some people have such strong negative reactions to the idea of a highly performant language that isn't a bytecode that they'll support a defunct Google experiment before a low-level JavaScript subset.

The problem with NaCl is that it is platform dependent. It is the 386 real mode instruction set which means it is bad for mobile platforms since nearly all of them are ARM based. NaCl will be slower to run since ARM devices will have to emulate the 386 instruction set.

That's not how it works. The original NaCl targeted only 32-bit x86, but now they also produce binaries for x86_64 and ARM too. If you're running on ARM, you get an ARM NaCl binary.

If the author of the website has updated his NaCl tooling and his website after updating his tooling.

That's a big if.

Not true.

With NaCl one has to provide multiple EXEs for each platform that one wants to support be it ARM, x86 or x64.

PNaCl was designed to solve the multiple EXEs problem by just providing one in LLVM bytecode to be jitted runtime.

> With NaCl one has to provide multiple EXEs for each platform that one wants to support be it ARM, x86 or x64.

So websites written today wont be viewable/runnable on architectures created tomorrow unless someone goes back, updates the NaCl tooling, gets the updated NaCl tooling to the original author and convinces the original author to fix his broken, platform-dependent website.

Excuse me if I say that sounds like a bunch of horseshit. If this had been invented (and embraced) before the advent of mobile-devices, half the internet would be unusable on smart-phones and tablets now.

Why on earth would we ant to create that sort of problems for the future? Websites tend to stick around, maintained or not, and new things will always emerge.

NaCl is a bad idea for any cross-platform medium and the internet in particular. End of story. The only people rallying NaCl are Google-fanboys who can't even see past their Google Chrome browser when testing regular websites.

I can't wait for this non-standard monstrosity to die.

Half the internet was unusable on mobile, the flash part...

Ah! I haven't been following the latest news surrounding NaCl. Thanks for the clarification.

I disagree. Granted, I'm an unusual case as I'm a compiler developer for a living, but my use of Asm.js would primarily be to write compilers for interesting or research programming languages to JS (granted, so I don't have to write JS). In this case the primary benefit isn't performance, it's having a reliable compile target that I can do profiling on. You wouldn't believe how important it is to have a stable (and well-specified) target language when you're writing a compiler.

I don't think it's necessarily true that only projects that need ASM.js's speed will target it. There are already several languages or tools in increasingly common use that target vanilla JavaScript, like Haxe or GWT. Developers don't use those because they can't make JavaScript perform, but because developing in another language is more convenient in some way: better syntax or easier code sharing. If these compilers could be modified to target ASM.js, you'd get the performance bump for free without sacrificing the existing state of usability in browsers that don't natively support it.

if you do that, ASM.js has definitely wrong level of interfacing with DOM and you're screwed.

You're right; I obviously didn't think that through. It does seem like there ought to be a way to abstract out the design effort of working with ASM.js, but it probably wouldn't work with existing code bases.

I don't understand the issue, or why he is right.

Care to explain?

What stops language X from targeting asm.js and still having higher-level parts in plain JS to deal with the DOM?

Right now the best tool to target asm.js is a fork of Emscripten that compiles a program in LLVM bytecode to an asm.js module. So any language that targets LLVM should be relatively easy to compile to asm.js.

The issue is that asm.js doesn't provide the full JavaScript & DOM API. Calls to native JavaScript functions go through a foreign function interface. The natural design in this case is just as you describe: a self-contained core for high-performance calculations called by a shell of plain JavaScript that can interface with the rest of the world. Similar two-layer patterns are used for NaCl Chrome apps, or games using Lua to script a C++ engine.

My original comment was written in the hope that existing language-to-JavaScript compilers could be modified to target asm.js, automatically gaining its performance boost for all future and current projects using, say, GWT. But existing projects aren't written with the two-layer pattern needed to target asm.js effectively. Perhaps the best you could do would be to run every function call that isn't in the module or asm.js stdlib through the FFI. That may not be worthwhile.

(Anyone can feel free to correct me if I'm totally off on something. This isn't exactly my specialty.)

It's not really about working everywhere. It's about providing the existing browser vendors their own parser, and reference implementation to help promote implementation. It's a small well constrained subset of what they already have. And just now have to provide a compiler for. Not trivial, but significantly easier then implementing the PNACL spec. The LLVM bitcode spec itself is large enough to ward of a second implementation.

> The idea that they'll "still work" in non-optimized browsers doesn't seem too convincing

The BananaBread demo ran very smoothly at fullscreen, 1920x1200, on Firefox 19. I was very impressed. I'm running on old hardware: a 3GHz Core2 Duo and NVidia Quadro 1700. I know it's not a full game, but it's awesome anyway.

I don't think BananaBread was that good of a demo for asm.js. It was a demo for regular WebGL (so for most Javascript engines), done a while ago. If they want to sell us on the combination of asm.js with WebGL, they need to show something even more impressive.

What about the fact that they've ported Unreal Engine 3 and are running it now with full speed inside the browser? I hope we get our hands on it soon, but you can watch the videos of it for now.

It runs OK without asm.js, but it's liquid smooth with it.

What else do you need?

I believe that's the point he was making, he wants to see that running in his browser.

Well, that's only the "mobile" Unreal 3. The same engine games on iOS and Android are using. It's not really the "same" Unreal 3 we see used in Devil May Cry 4 and other recent PC games based on it. It's probably a scaled down version even of the original Unreal 3, not the "Samaritan" one.

They probably couldn't have done more even if they wanted to, though, since asm.js or not, browsers can see only use the OpenGL ES 2.0-based WebGL API's. That's why I'm hoping the OpenGL ES 3.0-based (or better) WebGL will arrive very soon, although I haven't even heard if the Khronos group is working on it, so it's possibly they haven't even started yet.

This is the full Unreal Engine 3, all 1 million + lines of C++ code.

The art assets of the Citadel demo are I believe the same as in the Flash demo, which were optimized for a more mobile-friendly and touch-friendly environment.

However we also showed a full Unreal Tournament demo running, as I mentioned in another comment, both at our GDC presentation and in the booth where people could play it. That's a full desktop level.

Reply on news.ycombinator.com