Mark, On Jul 1, 2009, at 3:16 PM, Mark Engelberg wrote: > But each language encourages a certain style of design and algorithm, > so it IS fair to compare the way that the language encourages a > certain approach. For example, Clojure encourages you to use a more > functional approach and persistent data structures. If this ends up > being way slower than the mutable approach that Python encourages, > that is worth knowing. > > I remember one year, my ICFP VM in Python ran ridiculously slow in > part because Python doesn't have a switch statement, whereas other > languages do. So it is useful to look at what a language does and > does not allow you to do, and how that impacts speed. > > My point is: no comparison is going to be exactly apples to apples, > but the comparison can still be useful.
I think I may have conflated some ideas in my previous message. Let me explain. Firstly, I don't think there's any question that Clojure's performance isn't up to that of C. The JVM can always get better but it's probably going to be a while on that one. And I think the JVM establishes a reasonable ceiling on performance. To wit, if you don't think your program would run fast enough on the JVM, it's probably not going to run fast enough under Clojure either. Unless you can make up for it with cheap parallelism. I think everyone ought to know this coming in, but if C-level performance is really necessary, only a few languages will suffice and the decision of what to use to implement the code will necessarily flow from that. As for FP techniques themselves, there is ample proof that they are not a performance inhibition in the form of other FP languages that do not compromise on methodology but still achieve high performance. I'm talking about OCaml, Haskell, Common Lisp (not as FPy, but it can be done) and Scheme and sometimes Erlang. The language shootout has plenty of evidence for that. Please forgive my derision towards benchmarking languages. I guess you could say I am channelling Dijkstra here, but I think the algorithm dominates the debate. Quicksort in Ruby will beat bubble sort in C if your data is large enough. This is one reason I am not a big fan of comparing the speed of languages; another is that it often changes out from under you. Java itself is a great example of this: by the time everyone had gotten the message that it was slow, it had already become reasonably fast. The code that was to take the most advantage of the improvements was that which was written plainly and clearly rather than doing a lot of legwork to circumvent performance issues, and this is always the case. Clojure's young. I appreciate the novelty of the ICFP and I think it's being examined because it's on our minds rather than due to any qualities it has as an experiment, so I won't harp on it much, but I think to compare between different teams implementations would be to assume that each team was more-or-less equal in terms of skill but for the language. The whole point of the contest is to discover just how untrue that is. I remember in 2006 my team made a very small VM in C and we were extremely proud of it because we had wasted so much time on a VM in Ruby and again in Python, hoping it would be a substantial improvement. Another team had written a VM with a just-in-time compiler which defeated our braindead C implementation handily. It was written in Haskell, of course: http://comonad.com/reader/wiki;mode=category&item=Perl All the best, — Daniel Lyons PS: you can emulate a switch in Python by storing functions in a hash with the key being the dispatch value. But I don't think it will save your performance. --~--~---------~--~----~------------~-------~--~----~ 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 Note that posts from new members are moderated - please be patient with your first post. 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 -~----------~----~----~----~------~----~------~--~---
