"Everything has tradeoffs. One more example was when Martin explained how he was able to get a 10x performance boost by pinning a JVM to each socket in a server, then pinning that JVM's memory to the RAM sockets closest to that CPU socket. Then he carefully setup shared memory message passing via burning one core on each CPU to monitor the queues, and moving messages only in the directions directly supported by the Hyper Transport bus. Once again, that's amazing...once again I've never needed that to ship a product. "
This is absolutely fascinating to me. The ability to do this sort of thing is a tradeoff from using abstractions (threads, OS threads, Java threads) that closely match or can be massaged to match or 'have sympathy' for the hardware realities. I think this can get lost when we stray too far. On Fri, Mar 14, 2014 at 1:46 PM, Gary Trakhman <gary.trakh...@gmail.com>wrote: > > > > On Fri, Mar 14, 2014 at 1:35 PM, Raoul Duke <rao...@gmail.com> wrote: > >> i am probably out of my depth here, i do not have extensive real-world >> experience with the various ways to approach parallelism and >> concurrency (to be distinguished of course), more run of the mill >> stuff. so if i sound like i'm missing your point or am clueless i ask >> for your patience :-) >> >> > What's the sequential fraction of an arbitrary erlang program, can you >> even >> > know (I don't know erlang, so I'm honestly asking)? >> >> who cares? or rather, each person has to only care about their own >> program & situation. maybe their stuff fits erlang. maybe it fits >> better with something else e.g. LMAX. it. all. depends. :-) >> >> everything depends on context. Martin's talk even included the part >> where he bemoaned that people don't just stay single-threaded and fix >> their crappy code first. running to concurrency and parallelism is >> often a cop-out the way i hear him. that could be seen as arguing >> 'against' erlang. >> >> so there are places where your program is mostly sequential and things >> like "does the GC act like a GIL" do not matter as much as the >> situation where you are trying to be more concurrent + parallel but >> not distributed. in those sequential situations, maybe erlang becomes >> a square peg for the round hole. (although i personally, through >> suffering as a maintenance programmer, am a *huge* lover of the >> recursive single assignment "turn" based approach to things, and i >> love clojure's idea of having a consistent view of the world; most OO >> people shoot me in the foot a year after they've left the company, >> with their crappy macaroni code.) >> >> > Shared memory pretty darn convenient, and we don't have hundred-core+ >> boxes >> > yet. >> >> i'm confused in that i thought you wrote shared memory ~= message >> passing. so why talk about shared memory when that is a lie? just like >> Martin said, RAM is a lie. why not realize everything is really >> message passing in the long run, model it as such, understand the >> issues as such? i do not have a chip on my shoulder about this, i'm >> just sounding it out / exploring the thought. >> >> > Well, yes it's a lie, it's an abstraction, we love those as programmers > :-). The question is, is it worth the trouble and under what conditions? > > IMO, we don't understand message passing well enough to be great at > programming or characterizing distributed concurrent systems. I wonder how > this changes when you're writing erlang. I would guess that certain > classes of programs are really easy to write in erlang compared to other > languages, and I wonder at what cost? > > Clojure appealed to me because I was studying computer architecture in > grad school, and I think it has a great answer for cores<100 shared-memory > concurrency, but at some point I acknowledge that might not be good enough. > > I'm very interested in Netkernel's approach, actually: > http://www.1060research.com/products/ > It sort of marries the notion of immutable data with distribution and > message passing. URLs as pointers. > > > >> sincerely. >> >> -- >> 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/d/optout. >> > > -- 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/d/optout.
