4 ms·

Which programming languages are the fastest?

18 points by hitechsites 15y ago

Surprised that LISP is 20x faster than PHP or Perl in this benchmark (median times). It is even faster than Python and of course Ruby.

lvh 15y ago
I seem to remember that at one point, Pypy, Luajit and perhaps a Ruby interpreter were removed from the races. Anyone have any details on why that happened? These destroyed my ability to link to the shootout as data for showing that languages don't matter as much as implementations do, a nuance many newbies miss :(
- edsrzf 15y ago
  The benchmark game now only shows one implementation per language. The reasons aren't very satisfying IMO, but see this thread: http://thread.gmane.org/gmane.comp.python.pypy/7303/focus=7352 http://thread.gmane.org/gmane.comp.python.pypy/7303/focus=73...
  - igouy 15y ago
    If you want "the reasons" see the Help page - http://shootout.alioth.debian.org/help.php#implementationx http://shootout.alioth.debian.org/help.php#implementationx
- skymt 15y ago
  You can still point to gcc vs CINT to make that point dramatically. The help page has your answer, anyway. "Because I want to do fewer chores not more!" http://shootout.alioth.debian.org/help.php http://shootout.alioth.debian.org/help.php
- igouy 15y ago
  It's kind-of fun having "C" at both the top and bottom of a performance table - http://shootout.alioth.debian.org/u32/compare.php?lang=cint http://shootout.alioth.debian.org/u32/compare.php?lang=cint But let's note that here CINT is only being used as a C interpreter but a CINT script can call compiled classes/functions and compiled code can make callbacks to CINT interpreted functions - which I'm sure you understand would make it a lot faster.
angusgr 15y ago
As the page says, "No. Which programming language implementations have the fastest benchmark programs?" Which begs the question - aside from macho bragging rights, exactly what good is this kind of information? Assume I did have a specific problem case for which performance in terms of memory, time or LoC mattered. As a first step, I'd write a specific benchmarkable implementation of my own problem (or one very like it.) Then I'd need to profile and optimise that implementation in my chosen language(s), as well as stop and think laterally about ways I might be able to optimise around that specific problem. This is all assuming I'm working on a greenfields project where I have absolute free choice of language & runtime environment. Which happens for my personal projects, but never yet for a professional one. Not to mention that in all other cases apart from this hypothetical where performance matters, I would take the most human-readable program over the most fast, lean or concise one. Long story short, at no point can I see myself stopping and saying to myself. "You know what I need now? I need to see which programming language can generate a Mandelbrot set bitmap with the smallest memory footprint, without using any 'unfair' optimisation techniques."
- njharman 15y ago
  Exactly, I can't believe (what seems like a) majority of developers are still talking about language performance (and optimization). It matters for a small subsegment of our industry. The rest, speed/cost to implement and maintain far outweigh raw language performance.
  - angusgr 15y ago
    Yes! Also, even when you do care about performance, general performance isn't ever the same as specific performance. You have to optimise to your use case, not some arbitrary general use case like "render a Mandelbrot set" or "calculate pi". If I have a slow On^2 Erlang algorithm, then I'm a lot better off looking at ways to rewrite it as Olog(n) instead of scrapping Erlang and moving to Java because it had a better score on the programming language shootout.
    - igouy 15y ago

18 points by hitechsites 15y ago

Surprised that LISP is 20x faster than PHP or Perl in this benchmark (median times). It is even faster than Python and of course Ruby.

lvh 15y ago

I seem to remember that at one point, Pypy, Luajit and perhaps a Ruby interpreter were removed from the races. Anyone have any details on why that happened? These destroyed my ability to link to the shootout as data for showing that languages don't matter as much as implementations do, a nuance many newbies miss :(

edsrzf 15y ago
The benchmark game now only shows one implementation per language. The reasons aren't very satisfying IMO, but see this thread: http://thread.gmane.org/gmane.comp.python.pypy/7303/focus=7352 http://thread.gmane.org/gmane.comp.python.pypy/7303/focus=73...
- igouy 15y ago
  If you want "the reasons" see the Help page - http://shootout.alioth.debian.org/help.php#implementationx http://shootout.alioth.debian.org/help.php#implementationx
skymt 15y ago
You can still point to gcc vs CINT to make that point dramatically. The help page has your answer, anyway. "Because I want to do fewer chores not more!" http://shootout.alioth.debian.org/help.php http://shootout.alioth.debian.org/help.php
igouy 15y ago
It's kind-of fun having "C" at both the top and bottom of a performance table - http://shootout.alioth.debian.org/u32/compare.php?lang=cint http://shootout.alioth.debian.org/u32/compare.php?lang=cint But let's note that here CINT is only being used as a C interpreter but a CINT script can call compiled classes/functions and compiled code can make callbacks to CINT interpreted functions - which I'm sure you understand would make it a lot faster.

angusgr 15y ago

As the page says, "No. Which programming language implementations have the fastest benchmark programs?" Which begs the question - aside from macho bragging rights, exactly what good is this kind of information? Assume I did have a specific problem case for which performance in terms of memory, time or LoC mattered. As a first step, I'd write a specific benchmarkable implementation of my own problem (or one very like it.) Then I'd need to profile and optimise that implementation in my chosen language(s), as well as stop and think laterally about ways I might be able to optimise around that specific problem. This is all assuming I'm working on a greenfields project where I have absolute free choice of language & runtime environment. Which happens for my personal projects, but never yet for a professional one. Not to mention that in all other cases apart from this hypothetical where performance matters, I would take the most human-readable program over the most fast, lean or concise one. Long story short, at no point can I see myself stopping and saying to myself. "You know what I need now? I need to see which programming language can generate a Mandelbrot set bitmap with the smallest memory footprint, without using any 'unfair' optimisation techniques."

njharman 15y ago
Exactly, I can't believe (what seems like a) majority of developers are still talking about language performance (and optimization). It matters for a small subsegment of our industry. The rest, speed/cost to implement and maintain far outweigh raw language performance.
- angusgr 15y ago
  Yes! Also, even when you do care about performance, general performance isn't ever the same as specific performance. You have to optimise to your use case, not some arbitrary general use case like "render a Mandelbrot set" or "calculate pi". If I have a slow On^2 Erlang algorithm, then I'm a lot better off looking at ways to rewrite it as Olog(n) instead of scrapping Erlang and moving to Java because it had a better score on the programming language shootout.
  - igouy 15y ago