On 31/10/2007, Joshua Gargus schwa@fastmail.us wrote:
On Oct 30, 2007, at 3:28 PM, Igor Stasenko wrote:
On 30/10/2007, Jason Johnson jason.johnson.081@gmail.com wrote:
On 10/30/07, Igor Stasenko siguctua@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).
Then i wonder, why they don't drop the idea of having shared memory at all? Each CPU then could have own memory, and they could interact by sending messages in network-style fashion. And we then would write a code which uses such architecture in best way. But while this is not true, should we assume that such code will work faster than code which 'knows' that there is a single shared memory for all CPUs and uses such knowledge in best way?
I think that your proposal is very "clever", elegant, and fun to think about.
Thanks :)
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.
I thought that goals was pretty clear. We have a single image. And we want to run multiple native threads upon it to utilize all cores of multi-core CPU's. What we currently have is a VM, which can't do that. So, i think, any other , even naively implemented, which can do, is better than nothing. If you have any ideas how such VM would look like i'm glad to hear.