Earlier quoted context omitted.
I got 2,996 in Firefox and 1,277 in Chrome (2013 MacBook Air 13"). Interestingly, Chrome had much worse performance for float32 than float64... yet Firefox had slightly better performance. I guess the Chrome team implemented Math.fround yet none of the optimisations which make it useful!
I got a 4,690 on Firefox Nightly so there's so big improvements coming down the pipeline.
Massive: The asm.js Benchmark
41–50 of 74 posts
Re: Massive: The asm.js Benchmark
#42Earlier quoted context omitted.
> It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means every browser supports asm.js, and supports it today I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough f…
> I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough for them. ...what? asm.js is a compiler target for C code. It's not intended to be hand-written. It's also the default compiler target for C code on the web. You wouldn't really want to compile to…
asm.js is a compiler target, true. Is it really that much C specific? Isn't it possible to compile parts of JavaScript to asm.js? For example the parts which deal with drawing - computing points of - complex things on a canvas? That would be a good reason for JS devs to use asm.js - of course via a compiler, but if that's not available, I can imagine some people doing this by hand. Remember that people used to code in real asm all the time a few centuries ago.
Re: Massive: The asm.js Benchmark
#43Earlier quoted context omitted.
I don't think it's fair to characterize Traceur or TypeScript as plays to put Javascript under their author's control. Both have been useful for developing ES6, which Firefox has also been a leading implementer of. From my perspective almost all of the browser makers doing lots of cool stuff to push forward javascript and the web.
You're assuming StevePerkins was referring to Tracuer or TypeScript, I don't think they were. I assume they meant things like NaCl and Dart.
Re: Massive: The asm.js Benchmark
#44I'm often dismissive of Mozilla, for being so all-over-the-map and unfocused sometimes. However, I'm grateful for them being the only browser player that really does seem interested in progressing JavaScript. All of the other players seem more focused on transpiling solutions, which are really about replacing JavaScript with something else under their control. Mozilla is pretty much the only player that genuinely wor…
Re: Massive: The asm.js Benchmark
#45Earlier quoted context omitted.
I agree with these points. There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform (without becoming a really ugly hack), where I can see that happen for NaCl. This is a pity, because multithreading is something you need for making responsive applications (GUI not hanging when a computation occurs in the background). Yes, there's webworkers, but I don't conside…
> There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform Are you sure? I believe I heard somewhere that Mozilla might be working on that by sharing a typed array across Web Workers. I previously thought you couldn't do multi-threading, but now that I think about it, there's no real architectural reason you couldn't allow sharing a typed array between web worke…
Re: Massive: The asm.js Benchmark
#46Earlier quoted context omitted.
> I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough for them. ...what? asm.js is a compiler target for C code. It's not intended to be hand-written. It's also the default compiler target for C code on the web. You wouldn't really want to compile to…
If Opera/Dolphin/Safari/whatever don't ever implement optimizations for asm.js, its not really cross-platform anymore. Sure, theoretically they can execute the code, but the performance will be so far from the expectations of the developer that they will just end up telling the user to switch to Firefox (maybe Chrome if they can ever catch up). > Why would normal JS developers be writing in asm.js? Do you even unders…
I'm not sure that's really true. It doesn't have to be ultra-fast, just good enough.
> If it were as simple as you make it out to be, we would have hundreds of languages compiling to asm.js by now; C/C++, but also every language that compiles to C/C++ or LLVM bytecode. As it is, we have maybe a couple dozen large legacy codebases that have been ported.
Er, well, there aren't many languages which compile to native code. People can't compile Java, C#, JavaScript, Perl, Python, Ruby, PHP, etc. to native code. C/C++ do compile to native code, however.
> Ha. You obviously haven't tried to do that yet.
Oh, I have. I realise it has some difficulty to it.
> If getting the performance that asm.js developers expect out of asm.js requires the use of a browser that optimizes for asm.js, then the solution isn't cross-platform. In fact, it isn't really any better than NaCL, god forbid.
I'm not sure what you think asm.js is the solution to. Its purpose is for running native applications in the browser. It's not for making ordinary JS apps run fast.
Re: Massive: The asm.js Benchmark
#47Earlier quoted context omitted.
> I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough for them. ...what? asm.js is a compiler target for C code. It's not intended to be hand-written. It's also the default compiler target for C code on the web. You wouldn't really want to compile to…
> Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists? asm.js is a compiler target, true. Is it really that much C specific? Isn't it possible to compile parts of JavaScript to asm.js? For example the parts which deal with drawing - computing points of - complex things on a canvas? That would be a good reason for JS devs to use asm.js - of course via a compiler, but if that's…
No, but I'd say it's low-level language specific. C, C++, Pascal, Swift, Go, D and the like. Not C# or Java.
> Isn't it possible to compile parts of JavaScript to asm.js?
Yes... asm.js, which is a subset of JS, can be compiled to asm.js. You can compile any language to itself. There's no real point in doing so, however.
More seriously, no, not really. JS is a dynamic language. It can't be compiled ahead-of-time.
> For example the parts which deal with drawing - computing points of - complex things on a canvas?
No, you couldn't compile that to native code. If you tried, I doubt it'd be faster than your browser's existing JIT.
> That would be a good reason for JS devs to use asm.js - of course via a compiler, but if that's not available, I can imagine some people doing this by hand. Remember that people used to code in real asm all the time a few centuries ago.
You could hand-write asm.js, but it'd be difficult. Manually manipulating the heap and stack isn't fun. There's no memory allocator included. It would make far more sense to just write in C, compile it, and write glue code, or just to write easily JIT-ed JS in the first place.
Re: Massive: The asm.js Benchmark
#48Earlier quoted context omitted.
You're assuming StevePerkins was referring to Tracuer or TypeScript, I don't think they were. I assume they meant things like NaCl and Dart.
Dart compiled to JS just like Emscripten.
(And some features of the core language only work with an embedded Dart VM)
Re: Massive: The asm.js Benchmark
#49Earlier quoted context omitted.
> There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform Are you sure? I believe I heard somewhere that Mozilla might be working on that by sharing a typed array across Web Workers. I previously thought you couldn't do multi-threading, but now that I think about it, there's no real architectural reason you couldn't allow sharing a typed array between web worke…
That seems woefully underspecified compared to multithreading in C. Where's my test_and_set? How do I implement locking/mutexes? What's the equivalent of volatile in asmjs? Does it have a memory model like the Java Memory Model/OpenMP Memory Model? If you want to do safe, performant, multithreaded programming, these things need careful specification, especially in the context of optimizing compilers.
It's not even multithreading yet, it's just a means that support for it might be added.
Also, I don't see why you're complaining about it "compared to multithreading in C". To write for asm.js, you write in C. All this is implementation details for how the C compiler (emscripten, probably) will generate its code.
> Where's my test_and_set? How do I implement locking/mutexes? What's the equivalent of volatile in asmjs? Does it have a memory model like the Java Memory Model/OpenMP Memory Model?
Presumably, locks would be added somehow.
Re: Massive: The asm.js Benchmark
#50I'm often dismissive of Mozilla, for being so all-over-the-map and unfocused sometimes. However, I'm grateful for them being the only browser player that really does seem interested in progressing JavaScript. All of the other players seem more focused on transpiling solutions, which are really about replacing JavaScript with something else under their control. Mozilla is pretty much the only player that genuinely wor…
asmjs is a transpiling solution. No one is going to rewrite UnityEngine in hand-written asmjs. The vast majority of asmjs code is going to be transpiled, you can literally see it in the name: asm
It's quite different from, say, NaCl or Dart, which introduce a completely new language with a new set of APIs.