There's a study someone did that compared C++, Java, and Lisp implementations of various problems. It could be urban legend, but how I remember it:
The best C++ implementation was the fastest for each problem. But the average lisp implementation was faster then the average java or C++ implementation. The variance was the smallest on performance of lisp implementations -- it being a higher-level language. The time to deliver was least on average with lisp and with least variance. The code size and variance thereof was least in lisp. The correctness was greatest in lisp. Moral of the story? Either I remember this wrong or you have to be an extremely proficient programmer to get the bang for the buck out of C++. You gotta know about functors with inline constructors . . . buy lots of books, go to lots of conferences . . . .etc. Of course, another conclusion that makes sense to me is that the average lisp programmer is someone whose been coding for a while. Statistics can mislead. What were the sample sets like? Did the same people code for each language, etc., etc. Also, were it not for the terrible syntax for STL-type stuff (and the terrible, mile long errors) , , , ,and the terrible compile times, can anyone really say that C++ isn't a powerful language? Have you seen all the crazy stuff in the boost libraries? People extend them occasionally with parallel implementations, too. On Tue, Jan 13, 2009 at 1:28 AM, Mark P <pierh...@gmail.com> wrote: > > On Jan 13, 1:21 am, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: > > If you have > > highly-optimized, custom-designed numerical algorithms written in a > > low-level language like C++, you will never be able to write a version > > that is equally fast in a dynamic, virtual-machine language. > > I think you are essentially right (although some optimizations > can only be performed with runtime information). But highly-optimized > low-level code is very rigid. It is difficult to maintain it and > adapt it > to changing program needs and new technology (with different > optimization characteristics). > > So I am willing to wear a certain loss of performance in exchange > for a more agile program, but not too much. I think I'd be willing > to wear a 20% loss in performance (perhaps even 50%), but not > magnitudes much higher than this. And my gut feeling is that > 20% or so should be achievable for a lisp-style language. But the > Clojure+JVM solution sounds like it is still a way off from this. > > > Compilers are smart, but they are not that smart. > > I am a relative newcomer to lisp, but my impression is that > lisp should be thought of as both low level and high level > all in one. Ie, that the leverage from lower levels to higher > ones happens primarily via macros... which the programmer > has direct access to. So in theory a developer could use > macros to perform compiler-style optimizations within > lisp itself, except these optimizations could be tailored > to the particular application. So as long as the base level > lisp was implemented efficiently, the whole top-level > lisp program could be efficient. But from what I can tell, > even the best lisp compilers produce slow code. Even > SBCL lisp seems to be 3 to 4 times slower than C++. > So I must be misunderstanding something. I can't see > why lisps should be inherently so slow. > > > That being said, experience is the only reliable guide. If you want to > > know if Clojure will work for your job, the only thing to do is try > > it. > > Yes, I think some experimental coding might be in order. But > I'd like to get as much a grip on the performance landscape as > I can beforehand. > > Thanks for tempering any over-enthusiasm and giving me your > best honest assessment. > > Cheers, > > Mark P. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
