On Sat, Apr 27, 2013 at 11:23 PM, Yves S. Garret <yoursurrogate...@gmail.com > wrote:
> I'll take a blind stab at this and say that Erlang might actually do > more poorly, unless the chip's interchip message passing is taken > advantage of by Erlang. If there's a separate piece of hardware > taking on the role of being the messenger, having to waste computer > cycles to send a message isn't terribly efficient. > > > On Sat, Apr 27, 2013 at 11:17 PM, Cedric Greevey <cgree...@gmail.com>wrote: > >> On Sat, Apr 27, 2013 at 11:13 PM, Yves S. Garret < >> yoursurrogate...@gmail.com> wrote: >> >>> How would this compare to Erlang? >>> >>> >>> On Sat, Apr 27, 2013 at 10:51 PM, Cedric Greevey <cgree...@gmail.com>wrote: >>> >>>> https://en.wikipedia.org/wiki/Intel_MIC >>>> >>>> 50+ cores?! Clojure will leave every other language in the dust on >>>> something like that, thanks to its inherently scaleable concurrency >>>> constructs. Try writing a 50-threaded Java application without getting >>>> deadlocks all over the place, or cheating and using very coarse-grained >>>> locks (have fun with the task manager showing 2% CPU utilization when your >>>> app is running full-bore!). >>>> >>>> If big, 32-bit addressing spaces were what made automatic memory >>>> management really begin to come into its own (and with it, Java), then it's >>>> doubtless 50-core machines that will make automatic concurrency management >>>> really begin to come into its own. >>>> >>> >> Erlang might also do well on such a machine. The actor model likely >> involves more communication among the cores to get full utilization, but >> then, the page describes some sort of message-passing system among the >> cores on MIC, so ... >> > As always with these things, it's likely to depend on the shape of the problem. Many things (simulations, notably) fit very nicely into an actor model (and using Clojure agents would still involve a lot of message-passing -- all the send/send-off machinery would be busy). Others parallelize easily even with crude locking primitives like Java's -- homogeneous number-crunching such as giant vector or matrix operations can be chunked into several times as many pieces as there are cores and fed into a work-stealing queue system. Still others neither require lots of message passing from agent to agent in the data-flow, nor are easily broken into silos that crunch in near-isolation (and are suited to pmap type concurrency, or slightly more sophisticated methods meant to avoid idling some CPUs if work units are variable in size), but instead involve processes that work with a shared data structure but don't directly need to message each other for the most part. Those ones are a strong fit to Clojure's STM plus many core machines. -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
