Mark J. Reed wrote:
Am I the only one having bad flashbacks to Occam, here?  (Transputing Will
Change Everything!)

My $0.02, FWIW:

Concurrency is surprising.  Humans don't think that way.  And programs
aren't written that way - any program represented as a byte stream is
inherently sequential in nature.

No, you're not the only person thinking Occam ... though I should point out that none of my suggestions are "par" blocks -- a par block made every statement within the block execute in parallel with the other statements in that block (much like a Verilog fork/join pair).

I disagree with the idea that humans don't think concurrently (though more often they think in terms of data dependencies). If I ask someone to boil a kettle + make a cup of tea, and open a can of dogfood to feed the dog, they'd probably sequence the operations such that the kettle comes to the boil while they're feeding the dog ... they'll probably put teabags in the teacups concurrently, too. If you get a group of people together to achieve some goal (e.g. restore an old building) then the first thing they'll do is to partition the work so that team members can work in parallel.

The fact that programs aren't written that way is something that I think needs to change. Though, if done right, then things probably don't need to change too much. A program is not a simple byte stream: it's a random-access array. Multiple cores imply multiple physical program counters. If we assume that the core count will double every 18 months, then three years from now we'll be seeing 32-core machines quite regularly. I wouldn't be surprised to see this grow even faster (Moore's Law doesn't apply to architectural shifts).

Reply via email to