Hacker News Reader

Comment by slavak | Hacker News Reader

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!"

View on HN

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

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

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.

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

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

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.

x87

I'm sure he cackled into his pocket protector at the recent PHP/Java/gcc floating point parsing fiasco.

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

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.

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.

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

[2] http://shootout.alioth.debian.org/u32/program.php?test=spect...

[1] 12.54s < 11.14s ?

My bad. I must have been confusing the SBCL time for the GCC time.

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.

Reply on news.ycombinator.com