13 ms·
SBCL quicker than C?
- rst 16y agoSBCL = Steel Bank Common Lisp More precisely, if you tell the SBCL compiler to trust that all data types are as declared and omit type checks, it gives you code that's faster than gcc with the options at the bottom of this page: http://shootout.alioth.debian.org/u32/benchmark.php?test=spectralnorm&lang=gcc#log http://shootout.alioth.debian.org/u32/benchmark.php?test=spe... These are "inner loop only" compiler settings, at least the way I'd use it --- but it's still nice to see concrete demonstrations that you don't have to drop down to C code to get maximum performance. EDIT: (declaim (safety 0)) also omits array bounds checks, and checks for undefined variables.
- igouy 16y ago>>it gives you code that's faster than gcc with the options at the bottom of this page<< 1) Here are the timings for the C program you linked (x86 Ubuntu one core) - spectral-norm C GNU gcc #4 N CPU Elapsed 500 0.09 0.10 3,000 3.31 3.32 5,500 11.13 11.14 2) Here are the corresponding timings "if you tell the SBCL compiler..." spectral-norm Lisp SBCL #2 N CPU Elapsed 500 0.06 0.16 3,000 4.64 4.70 5,500 15.69 15.72 3) Is the program on the page you linked to faster or slower than the SBCL program ? http://shootout.alioth.debian.org/u32/performance.php?test=spectralnorm http://shootout.alioth.debian.org/u32/performance.php?test=s...
- rst 16y agoBolla says that alioth blew it, by not asking SBCL for full optimization --- and he does in fact get different timing with the optimization in place. From the original post: N=500 gcc 0.15u 0.00s 0.17r sbcl 0.08u 0.02s 0.21r N=3000 gcc 5.60u 0.00s 5.69r sbcl 5.18u 0.01s 5.41r N=5500 gcc 18.81u 0.01s 19.12r sbcl 17.42u 0.02s 17.76r I mentioned the alioth page mainly so people could see how gcc was being run.
- igouy 16y ago>>Bolla says that alioth blew it, by not asking SBCL for full optimization<< No he doesn't. The spectral-norm Lisp SBCL #2 program is Lorenzo Bolla's program - look at the program source code http://shootout.alioth.debian.org/u32/program.php?test=spectralnorm&lang=sbcl&id=2 http://shootout.alioth.debian.org/u32/program.php?test=spect... >>he does in fact get different timing with the optimization in place<< He get's different timing but the only explanation he provides is "So, different numbers on different boxes, which is not at all unexpected."
- igouy 16y ago>>Bolla says that alioth blew it, by not asking SBCL for full optimization<< Maybe you should ask Lorenzo Bolla if he was trying to create misunderstanding by posting one of his old (December 5th, 2010) blog entries to HN ;-) The benchmarks game website has been showing Lorenzo Bolla's spectral-norm Lisp SBCL #2 since December 8th 2010.
- rlpb 16y agoHe specifically asked gcc for optimisation for code size (-Os). For speed, he should be using -O3 only. He used "-Os -O3". This invalidates the benchmark.
- JoachimSchipper 16y agoHave you timed this? Instruction caches are finite, and overflowing them hurts performance so badly that some more loop unrolling may not help.
- rlpb 16y agoI've not timed anything, but asking gcc to optimise for size is the wrong thing to do when benchmarking for speed. I can think of lots of ways that this would cripple performance. Why not let gcc make its own decision? The only justification for using -Os in a speed benchmark is "I tried it both with and without the flag, and it was faster this way". I don't see any such assertion.
- deleted 16y ago[deleted]
- gwern 16y ago> The only justification for using -Os in a speed benchmark is "I tried it both with and without the flag, and it was faster this way". I don't see any such assertion. Really? It seems to me that this is quite enough: > I’ve just re-run the C benchmark without -Os (only -O3) but the results are the same.
- Tuna-Fish 16y agoThis is true for real software, not microbenchmarks. All of the shootout benchmarks will fit in their entirety in L1i cache -- which makes reducing the executable size pointless. Incidentally, this is probably the largest reason why so many people still use -O3 -- it wins in exactly the kind of programs that are used as simple and common benchmarks. It solidly loses on almost everything else.
- slavak 16y agoIs 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 agoI 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 agoI 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 agoN 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 agoFloating 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).
- deleted 16y ago[deleted]
- deleted 16y ago[deleted]
- deleted 16y ago[deleted]
- zachbeane 16y agoRobert Maas is mentally ill.
- deleted 16y ago[deleted]
- jsnell 16y agoAt least in the past the Shootout code wouldn't have explicit (declaim (optimize ...)) in the source files, but the command used to compile the files would have it. Did it really get removed from the command line?
- igouy 16y agoAlexey Voznyuk wanted it removed - My point is that obligatory "(optimize (speed 3) (safety 0) (debug 0) (compilation-speed 0) (space 0))" is totally wrong.
- jsnell 16y agoThanks for the explanation. I think he's totally wrong though, and could have just overridden whatever setting he was unhappy with in his own program. It seems crazy to pessimize every other program for the sake of one solution though, especially when the approach taken is considered cheating and the solution marked as "interesting alternative". And no criticism implied on the Shootout maintainers, I'm sure that dealing with the submitters is like herding cats :-)
- igouy 16y agoAlexey Voznyuk contributed several Lisp programs, and a couple still show as the fastest Lisp program - maybe you can do better? (The project name changed nearly 4 years ago http://groups.google.com/group/haskell-cafe/msg/61e427146c8d7ab4?hl=en&pli=1 http://groups.google.com/group/haskell-cafe/msg/61e427146c8d...)
- jsnell 16y agoI did years ago, and a few of them still seem to be around. But won't be doing it again both due to reasons we have discussed before, and because the implementations seem to have totally dived off the deep end of complexity by now, and don't really look like they'd be much fun anymore.
- 16y ago
- stevejohnson 16y agoI just started reading the thread linked from the blog post, and it felt like reading House of Leaves. Here are some choice quotes from various authors: Re Clojure: "This is a 'babel' plot to destroy lisp." "Pocket Forth is a free Forth interactive-interpretor that runs fine on my Macintosh "Performa 600" (68030-CPU) System 7.5.5." "The Mac is a desktop-publishing 'appliance' --- considering that you don't have a laser-printer, a Mac is about as useful to you as a bicycle is to a fish. Besides that, you don't seem like the desktop-publishing type of guy --- that is mostly a marketing-department girl thing." "I really foresee the collapse of civilization. The majority of people in America are motivated entirely by hate, fear, greed and envy, and this situation can't continue indefinitely. This is what I describe in my book, 'After the Obamacalypse,' which is included in the slide-rule package on my web-page." Another time I was sitting in my van in a parking lot. A skinny Jew walked up to the van, peered inside, then tried to open the door but discovered that it was locked, so he walked away. I got out and walked over to him, and I said: "What the hell do you think you're doing?" He also said that he thought it was his friend's van, but he didn't apologize at all, but became prideful and belligerent. When I said, "I think you're a thief," he said: "Look at the way you're dressed; you're the thief!" (I was wearing a hoodie). He told me that if I continued bothering him, he was going to call the police, and he got out his cell-phone. When I said, "I think you were looking for something to steal," he said: "There is nothing in your van worth stealing!" I beat him thoroughly with my fists and left him face down on the sidewalk in his own blood. Somewhat belatedly, be began to cry: "I'm sorry! I'm sorry!" It ends shortly after "Discussion subject changed to 'Whining (was Re: ordered associative arrays)' by John Passaniti."
- e40 16y agoFirst, what the hell are you talking about?? Second, someone upvoted this??
- neutronicus 16y ago1. The blog post links to a thread on comp.lang.lisp, which contains 3 or 4 posts about the shootout but was otherwise just nuts. 2. Eh, cataloging the type of wackos that hang out on comp.lang.lisp is something a lot of people enjoy.
- McP 16y agoFor N >= 3000 C is significantly faster. My guess is the initial slowness is caused by OMP initialising.
- unklem 16y agoThis question is incorrect, C is a language, SBCL is a CL compiler. Kindly amend that.
- lbolla 16y agoAfter reading all these interesting and enlightening comments (no pun intended here, there are all really useful), the blog post should really be titled: "A particular SBCL-compiled LISP-implementation of a specific algorithm gives comparable results to an analogous GCC-compiled C-implementation, when run on particular boxes."