On Jun 29, 2009, at 12:41 PM, fft1976 wrote:
> > Based on the recent survey "What are people using Clojure for?", > people are mostly using it for non-CPU-intensive work, like parsing, > report generation, GUIs, "glue" code. > > It's been argued by some that Clojure is as fast as Java, because at > worst, you can implement your bottlenecks in Java. I have a problem > with this argument, because the data structures that your Java has to > work with are still (wasteful) Clojure ones. You can use (make-array) and work with native Java arrays of native Java types if you like. And you can use Java's native interface if Java's too slow too, though I hear there is non-negligible cost to crossing the interface. > For example, a matrix data structure in Clojure could be based on Seqs > (or Seqs of Seqs) of dynamically typed elements. There is overhead > associated with this dynamic typing and mutation of the elements. (make-array) can make higher dimensional arrays as well. > When you discover that some procedure working on such data structure > is slow, you can reimplement it in Java, but do you think it could > compete with Java working on native statically typed arrays of floats? I don't see why that wouldn't be the case, if you were using Java's native multidimensional arrays. I don't think it would be as much fun, since it would become an exercise in managing mutable state, but if performance is the first priority, sacrifices have to be made. > I would be curious to know if anyone is using Clojure for CPU- > intensive work where performance really counts. This is kind of a dodge, but for most of my apps the perception of performance is more important than real performance, and responsiveness is the essential ingredient to that perception. Clojure does great once it's started up and performs better than most of the languages I'm accustomed to (Ruby, PHP, JavaScript, etc.) even before we throw in concurrency. Clojure's real value for me probably lies in helping with the glue code though. Most of my code seems to be glue code these days, and Clojure really minimizes the unfun and makes the rest quite short and pleasurable to write. As libraries have exploded I think more people find themselves writing more glue code than (?)leaf code. > I get the impression that Jon Harrop is gearing up to write Clojure > for Scientists. Also I remember someone saying they are working on the > Shootout entry for Clojure. Has this happened? Of course I would be interested if Dr. Harrop did write Clojure for Scientists. I think some of his ideas could use wider circulation. I'd be a little surprised if he did write it though; isn't he busy with F# still? As an aside, I wouldn't worry too much about wooing scientists. The ones I know aren't using Fortran because they like it so much as because their ancient simulations are huge and complex and they run on supercomputers with expensive compilers. The ones I know that aren't using Fortran are using Mathematica, where speed isn't the winning feature so much as the attractive environment. If single-core performance is your first priority, you probably are going to use C and sacrifice some portability. Being comparable in speed to Java in a language hosted on the JVM and implemented in Java is no small feat. For me, Clojure is a big improvement over Ruby or PHP. If one instead arrived from a lower level language, it would mean a loss of performance but a gain in productivity and abstraction. Sometimes those just aren't the right priorities. To each his own. — Daniel Lyons --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
