On 01/11/2007, Jecel Assumpcao Jr jecel@merlintec.com wrote:
Joshua Gargus wrote:
Thanks for this interesting list of your relevant work. I look forward to any other thoughts that you could add to this thread, in particular to provide a reality-check where your real-world experience disagrees with my theoretical understanding :-)
Sadly, my practical experience is far more limited than it should be, given all the years I have spent on this, since often a project would be abandoned after only preliminary results in favor of a "much better" one.
One thing that I haven't tried yet is making messages to futures return new futures instead of blocking (which I understood from this dicussion to be the E way). I had thought about it but imagined it might lead to ever growing graphs of pending messages with no actual work being done. I see now that in practice the overhead might be comparable to what my deadlock detector had. This would probably also make my "tail send" optimization mostly useless, which is a good thing.
In all my projects I took a very conservative path regarding blocks: I simply defined "." as a kind of barrier where all previous instructions must finish before any of the following instructions can be started. Since I was getting a lot of parallelism even with this I didn't worry too much about it and this allowed code like this to work just fine:
| a | a := 1. 1 to: 20 do: [ :i | a := a + i ]. a := a - 1. 1 to: 20 do: [ :x | a := a - x ]. ^ a
Having "." as a barrier is unecessary in the code below, but at least the results will be correct even if at a much reduced performance:
| a b | a := (1 to: 20) collect: [ :i | i * i ]. b := (1 to: 20) collect: [ :x | x + 7 ]. ^ a + b
It isn't very hard for the compiler to know which is the case for each example.
Yes, without barriers the following code simply will not work as desired:
| a b | a := (1 to: 20) collect: [ :i | i * i ]. Interval removeSelector: #collect: . b := (1 to: 20) collect: [ :x | x + 7 ]. ^ a + b
squeak-dev@lists.squeakfoundation.org