5 ms·

Is this really still news? Yes, we know you can get great performance in some tasks with languages other than C. I swear, if I see ANOTHER article with the link

by slavak 16y ago

Is this really still news? Yes, we know you can get great performance in some tasks with languages other than C. I swear, if I see ANOTHER article with the linkbait title of "X faster than C"... The decent ones posted at least bother to do a comparison with several pseudo-representative tasks. This one just goes "hey, I played around with this ONE SPECIFIC TASK NOBODY GIVES A CRAP ABOUT and IT RAN 0.006 MILLISECONDS FASTER THAN IN C! WOOOOOOOOOOOO!"

neutronicus 16y ago
"We beat C" is a claim that goes hand in hand with "we are viable for scientific computing", so I'm always interested in hearing it (although more benchmarks would be nice).
- JoachimSchipper 16y ago
  I recall at least one old FORTRAN guy wandering into comp.lang.c who had very few good things to say about C's handling of floating-point calculations...
  - neutronicus 16y ago
    I said "viable". Unfortunately, "Am I FORTRAN?" is the question that goes hand in hand with "Am I realistic for scientific computing". c'est la vie.
  - igouy 16y ago
    N CPU Elapsed 500 0.07 0.22 3,000 2.34 2.41 5,500 7.86 8.01 Intel Fortran http://shootout.alioth.debian.org/u32/performance.php?test=spectralnorm http://shootout.alioth.debian.org/u32/performance.php?test=s...
  - jedbrown 16y ago
    Floating point is not the problem, it's memory issues mostly due to C defaulting to allowing aliasing. C99 has the `restrict` keyword so you can generally get identical object code from both languages. SSE intrinsics are only available from C, you will either use them or assembly any time you care a lot about performance of tight kernels (very few nontrivial kernels are vectorized adequately by any of today's compilers).
    - JoachimSchipper 16y ago
      As I recall, this had very little to do with this guy complaints - it was a mixture of C allowing use of x87 80-bit-wide doubles and not allowing sufficient reordering of operations. That said, yes, restrict was added for this kind of thing.
      - neutronicus 16y ago
        x87 I'm sure he cackled into his pocket protector at the recent PHP/Java/gcc floating point parsing fiasco.
brownegg 16y ago
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...

by slavak 16y ago

neutronicus 16y ago

"We beat C" is a claim that goes hand in hand with "we are viable for scientific computing", so I'm always interested in hearing it (although more benchmarks would be nice).

JoachimSchipper 16y ago
I recall at least one old FORTRAN guy wandering into comp.lang.c who had very few good things to say about C's handling of floating-point calculations...
- neutronicus 16y ago
  I said "viable". Unfortunately, "Am I FORTRAN?" is the question that goes hand in hand with "Am I realistic for scientific computing". c'est la vie.
- igouy 16y ago
  N CPU Elapsed 500 0.07 0.22 3,000 2.34 2.41 5,500 7.86 8.01 Intel Fortran http://shootout.alioth.debian.org/u32/performance.php?test=spectralnorm http://shootout.alioth.debian.org/u32/performance.php?test=s...
- jedbrown 16y ago
  Floating point is not the problem, it's memory issues mostly due to C defaulting to allowing aliasing. C99 has the `restrict` keyword so you can generally get identical object code from both languages. SSE intrinsics are only available from C, you will either use them or assembly any time you care a lot about performance of tight kernels (very few nontrivial kernels are vectorized adequately by any of today's compilers).
  - JoachimSchipper 16y ago
    As I recall, this had very little to do with this guy complaints - it was a mixture of C allowing use of x87 80-bit-wide doubles and not allowing sufficient reordering of operations. That said, yes, restrict was added for this kind of thing.
    - neutronicus 16y ago
      x87 I'm sure he cackled into his pocket protector at the recent PHP/Java/gcc floating point parsing fiasco.

brownegg 16y ago

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...