<div dir="ltr">On Fri, Mar 8, 2013 at 12:15 PM, Ron Frazier (ALE) <span dir="ltr"><<a href="mailto:atllinuxenthinfo@techstarship.com" target="_blank">atllinuxenthinfo@techstarship.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The go language is supposed to be good for parallel processing but I don't know exactly how it works.<br>
</blockquote><div><br></div><div>I've been learning Go as a hobby for a few months and will comment with regard to this post and the original post (OP), although the OP doesn't mention Go. I find Go's concurrency support to be maybe the most fun and significant programming language feature I have seen in a long time. I'll add links for folks who want more info.<br>
</div><div><br>Rob Pike, who is maybe most closely associated with the concurrency support in Go, goes to great lengths to emphasize that parallelism and concurrency are different concepts.<br><br> <a href="http://talks.golang.org/2012/concurrency.slide#1">http://talks.golang.org/2012/concurrency.slide#1</a><br>
<br>The problem the OP is talking about is stated in terms of parallelism, because you want simultaneous execution of different parts of the problem, but Go's features are presented in terms of concurrency, and you get the ability to easily do parallelism as a side effect of concurrent programming.<br>
</div></div><br></div><div class="gmail_extra">In the case the OP mentions, the strategy for attacking the problem using idiomatic Go program design would be something like this:<br><br></div><div class="gmail_extra"> * decompose the problem into sequential sequences that need to be done<br>
</div><div class="gmail_extra"> These will become your goroutines.<br></div><div class="gmail_extra"><br> <a href="http://golang.org/ref/spec#Go_statements">http://golang.org/ref/spec#Go_statements</a><br> <a href="http://tour.golang.org/#62">http://tour.golang.org/#62</a><br>
<br></div><div class="gmail_extra"> * identify communication points between the sequences<br></div><div class="gmail_extra"> These will be places where the goroutines send values through channels.<br><br> <a href="http://golang.org/ref/spec#Channel_types">http://golang.org/ref/spec#Channel_types</a><br>
<a href="http://tour.golang.org/#63">http://tour.golang.org/#63</a><br> <a href="http://golang.org/doc/codewalk/sharemem/">http://golang.org/doc/codewalk/sharemem/</a><br><br></div><div class="gmail_extra"> * share memory for efficiency but pass "ownership" through channels<br>
<br></div><div class="gmail_extra">Finally, you'd need a trick I use to get real parallelism on many versions of the go runtime. It schedules goroutines onto O.S. processes. Tell the runtime to use more than one process, or you'll have concurrency without parallelism. See lines 75 and 79 below.<br>
<br> <a href="https://github.com/ecashin/go-getting/blob/master/bakery.go#L75">https://github.com/ecashin/go-getting/blob/master/bakery.go#L75</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">But so many people do this in scientific computing that there are probably libraries that do it faster than you'd be able to code up in less than months. I am assuming the OP is motivated by the desire to learn how to implement stuff like that, not just to do matrix math in parallel.<br>
<br></div><div class="gmail_extra">-- <br> Ed Cashin <<a href="mailto:ecashin@noserose.net">ecashin@noserose.net</a>><br> <a href="http://noserose.net/e/">http://noserose.net/e/</a><br> <a href="http://www.coraid.com/">http://www.coraid.com/</a>
</div></div>