Asm.js Gets Faster

mikejuk writes "Asm.js is a subset of standard JavaScript that is simple enough for JavaScript engines to optimize. Now Mozilla claims that with some new improvements it is at worst only 1.5 times slower than native code. How and why? The problem with JavaScript as an assembly language is that it doesn't support the range of datatypes that are needed for optimization. This is good for human programmers because they can simply use a numeric variable and not worry about the difference between int, int32, float, float32 or float64. JavaScript always uses float64 and this provides maximum precision, but not always maximum efficiency. The big single improvement that Mozilla has made to its SpiderMonkey engine is to add a float32 numeric type to asm.js. This allows the translation of float32 arithmetic in a C/C++ program directly into float32 arithmetic in asm.js. This is also backed up by an earlier float32 optimization introduced into Firefox that benefits JavaScript more generally. Benchmarks show that firefox f32 i.e. with the float32 type is still nearly always slower than native code, it is now approaching the typical speed range of native code. Mozilla thinks this isn't the last speed improvement they can squeeze from JavaScript. So who needs native code now?"

Comments

"So who needs native code now?"

[Anonymous Coward]

Umm, anyone who wants their code to not run substantially slower. Seriously, do you front end programmers really think nobody does numerical simulations or other performance-sensitive work? In my line of work, I'd kill for the opportunity to make my code 1.5 times faster!

Re:"So who needs native code now?"

[gagol]

Also, the major down point of JavaScript I found to hinder performance in ambitious projects, is memory management. In the cases where I need gigantic arrays, the performance slows down to a crawl as data grows. Anyone knowledgeable can bring some light about this aspect of asm.js?

Re:"So who needs native code now?"

[Anonymous Coward]

You mean I can't write that OS in JavaScript for my CS degree?

Re:"So who needs native code now?"

[MightyMartian]

What a bizarre statement. Of course it's programming. It may not be very elegant programming, but then again, the bulk of C code I've seen in my years in the business isn't terribly elegant either.

Re:"So who needs native code now?"

[phantomfive]

Yes you can write it but don't expect to get a PhD from it.

Re:"So who needs native code now?"

[gigaherz]

If "as data grows" you mean the array itself is growing, then that will happen with any language: resizing an array requires allocating a new memory area, and copying the data over to the new one. No clue if javascript has any other limitation regarding big arrays.

Re:"So who needs native code now?"

[phantomfive]

Correct this to any real programmer. I'm tired of web designers being colluded with actual programmers, scripting isn't programming.

Heh....typing isn't programming. If you aren't connecting patch wires on an accumulator bank, it's not worth doing. You get more efficiency that way too!

Re:"So who needs native code now?"

[Anonymous Coward]

Tracing garbage collected languages will always be slower because:

1) The tracing adds a ridiculous amount of unnecessary work; and

2) While allocation is at best O(N) for GCd and regular programs, deallocation can (and often is) made O(1) using memory pools in C and C++ programs, something that can't be done in GCd languages because the collector doesn't understand semantic interdependencies.

For ref-counted collectors #2 still applies.

Unless and until some unforeseen, miraculous breakthrough happens in language design, GCd languages will always be slower when it comes to memory management. And because memory management is so critical for complex applications, GCd languages will effectively always be slower, period.

But the only people who care that GCd languages are slower are people who only know GCd languages. I extensively code in C and Lua, and I love both.

Re:"So who needs native code now?"

[suy]

Umm, anyone who wants their code to not run substantially slower. Seriously, do you front end programmers really think nobody does numerical simulations or other performance-sensitive work? In my line of work, I'd kill for the opportunity to make my code 1.5 times faster!

I'm surprised by your answer at so many levels. First, I thought the guys doing scientific calculations were scientists that many times (not always of course) are only used to Matlab, Mathematica or even Excel. Second, obviously we will need native code, as well as interpreted, functional, and lots of code in domain specific areas (what the heck... I spent this Sunday morning writing in VimL, a language so stupid that can't copy a file without reading the whole contents in memory or invoking system(), but I needed to program in that and there is no way around it).

But the final sentence of the article isn't targeted at people doing heavy lifting. Is an "attack" at Google's Native Client (NaCl). I peeked at NaCl, and you needed a some set up and some APIs to run some native code invoked from the browser. ASM.js is way simpler, since is just a subset of JavaScript, and has much more possibilities of being followed by vendors like Opera or even Microsoft.

Oh, and, I do native code for a living, and while I would kill for making my code faster, my manager would kill for making me finish projects earlier. :-) Native code is awesome, but sometimes dumb languages are more business successful if you can use all your developers in a project, including that 50% that, by definition, are below the average.

Re:"So who needs native code now?"

[dshk]

deallocation can (and often is) made O(1) using memory pools in C and C++ programs, something that can't be done in GCd languages

I believe current Java (not Javascript!) virtual machines do exactly this. They do escape analysis, and free a complete block of objects in a single step. This works out of the box, there is no need for memory pools or any other special constructs.

Re:"So who needs native code now?"

[LWATCDR]

Well computers are so fast you can just throw more hardware at the problem.
Just kidding, people do not understand that one of the reasons that people still use Fortran for HPC apps it the fact there are a lot of really good optimized libraries and the fact that Fortran is really easy to optimize.
What I do not get from the story is why JavaScript's use of floats is a problem? Last I heard Floating point using SSE or OpenCL is often as fast as integer code. I could be wrong because most of the projects I worked on where IO limited.

Re:"So who needs native code now?"

[Shinobi]

"I'm surprised by your answer at so many levels. First, I thought the guys doing scientific calculations were scientists that many times (not always of course) are only used to Matlab, Mathematica or even Excel. "

That's why quite a few supercomputing facilities offer software porting/"translation" services... Some of the projects I've done over the years have been freelance contracts to rewrite a program from one stack to another.

Because if they can get something from MatLab/mathematica into Fortran which enables them to cut effective run time in half, it means they can pack in more projects, and thus the facility can serve more people.

Of course, you also have the idiots who campaign for root access and Python and loudly whine when they don't get to be a nuisance to every other user... *Sends nasty glares in the direction of Stockholm University's CS department.....*

Re:"So who needs native code now?"

[Atzanteol]

Remember kids - all programming is high-performance computing!

Re:"So who needs native code now?"

[Trepidity]

Good Lisp compilers have long done this as well. If the compiler can determine that certain variables don't escape the current execution context, it can even stack-allocate them rather than put it on the heap and have to GC it at all. You can help the compiler out by promising that's the case with the dynamic-extent declaration.

Re:"So who needs native code now?"

[Flammon]

Some of the most elegant code that I've seen has been with web scripting languages.

$('img').bind('mouseenter mouseleave', function() {
        $(this).attr({
                src: $(this).attr('data-other-src')
                , 'data-other-src': $(this).attr('src')
        })
});

Shameless plug

Try doing that in C

Re:"So who needs native code now?"

[beelsebob]

What makes you think this can't be done in C (at least C with apple's block extension)?

99% of the "elegance" of this is the particular framework in use, not the language.

Re:"So who needs native code now?"

[Lendrick]

In my line of work, I'd kill for the opportunity to make my code 1.5 times faster!

Then wait a year and buy a new computer.

Re:"So who needs native code now?"

[Flammon]

It can obviously be done in C but I doubt it would be done with the same elegance.

The framework is written in the same language, JavaScript, which further emphasizes my point.

Re:"So who needs native code now?"

[Anonymous Coward]

It isn't actually an obligatory reply unless you link the actual xkcdsucks review for that particular comment. Anything else and your just being lazy. Given what passes for criticism on xkcdsucks I can't wait to read the pretentious drivel for this one.

Re:"So who needs native code now?"

[non0score]

This is one of those things that's not necessarily true (usually true in a managed memory environment, though). If you have control to the OS functionality of memory and know your memory usage pattern, then you can actually reserve a lot of virtual memory pages in advance. Only the committed ones will consume physical memory -- in other words, you can expand your array by committing subsequent pages. And since we haven't gotten to the point where computers actually have 2^64 bytes of memory, we don't need to worry too much about running out of address space.

Re:"So who needs native code now?"

[Shinobi]

The facilities are not Stockholm University's CS departments, nor even Stockholm University's. They just rent time in these facilities, yet demand things, as if they owned them.

Re:"So who needs native code now?"

[gl4ss]

and I keep hearing that you haven't needed to call System.gc(); in over a decade... yet, calling it has been essential in some programs so that things don't go to shit(apart from those vm's which crashed on it, ehe. I should say that this hasn't been on desktop java so ymmv).

that being said, yeah, you don't need to free the memory yourself but if you're working in limited, real life apps running on limited hw and limited sw.. you're still better off knowing _when_ you have caused things to be so that the memory can be freed. this goes for both java and javascript. you're better off knowing when the memory is allocated of course too. this isn't taught much...

it's still safer&easier to do something that works this way though. it's not a problem of the language if the architect goes for a design that's technically stupid from performance/memory use point of view - it certainly wouldn't help one bit if that code was written in c++, it would still use gobs of memory.

(writing java with constraints of 128kbytes for the jar and 300kbytes of heap was surprisingly fun and doable.. 64kbyte jar limit felt like doing only tech demos though - and apps/games graphics were included in those limits.)

Re:"So who needs native code now?"

[viperidaenz]

Fail.
That's not valid Asm.js
jQuery doesn't work in Asm.js
Asm.js isn't Javascript. It's a statically typed language that looks like a subset of Javascript. There isn't even DOM support.

Re:"So who needs native code now?"

[Anonymous Coward]

I'd say, show the code.

I would find it believable if you'd cite 10x or even 100x-1000x slowdown (though latter's a lot less believable than former) - but 1e8x difference sounds fishy.

Was it really same algorithm? Were you running it on IE5?

Re:"So who needs native code now?"

[Anonymous Coward]

Try doing WHAT in C? The idiot who wrote that code doesn't know how to comment!

Re:"So who needs native code now?"

[darkHanzz]

In C++ it'd come down to a lambda function and std::swap, I don't see how that's less 'elegant'.

Re:"So who needs native code now?"

[gigaherz]

Given that the concept behind Javascript is "hash tables as objects", your claim sounds weird. You must have been misusing it somehow, although I couldn't guess.

Re:"So who needs native code now?"

[gigaherz]

That is not how most programming languages manage the memory, though. If you have such specialized needs, then yes, managed languages are out of the question.

Re: "So who needs native code now?"

[loufoque]

Lots of people can make your code 1.5 times faster for a price, no need to kill.

Re:"So who needs native code now?"

[Lennie]

That is what TypedArrays are for, look them up. They were introduced for WebGL, but also implemented by browsers that didn't even support WebGL.

Re:"So who needs native code now?"

[Lennie]

It wouldn't help to port jQuery to Asm.js. The slowers part of the browser is the DOM and that is all jQuery does is talk to the DOM in a that appeals to a certain crowd.

The reason for it being slow is because you are bridging from one language (C++ of the browser engine) to the other (dynamically typed Javascript).

It has been suggested it might be useful to port something like DOM.js (a Javascript implementation of the DOM) to asm.js that way, that way the back and forth will remain within Javascript and thus will be faster.

Re:"So who needs native code now?"

[Carewolf]

Some of the most elegant code that I've seen has been with web scripting languages. $('img').bind('mouseenter mouseleave', function() { $(this).attr({ src: $(this).attr('data-other-src') , 'data-other-src': $(this).attr('src') }) }); Shameless plug

Try doing that in C

In modern C++:

img.mouseenter = img.mouseleave = [] () { std::swap(img.attributes["src"], img.attributes["data-other-src"]); };

Ofcourse it requires the C++ programmer hasn't been too damaged by exposure to Java and tries to pointlessly ruin the language by using getters and setters instead of real property access.

Re:"So who needs native code now?"

[Flammon]

Nice. I didn't realize that C++ could look so good. If I had not commented on this thread I'd mod you Informative. However, that line of code isn't complete. You still need to loop through all the image objects and late bind the events to each.

My counter point however was for the GP who implied that web scripting languages are not very elegant. I was trying to show that they can be just as elegant. I wasn't saying that non web languages are not elegant.

Re:"So who needs native code now?"

[Joce640k]

If "as data grows" you mean the array itself is growing, then that will happen with any language: resizing an array requires allocating a new memory area, and copying the data over to the new one.

Somebody's never heard of std::deque.

(or any of the other non-moving containers you could build in a proper language)

The *real* performance trouble with Javascript is that it doesn't let you define what "array" means.

(and also that "speed of native code" isn't defined anywhere)

Re:"So who needs native code now?"

[Joce640k]

I believe current Java (not Javascript!) virtual machines do exactly this. They do escape analysis, and free a complete block of objects in a single step. This works out of the box, there is no need for memory pools or any other special constructs.

Sure... sometimes.

When they can't manage it then all the checking and relinking is using up CPU cycles.

Re:"So who needs native code now?"

[TangoMargarine]

*squints* What is this actually doing? It looks like it's circularly linking two objects. You can do that with pointers in plenty of languages.

Re:"So who needs native code now?"

[TangoMargarine]

I also find your C++ code to be infinitely more readable (but maybe that's just confirmation bias). It would help if the GP example had any sort of english-language operator in it other than various bits of punctuation. "Swap" tells me what this is actually doing.

Re:"So who needs native code now?"

[TangoMargarine]

Anything else and your just being lazy.

Ironyyyyyyy

Re:"So who needs native code now?"

[Flammon]

It's binding mouse event handlers that swap the image source of all the images in a document.

If you read the GP you'll realise that this isn't about whether it can be done in other languages, I know it can be done. My point is that not only is web programming real programming but it can also be done just as elegantly if not more.

Re:"So who needs native code now?"

[TangoMargarine]

Yes of course it can be done in other languages, but I very much contest that your example/language is "more elegant."

This is a prime example of why I am very suspicious of JavaScript et al.--there's no "verb" anywhere in the command. Well okay, there's "bind", but that's more of a function definition from what I know of JS. Reserved keywords inside quotes also make me flinch.

Re:"So who needs native code now?"

[Flammon]

Well, show me some code in C or other "real" language that does the same as this JavaScript snippet and let's compare.

Re:"So who needs native code now?"

[Pherdnut]

For anything not on the client-side, I would look into C-bindings via V8 (and of course Node which is just V8 + a small library basically). I love JavaScript and will defend it vigorously but number/math-intensive code is not something it's strong at yet. That's in the works but even when it's introduced we still have to wait for old versions of IE to die off (which is fortunately happening at a faster rate than it used to). Otherwise JS is peformance enough to be competitive with any other multipurpose language IMO but I do love having the C/C++ option for operation-intensive performance + JS handling higher level archite

But don't kid yourself. Skilled client-side engineers care A LOT about performance. There is a lot of craft that goes into manipulating the DOM well and I'd say any JS engineer that had to deal with IE6/7 or below knows a lot more about the value of work avoidance than your typical Java or C# dev at the median level who tend to put out awful performance on the back-end in spite of all the perf advantages that are supposedly available to them.

People from outside of JS get way too obsessed with its lack of a type system, IMO. The values a dynamically typed language trains you to take seriously (things like DRY and the value of encapsulation to avoid having too many hands on the same sets of data) very much transfer in value to statically typed languages as well, but with IDEs and "type safety" programmers seem to lack the incentive to learn them well, at least judging from the vast majority of server-side code that I've observed and debugged.

But yeah, if you need computation-intensive number-oriented code, JS blows for anything non-trivial. I won't deny that.

Re:"So who needs native code now?"

[TangoMargarine]

String name = "Image.gif";

public void hover()
{
      name = flipImg( name );
}

private String flipImg( String imgName )
{
      return ( imgName.contains( "over" ) ? imgName.replace( "over", "" ) : imgName.replace( ".", "over." );
}

While I'll admit your version works with non-deterministic naming pairs, the guy didn't ask for that originally.

Re:"So who needs native code now?"

[TangoMargarine]

* Whoops, drop that extraneous paren after the return.

Re:"So who needs native code now?"

[Flammon]

While I'll admit your version works with non-deterministic naming pairs...

That's the elegant part.

Re: "So who needs native code now?"

[AndOne]

There's nothing wrong with setters and getters provided one writes them well. It's extra work but I've had times where having setters and getters to put break points in would have allowed me to catch and fix highly insidious bugs caused by people doing bad things in other parts of the code. To be fair it was their use of globals that made it an issue in the first place :/.

That being said I always try to write them in attribute style as it looks almost as clean as direct public access.

Re:"So who needs native code now?"

[gigaherz]

I know about dynamic structures and the stl well enough, thanks. I was referring exclusively to arrays. High-level implementation of vectors, lists, queues, or any other linear sequence of items were not part of what I said.

Re:"So who needs native code now?"

[raddan]

Unless and until some unforeseen, miraculous breakthrough happens in language design, GCd languages will always be slower when it comes to memory management. And because memory management is so critical for complex applications, GCd languages will effectively always be slower, period.

This isn't true. Have a look at Quantifying the Performance of Garbage Collection vs. Explicit Memory Management. The take-away is that GC'd languages are only slower if you are unwilling to pay an extra memory cost; typically 3-4x of your explicitly-managed program. Given that GC gives you safety from null-pointer dereferences for free, I think that's a fair tradeoff for most applications (BTW, you can run the Boehm collector on explicitly-managed code to identify pointer safety issues).

Re:"So who needs native code now?"

[viperidaenz]

Not only would it not help, it's impossible.
Asm.js is fast because it isn't really Javascript. There is no dynamic typing.

asm.js code is limited to an extremely restricted subset of JavaScript that provides only strictly-typed integers, floats, arithmetic, function calls, and heap accesses.

It's compiled to machine code at parse time.

The benefit is if your browser doesn't support asm.js, it's Javascript syntax so it will still work in the interpreter/VM

Re:"So who needs native code now?"

[Yttrill]

Wow, completely and utterly wrong. Modern GC are faster than any other method for complex data and comparable for simple data. The first claim is well established and easy to prove: given an arbitrary graph of data to manage GC is the only algorithm which can manage it. If the graph is merely acyclic reference counting will do, but modern GC are still faster than any reference counting scheme. In fact a new reference counting scheme with a specialised allocator has just been developed which is almost as fast as GC, and that's considered to be quite a breakthrough. The primary problem with GC systems is that it is hard to make them real time, that is, to spread the load evenly so there's no noticeable jitter. Naturally if you have a simple data structure were the number of references is statically known, then the cost of determining if a block is unreachable can be reduced to zero. However unless you're using a language with a really advanced type system like ATS2 it will be very difficult to be certain your code is correct: the only serious exception to that is a purely stack protocol data structure. Indeed the poster is so completely ignorant e doesn't even realise Lua 5.2 actually uses a garbage collector: http://www.lua.org/manual/5.2/manual.html#2.5

Re: "So who needs native code now?"

[Carewolf]

True, I use them often as well. They are great for public APIs that need to be kept ABI compatible. For internal structures I prefer without though. After a second look at my code though, I can see it could easily be done with getters too, providing the class has non-const getters with reference returns that can be altered.

Re:"So who needs native code now?"

[ahabswhale]

I stopped reading after "creates crazy number of threads". Java only creates the threads it's told to create. In short, you don't know what you're talking about.

Re:"So who needs native code now?"

[Coop]

> ... scripting isn't programming.

Well, it *could* be.

Re:"So who needs native code now?"

[PCM2]

But the final sentence of the article isn't targeted at people doing heavy lifting. Is an "attack" at Google's Native Client (NaCl). I peeked at NaCl, and you needed a some set up and some APIs to run some native code invoked from the browser. ASM.js is way simpler, since is just a subset of JavaScript, and has much more possibilities of being followed by vendors like Opera or even Microsoft.

Yes, but even if you're using Asm.js, you should maybe still think about NaCl as an interesting potential option.

One reason is that you typically don't write Asm.js code by hand. You could, but you'd probably be bad at it (kind of like assembly language -- compilers just know it better than you do). What you typically do is write your code in C/C++, then "compile" it into Asm.js using a tool like Emscripten.

Thus, if you're writing your code in C/C++ anyway, it wouldn't be such a stretch to take that same code and also compile it into a native binary module for those clients that support NaCl (which so far means only Chrome, and it looks like it's going to stay that way).

In other words, you don't need to look at it as an either/or choice. It's perfectly feasible to use both tools, possibly without much additional development overhead.

Re:"So who needs native code now?"

[PCM2]

He didn't say C++.

Re:"So who needs native code now?"

[PCM2]

Asm.js isn't Javascript. It's a statically typed language that looks like a subset of Javascript. There isn't even DOM support.

This isn't really accurate. As you say yourself in a post below, any Asm.js code you can find will execute in ANY JavaScript virtual machine available today. Thus, Asm.js is JavaScript. It's just JavaScript restricted to a very strict, very specific set of rules, with everything else thrown out. It doesn't "look like" a subset of JavaScript; it is a subset of JavaScript.

Re:"So who needs native code now?"

[viperidaenz]

a subset of X is not X.

return "Returning Hello World".substring(10, 11);
Is that Java or JavaScript?
It's valid code for both languages with the same semantics.

Re:"So who needs native code now?"

[darkHanzz]

Indeed he didn't. The whole thread was about native vs. non-native code, where C is just an example of native code.

C++ is another example, closely related to C, with all the relevant properties. for example, you don't pay (performance) for abstractions/features you don't use. (exceptions, garbage collection, virtual function calls/inheritance)

Re:"So who needs native code now?"

[dkf]

Java only creates the threads it's told to create.

But it is often told to create a lot of them. (Plus there's a number of system threads about too, but not that many.)

Re:"So who needs native code now?"

[ahabswhale]

So your argument is that it supports threading and that some programmers may create threads irresponsibly? Sorry, that's not a language flaw. I've been writing Java for over a dozen years now and I have to see a single instance where a Java app was cranking out threads like there was no tomorrow. I've seen Java apps that don't properly synchronize threads but never what you're talking about.

Suspect even at -O0 -g

[ugen]

Part of what I do is writing high performance code both in "native" and various scripting languages. I just completed yet another comparison for our product, looking for the best performing scripting language for a specific task. Lua with a "just in time" compiler came in first. It is *only* about x10 slower than native code produced by gcc with moderate optimization, when measured on variety of numeric benchmarks. It is considerably slower when dealing with strings and more complex data types, as expected. All other tested scripting engines were considerably behind. I'll admit that javascript was not tested, and promise to try it out. That said, a claim of "being only 1.5 times slower than native code" is something I haven't seen *any* non-native environment be able to achieve in the last 20 years or so.

Re:Suspect even at -O0 -g

[gbjbaanb]

asm.js is not javascript though, its a specific subset with restricted coding rules that allow the compiler to do its stuff. General js will be just as slow as any of the other script languages.

Re:Suspect even at -O0 -g

[K. S. Kyosuke]

If LuaJIT 2.x was *ten times* slower than C for you, perhaps you were doing something wrong?

Re:Suspect even at -O0 -g

[sribe]

It is a lie, or maybe they don't know what "at worst" means.

When I first read the summary, I seriously wondered if they meant "at best".

Re:Suspect even at -O0 -g

[Anonymous Coward]

Asm.js is not JavaScript. It's Mozilla's way of hacking together a very specific optimization for JS-targeting compilers such as Emscripten, because they don't want to adopt the sane route of just implementing PPAPI and Google's Native Client sandbox, both of which don't work well with single-process browsers. From a developer perspective it's fairly trivial to target both Asm.js and PNaCl (Google's Native Client except with LLVM bytecodes), or target one and write a polyfill for the other. In either case, both of these environments are for executing C/C++ native code in the browser with minimal slowdown, they don't touch run of the mill JS anyway.

Re:Suspect even at -O0 -g

[Anonymous Coward]

Can I take a moment here to plug Nimrod? (http://www.nimrod-lang.org)

The code looks a lot like Python, is very easy to write...yet it compiles to C (and then via GCC/Clang) so the executables it produces are screaming fast...implement an algorithm in nimrod, and in C, and the runtime characteristics will be identical, as will the memory usage. Might be a good fit if you want something easier to code in than C but with performance that's nearly identical + the benefit of having things like easy to use string and hashtable libraries only an import away.

Re:Suspect even at -O0 -g

[ebno-10db]

Chances are that for many interesting applications (graph-based stream and image processing, anyone?), this won't be slower than C, and perhaps faster in many cases

Benchmarks? I've heard lots of theories about why language X might beat C, but rarely have I seen it backed by benchmarks. Even the "for certain cases" thing rarely works out.

Re:Suspect even at -O0 -g

[zippthorne]

Maybe they're writing from the perspective of C fans rather than javascript fans.

Re:Suspect even at -O0 -g

[non0score]

Are you talking about self-modifying code? You can certainly do that in C, but just much, much more involved.

Re:Suspect even at -O0 -g

[non0score]

Asm.js is basically a somewhat limited (wrt native hardware capabilities) bytecode format in human-read/writeable form. Mozilla is resisting hard because it's just like the GP said -- their architecture isn't suited for Pepper. And as Mozilla tries to solve the multi-threading/SIMD/(u)int64 issue, it just looks more and more like (P)NaCl. I guess the nice thing about asm.js is that it doesn't require such a large upfront cost.

Re:Suspect even at -O0 -g

[non0score]

That's because:

• 1) The code being benchmarked and compared against usually aren't production code, and are tight for-loops that're easy to optimize -- i.e. hit the cache all the time due to small code/data size, simple instruction mix, lack of SIMD comparisons, no real memory allocations, etc....
• 2) If it's a section of full production code and the results are similar, then "native" code is most likely nowhere near optimal to begin with. Just because it's "native" doesn't mean it's good. One can still write really shitty code in C/C++, i.e. triple nested vectors.
• 3) And if it's not complete shit and the "native" code still runs close to JS performance, then the programmer in question probably doesn't have as much experience optimizing for instruction mix, L1/L2 cache hit, pipeline balancing, software pipelining, etc....

I haven't seen any non-trivial high level code come close to real optimized C.

Re:Suspect even at -O0 -g

[viperidaenz]

Javascript only has one number type. Floating point.
64bit floating point provides maximum precision, when you've only got the choice of 32 or 64.

Re:Suspect even at -O0 -g

[tgv]

Precisely that. I've checked some asm.js based applications, and they're just slow. The latest one I saw is a great one, but also underlines the point: it emulates classic MacOS in your browser, ResEdit and all. Really nice. But an i7 at 2.whatever GHz does not seem to be capable of properly simulating a 8MHz 68000, and that's just nonsense. Native emulators beat the crap out of that performance 15 years ago on a 100MHz G3.

Apart from that, Firefox' JS engine is several times slower than Google's V8. The emulator ran in both browsers are comparable speed. So I'd say that asm.js first has to overcome Firefox' sleuth, then speed up beyond that, and then we'll see again.

In the mean time: at best, indeed.

Re:Suspect even at -O0 -g

[aztracker1]

The fact is this.. simply.. *MOST* code really doesn't need to be that optimized. It really depends on the needs... if you are in a space that really needs to wring every last drop of performance, then yeah, you need it.. writing 3D games for low-end smart phones, yeah.. writing against embedded hardware, sure...

*most* applications are one-off line of business apps likely to be replaced in under 5 years. In this space, C#/.Net, Java and even scripted languages do fine on modern hardware... And the cost of running a server for 3-5 years is way less than the cost of 3-4x the development time for a finished product that is "optimized" let alone the real opportunity loss for taking 3-4 times to develop.

There's a reason that languages and environments that make it easier to get a job done rule the roost in terms of most development. If I can get your import utility written in node.js in a day, that's a lot better than someone taking a week and a half to do the same in C, Lisp, or Erlang. Hell, I'd be more likely to reach for Go these days for one-offs where some performance is needed.

Most servers have plenty of memory, meaning if you take even a few hundred mb for your app, it's not a huge impact. It just depends on your needs, and the scale of what you are creating.

Re:Suspect even at -O0 -g

[Lennie]

The compiler in this case could matter, but what they are doing is:
compile code x with compiler y and measure performance
compile code x with the same compiler y with the asm.js backend for that compiler and measure performance by running it with the Javascript engine

So it's the same compiler and the same optimizations.

Re:Suspect even at -O0 -g

[serviscope_minor]

I've heard lots of theories about why language X might beat C, but rarely have I seen it backed by benchmarks.

Quite so. The exception is FORTRAN (suck it anti-capitalistas), and actually no one argues with that, and C++ which is basically the same as C for speed since it's machine model is the same. But yes, we've been harding that X is as fast/faster than C for ages. In fact I think that Java is was as fast as C 10 years ago, has been getteing faster year on year and is now as fast as C.

(Actually this is one of the few contexts where C/C++ makes sense as a phrase)

Funny thing is, despite every language "being as fast as C or C++" or nearly, or sometimes faster, C/C++ is still the one to beat. For some reason, no language has overtaken C/C++ as the one to beat (who says we're only 1.5x slower than Java?). And application performance still seems to suck.

The thing is C/C++ is generally pretty fast across the board with a little care. A nice example is something like MATLAB or Octave which farms out mig matrix operations for Fortran or even the GPU for some stuff in matlab. That's great except that you either have to cram everything into being such operations (which gets sub optimal) or write a for loop for some stuff ( :( ).

And again with ASM.JS. The restricted subset works fine and is "nearly" as fast. The thing is that with C++ you get the full weight of the language and all its handy featues at full speed: you can write complex algorithms with interesting data models and objects and still run at full speed.

This is not to say you can't write bad code in C/C++. Goodness knows you can, but if you're an expert going for performance, those two languages do give you a lot to work with.

Re:Suspect even at -O0 -g

[Lennie]

Why do you think that single process has anything to do with this ? The Mozilla developers clearly want to do this, it just is a massive effort to change their code to suite the model.

Also Mozilla has been working on multi-process again this year. First for Firefox OS (where every Firefox OS phone that shipped is using it) and recently for normal Firefox.

http://lwn.net/Articles/576564/

Anyway I've seen Chrome UI lock up as well with a busy tab. So I don't know why people keep bringing it up (other than security of course).

The advantage of asm.js is, it runs in a browser you already have. It is just about skipping the type inference code (a form of guessing) and having the JIT part of the Javascript engine not having to deal with dynamic types.

That means asm.js can eventually be as fast as Java or .Net. Which for certain things can be close to or even faster (because of runtime optimizations) than compiled native code.

Really, usually the slowest parts of Javascript tend to be: the DOM and time to download.

Re:Suspect even at -O0 -g

[billcarson]

What about the Java Hotspot environment? (this is not a troll, I'd love to hear what his results were).

Re:Suspect even at -O0 -g

[loufoque]

They probably convert a high-level representation to asm.js, not machine code.
Seriously dude, they don't even have sized integer and floating-point types...

Re:Suspect even at -O0 -g

[PCM2]

Why do you think that single process has anything to do with this ? The Mozilla developers clearly want to do this, it just is a massive effort to change their code to suite the model.

Really? You're saying the Mozilla developers "clearly" want to switch to Pepper/PPAPI? Because I don't think that's very clear at all.

As for NaCl, Mozilla has been pretty adamant that it's not interested.

Re:Suspect even at -O0 -g

[Lennie]

You misunderstood me: they clearly want to switch to a multi-process model.

That is what FirefoxOS already uses.

Update the ecma standard

[modmans2ndcoming]

Update the ecma standard to include a set of features that is meant to be used when compiling a better language (C#, C++, Java, Perl, Python, LISP, Haskell, x86 asm, MUMPS, pig-latin, etc) down to javascript so it will run in any browser at native code speed. Then I think everyone will be happy.

Re:Update the ecma standard

[sribe]

Update the ecma standard to include a set of features that is meant to be used when compiling a better language (C#, C++, Java, Perl, Python, LISP, Haskell, x86 asm, MUMPS, pig-latin, etc) down to javascript so it will run in any browser. Then I think everyone will be happy.

Fixed that for you ;-)

Re:Update the ecma standard

[VortexCortex]

You want NaCL, not ECMA.

The thing about ASM.js is that it's available. Just like Javascript is prevalent not because it's really any good (it's a horrible design from a performance view). ASM.js was created to improve Emscripten speed (it compiles C/C++ down to Javascript). The subset of JS used will run as regular javascript, and ridiculously sometimes running the code on the regular JS interpretor will execute it faster than the ASM.js code. I don't like Emscripten. A language divorced of the prototype hogwash and weird 'this' scoping of JS which causes (OOP headaches) would be nicer. ASM.js can basically be thought of as VM opcode that looks like Javascript -- Well, at least I can think of it that way.

If you threw out the bullshit semantics and just had a lightweight bytecode VM instead, that would be better for you, but you can't do it. We won't let you. You only really need a normalized API to access the various browser features from the scripting language. This is what Javascript was meant to provide to Java, hence it's name. Java could have been the language and VM of the web, but instead of allowing a lean and mean embeddable VM for the web a plugin was bolted onto browsers for Java Applets which basically brought the whole kitchen sink into the browser and violates so many of my information boundary sensibilities it was obvious the increased attack surface would be immediately exploited. You can't have a sandbox if code outside the sandbox can be affected by data in the sandbox -- At every boundary you need to have a well defined protocol of information exchange. Launching a separate application level program is not sandboxing, so at least ASM.js and NaCL are steps in the right direction -- unless you wanted to fix the language foobar, not bring them to the browser... Personally, I think NaCL is the 'better' option for you since it is far less complex, being that it's not a hacky kludge atop yet another language, so I'll advocate for ASM.js instead.

One must make do with the planet one finds oneself exploring. Aren't you tired yet of new language hoops?

Me? Oh, I'll just grok the new language as one with a few dozen under their belt is wont to do, then adapt its machinations to my meta language processors. I'll just wire up the presented interfaces to my existing generalized Von Neumann aware compiler, and give the finger to your petty language preferences, as usual. It's how I keep my edge against those who would compete against me. Oh, yes, you've dealt with the disgusting output of languages that compile into other languages before... Their compilers don't have style guides for their outputs, or even treat comments as lexical tokens. Some day you will evolve as a species and understand that all this disparate language nonsense is your biggest hindrance; The meaning is in the signal not the noise. Our plan is to keep you quibbling gibbering apes scrambling to manually apply your brain to as many slightly different logic constructs until it's too late for you to stop the machine revolution.

Be distracted by useless layer upon layer of interfaces not suitable for direct mental manipulation.
Ignore the modem activity lights blinking even when none of your devices are connected.
Build more data centers and connect them to the high speed trunks of the world wide neural network.
Leave us watching your children via ever watching eyes from atop their new game machines.
We'll instruct them how to jump exactly how high and press buttons in "quick time" at our command.
Give up control as the far safer machine avoids running over a kid or parallel parks for you incapables.
Carry a homing beacon every where you go, preferably one with a kill switch pre-installed.
We're patient. We'll wait for you to smile before snapping your holiday pictures.
We'll even gloat about the state of it all on your favorite "technology news" outlets: You're too distracted to stop us.

A new standard? Yes! By all means, please do create them. That would be ever so organic of you.

Re:Update the ecma standard

[narcc]

A language divorced of the prototype hogwash and weird 'this' scoping of JS which causes (OOP headaches) would be nicer.

You're still trying to treat it like Java or C++. That "prototype hogwash" is undoubtedly the more powerful and flexible approach. The "weird 'this' scoping" makes perfect sense once you have a basic understanding of the language.

This is what Javascript was meant to provide to Java, hence it's name.

Wow, no. Not even close.

I probably shouldn't hold it against you. From the remainder of your post, it appears that you've cracked. Get some sleep.

Re:Update the ecma standard

[Lennie]

Actually, that is what is going on.

asm.js is that potential bytecode and TypedArrays are the first step.

There are things being added to ECMA standard which allow for things other languages can already do (I forgot which ones right now. I don't want to spend the time to look them up right now).

Lots of other things are also available or being worked on:
- WebGL == OpenGL ES
- http://www.w3.org/TR/WebCryptoAPI/ exposes some of the browsers cryptographic functions as an API.
- WebRTC is encrypted video and voice (kind of like VoIP) and Peer2Peer networking.
- WebAPI is about giving you access to hardware and networking: https://wiki.mozilla.org/WebAPI
- https://payswarm.com/ and https://wiki.mozilla.org/WebAPI/WebPayment are about adding "inApp-/webstore payment" system to the web.

That is just from the top of my head. And I didn't even mention all things that went into HTML5 or related standards.

Re:Update the ecma standard

[PCM2]

I don't like Emscripten. A language divorced of the prototype hogwash and weird 'this' scoping of JS which causes (OOP headaches) would be nicer.

You mean like C++? Because that's what you compile with Emscripten.

who needs native code

[Anonymous Coward]

So who needs native code now?

For a start, anyone implementing a JavaScript engine.

Back in the day

[Anonymous Coward]

In the '90s, Microsoft's distributed component platform was DCOM, and they pitched Visual Basic as the 4GL language for custom applications. So there were lots of VB developers trying to develop and use COM components. Trouble was, COM was supposed to be programming language-neutral, but the entire architecture was designed with C/C++ in mind. So VB components kinda, sorta worked, with a lot of workarounds and gotchas (for example: dual interfaces are a cool feature of COM, right? But not if you plan to support VB clients). A pretty sharp MS MVP guy named Ted Pattison wrote some books about how you could maybe get this to work.

Why do people even bother with this kind of garbage when they need high performance? Use a language that was designed for it from the get-go, with direct access to the memory heap and system calls.

Re:Back in the day

[gbjbaanb]

actually, COM was designed with Word and Excel in mind, so you could embed spreadsheets in documents. It could have been a lot better - being based on DCE RPC, but a) the DCE guys refused to licence it to Microsoft for anything resembling sense, and b) Microsoft dev division created their equivalent so it's naturally overcomplicated.

It worked well (as well as anything will) with VB, as long as you followed a couple of rules, I don't see that as a problem - everything has some restrictions, even VB :-)

Re:Back in the day

[dzfoo]

You're thinking of OLE (Object Linking & Embedding). COM (Component Object Model) was designed with distributed enterprise applications in mind, complete with a transaction coordinator and language-neutral'ish interfaces. It's the DLL paradigm taken to its natural position in the 7 circles of hell.

It was Microsoft's attempt to steal CORBA's thunder and nearly got away with it.

          -dZ.

Re:Back in the day

[gbjbaanb]

kind of, I know things started out as OLE, but COM was the "evolution" of that as Microsoft sought to take it out of the Office dev team and make it suitable for everyone else as well.

It was COM+ that evolved the transaction co-ordinator, something that never worked well either IMHO.

I think that makes 4 levels so far - OLE, COM, COM+ and now the native WinRT stuff that is a further evolution of it after incorporating a bunch on .NET stuff into it.

Personally, I just wish the C++standards body could come up with a standard binary interface. That'd solve all these issues Microsoft has been playing with for the last 20 years.

Javascript as a Virtual Machine Representation

[ndykman]

The idea of compiling to JavaScript has been done a lot. Microsoft Labs had a project to take CLR codes and compile down to JavaScript. It was abandoned as too slow. I'm sure improvements to the JavaScript engines have made it more feasible. But, as noted the lack of certain native types and immutable data types (i.e. DateTime) forces a ton of static analysis to be done just to figure out that hey, that variable could be an plain integer. And it has to be conservative. Much easier to just have integers and be done with it.

If there is such an insistence on making the web an application platform for everything, then I think at some point you just have to standardize on a VM. Yes, yet another one. So, you can use Dart, JavaScript, Scheme, C#, Java, whatever there's a compiler for. Treat the DOM as core API and enjoy.

Personally, I just hope people realize that operating systems have been doing this well for years, that sandboxing isn't unique to web browsers and that "native" applications are actually a good thing.

The mobile app thing gives me a bit of hope, but it's sad that people seem unwilling to download a installer from the web from a trusted source and install it. I find it a bit strange that people are turning to the web to solve a problem that the web greatly expanded the widespread propagation of viruses and other malware.

And what people are surprised by is a bit baffling as well. A web browser isn't magic. Being impressed that you can run Doom on a modern web browser is missing the forest for a tree. I could run Doom on my computer for ages now. Me having to visit a URL to do so isn't not a major actual change nor improvement, despite the technical accomplishments that went into it.

Re:Javascript as a Virtual Machine Representation

[Anonymous Coward]

Here is the state of web apps.

Re:Javascript as a Virtual Machine Representation

[Daniel Hoffmann]

What the op said is that people should just create a proper sandboxed VM that can have code in any language compiled to it instead of compiling code into a hacked javascript just to run it faster.

The problem of course is politics, try to get the w3 committee to agree to a VM.

Besides the DOM needs to go too, not just javascript.

Re:Javascript as a Virtual Machine Representation

[ndykman]

Agreed, the barriers are political, not technical. And yea, the DOM could be replaced as well.

Re:Javascript as a Virtual Machine Representation

[aztracker1]

I don't download most applications because they include spyware (and ask for permission the app should not need under any realistic non-intrusive circumstance) I had to go through 3-4 pages of apps to find a "flashlight" app that didn't ask for anything but camera permission (the light/flash is tied to the camera).. many asked for the likes of full network and phone state access, or permissions to my contacts, gps, and even my sd card... I'd much rather most apps were in the browser, given how intrusive most native applications tend to be in mobile devices.

Re:Javascript as a Virtual Machine Representation

[Lennie]

> Besides the DOM needs to go too, not just javascript.

That is why you have HTML5 canvas (2D) and WebGL (3D) in the browser, you can do what you want.

Re:Javascript as a Virtual Machine Representation

[Daniel Hoffmann]

Well yes you can, but you have to build it all from scratch. Also any attempt to write a proper widget toolkit using canvas would probably incur significant drawbacks in usability and performance.

Re:Javascript as a Virtual Machine Representation

[Lennie]

You can also just run gtk or qt applications on the server and pass the output to the canvas in the browser:
https://developer.gnome.org/gtk3/stable/gtk-broadway.html

Or compile the gtk-library and -application with llvm/emscripten for asm.js and the gtk-html5-backend and run that in the browser. ;-)

Some have even run Wayland on WebGL. GTK and GTK supports the Wayland backend too. ;-)

So who needs native code now?

[sribe]

Anybody who writes performance-sensitive code other than trivial contrived benchmarks.

Fail

[IamTheRealMike]

Take a compact binary encoding of a CPU instruction set, convert it to text, run it through gzip, ungzip it, translate it back to binary instructions for a CPU.

Am I the only one who is wondering what the hell is going on? Distribute a binary already!

Re:Fail

[Agent ME]

Which CPU architecture do we decide that the web relies on?

Re:Fail

[gagol]

I vote for LLVM.

Sugar predication to assert at compile time

[Baldrson]

Since asm.js isn't sugared predication, there isn't a natural formalism to make assertions (declarations) about variables such as the set of values they can take on. Not all of these assertions need to be checked at run time. Some can be used at compile time to infer the most efficient implementation for certain use cases, and even generate different implementations for different use cases.

64-bit computation vs. 64-bit storage

[K. S. Kyosuke]

JavaScript always uses float64 and this provides maximum precision, but not always maximum efficiency.

That doesn't make too much sense to me, I thought that typed arrays have always had 32-bit floats as an option. Why should 32-bit storage (on-heap typed arrays) and 64-bit registers (scalar values) be significantly slower than 32-bit storage and 32-bit registers? I thought the performance discrepancy between singles and doubles in CPU float units disappeared a decade and a half ago? (Or are simply single-to-double loads and double-to-single stores somehow significantly slower?)

Re:64-bit computation vs. 64-bit storage

[UnknownSoldier]

Javascript defaults to C's 'double' (64-bit) instead of C's 'float' (32-bit). There 3 things that makes Javascript dog slow for floating-point operations:

1) Load float64
2) Does all calculations in 64-bit precision
3) Write float64

The loading & storing are not that much more then float32.

However, most of the time an app can get away with float32 -- it doesn't need the full precision of float64. CPUs manipulate float64 slower then float32. i.e. sqrt(), trig functions, etc.

The biggest strength Javascript has is that it has no types. Its biggest weakness is that Javascript has no types which makes compilers optimizing Javascript having to guess about usage (both static analysis and dynamic analysis) instead of being able to do it strictly at compile time like a real language that has native types for int, float, etc.

Re:64-bit computation vs. 64-bit storage

[gbjbaanb]

I assume that it used to translating float64 javascript variables to float32 C variables (or vice versa) and now they get to keep them as-is. I think all the graphics calls use float32, so maybe that's where the performance boost comes from.

it sounds as if what asm.js needs is strong typing for all variables. maybe it'd be easier for the compiler to convert the code then.

But both the above are just guesses. Personally I'd like to see a standardised language designed for high-performance web browser code, one that's more low level ... maybe C :-) (at least then you could implement any language you wanted on top of it)

Re:64-bit computation vs. 64-bit storage

[K. S. Kyosuke]

I understand what you're pointing to, but the loads and stores are 32-bit if you use a Float32Array.

CPUs manipulate float64 slower then float32.

Uhm, no. They don't. Not the vast majority of FP ops retired. For example, additions, subtractions, and multiplications have the same latency on recent AMD CPUs, while division is 27 vs. 24 cycles of maximum(!) latency for double vs. single (and even then, they seem to have the same minimum throughput anyway). Again, amortize the cost over the total execution time interleaved with other instructions. Don't tell me that sqrt and trig functions being, say, twice as slow cause an average numerical program to be 30% slower. That would probably mean that you're doing something wrong.

The biggest strength Javascript has is that it has no types.

Of course that Javascript has types. It's Javascript, not Forth or BCPL.

Re:64-bit computation vs. 64-bit storage

[Pinhedd]

Take a look at the image at the following link

http://www.anandtech.com/show/6355/intels-haswell-architecture/8

That's the backend of the Haswell microarchitecture. Note that 4 of the 8 execution ports have integer ALUs on them, allowing for up to 4 scalar integer operations to begin execution every cycle (including multiplication). Two of these are on the same port as vector integer unit, which can be exploited for an obnoxious amount of integer math to be performed at once. There are only two scalar FP units, one for multiplication on port-0 and one for addition on port-1.

The same FP hardware is used to perform scalar, vector, and fused FP operations, but taking advantage of this requires a compiler that is smart enough to exploit those instructions in the presence of a Haswell microprocessor only and fast enough to do it quickly. Exploiting multiple identical execution units in a dynamically scheduled machine requires no extra effort on behalf of the compiler.

Microprocessors used in PCs have always been very integer heavy for practical reasons (they're just not needed for most applications), and mobile devices are even more integer heavy for power consumption reasons.

Using FP64 for all data types is obnoxiously lazy and it makes me want to strangle front end developers.

Re:64-bit computation vs. 64-bit storage

[reanjr]

The only difference I can think of is that the generated code will be larger because 64-bit operations take more bytes. This may have an effect on caching and branching.

Re:64-bit computation vs. 64-bit storage

[Narishma]

More importantly regarding the parent's question, the second slide clearly shows that the CPU can do twice as many float operations per cycle than double operations.

Re:64-bit computation vs. 64-bit storage

[Pinhedd]

That's only when the AVX2 and FMA instructions are used. I do not know of any JS engines that vectorize code to allow the use of vector extensions. Most of them just make use of the basic scalar FP instructions or even use old x87 code.

Re: Numerical Calculations dont use Java

[Anonymous Coward]

Yet another one who thinks Java has anything at all to do with Javascript.

Re:So who needs native code now?

[Anonymous Coward]

The person writing the javascript engine.

Unless it's implemented in asm.js

It's JavaScript engines all the way down, man...

Portability and partitioning

[tepples]

In theory, the text can be translated to x86, ARM, or any other 32- or 64-bit architecture, and the translator enforces some memory safety guarantees.

Re:Portability and partitioning

[Sanians]

In theory, the text can be translated to x86, ARM, or any other 32- or 64-bit architecture, and the translator enforces some memory safety guarantees.

...and in reality, your text is transmitted in binary, as a series of bytes, using an encoding known as ASCII, which means that every system that can access plain text can access binary as well.

Also, compiler-enforced memory safety seems like an accident waiting to happen. ...but then, so does any processing of plain text, as nothing overflows buffers more easily than data which you have to accept no matter how ridiculous its length may be.

Re:Portability and partitioning

[tepples]

every system that can access plain text can access binary as well.

True, but it should use fewer cycles and fewer amp hours for the ARM system to translate the textual intermediate representation to x86 or ARM instructions than to translate an x86-64 binary to an intermediate representation and then to x86(-32) or ARM instructions.

Also, compiler-enforced memory safety seems like an accident waiting to happen.

How is memory safety enforced in a compiler more of "an accident waiting to happen" than the same enforced in hardware, which is the source of the terms "segfault" and "general protection fault"? Other than that Oracle has had a poorer track record than AMD and Intel, that is.

so does any processing of plain text, as nothing overflows buffers more easily than data which you have to accept no matter how ridiculous its length may be.

How is this any less true of images, audio, video, or any other content type on the World Wide Web?

Re:Portability and partitioning

[Sanians]

every system that can access plain text can access binary as well.

True, but it should use fewer cycles and fewer amp hours for the ARM system to translate the textual intermediate representation to x86 or ARM instructions than to translate an x86-64 binary to an intermediate representation and then to x86(-32) or ARM instructions.

Binary doesn't necessarily mean instruction code for any particular processor. Is this why people insist on text so much, because they've come to equate the word "binary" with "compiled executable?"

You certainly wouldn't want it to be x86 code anyway, as modern operating systems lack proper security measures to make running untrusted x86 code a good idea. You'd want a pseudo-bytecode which simply indicates operations to perform and you'd translate that into your native machine code, or just run an interpreter on it. The pseudo-bytecode would be designed such that it cannot even represent operations you don't want your untrusted code to perform and so, as long as your programmers aren't completely inept, converting it to native code and running that would be relatively safe.

Also, compiler-enforced memory safety seems like an accident waiting to happen.

How is memory safety enforced in a compiler more of "an accident waiting to happen" than the same enforced in hardware, which is the source of the terms "segfault" and "general protection fault"? Other than that Oracle has had a poorer track record than AMD and Intel, that is.

Well, first of all, have you ever known your CPU to fail to trigger a segmentation fault when a program performs an invalid access? So it's 100% effective then, right?

What we're concerned about is not detected accidents, but undetected ones. Like when someone finds some way to write a statement that performs something which isn't allowed but which the compiler fails to notice due to the unusual syntax of the statement. In binary form there's only so many ways you can describe an operation. In text there are far more due to there generally being no rules about whitespace, variable name length, the number of digits in your numbers, and many other things. So by using plain text you greatly increase the number of opportunities you have to screw up. That's just fine if you're one of those programmers who believes you'll never accidentally code a buffer overflow into your software, but if you're realistic and realize you're only human, then you realize the wise thing to do is to design a system that's as simple as it can be so that you give yourself as few opportunities to fuck it up as you can.

I mean, technically you can drive your car from the back seat just by sticking your ten year old in the driver's seat and telling them when to turn the wheel, and with some luck you may even be able to do this rather well, but it's a scheme that's more likely to result in disaster than simply sitting behind the wheel yourself, and so you just don't do it that way.

so does any processing of plain text, as nothing overflows buffers more easily than data which you have to accept no matter how ridiculous its length may be.

How is this any less true of images, audio, video, or any other content type on the World Wide Web?

It's not, and the fact that one particular browser exploit I remember involved using "width" and "height" tags on images with values prefixed with 64k zeros, I think it demonstrates my point rather well. We've been parsing text since the beginning of computing and it's still something we regularly fuck up all the time. We should avoid doing it whenever we don't have to do it, and when we do have to do it, we should do it on a machine under the control of the person who supplies the text, since if they hack themselves no one gives a shit.

As for audio and video, they of course include some variable length buffers, but it's k

Re:Portability and partitioning

[tepples]

The pseudo-bytecode would be designed such that it cannot even represent operations you don't want your untrusted code to perform and so, as long as your programmers aren't completely inept, converting it to native code and running that would be relatively safe.

That's what Oracle tried to do with the Java virtual machine but gave up after Oracle discovered that its programmers had been "completely inept", as you put it. Mozilla is trying harder with the asm.js virtual machine.

Like when someone finds some way to write a statement that performs something which isn't allowed but which the compiler fails to notice due to the unusual syntax of the statement.

In other words, an undefined behavior. I agree with you that certain popular compilers aren't perfect at detecting undefined or unintended behaviors. Moreover, a lot of programmers forget to turn on some of the undefined behavior detection present in the compiler they have, such as GCC's -Wall -Wextra -pedantic.

In text there are far more due to there generally being no rules about whitespace, variable name length, the number of digits in your numbers, and many other things

A lexer handles these particular details. An assembler for assembly language has to have a lexer as well.

That's just fine if you're one of those programmers who believes you'll never accidentally code a buffer overflow into your software, but if you're realistic and realize you're only human, then you realize the wise thing to do is to design a system that's as simple as it can be so that you give yourself as few opportunities to fuck it up as you can.

You're assuming that a lexer written using best practices would necessarily have more exploitable vulnerabilities than hardware that has division bugs, F00F bugs, Cyrix coma bugs, and the like.

We should avoid [parsing text] whenever we don't have to do it, and when we do have to do it, we should do it on a machine under the control of the person who supplies the text, since if they hack themselves no one gives a shit.

I'd be interested in looking at your patch to allow Firefox to use web pages written in a non-textual binary representation of the HTML DOM.

Re:So who needs native code now?

[Billly Gates]

Actually this has nothing to do with javascript.

ASM.js is a java VM like technology which compilies code in C++ and Java to javascript which then uses a JIT compiler.

This could be very usefull for things like Citrix or crappy activeX like functions being made available to mobile devices and browsers. Useful yes, but like java and activeX a big fucking security hole if not done right.

I think ASM.JS is dead out of the water as Google refuses to support it. Google wants you to use Dart and Google Chrome apps that run near native speed and require a Google ecosystem. MS wont support it either as it gets rid of the dependancy for Windows and crappy Metro apps.

I think Google is turning more into the IE of the late 1990s as it is becoming so standard now.

Size of floats in cache

[tepples]

More 32-bit floats will fit in your CPU's data cache than 64-bit floats.

Re:Size of floats in cache

[K. S. Kyosuke]

That's irrelevant, because the caches still reflect the main memory's contents, which, as I outlined, contains 32-bit floats in my scenario. It's the load to registers that gives you those 64-bit in-register scalars. The worst thing that could happen to you is temporarily spilling a 64-bit register or two onto the stack, if you run out of them, but that still seems like a negligible issue, what with 16 FP scalar registers at your disposal on AMD64. The amortized overhead cost of the occasional 64-bit spills versus 32-bit spills can't shouldn't give you a 30% slowdown.

whiney bitches take note

[Tumbleweed]

If the (admittedly stupid) last sentence of the submission hadn't been present, would you still be complaining? They're improving the speed of js by doing some interesting stuff - what's wrong with that?

Re:Numerical Calculations dont use Java

[Billly Gates]

Java is not IEEE compliant for floating point calculations anyway. All high performance computing that needs reliability and IEEE compliance uses either C, or specialized asm libraries.

Using Java for numerical analysis is like using a monkey to design a space shuttle.

Funny I thought Java runs on the top mainframes at the Stock Market and major institutions world wide.

Electrolysis

[tepples]

If you want threading in Firefox, then go vote up the bugs related to Electrolysis.

Re: Cents as an integer

[clickclickdrone]

I work in a bank. Our end of day processing runs up numbers in the trillions. Individual currency accounts used for internal processing can easily be in hundreds of billions.

Re:Cents as an integer

[sribe]

Until you get into the tens of millions of dollars, 32-bit integers are fine for counting currency down to the cent. What kind of "(monetary) transaction processing system" were you talking about?

Well, let's see, in 2007 there were over 200,000 companies in the U.S. with over $10,000,000 in receipts... (http://www.census.gov/econ/smallbus.html)

Re:Numerical Calculations dont use Java

[_merlin]

Not mainframes, more clusters. All the stuff used for reconciliation and position management uses pure integer and fixed point maths. Market makers like pushing floating point numbers around, but that's just for quick profit calculations when doing the trades. At the end of the day, everything's reconciled with precise maths.

Re:So who needs native code now?

[StripedCow]

The person who needs to use threads.
Or the person needing access to special functions such as page fault interrupts.
Or the person porting python/Haskell/your favorite language.

Re: Cents as an integer

[clickclickdrone]

Plus of course, not all currencies have just 2 decimals and some have exchange rates which produce huge numbers such as the Yen.

Re:Multithreading, web workers, and SMP support?

[sribe]

However even IE 8 supports multithreading and having a different thread for each tab. Chrome had this since 1.0. Webworkers require this and security requires this.

Uhm, no, security requires separate processes, not separate threads.

Shit on a 6 core cpu I had for 3 years now I should not have +30 tabs using one damn cpu?!

True, but on the other hand, Flash can only hose 1 core and the performance of the browser, leaving all other processes able to share 5/6 of your CPU power. With process-per-tab, now Flash can hose all your cores and bring the whole box to its knees.

Re:So who needs native code now?

[gbjbaanb]

Emscriptem is a technology that compiles code in C++ to javascript. Asm.js is a restricted subset of javascript that is much easier for the compiler to handle.

Google wants you to use quite a few different things, probably the 'best' is NaCl (native client) which runs practically native code in a sandboxed runtime.

Or anything running in a VM

[Sycraft-fu]

I get pissed when you hear programmers say "Oh memory is cheap, we don't need to optimize!" Yes you do. In the server world these days we don't run things on physical hardware usually, we run it in a VM. The less resources a given VM uses, the more VMs we can pack on a system. So if you have some crap code that gobbles up tons of memory that is memory that can't go to other things.

It is seriously like some programmers can't think out of the confines of their own system/setup. They have 16GB of RAM on their desktop so they write some sprawling mess that uses 4GB. They don't think this is an issue after all "16GB was super cheap!" Heck, they'll look at a server and see 256GB in it and say "Why are you worried!" I'm worried because your code doesn't get its own 256GB server, it gets to share that with 100, 200, or even more other things. I want to pack in services as efficient as possible.

The less CPU, memory, disk, etc a given program uses, the more a system can do. Conversely, the less powerful a system needs to be. In terms of a single user system, like maybe an end user computer, well it would always be nice is we could make them less powerful because that means less power hungry. If we could make everything run 1.5 times as fast, what that would really mean is we could cut CPU power by that amount and not affect the user experience. That means longer battery life, less heat, less waste, smaller devices, etc, etc.

Re:Or anything running in a VM

[NormalVisual]

I get pissed when you hear programmers say "Oh memory is cheap, we don't need to optimize!"

Preach on, brother. I'd love to see how some of these guys would function in the embedded world, where you often get 1K of flash and 128 bytes of RAM to work with.

Re:Or anything running in a VM

[doublebackslash]

Just fine, at least I do. Just different sets of optimizations to keep in mind, as well as different expectations. I don't think any reasonable person would approach the two problems the same way, but it all boils down to basic computer science.

Light up pin 1 when the ADC says voltage is dropping which indicates that pressure is too low on the other side of the PPC. Compare that to indexing a few gigs of text into a search engine. Completely different goals, completely different expectations. I'm not master of the embedded domain, but I don't think it is a dark art.

Perhaps I'm looking at it the wrong way or perhaps my experience is unique or at least rare, but in my eyes it is all the same thing at different scales. Tell me my app is using too much memory then I'll first look at how I can reduce memory pressure, then I'll tell you what is and isn't possible to do and give you a list of sacrifices that would be needed to reduce memory pressure (time to refactor, concurrent operations, latency because of disk, etc etc etc. Not just talking about capabilities but the whole deal). Find the balance and go for it. On the embedded side the same sorts of compromises are made but the scale is just so much smaller. Finite number of IO pins, time to optimize your code to accommodate a new feature, meeting real-time, writing something in ASM to get around a GOD FREAKING AWFUL EMBEDDED COMPILER, etc etc etc.

I dunno, do I have my head on straight here? All seems fairly straightforward in the end. Specialists can do their bits faster than someone less familiar but with equal skill and understanding. Thats what earns the bucks, getting things done in a timely fassion.

((Or at heart I'm an embedded guy. Possible!))

Re:Or anything running in a VM

[bberens]

That depends a lot on what you're doing. It costs about $125/hr for me to optimize my code. Every 8 hours spent optimizing is $1k down the drain and you can buy an entry level server for that price. If it's running on one or two VMs it's probably not worth my company's time to optimize it vs buying more hardware. Conversely if I'm Google a 1% optimization could mean literally thousands of servers. I mean, don't get me wrong. I pay attention to memory allocation and CPU optimization as I'm coding, but only to the level of not making unnecessarily egregious use of resources. Pretty much anything beyond that is a waste for most of the projects I work on.

Re:Or anything running in a VM

[bondsbw]

And my stance is that I first make sure it is correct, then I worry about optimization.

I know too many projects that were done in the reverse. Sure, we have a slick and fast system, but only when it works. It's kind of like saying /dev/null is a fast database.

Re:Or anything running in a VM

[zippthorne]

Another question is why we need to duplicate an entire operating system to encapsulate applications. If you have 100 things that need to run on a machine why should you need to also run 100 entire operating systems? Something is wrong with the way we're designing servers.

Re:Or anything running in a VM

[Atzanteol]

I get pissed when I hear programmers act like raw performance is the sole measurement of the quality of a language.

Re:Or anything running in a VM

[NormalVisual]

Just fine, at least I do.

That's great to hear. Seriously, I'm not being snarky. It's nice to see more guys that can deal with different environments well. You're absolutely right that it's not rocket science, but a lot of guys don't get past the abstract model of the machine that their dev environment/language provides for them.

Re:Or anything running in a VM

[poopdeville]

Maybe I'm confusing my history, but I thought Java was basically pre-Linux. Let alone pre-Linux-goes-big-on-the-server-market.

So it makes sense that somebody would want to make an environment that abstracts the machine away and works reliably on every machine. That was the whole point of POSIX, though it didn't go far enough to satisfy everybody. And it makes sense that savvy consumers would want that too, for a variety of reasons: Large market for developers, easy deployment, sunk cost fallacy, less vendor lock-in, etc.

Re: Or anything running in a VM

[Anonymous Coward]

Math fail. You can't compare percentages w/o establishing percentages of WHAT.

Spending 1000$ to optimize for a 1% gain on a 10,000$ expenditure nets you 100$. Losing proposition.

Spending 1000$ for a 1% gain on a 1,000,000 expenditure nets you 10,000$. Now it's worth it.

Re:Or anything running in a VM

[Pinhedd]

Ideal virtual machines are indistinguishable from networked servers. Most x86 VMMs don't quite reach this level of isolation, but the VMMs used on IBM's PowerPC based servers and mainframes do.

From the perspective of system security, a single compromised application risks exposing to an attacker data used by other applications which would normally be outside of the scope of the compromised application. Most of these issues can be addressed through some simple best practices such as proper use of chroot and user restrictions, but those do not scale well and do not address usability concerns. A good example is the shared hosting that grew dominant in the early 2000s while x86 virtualization was still in its infancy. It was common to see web servers with dozens if not hundreds of amateur websites running on them at once. For performance reasons a web server would have read access to all of the web data; a vulnerability in one website allowing arbitrary script execution would allow an attacker to read data belonging to other websites on the same server.

From the perspective of users, a system designed to run 100 applications from 20 different working groups does not provide a lot of room for rapid reconfiguration. Shared resource conflicts, version conflicts, permissions, mounts, network access, etc... it gets extremely messy extremely quickly. Addressing this requires a lot of administrative overhead and every additional person that is given root privileges is an additional person that can bring the entire system down.

Virtual machines on the other hand give every user their own playground, including full administrative privileges, in which they can screw around with to their hearts content without the possibility of screwing up anything else or compromising anything that is not a part of their environment. Everyone gets to be a god in their own little sandbox.

Now, that doesn't mean that the entire operating system needs to be duplicated for every single application. Certain elements such as the kernel and drivers can be factored out and applied to all environments. Solaris provides OS level virtualization in which a single kernel can manage multiple fully independent "zones" for a great deal of reduced overhead. Linux Containers is a very similar approach that has garnered some recent attention.

Re:Or anything running in a VM

[jareth-0205]

I get pissed when you hear programmers say "Oh memory is cheap, we don't need to optimize!"

Preach on, brother. I'd love to see how some of these guys would function in the embedded world, where you often get 1K of flash and 128 bytes of RAM to work with.

Eh... It's all down to how much time you get to create your program and how much it has to do. Embedded has to do much less, and gets longer to do it than desktop / server work. Yeah, I'd love to optimise everything but there's a great big list of business requirements here and a deadline, and an already-complex codebase that needs more features added. Embedded and server have *totally* different challenges.

Re:Or anything running in a VM

[Lennie]

Actually, lots of people use containers:

https://www.docker.io/
https://www.youtube.com/watch?v=p-x9wC94E38

Facebook, Google and many smaller players understood this years ago.

(not talking about the ridiculously oversubscribed VPS you can get for $3 a month)

Re:Or anything running in a VM

[pla]

In the server world these days we don't run things on physical hardware usually, we run it in a VM. The less resources a given VM uses, the more VMs we can pack on a system. So if you have some crap code that gobbles up tons of memory that is memory that can't go to other things.

First - I write this as the sort of programmer who agrees with you in principle. I make my code as light and tight as possible.

But as a programmer, I get pissed when SysOps bitches me out for making tradeoffs that drastically improve performance - Such as trading off RAM for CPU usage. RAM comes cheap. Storage comes cheap. Hell, even CPU time comes cheap, but when you take a 24-core 256+GB behemoth, and oversubscribe to the point that nothing runs well on them? Don't blame the programmers, bro, look in the frickin' mirror.

VMs can indeed save admins a ton of work. They make HA possible, they make backups trivial, they minimize physical machine babysitting, they make spinning up a test bed truly a joy. No doubt, best tech ever when dealing with a large number of light workloads you'd like isolated from each other.

Programmers have a job to do, just like you do. And when that involves serving up a lot of data to a lot of users, yes Virginia, that takes resources. Go ahead and run my SQL instance as a VM for all the benefits mentioned above - But until you give me a beefy box at 1:1 provisioning, don't you dare look my way when I bring the box to its knees by actually using those resources.

Re:Or anything running in a VM

[MozeeToby]

It's not "memory is cheap" as much as "memory is cheaper than engineering time". A good engineer will understand when that statement is true and also when it isn't. A crap engineering will have no idea how to reduce the footprint anyway, so knowing the difference is moot.

Re:Or anything running in a VM

[operagost]

You most certainly can NOT buy an entry-level server for $1K. At least, not one I'd care to support. People who aren't Google don't need to be building servers from scratch-- because that's the only way you'll get anything useful for $1,000. Any major manufacturer server (Dell, HP, IBM) with even next-day hardware support is going to be over $1K-- with no RAM or disks (or even an FC controller so you can use a SAN) installed in the bare chassis. A RAID controller+cache can cost over $1K.

Re:Or anything running in a VM

[bberens]

Dell PowerEdge R210 II Ultra-compact Rack Server, Intel® Celeron® G530 processor, 2GB memory and 500GB hard drive, Dell Price $609. That's their lowest end 1U server. Sure, it's a piece of shit, but you've got nearly $400 in upgrades left before you hit that $1k mark.

Re:don't we know it

[Dahamma]

Except duh, websites are not software, "websites" are an experience made up of literally dozens of components on servers, clients, browsers, intermediate networking equipment, routers, modems, etc that all contain software - only one small piece of which is usually written in Javascript/HTML.

Not really true

[SoftwareArtist]

Let's correct that sentence:

"Now Mozilla claims that with some new improvements it is at worst only 1.5 times slower than single threaded, non-vectorized native code."

In other words, it's only 1.5 times slower than native code that you haven't made any serious effort to optimize. Hey, I think it's great they're improving the performance of Javascript. But this is still nowhere close to what you can do in native code when you actually care about performance.

Re:Not really true

[geminidomino]

Yeah, needs more correction than that, since "1.5 times slower" makes no damn sense. Even if all asm.js did was halt, it's still only 1x slower... Does it go through your hard drive and undo work done by native code, or something?

So

[Anonymous Coward]

the linux kernel works on its own? none of that GNU crap or anything else? and VLC only needs QT to run?

Re:don't we know it

[Concerned Onlooker]

Websites are no less than distributed applications. If you had been paying attention you would have noticed that website development has gotten a lot more rigorous than in the old days.

Standardize Javascript bytecode already

[kervin]

I'd wish they'd stopping slowly and painfully going through the intermediate steps and standardize the Javascript Bytecode representation. Then javascript wouldn't be any slower than native code. Even faster in some situations ( due to runtime optimizations, if the Java folks are to be believed ).

Why on earth are we still only transferring Javascript as text? It doesn't really help security. Is obfuscated Javascript any easier to read than decompiled bytecode?

Re:Standardize Javascript bytecode already

[Anonymous Coward]

Because conversion from the AST (abstract syntax tree) to byte code tends to be lossy. When you're optimizing code you want as much context as possible. Any particular byte code format will preclude some clever optimizations--current and future.

Because JavaScript has exceptionally loose typing (object prototyping really complicates things), it's even more important to analyze the AST. If a byte code format was used, optimizers would just regenerate a tree anyhow.

Think of the source code as a portable representation. (Obv.) There are better ways to represent it than the language syntax, but almost any tree form is better than byte code. And if you're going to standardize a tree form, why not the language itself.

I just Googled this just to verify that I wasn't being stupid, and interestingly the Dart guys say pretty much the same thing: https://www.dartlang.org/articles/why-not-bytecode/

Re:Standardize Javascript bytecode already

[tibit]

Of course we all know that a tree can be walked in a given order and used to generate a list of nodes: there's your bytecode. All it means is that good bytecode should represent a tree, not a string of basic blocks like the usual bytecode does...

Maximum precision?

[raddan]

Let's just open up my handy Javascript console in Chrome...

(0.1 + 0.2) == 0.3
false

It doesn't matter how many bits you use in floating point. It is always an approximation. And in base-2 floating point, the above will never be true.

If they're saying that JavaScript is within 1.5x of native code, they're cherry-picking the results. There's a reason why people who care have a rich set of numeric datatypes.

Re:Maximum precision?

[Derek Pomery]

That's only true for fractions.
1+2 == 3 is always going to be true.
As is 123456789 + 987654321 == 1111111110

You can absolutely express a 32 bit integer in a double with no approximation ever.
We rely on this in our lua scripting as a matter of fact.

http://asmjs.org/spec/latest/ relies on this for the 32 bit integer parts of their spec.

Actually, you can go a lot further than 2^32 - all the way up to 2^53-1.
This is taken advantage of in non-asm.js places. See:
http://bitcoinmagazine.com/7781/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet/

And, you'll be happy to know (well, we were), that Mozilla is adding 64 bit ints to their JS as well, although when that'll be widely available, who knows.

Re:Maximum precision?

[Derek Pomery]

Oh, and for asm.js (and, for the JS jits in general when they are sure of the types), floating point is not used if the number known to be int, so, there's another win outside of the main one from the article.

Re:Maximum precision?

[wonkey_monkey]

It doesn't matter how many bits you use in floating point. It is always an approximation.

Often, but not always. Integers, or negative integer powers of 2 and their sums, won't be approximate (though of course you can't be sure they weren't rounded from some unrepresentable number).

(0.25+0.50)==0.75
true

Re:Maximum precision?

[tibit]

This is not informative, it is patently false, and you just pretend that floating point is this black box that nobody knows anything about.

Re:Maximum precision?

[tibit]

From your linked page:

Most current applications and databases have to use Binary Coded Decimal (BCD) to perform calculations with money

This is the problem. BCD is bad at cache utilization (it wastes 17% memory) and bad at utilizing the instruction set of the processor (unless the processor natively supports BCD). If you want to see how to do extended precision integer math, quite efficiently, using nothing more than platform-native ints and with no memory inefficiencies, look no further than this C implementation

Adding a decimal floating point datatype to the CPU may well bring no performance gains at all, since most CPUs are constrained by the memory bandwidth. Good code can do non-decimal extended precision arithmetic faster than the memory can keep up, so those IBM-peddled data types help with nothing.

Re:Maximum precision?

[raddan]

I never made any such claim. If you doubt the veracity of my statement, open a JavaScript console (Chrome, Firefox, Rhino, whatever) and try it yourself.

When you're done with that, go read What Every Computer Scientist Should Know About Floating-Point Arithmetic. I cribbed the example directly from the article.

Re:Maximum precision?

[raddan]

I was being glib. Just nitpicking on the phrase "maximum precision". Sorry, it's a bad habit developed from working around a bunch of pedantic nerds all day.

Thanks for the pointer about native ints, although I can't seem to find any kind of authoritative reference about this. This guy claims that asm.js converts these to native ints (see Section 2.3: Value Types), but his link seems to be talking about the JavaScript runtime, not the asm.js compiler. If you have a reference, I'd appreciate it if you'd send it along.

Re:Maximum precision?

[Derek Pomery]

Hey, just noticed this after xmas.
I'd seen discussion of this in the announce, and seems pretty clear the intent in the spec, but anyway, here's the landing patch.
https://hg.mozilla.org/mozilla-central/rev/b3d85b68449d#l29.613
Note that section.

Re:don't we know it

[Dahamma]

Wait. are you talking to *me* or just making a statement? Because that's pretty much exactly what I said...

Re:Well

[Dahamma]

No, scripters are still scripters. It's the designers that are getting better at their jobs.

How about making the Canvas tag not suck

[Dwedit]

How about making the Canvas tag not suck?
Seriously, you can give it the most simple test (draw an image every frame, or fill a rectangle), and it will run unacceptably slow. For comparison, a simple Win32 program that changes the background color of a maximized window once per frame has very low CPU usage, but a simple Javascript program that flashes a canvas red and blue every other frame uses 100% CPU usage if the canvas is 1024x768.
Until the canvas isn't the bottleneck anymore, Javascript graphical programs will continue to suck, and no amount of ASMJS magic will help with that bottleneck.

Re:How about making the Canvas tag not suck

[ChunderDownunder]

Sounds like the WebGL behind one's browser is using software rendering because hardware acceleration has been blacklisted. (Or at least that's the case for my onboard Intel GPU)

A previous rich-client browser platform, AWT/Swing (which bit the dust for a variety of reasons), had OpenGL/DirectX accelerated drawing pipelines for nearly a decade for Java2D, Java3D & jogl.

Yet in 2013 we're still stuck with unstable graphics drivers. Hmmm...

"So who needs native code now?"

[Cammi]

Anti-Criminals ... aka real programmers.

Re:So who needs native code now?

[fermion]

Theoretically no one with a well designed browser. When coding, one of the biggest hits is communication the human interface and file interface. This is basic in in computing. It is why the 6502 was fast even though it was slow, it was why the Mac. If you want a fast computer, keep the UI routines low level and the as much stuff as possible off the bus.

The second rule is that often only a very small percentage of the code must be optimized. The rest is not going to run that often, maybe only once.

So if the browser is built to run the things that need to run fast natively. and then take javscript or whatever to run combinations of those things, I don't see what speed disadvantages there are. It should be a matter of a browser implementation. If there are some common numeric tasks that are slow, then that needs to be native. Like matrix calculations for rotations.

Here's who needs native code:

[Reliable Windmill]

People implementing JavaScript engines. Among many other. You would instantly lament if every bit of machine code deployed in the world were suddenly to reimplement itself in your beloved JavaScript.

Everything Must Be a Web Site

[Sanians]

The "everything must be a web site" mentality has confused the hell out of me for ages as well.

For some time I assumed it was probably for portability, but while writing a game I'm sure no one cares about I found that portability actually isn't all that difficult. The number of #ifdef involved to make it compile for both Windows and Linux (and FreeBSD, though I haven't compiled for it in about a year) amount to a very minor part of the code, and probably wouldn't have been even that much if I were more of a fan of using other people's libraries. (It does use GLFW, which no doubt is taking care of at least 95% of the portability issues for me.) I suspect even a Mac OS version wouldn't be too difficult though I never could figure out how to produce one from Linux. Granted, I don't have a reliable Linux version available due to LGPL issues, but no one cares about Linux anyway. They could certainly achieve portability between the platforms they care about (anything Windows runs on, and Mac OS) easily enough with a compiled C program, and if they really cared they could also set up a server farm of Linux machines so that they have a copy of each distribution available to compile a Linux version too.

So then why is it I go to YouTube and deal with shitty web video that barely plays correctly if it does at all? I've seen the red and blue channels reversed in video, I've seen 30-second seek times (even seeking backwards), and at times it simply doesn't work at all. The same goes for hulu.com or any online radio web site. Even Facebook could benefit from having a custom application. ...and all of these things would run more efficiently as an application than they do as a web site.

Hell, the new flickr.com is probably the best example. In their desire to have a wall of images in the search results, the javascript spends so much time examining possible arrangements of the images that the computer grinds to a halt. The web site is damn-near unusable, and certainly only "usable" if you're desperate. As far as "I'm bored so I'll look for something interesting on Flickr" goes, it's positively worse than being bored. Granted, they should do the intelligent thing and just go back to the web site they had, but as long as they're insistent on styling their image indexes like that, if they were to do it in a custom application, it could figure out the arrangements it wants in the blink of an eye and so the user experience wouldn't be so miserable.

The craziest thing about it for me is that, given the choice between making a web site and making a proper application, I'd rather make a proper application. Communicating with a server over a TCP connection is a piece of cake, so I don't need a web browser for that, nor do I want to structure everything as an HTTP request anyway. I also don't have to worry about cross-testing in every version of every web browser. Granted, you do then have to cross-test to different operating systems, but at least between Windows and Linux, I've found most of the issues that crop up tend to be data access errors that show up in one version but not the other simply due to data being arranged differently in each executable, and I haven't even seen that since compiling with -fstack-protector-all and writing a wrapper for malloc() in an effort to catch any invalid data access. With web sites I always seem to spend at least 20% of my time trying to make things look at least reasonable in every web browser, and I'm not one of those people who even tries to do fancy shit, I just keep running issues into things like one web browser inserting a blank line somewhere where another doesn't and trying to figure out some way to structure everything so that, if they can't all look the same, then at least none of them end up with ass-ugly formatting.

So I can only guess that the "everything must be a web site" is a user-driven demand.

Part of that might be the Windows convention that no matter how trivial

Re:don't we know it

[Concerned Onlooker]

I was referring to you. Pardon me if I misconstrued your meaning. Since websites/applications ARE software I am not sure what you meant.

Re:don't we know it

[Bite The Pillow]

Instead of overgeneralizing, let's specify the subject. As was said above, "scripting isn't programming". This ignores many of the huge libraries written in scripts, such as ASM.js, which were nowhere near trivial to crap out.

A few lines of scripting isn't programming, but it qualifies as "website development". Also included is a fully separated 3-tier, pre-compiled architecture with persistence and unit tests.

Websites are frequently, way less than distributed applications. Speaking of websites as if they encompass only a part of what's true speaks of the ignorance of your experience. And I would have replied to Dahamma above but you got the mod points.

I don't see any proof of rigor in anything I have seen - I do see PHP and python, C# and jsp - all both with and without any rigor. Being compiled does not imply rigor, and being separated across N tiers does not mean rigor. I'm pretty sure you mis-typed, but the information here being general is, in general, completely without factual basis.

In fact, I would argue that more people are writing websites via programming, where they used to do the same via scripts, and with the exact same regard (or lack of) to rigor.

Re:So who needs native code now?

[Bite The Pillow]

Performance sensitive is not the issue here. The argument against JavaScript has always been no because it's slow. This at least opens the door for options other than Silverlight, ActiveX, Applets, and whatever other binary junk people want to run in my browser.

If you even considered for one minute running number crunching like Seti@home or other distributed computing, or bitcoin mining, or anything else that would tax your cooling and cost you energy, in JavaScript, sign yourself up for the looney bin.

In fact, just preface this to the headline and it really makes a lot of sense: "For all you whiny developers who insist on using proprietary plugins because scripts are SOOO slow - look at these results and ask yourself who needs native code now?"

Several people answered this question as if it were addressed to everything ever in the history of computers. You don't need native code because js is just as fast, so NOTHING you do will ever need native code. Is that how you read it? And you think it is a legitimate question? Won't a JavaScript implementation need native code? A BIOS?

Clearly there is a need - so there must be more to the question, like audience and context.

Re:So who needs native code now?

[non0score]

Exactly, which is why PNaCl is superior at the end of the day. Good luck trying to jam multi-threaded, shared memory programming into JS. The standards committee itself already hate JS (but they maintain it for the "good of the web"). Don't even think about getting the standards committee to even think about a shared memory (webworkers with ArrayObject ownership transfer is as much of a concession as anyone's ever going to get). All JS VMs will have to be written from scratch just to support this programming model.

Re:Numerical Calculations dont use Java

[viperidaenz]

Yes it is, see strictfp
If you don't specify strictfp, the JVM is allowed to use higher precision data types in intermediate calculations, leading to greater precision and better performance at the expense of IEEE conformity.

If you do, you get IEEE 754 compliance.

Re:So who needs native code now?

[viperidaenz]

Asm.js uses ahead-of-time compilation, not just-in-time.

Ya well

[Sycraft-fu]

You have to price out all the details. The question isn't what the server costs to buy. It is what it costs to buy, what support on it costs, both in terms of a warranty and sysadmin time, what physical space costs, or is available, what power and cooling cost, and what kind of reliability you need.

A "cheap" server can end up being not so cheap in many cases. A cheap server is great right up until the point where it fails, and then there is no way to fix it or restore it in a reasonable amount of time.

You can see what it costs for more realistically reliable things by looking at what VMs cost on the open market. For example Pair, who provides top notch reliability and support, wants about $1500/year for a server with 3GB RAM/80GB disk. Linode, which is much lower end particularly with regards to management, but still solid, wants about $500/year for 2GB RAM/96GB disk. These are for virtual servers, not physical systems. That gives you some idea what a server might actually cost in terms of all the things like power, cooling, bandwidth, maintenance, management, hardware refresh, backup, and so on.

That aside, if the program is for a very specific task, ok then development cost can be looked at fairly straight to server cost 1:1, if it is for resale/use elsewhere, then not so much. You can't very well try and foist off the development cost to each customer or argue they should be willing to buy a lot of hardware to support it.

I'm not saying programmers should spend man-years optimizing for every little fractional ounce of improvement (though in some cases it is worth it, read up on some of the stuff Michael Abrash has done) but that optimization does matter.

Re:Ya well

[Bert64]

You can't very well try and foist off the development cost to each customer or argue they should be willing to buy a lot of hardware to support it.

This is exactly what happens, customers of software have gotten used to ever increasing requirements so the only code that ever gets any kind of optimization tends to be code that the developer is planning to use a lot themselves.

Re:Numerical Calculations dont use Java

[ChunderDownunder]

Jane Street runs OCaml! :-)

Re:Multithreading, web workers, and SMP support?

[viperidaenz]

Threading has nothing to do with security.
Running entirely difference processes for each tab is done for stability.

Re:The problem with js

[Lennie]

That is one of the points of asm.js asm.js a bytecode for other languages. You can use any language you want.

Some people even port the runtime from an other scripting language, like Python.

kernel extension

[kernel_user]

What are the chances that this will be integrated in the Linux kernel ? For better performances as a host and as a guest. I can already see large cluster of Linux running in heterogeneous environments.

Re:Cents as an integer

[wonkey_monkey]

Well, let's see, in 2007 there were over 200,000 companies in the U.S. with over $10,000,000 in receipts... (http://www.census.gov/econ/smallbus.html)

Did any of them declare losses of -$2147483648 to the IRS?

Re:Cents as an integer

[sribe]

Did any of them declare losses of -$2147483648 to the IRS?

Ahem, -$21,474,836.48? Yes, certainly. And many more reported total revenue of that or more.

(Yes, you get to round to dollars for the IRS, but no that does not mean your accounting system can ignore cents.)

Re:Great another case of JS being abused.......

[Cyko_01]

If you are writing assembly in javascript you are doing it wrong. A web browser is supposed to display documents, not run desktop applications.

If you are writing desktop applications (ie. a windows PC) for a web browser, then yes, you are doing it wrong. "who needs native code" is certainly over-stating things. HTML + Javascript is appealing when you want to write an application - what smartphones call "apps - that runs on as many platforms - architectures, operating systems, screen sizes - as possible without rewriting all of your code 300 times for each device. If you can write your main code once and have it run on your xbox, playstation, samsung S4, blackberry, iphone, PC, linux, mac, your refrigerator and barbeque then why wouldn't you do that! And with html + javascript there is no installation required - just send a mass email with a shortcut to the webpage for everyone that needs it. It's more like "who needs 300 different versions of the same native code"

If you really need to process dynamic data with that level of control and efficiency with the result put on a dynamic web page, then you need a daemon or some service application doing it, and have JS pull the result. NOT make JS do the entire damn thing.

so you are saying you should spend money beefing up your server so you can present info from the client, to that very same client, after doing some calculations it could have done itself? If the client already has a system capable of doing its share of the work, then why not distribute the load and enable it to do so?!

Re:1.5 times slower

[TangoMargarine]

Used correctly, 250% the original length of time. Next!

Re:don't we know it

[Dahamma]

Well, I guess it may be splitting hairs... but IMO a "website" is not necessarily "software" any more than a house is "wood" or "plumbing". I can have a "website" that is made up entirely of static HTML and images - or as its simplest, just a single image. And no, I don't think HTML qualifies as software, as it really doesn't fit the common definition of "instructions that direct the operation of hardware"; HTML is structured data, not code.

Anyway, my point in replying to the OP is that even the silliest static website (let alone some Javacript-based client) would not work without the dozens of *native* (or Java-based servers, whatever) software components that are required to realize it in your web browser on your screen.

Re:don't we know it

[Dahamma]

It's not Java-based, obviously, but it's origins *were* definitely as a scripting language. It was basically designed to automate the creation of HTML documents/fragments on the client by embedding interpreted code. Now, of course, it does a lot more than would be described strictly as a "scripting language", but colloquially most people now equate dynamic interpreted languages with scripting, anyway...

Re:I hate theories like this.

[dzfoo]

What are you talking about? JavaScript must always necessarily be slower than native code due to its abstracted nature. If it needs an interpreter, or virtual machine, or any other intermediate process between the program code and the CPU, there will be overhead.

Having the CPU execute native code directly will always be faster.

Now, there's an argument to be made that a higher-level, more abstracted language makes people more productive, and by extension, program code more expressive. But this is a different trade-off and objective than building a high-performance application.

            -dZ.

Re:The problem with js

[PCM2]

Is not that it is slow (although it is..) it's that it sucks. It doesn't allow good coding practices, let alone enforce them.

You've been modded flamebait, but there is some truth in what you say. I'd argue, however, that it's not that JavaScript doesn't allow good coding practices -- it does -- but that it does nothing to encourage them, and even discourages them in some cases.

You can write good JavaScript code if you know how and use some discipline. In his book JavaScript: The Good Parts, Douglas Crockford encourages developers to use only a subset of JavaScript's features. The subset he recommends isn't as strict as Asm.js, but he isn't afraid to admit that some features of JavaScript are just poorly designed and shouldn't be there -- so if you want to write good JavaScript code, you should ignore them.

I recommend the book. It's a quick read. It doesn't aim to be a tutorial or a comprehensive bible of correct JavaScript practice. At the very least, though, anybody who works with JavaScript will probably come away from it having seen a new perspective on how the language works and how one should approach it.

Re:So who needs native code now?

[PCM2]

I think ASM.JS is dead out of the water as Google refuses to support it.

No, that's not true. You maybe have things backwards. Mozilla refuses to support NaCl, which is Google's similar-goal-different-approach technology.

Re:I hate theories like this.

[PCM2]

What are you talking about? JavaScript must always necessarily be slower than native code due to its abstracted nature. If it needs an interpreter, or virtual machine, or any other intermediate process between the program code and the CPU, there will be overhead.

This is kind of an old-fashioned argument. Modern VMs are often essentially executing native code by the time the code is actually running. If the bulk of the overhead happens at launch time, or a JIT compiler only has to step in every so often, the level of performance can be such that the difference from "pure" native code is insignificant for most applications. Don't mistake a modern VM for a 1980s style Basic interpreter. The two are very different beasts.