3 ms·

True, but it's not just the fact that it's a common (and often garbage) claim--it's also about the relative worth if it's proven true. I mean, if I could reall

True, but it's not just the fact that it's a common (and often garbage) claim--it's also about the relative worth if it's proven true. I mean, if I could really get C performance out of SBCL (and for my purposes, I can't), I'd sure as hell want to know. Think cold fusion. Sure, "wolf" has been cried a lot of times, but you're still going to want to know as soon as it happens "for real".

slavak 16y ago
That's true, but these posts aren't ever of the "language Y is actually as good as or better than C, always!" variety, are they? Instead what we get is the results of (in the best case) a couple of micro-benchmarks that happen to show comparable performance to C. If someone could show me that "yes, your Python programs are now AS FAST AS C!" then of course I'd be ecstatic to hear that; but the posts letting me know that "Python is as fast as C when approximating solutions to problem X, for some X you've never heard of and never will" get kind of old after the 137th time I read them. For me this is comparable to someone posting about yet another problem in NP that is REALLY FRICKIN' HARD, so probably P=/=NP. I know many problems in NP are hard - you're not adding anything to the discussion by showing me yet another one. Let me know when you have an actual proof that P=/=NP.
- gte910h 16y ago
  Actually slavak, inner loop C performance is all that's necessarily to make many of these tools viable. If I can write my entire program in LANGUAGEX and just compile the inner loop a magic way and voila, the program runs at 85% C speed, we have a winner. We can use it in long-running programs which have a fierce compute time bounding. This is an article explaining the magic way for a flavor of lisp.
- GregBuchholz 16y ago
  It is interesting to note that a beautiful python program from the "interesting alternative" category [1] beats the C program, and LuaJIT is always impressive [2] on these sorts of microbenchmarks (beating SBCL, with one third the source code). [1] http://shootout.alioth.debian.org/u32/program.php?test=spectralnorm&lang=python3&id=2 http://shootout.alioth.debian.org/u32/program.php?test=spect... [2] http://shootout.alioth.debian.org/u32/program.php?test=spectralnorm&lang=luajit&id=1 http://shootout.alioth.debian.org/u32/program.php?test=spect...
  - igouy 16y ago
    [1] 12.54s < 11.14s ?
    - GregBuchholz 16y ago
      My bad. I must have been confusing the SBCL time for the GCC time.
- sedachv 16y ago
  If you are such an expert on what makes a benchmark representative of "real-world" problems, you're welcome to make a contribution to the Shootout. I'm sure they'll be glad to accept it, and everyone will be relieved to find out all the other benchmarks are worthless and everyone has been wasting their time.

slavak 16y ago

That's true, but these posts aren't ever of the "language Y is actually as good as or better than C, always!" variety, are they? Instead what we get is the results of (in the best case) a couple of micro-benchmarks that happen to show comparable performance to C. If someone could show me that "yes, your Python programs are now AS FAST AS C!" then of course I'd be ecstatic to hear that; but the posts letting me know that "Python is as fast as C when approximating solutions to problem X, for some X you've never heard of and never will" get kind of old after the 137th time I read them. For me this is comparable to someone posting about yet another problem in NP that is REALLY FRICKIN' HARD, so probably P=/=NP. I know many problems in NP are hard - you're not adding anything to the discussion by showing me yet another one. Let me know when you have an actual proof that P=/=NP.

gte910h 16y ago
Actually slavak, inner loop C performance is all that's necessarily to make many of these tools viable. If I can write my entire program in LANGUAGEX and just compile the inner loop a magic way and voila, the program runs at 85% C speed, we have a winner. We can use it in long-running programs which have a fierce compute time bounding. This is an article explaining the magic way for a flavor of lisp.
GregBuchholz 16y ago
It is interesting to note that a beautiful python program from the "interesting alternative" category [1] beats the C program, and LuaJIT is always impressive [2] on these sorts of microbenchmarks (beating SBCL, with one third the source code). [1] http://shootout.alioth.debian.org/u32/program.php?test=spectralnorm&lang=python3&id=2 http://shootout.alioth.debian.org/u32/program.php?test=spect... [2] http://shootout.alioth.debian.org/u32/program.php?test=spectralnorm&lang=luajit&id=1 http://shootout.alioth.debian.org/u32/program.php?test=spect...
- igouy 16y ago
  [1] 12.54s < 11.14s ?
  - GregBuchholz 16y ago
    My bad. I must have been confusing the SBCL time for the GCC time.
sedachv 16y ago
If you are such an expert on what makes a benchmark representative of "real-world" problems, you're welcome to make a contribution to the Shootout. I'm sure they'll be glad to accept it, and everyone will be relieved to find out all the other benchmarks are worthless and everyone has been wasting their time.