-
-
Re: Interesting article about concurrent programming, any thoughts?
"Sonoman" <billgates@micr osoft.com> wrote...[color=blue]
> http://www.gotw.ca/publications/concurrency-ddj.htm[/color]
Is this a write-only newsgroup?
-
Re: Interesting article about concurrent programming, any thoughts?
* Sonoman:[color=blue]
>
> http://www.gotw.ca/publications/concurrency-ddj.htm[/color]
Herb does a good job of convinving the socially bound technicians
(non-engineers, non-scientists, non-thinkers) of a self-evident
historical fact. Namely that we'll increasingly be doing parallel and
distributed processing, both hardware and software. The presentation is
very well matched to what I presume is the intended audience.
Minus: the graph of CPU-speeds presented seems to be exaggerated (at
least visually the drawn graph doesn't seem to be anywhere near a best
fit to the data) -- to make a point that is in all likehood true.
With respect to C++ the now 60 years of historical precedent of ever
more parallelism doesn't mean very much, just, AFAICS, (1) that it's
over time to get some standardized threading support as other languages
have enjoyed the last few decades, and (2) that C++ and other
conventional thread-viewpoint languages will in all likelyhood continue
their migration toward pure support roles. I wish Herb would write an
article about those aspects. That kind of thing is what he excels at.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Comment
-
Re: Interesting article about concurrent programming, any thoughts?
Alf P. Steinbach wrote:
[color=blue]
> Herb does a good job of convinving the socially bound technicians
> (non-engineers, non-scientists, non-thinkers) of a self-evident
> historical fact. Namely that we'll increasingly be doing parallel and
> distributed processing, both hardware and software. The presentation is
> very well matched to what I presume is the intended audience.
>
> Minus: the graph of CPU-speeds presented seems to be exaggerated (at
> least visually the drawn graph doesn't seem to be anywhere near a best
> fit to the data) -- to make a point that is in all likehood true.
>
> With respect to C++ the now 60 years of historical precedent of ever
> more parallelism doesn't mean very much, just, AFAICS, (1) that it's
> over time to get some standardized threading support as other languages
> have enjoyed the last few decades, and (2) that C++ and other
> conventional thread-viewpoint languages will in all likelyhood continue
> their migration toward pure support roles. I wish Herb would write an
> article about those aspects. That kind of thing is what he excels at.[/color]
From a message of mine in clc++m:
I think what we really need for concurrency so as to take advantage of
multicore processors in straight-forward applications (that is our usual
applications that have no reason to have concurrent design), is a safe
language level support in the style of OpenMP (which as far as I know is
not safe in the sense that it is "hard-coded" and does not throw
exceptions in case of errors for example).
Perhaps the "safe part", should be additional compiler checks on such
multithreading declarations.
OpenMP: http://www.openmp.org
VC++ 2005 will support OpenMP 2.
--
Ioannis Vranos
Comment
Comment