4 ms·

> languages and environments that run around an order of magnitude faster than Javascript (on Javascript's best day) I'd love to see the programming language

> languages and environments that run around an order of magnitude faster than Javascript (on Javascript's best day) I'd love to see the programming language that's an order faster than Google V8. See http://benchmarksgame.alioth.debian.org/u32/javascript.php http://benchmarksgame.alioth.debian.org/u32/javascript.php and play with it a little bit ;-)

jerf 13y ago
Javascript's speed can be overstated, especially on benchmarks, where everything can be just so, and maximize the amount of time you spend in the C portion of the runtime. In practice, you do not get a "mere" 3x performance loss in Javascript code, especially for things like what supercomputers do. At least, I haven't seen anyone seriously report that result for anything like real code. asm.js may overcome that to some extent, but as I mentioned elsewhere, the real problem is bandwidth. Frankly you could run things effectively instantaneously on the client side, and still end up with wildly worse performance on this sort of cluster than a real supercomputer.
- wilkinson 13y ago
  Google V8's regular expressions can outrun C for real bioinformatics workflows, and it's actually not even close. I routinely write JS that outruns C and C++, and you haven't seen it in reports because my papers haven't been accepted yet. I doubt that I'm the only person capable of writing "amazing" code. Do you write JS? As for bandwidth, there is no reason to believe that bandwidth is an issue for all parallel architectures. Stream processing works very well under the given constraints, for example.
  - jerf 13y ago
    "Do you write JS?" Yes, along with a ton of other languages. It is well known that if you use a slow language to set up problems for code written in fast implementations, the result can still be quite fast, but it's the fast bit, not the slow bit that's responsible. See also NumPy. It's not Javascript being fast, it's the regex engine. If what you're doing is regexes, it's almost certainly more efficient to just do the regexes than to try to ship the relevant strings down over commodity internet connections... which is, indeed, exactly why you don't take this approach in your code.

jerf 13y ago

Javascript's speed can be overstated, especially on benchmarks, where everything can be just so, and maximize the amount of time you spend in the C portion of the runtime. In practice, you do not get a "mere" 3x performance loss in Javascript code, especially for things like what supercomputers do. At least, I haven't seen anyone seriously report that result for anything like real code. asm.js may overcome that to some extent, but as I mentioned elsewhere, the real problem is bandwidth. Frankly you could run things effectively instantaneously on the client side, and still end up with wildly worse performance on this sort of cluster than a real supercomputer.

wilkinson 13y ago
Google V8's regular expressions can outrun C for real bioinformatics workflows, and it's actually not even close. I routinely write JS that outruns C and C++, and you haven't seen it in reports because my papers haven't been accepted yet. I doubt that I'm the only person capable of writing "amazing" code. Do you write JS? As for bandwidth, there is no reason to believe that bandwidth is an issue for all parallel architectures. Stream processing works very well under the given constraints, for example.
- jerf 13y ago
  "Do you write JS?" Yes, along with a ton of other languages. It is well known that if you use a slow language to set up problems for code written in fast implementations, the result can still be quite fast, but it's the fast bit, not the slow bit that's responsible. See also NumPy. It's not Javascript being fast, it's the regex engine. If what you're doing is regexes, it's almost certainly more efficient to just do the regexes than to try to ship the relevant strings down over commodity internet connections... which is, indeed, exactly why you don't take this approach in your code.