5 ms·

While this is great news for Python, there are quite a few dynamic languages now beyond LuaJIT showing that it's possible to get stellar perf - JavaScript, Rack

While this is great news for Python, there are quite a few dynamic languages now beyond LuaJIT showing that it's possible to get stellar perf - JavaScript, Racket, Clojure.

dman 16y ago
Done leave common lisp out - sbcl is no slouch and hasnt been for quite some time.
- swannodette 16y ago
  Totally forgot, Common Lisp's performance w/o sacrificing dynamism is what got me excited about Lisp in the first place.
  - kragen 16y ago
    My very limited experience with SBCL has been that, although you can get performance that's considerably better than CPython, you don't get close to C performance without sacrificing dynamism and safety.
kragen 16y ago
Last I heard, no JS engine was close to LuaJIT's performance; they were all worse by a factor of five or so. Clojure being in the LuaJIT ballpark would surprise me (do you have benchmarks?) but Racket wouldn't. (But I wouldn't call Scheme a dynamic language!)
- euccastro 16y ago
  > But I wouldn't call Scheme a dynamic language! Care to elaborate?
  - kragen 16y ago
    Scheme operations are mostly early-bound, even more so than Common Lisp; you standardly use vector-ref or string-ref, for example, instead of nth. (There are Schemes where this is not true, such as RScheme, but Racket is not among them.) Vectors aren't resizable; for that kind of thing, you must use lists. You can't attach arbitrary properties to some arbitrary object, the way you can in JS or Ruby. You can't introduce new variable bindings in the middle of a block. (What you do instead is make a new nested block.) Finite maps (assoc, make-hash-table) are second-class citizens. Standard Scheme is nonreflective; you're supposed to do your metaprogramming with macros, not reflection and interposition. (I don't know how much reflection Racket supports, but I'd guess almost none.) The object-literal syntax is quasiquote, which is clumsy. It does have dynamic typing, but that's not what it means to be a "dynamic language". Dynamic languages are late-bound; everything is up for grabs at runtime. In standard Scheme, this is true in the fairly useless sense that everything depends on the bindings in the global namespace, so you could in theory (set! car somethingweird), but this is very rarely practical; it almost serves only to make optimizing Scheme compilers difficult to write. Aside from that, the language leans much further toward early binding, doing things at compile-time, and using efficient data structures at the cost of flexibility.
    - euccastro 16y ago
      I don't think the meaning you give to "dynamic" here has much bearing on the difficulty of just-in-time compilation, except for reflection. In Scheme you can define and create new functions and macros at runtime. There is not much else that is dynamic about the Scheme standard[1] because... there's not much else to the Scheme standard. As for reflection, I see that mainly as a tools/debugging aid, and therefore very implementation-specific stuff. "Dynamic" languages have reflection in their definition because they are mostly defined by implementation. That said, the Scheme standard doesn't preclude reflectivity at all, nor seems particularly compile-oriented to me. Nowhere it is assumed that implementations be compilers at all. I think most of the things you find missing there were not left out for efficiency, but because it was rightly considered that they don't belong in the language spec at all. [1] By the "Scheme standard" I mean R5RS.
      - 16y ago
- justincormack 16y ago
  Indeed. The LuaJIT interpreter with JIT disabled is a similar speed to V8 in most benchmarks.
- swannodette 16y ago
  http://shootout.alioth.debian.org/u64/which-language-is-best.php?gpp=on&java=on&sbcl=on&ghc=on&csharp=on&clojure=on&racket=on&v8=on&hipe=on&lua=on&python3=on&vw=on&yarv=on&xfullcpu=1&xmem=0&xloc=0&nbody=1&fannkuchredux=1&meteor=0&fasta=1&spectralnorm=1&revcomp=1&mandelbrot=1&knucleotide=1&regexdna=1&pidigits=1&chameneosredux=0&threadring=0&binarytrees=1&calc=chart http://shootout.alioth.debian.org/u64/which-language-is-best... Clojure 1.2.0 is already faster than Racket. Version 1.3.0 will probably bring it close to Go territory on those benchmarks. For my own work I've found that getting Clojure in the Java ballpark is certainly possible.
  - kragen 16y ago
    You're right; it looks like Racket is not in the C/LuaJIT ballpark, either. It's too bad the LuaJIT results are no longer on the web site.
    - swannodette 16y ago
      Last Alioth results I saw LuaJIT was slower than Java, and certainly not in the C ballpark at all.
      - kragen 16y ago
        http://lua-users.org/lists/lua-l/2009-10/msg01098.html http://lua-users.org/lists/lua-l/2009-10/msg01098.html shows LuaJIT beating GCC 4.3.2 on some parts of SciMark, and no more than 3× worse on any part. I'm importing the shootout CVS repository into Git, so hopefully we can make some more definitive comparisons soon.
        swannodette 16y ago
        Those overall results show that LuaJIT doesn't really compete much the JVM running under server mode.
        kragen 16y ago

While this is great news for Python, there are quite a few dynamic languages now beyond LuaJIT showing that it's possible to get stellar perf - JavaScript, Racket, Clojure.

dman 16y ago

Done leave common lisp out - sbcl is no slouch and hasnt been for quite some time.

swannodette 16y ago
Totally forgot, Common Lisp's performance w/o sacrificing dynamism is what got me excited about Lisp in the first place.
- kragen 16y ago
  My very limited experience with SBCL has been that, although you can get performance that's considerably better than CPython, you don't get close to C performance without sacrificing dynamism and safety.

kragen 16y ago

Last I heard, no JS engine was close to LuaJIT's performance; they were all worse by a factor of five or so. Clojure being in the LuaJIT ballpark would surprise me (do you have benchmarks?) but Racket wouldn't. (But I wouldn't call Scheme a dynamic language!)

euccastro 16y ago
> But I wouldn't call Scheme a dynamic language! Care to elaborate?
- kragen 16y ago
  Scheme operations are mostly early-bound, even more so than Common Lisp; you standardly use vector-ref or string-ref, for example, instead of nth. (There are Schemes where this is not true, such as RScheme, but Racket is not among them.) Vectors aren't resizable; for that kind of thing, you must use lists. You can't attach arbitrary properties to some arbitrary object, the way you can in JS or Ruby. You can't introduce new variable bindings in the middle of a block. (What you do instead is make a new nested block.) Finite maps (assoc, make-hash-table) are second-class citizens. Standard Scheme is nonreflective; you're supposed to do your metaprogramming with macros, not reflection and interposition. (I don't know how much reflection Racket supports, but I'd guess almost none.) The object-literal syntax is quasiquote, which is clumsy. It does have dynamic typing, but that's not what it means to be a "dynamic language". Dynamic languages are late-bound; everything is up for grabs at runtime. In standard Scheme, this is true in the fairly useless sense that everything depends on the bindings in the global namespace, so you could in theory (set! car somethingweird), but this is very rarely practical; it almost serves only to make optimizing Scheme compilers difficult to write. Aside from that, the language leans much further toward early binding, doing things at compile-time, and using efficient data structures at the cost of flexibility.
  - euccastro 16y ago
    I don't think the meaning you give to "dynamic" here has much bearing on the difficulty of just-in-time compilation, except for reflection. In Scheme you can define and create new functions and macros at runtime. There is not much else that is dynamic about the Scheme standard[1] because... there's not much else to the Scheme standard. As for reflection, I see that mainly as a tools/debugging aid, and therefore very implementation-specific stuff. "Dynamic" languages have reflection in their definition because they are mostly defined by implementation. That said, the Scheme standard doesn't preclude reflectivity at all, nor seems particularly compile-oriented to me. Nowhere it is assumed that implementations be compilers at all. I think most of the things you find missing there were not left out for efficiency, but because it was rightly considered that they don't belong in the language spec at all. [1] By the "Scheme standard" I mean R5RS.
    - 16y ago
justincormack 16y ago
Indeed. The LuaJIT interpreter with JIT disabled is a similar speed to V8 in most benchmarks.
swannodette 16y ago
http://shootout.alioth.debian.org/u64/which-language-is-best.php?gpp=on&java=on&sbcl=on&ghc=on&csharp=on&clojure=on&racket=on&v8=on&hipe=on&lua=on&python3=on&vw=on&yarv=on&xfullcpu=1&xmem=0&xloc=0&nbody=1&fannkuchredux=1&meteor=0&fasta=1&spectralnorm=1&revcomp=1&mandelbrot=1&knucleotide=1&regexdna=1&pidigits=1&chameneosredux=0&threadring=0&binarytrees=1&calc=chart http://shootout.alioth.debian.org/u64/which-language-is-best... Clojure 1.2.0 is already faster than Racket. Version 1.3.0 will probably bring it close to Go territory on those benchmarks. For my own work I've found that getting Clojure in the Java ballpark is certainly possible.
- kragen 16y ago
  You're right; it looks like Racket is not in the C/LuaJIT ballpark, either. It's too bad the LuaJIT results are no longer on the web site.
  - swannodette 16y ago
    Last Alioth results I saw LuaJIT was slower than Java, and certainly not in the C ballpark at all.
    - kragen 16y ago
      http://lua-users.org/lists/lua-l/2009-10/msg01098.html http://lua-users.org/lists/lua-l/2009-10/msg01098.html shows LuaJIT beating GCC 4.3.2 on some parts of SciMark, and no more than 3× worse on any part. I'm importing the shootout CVS repository into Git, so hopefully we can make some more definitive comparisons soon.
      - swannodette 16y ago
        Those overall results show that LuaJIT doesn't really compete much the JVM running under server mode.
        kragen 16y ago