On 13.01.2009, at 05:35, Mark P wrote: > I know that there are other functional approaches where > the compiler automatically finds ways to parallelize. Is there > much scope for this in Clojure? Or is it all pretty much > manually added concurrency?
I am not aware of any auto-parallelizing compiler that is actually useful in practice. All useable parallelization schemes rely at least on hints from the programmer, and most leave the whole specification of parallelism to the programmer. One might say that data-parallel systems are auto-parallelizing, but they aren't really: the programmer has to define the data that is being distributed, which counts for me as a parallelization hint. Clojure does nothing at all, it just provides an infrastructure for pure functional programming that makes concurrency and parallel computing easier to implement than most other languages. > And this leads to another question I have about Lisp-style > languages in general. I get the impression that in Lisp > much of the "compiler" is Lisp code itself. Ie, layer and > layer of macros build up towards the language that then > actually gets "used". Does this layer upon layer of macros > lead to inefficiencies in itself? Or is the opposite true? Macros are handled at compile time, so they add no run-time overhead. There remains the question of how good the compiler can optimize the expressions resulting from macro expansion. But the same question applies to any other compiler, as most of them first transform the input language into some simple intermediate language and then optimize at that level. The difference with Lisp is just that the simple intermediate language is a subset of the full language. > That seems to match what I've read. On average I get the > impression that it is about 2 times as slow as efficient C++ code > and uses maybe 10 times as much memory. I wouldn't trust any "average"! > What I'm wondering is whether there is still quite a bit of > "fat to be trimmed" with HotSpot, or whether it's approaching > the limits of what is achievable. JIT technology being young and in rapid development, it would be risky to do any prediction there. >> You could also consider writing Clojure code that generates C++ code. >> Or C, or why not directly LLVM. > > Thanks. Worth considering. Though I don't really know > whether this is a practical option or not. Maybe it is. There are efficient real-life libraries that use this approach. The best known is probably FFTW, which consists of optimized C code generated by functional OCaml code. I have no doubt that Clojure could take the role of OCaml there. Of course, writing such an optimizing library requires a significant effort. Konrad. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
