On Tue, 2009-06-30 at 01:55 -0600, Daniel Lyons wrote: > > 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.
Optimize the Clojure or java code before anything else. There is a significant cost in using JNI. You pay it each time you cross the frontier... there's heavy structure copying... > > > 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. Right... no need to rewrite the low level Java stuff but more fun and faster code writing is to be expected with Clojure than Java. At least you will have a prototype faster instead of writing piles of code line for months before anything lifts from the ground. > > > 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. Agree, you would be better thinking about new parallel algorithms, easily expressed in Clojure compared to other languages, to gain some speed. Sometime the nature of the problem does not allow this (unavoidable computation dependencies) however Clojure allows you to test new alternatives to use multiple CPUs to find better ways to express your problem. These alternatives have not been tried out yet because we just happen now to have cheap SMP on the desktop. Testing new parallel solutions on these high-cost parallel architectures is way to high in terms of $$$$. they have to be tested on small scale first to see the if they provide any benefits. There's much to gain in changing our new designs to think "parallel" but it's not a reflex for older systems where things have been done "the same way" for years because of $$$ and hardware constraints. There's a need for new approaches in design given the new tools we now have at hand. Luc > > — > Daniel Lyons > > > > > Luc Préfontaine Armageddon was yesterday, today we have a real problem... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
