Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Asm.js Gets Faster

timothy posted about 9 months ago | from the getting-better-all-the-time dept.

Firefox 289

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?"

cancel ×

289 comments

Sorry! There are no comments related to the filter you selected.

"So who needs native code now?" (5, Informative)

Anonymous Coward | about 9 months ago | (#45762631)

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?" (2)

gagol (583737) | about 9 months ago | (#45762769)

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?" (1)

gigaherz (2653757) | about 9 months ago | (#45763017)

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?" (2, Informative)

Anonymous Coward | about 9 months ago | (#45763161)

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?" (4, Informative)

dshk (838175) | about 9 months ago | (#45763371)

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?" (3, Funny)

Anonymous Coward | about 9 months ago | (#45762813)

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

Re:"So who needs native code now?" (-1)

Anonymous Coward | about 9 months ago | (#45762905)

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

Re:"So who needs native code now?" (0)

Anonymous Coward | about 9 months ago | (#45762955)

> I'm tired of web designers being colluded with actual programmers, scripting isn't programming.

Of course it is, it's just programming to a different platform. It's programming to target applications instead of CPU architectures.

Re:"So who needs native code now?" (-1)

Anonymous Coward | about 9 months ago | (#45763141)

No it's not, it's web design.

Re:"So who needs native code now?" (0)

Anonymous Coward | about 9 months ago | (#45763191)

Said the person who's obviously never worked on a complex database-driven web application, and thus has no fucking clue what's required...

Re:"So who needs native code now?" (4, Insightful)

MightyMartian (840721) | about 9 months ago | (#45763001)

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?" (5, Insightful)

phantomfive (622387) | about 9 months ago | (#45763027)

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?" (0)

Anubis IV (1279820) | about 9 months ago | (#45763065)

Obligatory xkcd: http://xkcd.com/378/ [xkcd.com]

Re:"So who needs native code now?" (-1, Troll)

fisted (2295862) | about 9 months ago | (#45763431)

Obligatory [blogspot.com] reply [blogspot.co.uk]

don't we know it (-1)

Anonymous Coward | about 9 months ago | (#45763047)

Considering how much software just plain sucks and how many websites just plain work, maybe both groups should switch places.

Re:don't we know it (1)

Dahamma (304068) | about 9 months ago | (#45763079)

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.

So (1)

Anonymous Coward | about 9 months ago | (#45763111)

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 (3, Informative)

Concerned Onlooker (473481) | about 9 months ago | (#45763117)

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.

Well (0)

Anonymous Coward | about 9 months ago | (#45763181)

I've noticed websites have gotten alot more sophisticated, and operating systems (linux included) are still a PITA to maintain. So knock scripters all you want, at least they're getting better at their jobs.

Re:Well (1)

Dahamma (304068) | about 9 months ago | (#45763319)

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

Re:don't we know it (1)

Dahamma (304068) | about 9 months ago | (#45763307)

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

Or anything running in a VM (5, Informative)

Sycraft-fu (314770) | about 9 months ago | (#45763067)

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 (-1)

Anonymous Coward | about 9 months ago | (#45763215)

Buy a faster computer...

Re:Or anything running in a VM (2)

NormalVisual (565491) | about 9 months ago | (#45763269)

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 (2, Informative)

doublebackslash (702979) | about 9 months ago | (#45763707)

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:"So who needs native code now?" (1)

suy (1908306) | about 9 months ago | (#45763189)

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?" (1)

Shinobi (19308) | about 9 months ago | (#45763547)

"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?" (1)

LWATCDR (28044) | about 9 months ago | (#45763435)

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.

The problem with js (0, Flamebait)

Anonymous Coward | about 9 months ago | (#45762645)

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.

Suspect even at -O0 -g (1)

ugen (93902) | about 9 months ago | (#45762653)

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 (2)

gbjbaanb (229885) | about 9 months ago | (#45762781)

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 (2)

K. S. Kyosuke (729550) | about 9 months ago | (#45762823)

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

Re:Suspect even at -O0 -g (0)

Anonymous Coward | about 9 months ago | (#45763239)

All these claims by scripting languages of being 1x or 1.5x slower than C are for very specific benchmarks. In real world applications LuaJIT gets nowhere near the performance of C. I love Lua, I think LuaJIT is the bee's knees, and I write almost as much Lua code as I do C code. But LuaJIT simply can't optimize sprawling code which creates a ton of temporary compound objects all over the places, or which maintains a huge heap.

Plus, LuaJIT only supports a maximum 2GB heap. So frankly it's quite impossible to write a sophisticated, server-side application in LuaJIT without relying on a ton of C code underneath.

The nice thing about Lua (and LuaJIT) is how well it integrates with C. That's the killer feature. It's a beautiful language in its own right, but it also has a beautiful interface to C code, heads-and-shoulders above Perl, Python, and Ruby. That's why Lua folks don't tend to get into pissing matches with C folks ( although there are a few LuaJIT fanboys that stand out in that regard). Lua and C complement each other.

Re:Suspect even at -O0 -g (0)

K. S. Kyosuke (729550) | about 9 months ago | (#45763315)

All these claims by scripting languages of being 1x or 1.5x slower than C are for very specific benchmarks. In real world applications LuaJIT gets nowhere near the performance of C.

If it's slow for you, send Mike Pall a bug report. I'd say that all claims for speed are for specific benchmarks - how would you measure performance with abstract benchmarks? But even if LuaJIT loses on some issues, it has (besides the pretty awesome and much direct C data access performance) one crucial feature that C doesn't: you can use generative solutions to increase performance where C won't allow you to do it - that is, take the larger task at hand (at runtime), generate a piece of code, and run it. 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 (C would force you to do either lot of memory moves or a lot of calls, both of which can get removed with code transformations - with the memory barrier continuously rising, C's speed won't save you here).

Re:Suspect even at -O0 -g (0)

Anonymous Coward | about 9 months ago | (#45763429)

I'll also add webapp firewall's actual rules engine [cloudflare.com] - needs quite a bit of performance and profits quite a bit from dynamic compilation.

Cloudflare likes them their Lua, what with their LuaJIT's sponsorship and, IIRC, Nginx's Lua module author's now working for them.

Re:Suspect even at -O0 -g (0)

loufoque (1400831) | about 9 months ago | (#45762871)

It is a lie, or maybe they don't know what "at worst" means.
It's easy to come up with a C snippet that is 2 times faster with one compiler than another compiler. Likewise it should be trivial to come up with a snippet that is 2 times faster with a C compiler than with asm.js.

Re:Suspect even at -O0 -g (0)

Anonymous Coward | about 9 months ago | (#45762901)

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

I suspect that's the case.
After all, they did go on to claim that "JavaScript always uses float64 and this provides maximum precision,". No, it does not. Floating point is, by definition, not precise- if you want maximum precision you wouldn't use floating point to start with.

Re:Suspect even at -O0 -g (1)

sribe (304414) | about 9 months ago | (#45763039)

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 (2, Informative)

Anonymous Coward | about 9 months ago | (#45763095)

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 (1)

Anonymous Coward | about 9 months ago | (#45763453)

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.

So who needs native code now? (0)

Anonymous Coward | about 9 months ago | (#45762659)

The person writing the javascript engine.

Re:So who needs native code now? (2, Funny)

Anonymous Coward | about 9 months ago | (#45762851)

The person writing the javascript engine.

Unless it's implemented in asm.js

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

Re:So who needs native code now? (1)

StripedCow (776465) | about 9 months ago | (#45763005)

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:So who needs native code now? (0)

Anonymous Coward | about 9 months ago | (#45763045)

pnacl gives you threads:

http://gonativeclient.appspot.com/demo/earth

Update the ecma standard (1)

modmans2ndcoming (929661) | about 9 months ago | (#45762675)

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 (2)

sribe (304414) | about 9 months ago | (#45762775)

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 (1)

VortexCortex (1117377) | about 9 months ago | (#45763153)

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.

Numerical Calculations dont use Java (-1)

Anonymous Coward | about 9 months ago | (#45762683)

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.

Re: Numerical Calculations dont use Java (0)

Anonymous Coward | about 9 months ago | (#45762783)

You laugh, but I have at times been in fear that my boss was going to ask us to do our (monetary) transaction processing system in node.js

I thought silently, the day that happens is the day I resign. Some people just cannot be told.

Cents as an integer (0)

tepples (727027) | about 9 months ago | (#45762833)

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?

Re: Cents as an integer (1)

clickclickdrone (964164) | about 9 months ago | (#45762949)

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 (0)

Anonymous Coward | about 9 months ago | (#45762983)

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?

"Down to the cent" means the result is accurate to two decimal places, which requires that your calculations be accurate to at least 3 decimal places.
There are many situations in finance and banking where 5 decimal places of precision are required, and even some cases where it's required to be as high as 9 decimals.

Re: Cents as an integer (1)

clickclickdrone (964164) | about 9 months ago | (#45763009)

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

Re:Cents as an integer (1)

sribe (304414) | about 9 months ago | (#45762989)

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 (1)

Anonymous Coward | about 9 months ago | (#45762811)

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

Re:Numerical Calculations dont use Java (0)

Anonymous Coward | about 9 months ago | (#45762839)

Java != JavaScript

Re:Numerical Calculations dont use Java (1)

Billly Gates (198444) | about 9 months ago | (#45762919)

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.

Re:Numerical Calculations dont use Java (2)

_merlin (160982) | about 9 months ago | (#45762993)

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:Numerical Calculations dont use Java (1)

roman_mir (125474) | about 9 months ago | (#45762985)

One of these days I will be next to somebody who will not be an AC and who will confuse Javascript with Java and that person will be very sure of himself that what comes out of his mouth makes any kind of sense. It will be a fine day to murder that person right on the spot. I will truly and thoroughly enjoy it.

who needs native code (1)

Anonymous Coward | about 9 months ago | (#45762689)

So who needs native code now?

For a start, anyone implementing a JavaScript engine.

Back in the day (1)

Anonymous Coward | about 9 months ago | (#45762737)

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 [amazon.com] 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 (1)

gbjbaanb (229885) | about 9 months ago | (#45762831)

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 :-)

Javascript as a Virtual Machine Representation (5, Interesting)

ndykman (659315) | about 9 months ago | (#45762745)

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 (1)

Anonymous Coward | about 9 months ago | (#45762921)

Here is the state of web apps. [xkcd.com]

Re:Javascript as a Virtual Machine Representation (0)

Anonymous Coward | about 9 months ago | (#45762957)

I don't think you understand what asm.js is. It's an attempt to do the static analysis during a compile-to-javascript phase, and generate code such that the runtime KNOWS it can skip type checks, garbage collection, and other slowness.

What asm.js is therefore doing is approaching the problem from the perspective of starting from a Javascript runtime, and stripping out the bits that make it slow when running native code. It will probably never be "as fast", but it comes with the benefits of being cross-platform and having access to the browser's libraries.

In short, there's really no point in thinking asm.js is javascript beyond it using a subset of javascript syntax as it's "bytecode". That makes it inherently less efficient, but it's just a start. There's no reason they can't create a more efficient format as they progress the spec.

In the end, this is the opposite approach to solving the problem as NaCl, but it's showing exactly the same promise, and is easier for existing JS engines to morph to support it.

Re:Javascript as a Virtual Machine Representation (1)

Daniel Hoffmann (2902427) | about 9 months ago | (#45763645)

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.

So who needs native code now? (3, Interesting)

sribe (304414) | about 9 months ago | (#45762747)

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

Re:So who needs native code now? (2)

Billly Gates (198444) | about 9 months ago | (#45762891)

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.

Re:So who needs native code now? (2)

gbjbaanb (229885) | about 9 months ago | (#45763037)

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.

Re:So who needs native code now? (0)

Anonymous Coward | about 9 months ago | (#45763519)

asm.js has nothing to do with Java, it does not use a Java VM, and Chrome technically supports it right now (as does every other Javascript runtime, as it is just Javascript).

From the webpage: "an extraordinarily optimizable, low-level subset of JavaScript".

Please read this: http://asmjs.org/faq.html

Re:So who needs native code now? (1)

fermion (181285) | about 9 months ago | (#45763587)

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.

1.5 times slower (0)

Anonymous Coward | about 9 months ago | (#45762751)

What is 3/2 times slower mean? Actually 1/2 times slower, so 2 times slower? Or that if it was 1.5 times faster it would be the other thing, so it must be 2/3 as fast? But then 1 times faster would be the same, so maybe it must be 2.5 times, or 4/5 as fast? NERD RAGE

Fail (1)

IamTheRealMike (537420) | about 9 months ago | (#45762771)

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!

Portability and partitioning (1)

tepples (727027) | about 9 months ago | (#45762889)

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.

Sugar predication to assert at compile time (1)

Baldrson (78598) | about 9 months ago | (#45762791)

Since asm.js isn't sugared predication [slashdot.org] , 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 (3, Interesting)

K. S. Kyosuke (729550) | about 9 months ago | (#45762805)

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?)

Size of floats in cache (1)

tepples (727027) | about 9 months ago | (#45762895)

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

Re:Size of floats in cache (1)

K. S. Kyosuke (729550) | about 9 months ago | (#45762953)

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.

Re:64-bit computation vs. 64-bit storage (1)

UnknownSoldier (67820) | about 9 months ago | (#45762941)

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 (1)

K. S. Kyosuke (729550) | about 9 months ago | (#45763123)

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 (1)

gbjbaanb (229885) | about 9 months ago | (#45762965)

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 (4, Informative)

Pinhedd (1661735) | about 9 months ago | (#45763419)

Take a look at the image at the following link

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

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.

Multithreading, web workers, and SMP support? (0)

Billly Gates (198444) | about 9 months ago | (#45762853)

Firefox is falling quite behind even if it does support ASM.JS. After FF 3.6 and 4.0 I switched browsers. Firefox has improved recently with ram usage and bugs and is usable after version 13.

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. Shit on a 6 core cpu I had for 3 years now I should not have +30 tabs using one damn cpu?!

Until Firefox helps spread this out and support modern standards and increase security by threading I do not care about ASM.js as I wont use a browser that supports it.

Electrolysis (1)

tepples (727027) | about 9 months ago | (#45762927)

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

Re:Multithreading, web workers, and SMP support? (1)

sribe (304414) | about 9 months ago | (#45763029)

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:Multithreading, web workers, and SMP support? (0)

Anonymous Coward | about 9 months ago | (#45763615)

Based on your language, it doesn't matter if Firefox ever catches up. There will always be some pet feature they don't support for you to quibble about. Why should anyone care what you have to say in that light?

whiney bitches take note (1)

Tumbleweed (3706) | about 9 months ago | (#45762903)

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?

www.denetimliserbestlik.net (0)

Anonymous Coward | about 9 months ago | (#45762915)

denetimliserbestlik.net

Re:www.denetimliserbestlik.net (0)

Anonymous Coward | about 9 months ago | (#45762979)

denetimliserbestlik.net

I should not have visited that site. Now I'm scarred for life.

Re:www.denetimliserbestlik.net (0)

Anonymous Coward | about 9 months ago | (#45762997)

What has been seen, cannot be unseen.

Not really true (2)

SoftwareArtist (1472499) | about 9 months ago | (#45763097)

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.

Standardize Javascript bytecode already (1)

kervin (64171) | about 9 months ago | (#45763151)

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 (0)

Anonymous Coward | about 9 months ago | (#45763203)

Because compiling it to bytecode would make it obvious that it's just like the Java hype of the early 00s, and then it wouldn't be kewl anymore.

Re:Standardize Javascript bytecode already (0)

Anonymous Coward | about 9 months ago | (#45763355)

Because this way it will run on any relatively modern browser. There's nothing stopping asm.js from switching to a non-plaintext binary format (or even making that optional) other than browser engines not supporting it yet. It will also be tougher to tell browser makers to support a certain set of bytecodes until it's known what's feasible and required. If it wasn't such a pain, then NaCl would have been adopted years ago.

Maximum precision? (4, Informative)

raddan (519638) | about 9 months ago | (#45763197)

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 [ibm.com] .

Mining (0)

Anonymous Coward | about 9 months ago | (#45763387)

Excellent! Can mine litecoins already :-)

How about making the Canvas tag not suck (1)

Dwedit (232252) | about 9 months ago | (#45763393)

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.

"So who needs native code now?" (1)

Cammi (1956130) | about 9 months ago | (#45763539)

Anti-Criminals ... aka real programmers.

64 Bit Integers (0)

Anonymous Coward | about 9 months ago | (#45763593)

float64 is not good for human programmers. You can't store even 64 bit integers in native javascript. You don't have to be a scientific programmer to need Int64. There are tons of applications where 64bit integers are used and javascript can't handle it. For example in .net DateTime ticks are a 64 bit integer type, try taking the current time in .net ticks and using it in javascript. Not wanting to know the variable type is crazy, strongly typed code is always more manageable and less prone to mistakes.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>