6 ms·

BTW, C/C++ code that is compared has multithreading and SIMD capability disabled. In the third page they benchmark asm.js and native with multithreading and SSE

• azakai 13y ago
  Of course single-threaded code will lose to SIMD or threaded code. That's not saying anything surprising. The important thing is to realize that until just recently - a few months or so - people did not believe that SINGLE-threaded JS code on the web could be close to native speed. The Ars article here even has "surprise" in the title when it concludes that in fact that is possible :) So that is a crucial milestone. Is the job done? No, as you say, SIMD and threads are important. But we had to first get single-threaded performance to the right area. Next, browser vendors need to work together to standardize stuff that will allow SIMD and more threading. This is definitely possible if everyone is interested in making the web faster, which I certainly believe is the case.
  • npalli 13y ago
    Ok thanks. I guess I'm confused about the gains with asm.js. Looks like it is in the same ballpark performance wise as regular JS (and slower in some cases). So, why would anyone write in a crippled C-like subset of javascript and get normal javascript like performance. In the future if threading and SIMD is standardized, won't regular JS gain performance as well?
    • azakai 13y ago
      No, look again at the numbers - asm.js gets much closer to native speed than normal JS, in many cases, especially large apps. In addition to the numbers in the article, you can see for example, http://kripken.github.io/mloc_emscripten_talk/#/28 http://kripken.github.io/mloc_emscripten_talk/#/28 asm.js code makes it easier to get within reach of native performance.
    • bad_user 13y ago
      > why would anyone write in a crippled C-like subset of javascript Because asm.js is not meant for people, but for compilers. For example the Unreal Engine has been recently compiled from C/C++ to asm.js and is running in the browser: http://www.unrealengine.com/html5/ http://www.unrealengine.com/html5/
      • camus 13y ago
        ... best viewed in ... netscape ?
        • cristiantincu 13y ago
          “Best viewed in Netscape” still wins over “Download for Windows (x86)”.
    • riffraff 13y ago
      you are not expected to write asm.js, it's to be considered a compiler target (for e.g. emscripten etc)
  • anon1385 13y ago
    >The important thing is to realize that until just recently - a few months or so - people did not believe that SINGLE-threaded JS code on the web could be close to native speed. Single threaded Javascript was already 'fast enough' for the CRUD interfaces that makes up most web apps. Web apps are horrible to use because the network is unreliable for many people, latency is terrible for just about everybody, browsers provide a very poor and limited set of APIs for many of the tasks people actually want to do (interacting with hardware, file systems, audio, inter-app interoperability etc) and apps are forced to run inside a sandbox that can't be escaped. Cloud services nearly always mean that users lose control of their data. Web apps are rarely open source (and if they are you still can't change the version of the app that you actually use because it runs on a server you don't control). A faster Facebook with 3D effects is still a terrible platform. Homer Simpson: Kids: there's three ways to do things; the right way, the wrong way and the Max Power way! Bart: Isn't that the wrong way? Homer Simpson: Yeah, but faster! I think a lot of this obsession over Javascript speed is a distraction (support for more languages is nice for developers of course). Making slightly faster VMs is just an engineering problem: throw more resources at it and things will improve. The hard problems are political and also related to the basic network infrastructure (constrained by the laws of physics). Trying to recreate the entire operating system inside the browser, for all possible uses (even performance sensitive things), is a huge overreach when we don't seem to have a clue how to make the basic web app experience good. Why is it hard? Because the founding idea of a single sandboxed standard for all platforms is unworkable in the real world. Not only does it mean all developers surrendering complete control to the people defining the standard (who also happen to be big players in many other related markets), it relies on the big players actually agreeing, which is often not in their interest. If the world had moved to Gopher based OSs in the early 90s the web as we know it would not have come into existence. What future possible technologies are we destroying by locking ourselves into the web sandbox?
    • hughw 13y ago
      Your premise is demonstrably wrong > Why is it hard? Because the founding idea of a single sandboxed standard for all platforms is unworkable in the real world. Not only does it mean all developers surrendering complete control to the people defining the standard (who also happen to be big players in many other related markets), it relies on the big players actually agreeing, which is often not in their interest. The innovation in browsers and webapps is coming from the vendors each acting individually, and puling standards bodies along with them. If you as a developer, are waiting around for them all to agree on any technology, before leveraging it, then you are just paralyzed. Develop against WebGL and asm.js now to get early mover advantages. If you wait for universal uptake, you'll never get anything done.
• crabasa 13y ago
  Is it fair to describe JS as single-threaded when all modern browsers support web workers? Related: Why does it seem like web workers don't exist? I can hardly think of any popular libraries or web apps that make use of them, despite the seemingly obvious utility.
  • tachyonbeam 13y ago
    Web workers are more like multiple processes than multiple threads, but yes, there are ways to use more than one CPU core in JS too.
  • danmaz74 13y ago
    Our hashtagify.me uses them :)
  • kybernetikos 13y ago
    After getting very excited and doing a bunch of work, we did a lot of performance tests and discovered that for our use case all they did was increase processor load for the same work - the penalty associated with serialising and deserialising things to go across postMessage was greater than the work we were getting done on the other thread. Of course this was in the early days, and it'd be good to retest it to see if it's better now. I think that there are a lot of interesting use cases for WebWorkers, but you also have to be aware that for some things they will actually slow down your application.
    • Yoric 13y ago
      Working on it :)
    • i_s 13y ago
      It is still not good. I've started working on an asteroids game [0], and I tried moving my physics calculations to a background thread, but it ended up being slower. 0 http://www.isaksky.com/asteroids/ http://www.isaksky.com/asteroids/
  • Yoric 13y ago
    Let me detail tachyonbeam's answer. All modern web browsers (I'll try not to troll about IE) support web workers. However, the semantics of web workers is message-passing (by copy, most of the time), which is the semantics generally associated to multi-process rather than multi-threading. Most developers using threads expect some kind of memory sharing, which is impossible with web workers at the moment. Shared workers (not implemented in any browser atm, I believe) will take care of some usage scenarios. Other alternatives are being explored (e.g. [Parallel JS](http://smallcultfollowing.com/babysteps/blog/2012/01/09/parallel-javascript/) http://smallcultfollowing.com/babysteps/blog/2012/01/09/para...). However, for the time being, don't expect any support from JS to do shared memory concurrency. Note: I'm a Firefox dev.
• sillysaurus 13y ago
  anyone writing performance sensitive apps will use multithreading That assumes the performance sensitive app is amenable to multithreading. Many aren't.
  • vilya 13y ago
    Your comment has made me curious. I tried to think of some examples of performance sensitive apps that aren't amenable to multi-threading and I couldn't, but it seems like they could offer interesting areas for R&D. Can you share some examples?
    • Yoric 13y ago
      Consider a single tab of a web browser, for instance. By specification, much of the code must run in the same thread. Keeping the semantics while getting code out of the thread is extremely difficult, often impossible. I should know, that's my dayjob :)
      • vilya 13y ago
        So the reason you can't make it faster than JavaScript by multi-threading it is... because of JavaScript? :-) I had a look at your profile and it looks like you're doing some very valuable work. I was rather hoping for some examples which didn't involve JavaScript, though.
        • saucetenuto 13y ago
          It used to be that almost all PC games were single threaded. Many still are: Civilization 4, Dwarf Fortress, and Morrowind, for example.
    • fulafel 13y ago
      Many things are hard to parallelize using current technology, and there indeed has been lots of research done on it. History goes back to the supercomputer era (Cray, Connection Machine, Transputer etc.) The term of art is "inherently sequential" problems (vs "embarrassingly parallel"). In addition, the programming effort gets untenable quickly due to Amdahl's law when the amount of parallelism increases. Eg. if you have 100 cores, even if only 1% of work in your program is sequential, your performance goes down the drain. Currently we're in the comfy phase of the curve with few cores... We've been making good progress with parallel-minded reimaginings of programming languages and computer architectures on one front: GPUs. On the CPU we are saddled with the inertia and backwards compatibiltiy lock-in of tools and culture (witness lasting use of C++ as a tool to write parallel software)
• haberman 13y ago
  > multithreading and SIMD capability disabled [EDIT: it looks like I may have misinterpreted the article; see replies] To clarify, I believe they ran the benchmarks with SSE disabled. SSE is more than just SIMD; these days SSE is used for most (all?) floating-point calculations, even non-SIMD. If you disable SSE, you force floating-point ops to use the old x87 FPU, which has been discouraged by the CPU manufacturers for over 10 years. In other words, disabling SSE is significantly crippling all floating-point performance. http://www.realworldtech.com/physx87/4/ http://www.realworldtech.com/physx87/4/ http://stackoverflow.com/questions/3206101/extended-80-bit-double-floating-point-in-x87-not-sse2-we-dont-miss-it http://stackoverflow.com/questions/3206101/extended-80-bit-d... (nothing against asm.js, which I think is very cool)
  • azakai 13y ago
    Why would you assume they disabled SSE? Compilers generate SSE by default when optimizing, I would be very surprised if Peter Bright disabled it. And not only do normal C/C++ compilers generate SSE, but JS engines generate SSE as well. So SSE was being used on both sides of the comparisons here, I am pretty sure. What was disabled was C/C++ code that explicitly used SIMD intrinsics or explicitly used SSE function calls in C/C++.
    • haberman 13y ago
      I must have misinterpreted this remark: > In general, I took the highest-ranked pure C++ routines for each test. Versions that used, for example, SSE functions were excluded, as were those with explicit multithreading. For "functions" I interpreted "functionality," but I think now it must mean SSE intrinsics? Sorry for the confusion.
      • DrPizza 13y ago
        Yes, sorry, I meant SSE intrinsics. As I think I note later in the article, the compiler I used emitted scalar SSE2 for floating point.
      • Gravityloss 13y ago
• VoxPelli 13y ago
  There is work going on in enabling Javascript to get better at doing things in parallel - both on CPU and GPU. Eg. check out the ParallelArray() from the River Trail project by Intel: http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism http://wiki.ecmascript.org/doku.php?id=strawman:data_paralle... & http://en.m.wikipedia.org/wiki/River_Trail_(JavaScript_engine) http://en.m.wikipedia.org/wiki/River_Trail_(JavaScript_engin... At least Firefox has an initial implementation: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/ParallelArray https://developer.mozilla.org/en-US/docs/JavaScript/Referenc... The benefit if asm.js being based on ordinary javascript is that they can use these improvements to javascript itself right away more or less.
• Spearchucker 13y ago
  It's good progress all the same, but doesn't do much for the end user that still relies on an often shitty Internet connection.
• fulafel 13y ago
  > anyone writing performance sensitive apps will use MT right? No, multithreading not that simple - usually it's the last trick you should try to pull and even then only if the stars align just right. You need to have expert programmers on hand (of the rare breed who can pull this off), the good luck to succeed and the time budget to spend on the big code reachitecting and experimentation. If you're running on something else than modern consoles, you don't know how many cores your users will have, the average might be 2 so your average returns on the effort will suck (vs spending equivalent effort elsewhere). Witness modern Web browsers, for example, where Google, Mozilla, Apple and Microsoft employ some of the best C++ programmers in the world, routinely of pulling off heroic feats, and they haven't seen it worth the effort yet despite Core 2 and Athlon X2 hitting mainstream desktop at about 2005-2006, 8 years ago.
  • nnnnnnnninnnnnn 13y ago
    You're making writing multi-threaded code sound like a herculean task. Sure, doing MT with mutexes is a pain, but programming with actors (message passing) is simpler. You can easily scale this for variable number of cores.
  • w0utert 13y ago
    I think you are overstating the problems writing multithreaded code a little here. Yes, it's a lot harder than single-threaded code, yes you need to know what you are doing, yes you need to carefully design your code to enable efficient and safe multithreading, and no you don't get speed for free. All true, but you are making it sound as if writing multithreaded code is rocket science, some kind of mad skill only the top 0.5% programmers can handle. It's not that bad you know... If you're a half-way decent programmer and don't litter your single-threaded code with globals, shared memory and functions with side-effects, like you shouldn't anyway, parallelizing it after the fact to at least is usually pretty straightforward even. Maybe not optimal, but safe, and faster than single-core on multi-core hardware.
    • fulafel 13y ago
      Sure, you can write the code if you're a half-way decent programmer. But getting it to work correctly and bug free in presence of nondeterministic behaviour and races is in the domain of the very small minority, when you're talking about large code bases. I'm betting the minority is less than 0.5%. Half way decent C++ programmers aren't many % of programmers, and people who can make a reliably working parallelized do-over for a nontrivial code base are maybe 1% of that. I'll say 0.05% max.
• Marat_Dukhan 13y ago
  It really should be a 100x slowdown! Their "optimized" Linpack numbers (41 GFLOPs) are too low for this system. The CPU they use can deliver 108 GFLOPs at base frequency and 120 GFLOPs at max turbo frequency, and good LU implementations (e.g. MKL) can achieve >90% of these peak numbers.