Concurrent Futures

Joshua Gargus schwa at fastmail.us
Tue Oct 30 23:29:44 UTC 2007


On Oct 30, 2007, at 3:28 PM, Igor Stasenko wrote:

> On 30/10/2007, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
>> On 10/30/07, Igor Stasenko <siguctua at gmail.com> wrote:
>>> which is _NOT_ concurrent
>>> computing anymore, simple because its not using shared memory,  
>>> and in
>>> fact there is no sharing at all, only a glimpse of it.
>>
>> Huh?  What does sharing have to do with concurrency?  The one and  
>> only
>> thing shared state has to do with concurrency is the desire to speed
>> it up, i.e. a premature optimization.  That's it.
>>
> Look. A current multi-core architecture uses shared memory. So the
> logical way how we can utilize such architecture at maximum power is
> to build on top of it.
> Any other (such as share nothing) introducing too much noise on such
> architectures.

It is unreasonable to assume that ad-hoc, fine-grained sharing of  
objects between processors will give you the fastest performance on  
the upcoming machines with 100s and 1000s of cores.  What about  
memory locality and cache coherency?  It is not cheap to juggle an  
object between processors now, and it will become more expensive as  
the number of cores increase.

In a different email in the thread, you made it clear that you  
consider distributed computing to be a fundamentally different beast  
from concurrency.  Intel's chip designers don't see it this way.  In  
fact, they explicitly formulate inter-core communication as a  
networking problem.  For example, see http://www.intel.com/technology/ 
itj/2007/v11i3/1-integration/4-on-die.htm (I've better links in the  
past, but this is the best that I could quickly find now).

I think that your proposal is very "clever", elegant, and fun to  
think about.  But I don't see what real problem it solves.  It  
doesn't help the application programmer write correct programs (you  
delegate this responsibility to the language/libraries).  It doesn't  
make code at maximum speed, since it doesn't handle memory locality.   
In short, it seems like too much work to do for such uncertain  
gains... I think that we can get farther by examining some of our  
assumptions before we start, and revising or goals accordingly.

Cheers,
Josh



>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>




More information about the Squeak-dev mailing list