Dennis, I read that piece, and I know we have to start somewhere with
supporting multiprocessing, but focusing on multicore, then moving out seems
ass-backwards. Generalizing concurrency and how to exploit any unit of
computing power (wherever it is), then applying multicore to whatever that
model yields makes more sense, no?

James

"James Smith" <jksmith> wrote in message
news:7221
> Dennis, I read that piece, and I know we have to start somewhere with
> supporting multiprocessing, but focusing on multicore, then moving out
> seems ass-backwards. Generalizing concurrency and how to exploit any unit
> of computing power (wherever it is), then applying multicore to whatever
> that model yields makes more sense, no?
>
> James
>
I see what you are saying (or correct me if I am wrong). You'd rather
design for the specific and generalize from there?

Well, you could do it that way, but there is a high probability that your
solution would be tied to a specific scenario, no?

Design scaleability, although not an explicitly stated goal, would surely be
a basic foundational assumption driving any of Sutter's work, I would
think... Considering who his constituency is...

-d

> Design scaleability, although not an explicitly stated goal, would surely
be
> a basic foundational assumption driving any of Sutter's work, I would
> think... Considering who his constituency is...

What I mean is, we're focusing on multiprocessor development being
introduced by multi-core processors. We need a more generalized solution
which does not focus on multi-core, then optimize that solution for
multi-core. A die can only hold so many cores, but Google's The Dalles
center in Oregon holds 50k boxes I bet. And this brings up an even more
internesting issue than just getting a single Delphi prog to run on multiple
cores: How does one run a debugger on an "application" which makes use of
thousands of boxes at the same time?

Sutter has noodled on all of this I'm sure, but he just focused on
multi-core issues for that particular article.

James

> Sutter has noodled on all of this I'm sure, but he just focused on
> multi-core issues for that particular article.

Well, there are several underlying "issues" which explain this focus:
- multicore hardware is mainstream today: quad-core is consumer level
hardware, pro hardware can do 16-core on a rather low budget
- multicore software doesn't exist, ie. it requires inordinate amount of
time to develop, and apart from a few special cases, it is beyond the
"economically feasible" reach of regular software development tools
- large server farms (like google's) are built with special tasks in
mind, with significant hardware & software budget, so even if software
dev is expensive, it's (relatively) not as bad as for desktop and
entreprise software

In other words, multicore is quite an "urgent" problem today, if you
want to sell hardware and software that makes use of said hardware.

Eric