Re: Clojure in Computing in Science and Engineering
On Jun 20, 2009, at 12:29, Jon Harrop wrote: The Task Parallel Library. It uses concurrent wait-free work- stealing queues to provide an efficient implementation of work items than can spawn other work items with automatic load balancing on shared memory machines. Cilk uses the same technology (well worth a look if you haven't already seen it!). I know about Cilk, and I agree that this approach is useful in practice. That makes it easy to write efficient parallel algorithms in any .NET language. In particular, it can sustain billions of work items (as opposed to thousands of threads or processes) and the time taken to spawn is ~30,000x faster than forking a process. Extremely useful stuff! Indeed! What are parallel map reduce etc. implemented upon in Clojure? Java threads, according to the documentation: clojure.core/future ([ body]) Macro Takes a body of expressions and yields a future object that will invoke the body in another thread, and will cache the result and return it on all subsequent calls to deref/@. If the computation has not yet finished, calls to deref/@ will block. The macro future is used in the implementation of pmap. 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 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Sun, 21 Jun 2009 14:39:37 +0100, Jon Harrop j...@ffconsultancy.com wrote: I had not looked at Intel's offering because it does not (AFAIK) support accurate garbage collection. Also, it is worth noting that there is no difference between data and task parallelism in a genuine functional language. Well, I meant task parallelism vs. data parallelism in the design intent, rather than the implementation. I find that calling computational fluid dynamics data parallel, and a telecom switch task parallel is useful even if happens that solutions to both sorts of problems in genuine FP are somehow isomorphic. I feel that's because the problem domains, and the ways a typical programmer thinks about the solutions, are different enough that the isomorphism isn't likely to be astonishingly useful in practice. Well, maybe except for programming in the small. For instance, I don't see overwhelming practical applications of proving one could implement a telecom switch as parallel maps and reductions over a bunch of functions, unless (perhaps) you're a compiler writer and/or designing a DSL for the purpose. It's fun as a thought experiment, but I think that it would stray too far from the language of the problem without lots of sugar that would (it seems to me) just sort of take you back to where you started in terms of expressiveness. But then again, those sorts of visions aren't my forte :) Right. If you hand-roll your C++ very carefully then you can get decent performance but I was disappointed with the performance of the template libraries and quality of g++ back in 2004 and have never used C++ since. Yeah, g++ 4.1 and 4.2 seemed to have a reputation for being especially bad at optimizing away abstraction penalties of heavy template usage. I understand this is much better in recent releases, but I haven't measured it myself. For all it's warts, C++ (like Java) has interesting things happen to it here and there, if only by sheer volume and chance. And every so often a problem comes along that feels like a good fit. Maybe I'm just perverse, and I bet *nobody* here will agree with me, but sometimes I feel wrong when I use a language like a Lisp, with its symbolic and meta-everything sweet spot, to do something as brutish and mundane as picking apart awful binary formats and chewing through vectors of integers and floats. It feels like ruining expensive top shelf bourbon by pouring it in Coke :) -Kyle --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
Maybe I'm just perverse, and I bet *nobody* here will agree with me, but sometimes I feel wrong when I use a language like a Lisp, with its symbolic and meta-everything sweet spot, to do something as brutish and mundane as picking apart awful binary formats and chewing through vectors of integers and floats. It feels like ruining expensive top shelf bourbon by pouring it in Coke :) I do see your point (and as a bourbon enthusiast, I understand the analogy!). That's the nice thing about Clojure over other Lisps: more abstraction means more opportunity to hide these things, which at least means you can forget about the Pappy and Coke someone's drinking! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Monday 22 June 2009 12:01:19 Konrad Hinsen wrote: Java threads, according to the documentation: clojure.core/future ([ body]) Macro Takes a body of expressions and yields a future object that will invoke the body in another thread, and will cache the result and return it on all subsequent calls to deref/@. If the computation has not yet finished, calls to deref/@ will block. The macro future is used in the implementation of pmap. If that is spawning a new thread every time a future is created then it is really for concurrent programming rather than parallel programming. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Monday 22 June 2009 22:33:24 Stephen C. Gilardi wrote: On Jun 22, 2009, at 5:53 PM, Jon Harrop wrote: If that is spawning a new thread every time a future is created then it is really for concurrent programming rather than parallel programming. The thread is from a cached thread pool provided by the Executors class: http://java.sun.com/javase/6/docs/api/java/util/concurrent/Executors.html#n ewCachedThreadPool%28%29 Ok, that will be reliable then but performance is quite a bit worse than it could be. Essentially the same as pre-TPL .NET, e.g. using asynchronous workflows in F# today. The migration occurs officially on the MS side with the release of .NET 4 next year. Is there a similar plan on the JVM side? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Sat, Jun 20, 2009 at 11:29 AM, Jon Harrop j...@ffconsultancy.com wrote: The Task Parallel Library. It uses concurrent wait-free work-stealing queues to provide an efficient implementation of work items than can spawn other work items with automatic load balancing on shared memory machines. Cilk uses the same technology (well worth a look if you haven't already seen it!). That makes it easy to write efficient parallel algorithms in any .NET language. In particular, it can sustain billions of work items (as opposed to thousands of threads or processes) and the time taken to spawn is ~30,000x faster than forking a process. Extremely useful stuff! Sounds similar to ForkJoin, which Rich pointed out to me a while ago: http://www.ibm.com/developerworks/java/library/j-jtp11137.html Anand --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Sunday 21 June 2009 02:44:02 Kyle Schaffrick wrote: On Sat, 20 Jun 2009 11:29:44 +0100 Jon Harrop j...@ffconsultancy.com wrote: The Task Parallel Library. It uses concurrent wait-free work-stealing queues to provide an efficient implementation of work items than can spawn other work items with automatic load balancing on shared memory machines. Cilk uses the same technology (well worth a look if you haven't already seen it!). That makes it easy to write efficient parallel algorithms in any .NET language. In particular, it can sustain billions of work items (as opposed to thousands of threads or processes) and the time taken to spawn is ~30,000x faster than forking a process. Extremely useful stuff! Interesting. It strikes me that it's called task parallel library, while it sounds a lot like Intel Threading Building Blocks, which is a sort of STL-style quasi-functional template library for *data*-parallel algorithms; the stuff people like to write with Fortran, OpenMP and friends. I had not looked at Intel's offering because it does not (AFAIK) support accurate garbage collection. Also, it is worth noting that there is no difference between data and task parallelism in a genuine functional language. It uses a work-stealing thread-pool scheduler as well, atop which stuff like parallel maps and reductions are implemented as templates. You can create your own work items and stick them in the scheduler by hand, but the useful bits are actually the prefab algorithms, IMO. Right. If you hand-roll your C++ very carefully then you can get decent performance but I was disappointed with the performance of the template libraries and quality of g++ back in 2004 and have never used C++ since. I've heard good things about D but, IMHO, it fails to cash in on lots of language features. Most notably FP. The tunable/pluggable slicing strategies, built on the standard iterator concepts, are particularly interesting way to give you full control of work unit granularity, without having to know too much about the innards of the algorithms themselves. Yes. The nice thing about using a functional language is that you can easily pass two functions, one to solve the problem and the other describing the complexity of the first as a function of its inputs. If necessary, you can augment your data structures with extra information to make it efficient to compute complexities. Then you can use the new complexity function to intelligently parallelize your algorithms into tasks such that the (roughly-constant) overhead of spawning tasks is guaranteed to be small compared to the work done by the task and, hence, you can greatly increase the probability of getting a speedup compared to ordinary chunking. Moreover, there is great benefit in sharing the same load balancing system. For example, if you write a parallel .NET program where tasks invoke the Intel MKL then the MKL uses independent parallelization and that renders your performance unpredictable at best and awful at worst. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Sunday 21 June 2009 08:55:54 Anand Patil wrote: Sounds similar to ForkJoin, which Rich pointed out to me a while ago: http://www.ibm.com/developerworks/java/library/j-jtp11137.html Yes. I believe the main difference is that the TPL does not block because there is no join operation. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On 19.06.2009, at 10:35, Jon Harrop wrote: If you really do mean scientific applications in general (e.g. Mathematica, MATLAB) then I would say that they are definitely almost all running on multicore desktops and not distributed clusters. What I really meant is scientific applications typically written by scientists, and in my experience that is mostly number-crunching stuff, if only because that's all most scientists would care to write. Mathematica and MATLAB are written and maintained by professional programmers. Shared-memory parallelism is certainly a major problem in scientific computing today so I, for one, would love to see parallelized Clojure solutions to interesting problems (even toys). What sort of basic infrastructure would you use in Clojure, e.g. equivalent to Microsoft's TPL? What't TPL? 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 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Jun 20, 3:34 am, Konrad Hinsen konrad.hin...@laposte.net wrote: On 19.06.2009, at 10:35, Jon Harrop wrote: If you really do mean scientific applications in general (e.g. Mathematica, MATLAB) then I would say that they are definitely almost all running on multicore desktops and not distributed clusters. What I really meant is scientific applications typically written by scientists, and in my experience that is mostly number-crunching stuff, if only because that's all most scientists would care to write. Mathematica and MATLAB are written and maintained by professional programmers. Shared-memory parallelism is certainly a major problem in scientific computing today so I, for one, would love to see parallelized Clojure solutions to interesting problems (even toys). What sort of basic infrastructure would you use in Clojure, e.g. equivalent to Microsoft's TPL? What't TPL? Konrad. Pretty cool. I went to school 10 years ago and Lisp was supposed to be language of choice for AI but the implementations didn't seem practical. I think Clojure brings a lot of useful libraries and usefulness to the Lisp world. Maybe we will see the emergence of Lisp again. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Saturday 20 June 2009 08:34:39 Konrad Hinsen wrote: On 19.06.2009, at 10:35, Jon Harrop wrote: If you really do mean scientific applications in general (e.g. Mathematica, MATLAB) then I would say that they are definitely almost all running on multicore desktops and not distributed clusters. What I really meant is scientific applications typically written by scientists, and in my experience that is mostly number-crunching stuff, if only because that's all most scientists would care to write. Mathematica and MATLAB are written and maintained by professional programmers. Ok. I think scientists write a lot of other software as well and, in particular, the vast majority of their code is disposable software written in languages like Mathematica. That software runs on individual desktops. Shared-memory parallelism is certainly a major problem in scientific computing today so I, for one, would love to see parallelized Clojure solutions to interesting problems (even toys). What sort of basic infrastructure would you use in Clojure, e.g. equivalent to Microsoft's TPL? What't TPL? The Task Parallel Library. It uses concurrent wait-free work-stealing queues to provide an efficient implementation of work items than can spawn other work items with automatic load balancing on shared memory machines. Cilk uses the same technology (well worth a look if you haven't already seen it!). That makes it easy to write efficient parallel algorithms in any .NET language. In particular, it can sustain billions of work items (as opposed to thousands of threads or processes) and the time taken to spawn is ~30,000x faster than forking a process. Extremely useful stuff! I assume the JVM has everything required to implement wait-free algorithms? What are parallel map reduce etc. implemented upon in Clojure? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Sat, 20 Jun 2009 11:29:44 +0100 Jon Harrop j...@ffconsultancy.com wrote: On Saturday 20 June 2009 08:34:39 Konrad Hinsen wrote: What't TPL? The Task Parallel Library. It uses concurrent wait-free work-stealing queues to provide an efficient implementation of work items than can spawn other work items with automatic load balancing on shared memory machines. Cilk uses the same technology (well worth a look if you haven't already seen it!). That makes it easy to write efficient parallel algorithms in any .NET language. In particular, it can sustain billions of work items (as opposed to thousands of threads or processes) and the time taken to spawn is ~30,000x faster than forking a process. Extremely useful stuff! Interesting. It strikes me that it's called task parallel library, while it sounds a lot like Intel Threading Building Blocks, which is a sort of STL-style quasi-functional template library for *data*-parallel algorithms; the stuff people like to write with Fortran, OpenMP and friends. It uses a work-stealing thread-pool scheduler as well, atop which stuff like parallel maps and reductions are implemented as templates. You can create your own work items and stick them in the scheduler by hand, but the useful bits are actually the prefab algorithms, IMO. The tunable/pluggable slicing strategies, built on the standard iterator concepts, are particularly interesting way to give you full control of work unit granularity, without having to know too much about the innards of the algorithms themselves. -Kyle --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On 19.06.2009, at 00:07, Brett Morgan wrote: Silly question of the week, clojure+terracotta be used to do scientific cluster computing? The big question is what the performance impact of terracotta is, both for simple but large date (a big array, for example) and for big complex data structures (such as a tree). Is there anyone here with Terracotta experience? 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 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Jun 18, 2:00 am, Konrad Hinsen konrad.hin...@laposte.net wrote: The July/August issue of the IEEE magazine Computing in Science and Engineering has an introduction to functional programming for scientists that uses Clojure for the examples. It is already available (a bit in advance of the paper issue) at IEEE's Computing Now portal: http://www2.computer.org/portal/web/computingnow/0609/whatsnew/cise I happen to be the author of the article and also a member of the editorial board of the magazine, so I have no merit for getting it published :-) BTW, if anyone has an interesting scientific application in Clojure (including a mixture of Clojure + Java, for example), and wants to write about it, please contact me! Actually, I am interested in articles on any interesting technology for scientific computing, it doesn't even have to be Clojure. Konrad. Awesome! I've been looking to see if any papers would start being written about/using clojure. Will be exciting to see science done in clojure! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Thu, Jun 18, 2009 at 2:00 AM, Konrad Hinsenkonrad.hin...@laposte.net wrote: The July/August issue of the IEEE magazine Computing in Science and Engineering has an introduction to functional programming for scientists that uses Clojure for the examples. It is already available (a bit in advance of the paper issue) at IEEE's Computing Now portal: http://www2.computer.org/portal/web/computingnow/0609/whatsnew/cise I happen to be the author of the article and also a member of the editorial board of the magazine, so I have no merit for getting it published :-) Cool! Thanks for the exposure. Rich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
That is funny... I put a little Clojure plug into the article entitled Trailblazing with Roadrunner in the very same issue of CiSE. Paul On Jun 18, 12:00 am, Konrad Hinsen konrad.hin...@laposte.net wrote: The July/August issue of the IEEE magazine Computing in Science and Engineering has an introduction to functional programming for scientists that uses Clojure for the examples. It is already available (a bit in advance of the paper issue) at IEEE's Computing Now portal: http://www2.computer.org/portal/web/computingnow/0609/whatsnew/cise I happen to be the author of the article and also a member of the editorial board of the magazine, so I have no merit for getting it published :-) BTW, if anyone has an interesting scientific application in Clojure (including a mixture of Clojure + Java, for example), and wants to write about it, please contact me! Actually, I am interested in articles on any interesting technology for scientific computing, it doesn't even have to be Clojure. 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 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Jun 18, 2:00 am, Konrad Hinsen konrad.hin...@laposte.net wrote: The July/August issue of the IEEE magazine Computing in Science and Engineering has an introduction to functional programming for scientists that uses Clojure for the examples. It is already available (a bit in advance of the paper issue) at IEEE's Computing Now portal: http://www2.computer.org/portal/web/computingnow/0609/whatsnew/cise I happen to be the author of the article and also a member of the editorial board of the magazine, so I have no merit for getting it published :-) Really neat -- hopefully there will be a follow-up that demonstrates Clojure's concurrency features (perhaps contrasting it with Haskell). -- Michel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On 18.06.2009, at 16:47, psf wrote: That is funny... I put a little Clojure plug into the article entitled Trailblazing with Roadrunner in the very same issue of CiSE. Great minds think alike ;-) On 18.06.2009, at 18:16, Michel Salim wrote: Really neat -- hopefully there will be a follow-up that demonstrates Clojure's concurrency features (perhaps contrasting it with Haskell). The problem is that neither one is particularly well suited for the majority of scientific applications, which work best on distributed- memory machines. Of course this may change with the increasing number of cores-per-processor, shared-memory SMP may become fashionable again even for number crunching. Anyway, if anyone has a scientific (in the widest possible sense) application that exploits Clojure's currency, contact me if you want to write about it! 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 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
On Thu, Jun 18, 2009 at 5:48 PM, Konrad Hinsen konrad.hin...@laposte.netwrote: On 18.06.2009, at 16:47, psf wrote: That is funny... I put a little Clojure plug into the article entitled Trailblazing with Roadrunner in the very same issue of CiSE. Great minds think alike ;-) On 18.06.2009, at 18:16, Michel Salim wrote: Really neat -- hopefully there will be a follow-up that demonstrates Clojure's concurrency features (perhaps contrasting it with Haskell). The problem is that neither one is particularly well suited for the majority of scientific applications, which work best on distributed- memory machines. Of course this may change with the increasing number of cores-per-processor, shared-memory SMP may become fashionable again even for number crunching. Anyway, if anyone has a scientific (in the widest possible sense) application that exploits Clojure's currency, contact me if you want to write about it! Great article, Konrad. Thanks for giving us something to email to colleagues! I've got something bubbling away on the back burner, but will let the suspense build up a bit ;). Anand --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Clojure in Computing in Science and Engineering
Silly question of the week, clojure+terracotta be used to do scientific cluster computing? On Fri, Jun 19, 2009 at 2:48 AM, Konrad Hinsen konrad.hin...@laposte.netwrote: On 18.06.2009, at 16:47, psf wrote: That is funny... I put a little Clojure plug into the article entitled Trailblazing with Roadrunner in the very same issue of CiSE. Great minds think alike ;-) On 18.06.2009, at 18:16, Michel Salim wrote: Really neat -- hopefully there will be a follow-up that demonstrates Clojure's concurrency features (perhaps contrasting it with Haskell). The problem is that neither one is particularly well suited for the majority of scientific applications, which work best on distributed- memory machines. Of course this may change with the increasing number of cores-per-processor, shared-memory SMP may become fashionable again even for number crunching. Anyway, if anyone has a scientific (in the widest possible sense) application that exploits Clojure's currency, contact me if you want to write about it! Konrad. -- Brett Morgan http://brett.morgan.googlepages.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
