-
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire
gremlin wrote:It's an interesting interview.
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire
"gremlin" <gremlin@roseta ttoo.comwrote in message
news:v5KdncJt27 DKykPVnZ2dnUVZ_ oHinZ2d@comcast .com...I get a not found error:
The requested URL
/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Questionnaire
was not found on this server.
Where is the correct location?
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire
Chris M. Thomasson wrote:The link is the correct location I just tried it."gremlin" <gremlin@roseta ttoo.comwrote in message
news:v5KdncJt27 DKykPVnZ2dnUVZ_ oHinZ2d@comcast .com...>
I get a not found error:
>
The requested URL
/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Questionnaire
was not found on this server.
>
Where is the correct location?
--
Ian Collins.
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire
"Ian Collins" <ian-news@hotmail.co mwrote in message
news:6k8eftF6e1 smU1@mid.indivi dual.net...Hey, it works now! Weird; perhaps temporary server glitch. Who knows.Chris M. Thomasson wrote:>>"gremlin" <gremlin@roseta ttoo.comwrote in message
>news:v5KdncJt2 7DKykPVnZ2dnUVZ _oHinZ2d@comcas t.com...>>
>I get a not found error:
>>
>The requested URL
>/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Questionnaire
>was not found on this server.
>>
>Where is the correct location?
The link is the correct location I just tried it.
;^/
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire
"Chris M. Thomasson" <no@spam.invali dwrote in message
news:GxDDk.1321 7$VS3.2126@news fe12.iad..."Ian Collins" <ian-news@hotmail.co mwrote in message
news:6k8eftF6e1 smU1@mid.indivi dual.net...>>Chris M. Thomasson wrote:>>>>"gremlin" <gremlin@roseta ttoo.comwrote in message
>>news:v5KdncJt 27DKykPVnZ2dnUV Z_oHinZ2d@comca st.com...
>>>http://www.cilk.com/multicore-blog/b...-Questionnaire
>>>>
>>>
>>I get a not found error:
>>>
>>The requested URL
>>/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Questionnaire
>>was not found on this server.
>>>
>>Where is the correct location?
>The link is the correct location I just tried it.
Hey, it works now! Weird; perhaps temporary server glitch. Who knows.
>
;^/
Q: The most important problem to solve for multicore software:
A: How to simplify the expression of potential parallelism.
Humm... What about scalability? That's a very important problem to solve.
Perhaps the most important. STM simplifies expression of parallelism, but
its not really scaleable at all.
I guess I would have answered:
CT-A: How to simplify the expression of potential parallelism __without
sacrificing scalability__.
Q: My worst fear about how multicore technology might evolve:
A: Threads on steroids.
Well, threads on steroids and proper distributed algorihtms can address the
scalability issue. Nothing wrong with threading on steroids. Don't be
afraid!!!!! I am a threading freak, so I am oh so VERY BIASED!!! ;^|
Oh well, that my 2 cents.
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire
Chris M. Thomasson wrote:Well it is running on windows :)"Ian Collins" <ian-news@hotmail.co mwrote in message
news:6k8eftF6e1 smU1@mid.indivi dual.net...>>Chris M. Thomasson wrote:>>>>"gremlin" <gremlin@roseta ttoo.comwrote in message
>>news:v5KdncJt 27DKykPVnZ2dnUV Z_oHinZ2d@comca st.com...
>>>http://www.cilk.com/multicore-blog/b...-Questionnaire
>>>>
>>>>
>>>
>>I get a not found error:
>>>
>>The requested URL
>>/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Questionnaire
>>>
>>was not found on this server.
>>>
>>Where is the correct location?
>The link is the correct location I just tried it.
Hey, it works now! Weird; perhaps temporary server glitch. Who knows.
>
--
Ian Collins.
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire
In article <2GDDk.13223$VS 3.730@newsfe12. iad>, "Chris M. Thomasson"
<no@spam.invali dwrote:
"Chris M. Thomasson" <no@spam.invali dwrote in message
news:GxDDk.1321 7$VS3.2126@news fe12.iad..."Ian Collins" <ian-news@hotmail.co mwrote in message
news:6k8eftF6e1 smU1@mid.indivi dual.net...Chris M. Thomasson wrote:
>"gremlin" <gremlin@roseta ttoo.comwrote in message
>news:v5KdncJt2 7DKykPVnZ2dnUVZ _oHinZ2d@comcas t.com...
>>>
[...]Sounds like Stroustrup wants to minimize extra notation in source codeQ: The most important problem to solve for multicore software:
>
A: How to simplify the expression of potential parallelism.
>
>
Humm... What about scalability? That's a very important problem to solve.
Perhaps the most important. STM simplifies expression of parallelism, but
its not really scaleable at all.
>
I guess I would have answered:
>
CT-A: How to simplify the expression of potential parallelism __without
sacrificing scalability__.
>
>
Q: My worst fear about how multicore technology might evolve:
>
A: Threads on steroids.
>
>
Well, threads on steroids and proper distributed algorihtms can address the
scalability issue. Nothing wrong with threading on steroids. Don't be
afraid!!!!! I am a threading freak, so I am oh so VERY BIASED!!! ;^|
relating to parallel execution, to not have it take on a life of its own.
Exceptions might be an example of minimal impact, where lots of code
doesn't require any explicit mention of handling exceptions.
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore ProustQuestionn aire
On Sep 28, 6:31 am, "Chris M. Thomasson" <n...@spam.inva lidwrote:[...]"Chris M. Thomasson" <n...@spam.inva lidwrote in
messagenews:GxD Dk.13217$VS3.21 26@newsfe12.iad ..."Ian Collins" <ian-n...@hotmail.co mwrote in message
news:6k8eftF6e1 smU1@mid.indivi dual.net...Chris M. Thomasson wrote:
>"gremlin" <grem...@roseta ttoo.comwrote in message
>>news:v5KdncJt 27DKykPVnZ2dnUV Z_oHinZ2d@comca st.com...
>>>http://www.cilk.com/multicore-blog/b...Bjarne-Stroust....Q: The most important problem to solve for multicore software:A: How to simplify the expression of potential parallelism.And what do you think simplifying the expression of potentialHumm... What about scalability? That's a very important
problem to solve. Perhaps the most important. STM simplifies
expression of parallelism, but its not really scaleable at
all.
parallelism achieves, if not scalability?
[...]Q: My worst fear about how multicore technology might evolve:A: Threads on steroids.I'm not too sure what Stroustrup was getting at here, but havingWell, threads on steroids and proper distributed algorihtms
can address the scalability issue. Nothing wrong with
threading on steroids. Don't be afraid!!!!! I am a threading
freak, so I am oh so VERY BIASED!!! ;^|
to write explicitly multithreaded code (with e.g. manual locking
and synchronization ) is not a good way to achieve scalability.
Futures are probably significantly easier to use, and in modern
Fortran, if I'm not mistaken, there are special constructs to
tell the compiler that certain operations can be parallelized.
And back some years ago, there was a fair amount of research
concerning automatic parallelization by the compiler; I don't
know where it is now.
Of course, a lot depends on the application. In my server,
there's really nothing that could be parallelized in a given
transaction, but we can run many transactions in parallel. For
that particular model of parallelization , classical explicit
threading works fine.
--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore ProustQuestionn aire
James Kanze wrote:We along with Fortran and C programmers, can use OpenMP which from myOn Sep 28, 6:31 am, "Chris M. Thomasson" <n...@spam.inva lidwrote:
>>>A: Threads on steroids.>>Well, threads on steroids and proper distributed algorihtms
>can address the scalability issue. Nothing wrong with
>threading on steroids. Don't be afraid!!!!! I am a threading
>freak, so I am oh so VERY BIASED!!! ;^|
I'm not too sure what Stroustrup was getting at here, but having
to write explicitly multithreaded code (with e.g. manual locking
and synchronization ) is not a good way to achieve scalability.
Futures are probably significantly easier to use, and in modern
Fortran, if I'm not mistaken, there are special constructs to
tell the compiler that certain operations can be parallelized.
And back some years ago, there was a fair amount of research
concerning automatic parallelization by the compiler; I don't
know where it is now.
>
limited experience with, works very well.
--
Ian Collins.
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore ProustQuestionn aire
On Sep 27, 5:55 pm, "gremlin" <grem...@roseta ttoo.comwrote:Q: The most important problem to solve for multicore software:
A: How to simplify the expression of potential parallelism.
That is interesting. Especially since the C++0x committee aims at the
very low level of library-based parallelism.---They will not be able
to "simplify the expression of potential parallelism" that way. Not in
C++0x, at least.
Best Regards,
Szabolcs
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire
James Kanze <james.kanze@gm ail.comwrote:
Agreed. I have played around with Occam's expression of Communicating>Q: My worst fear about how multicore technology might evolve:>A: Threads on steroids.>Well, threads on steroids and proper distributed algorihtms
can address the scalability issue. Nothing wrong with
threading on steroids. Don't be afraid!!!!! I am a threading
freak, so I am oh so VERY BIASED!!! ;^|
I'm not too sure what Stroustrup was getting at here, but having
to write explicitly multithreaded code (with e.g. manual locking
and synchronization ) is not a good way to achieve scalability.
Sequential Processes (CSP). I would like to see CSP explored further in
C++.
What I have found so far is
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire
"Szabolcs Ferenczi" <szabolcs.feren czi@gmail.comwr ote in message
news:184232bc-2c49-42ce-8b76-b4c1634b0cb7@x3 5g2000hsb.googl egroups.com...
On Sep 27, 5:55 pm, "gremlin" <grem...@roseta ttoo.comwrote:Q: The most important problem to solve for multicore software:
A: How to simplify the expression of potential parallelism.Your mistaken. The language and the library are highly integrated and dependThat is interesting. Especially since the C++0x committee aims at the
very low level of library-based parallelism.
on one another. Its definitely NOT a purely library based solution. Similar
to the way a POSIX compliant compiler interacts with a PThread library.
C++ is not about simplification as its a low-level systems language.---They will not be able
to "simplify the expression of potential parallelism" that way. Not in
C++0x, at least.
However, due to its low-level nature you can certainly use C++0x to create a
brand new language that attempts to "simplify the expression of potential
parallelism".
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire
"James Kanze" <james.kanze@gm ail.comwrote in message
news:4a3be8d6-4291-4068-9761-3441b9eda047@m7 3g2000hsh.googl egroups.com...
On Sep 28, 6:31 am, "Chris M. Thomasson" <n...@spam.inva lidwrote:[...]"Chris M. Thomasson" <n...@spam.inva lidwrote in
messagenews:GxD Dk.13217$VS3.21 26@newsfe12.iad ..."Ian Collins" <ian-n...@hotmail.co mwrote in message
>news:6k8eftF6e 1smU1@mid.indiv idual.net...
>Chris M. Thomasson wrote:
>>"gremlin" <grem...@roseta ttoo.comwrote in message
>>>news:v5KdncJ t27DKykPVnZ2dnU VZ_oHinZ2d@comc ast.com...
>>>>http://www.cilk.com/multicore-blog/b...Bjarne-Stroust...Q: The most important problem to solve for multicore software:A: How to simplify the expression of potential parallelism.Humm... What about scalability? That's a very important
problem to solve. Perhaps the most important. STM simplifies
expression of parallelism, but its not really scaleable at
all.Take one attempt at simplifying the expression of potential parallelism;And what do you think simplifying the expression of potential
parallelism achieves, if not scalability?
STM. Unfortunately, its not really able to scale. The simplification can
introduce overhead which interfere with scalability. IMVHO, message-passing
has potential. At least I know how to implement it in a way that basically
scales to any number of processors.
[...]Q: My worst fear about how multicore technology might evolve:A: Threads on steroids.Well, threads on steroids and proper distributed algorihtms
can address the scalability issue. Nothing wrong with
threading on steroids. Don't be afraid!!!!! I am a threading
freak, so I am oh so VERY BIASED!!! ;^|That's relative to the programmer. I have several abstractions packaged intoI'm not too sure what Stroustrup was getting at here, but having
to write explicitly multithreaded code (with e.g. manual locking
and synchronization ) is not a good way to achieve scalability.
a library which allows one to create highly scaleable programs using
threads. However, if the programmer is not skilled in the art of
multi-threading, well, then its not going to do any good!
;^(
They have some "caveats". I have implemented futures, and know that a trulyFutures are probably significantly easier to use,
scaleable impl needs to use distributed queuing which does not really follow
true global FIFO. There can be ordering anomalies that the programmer does
not know about, and will bit them in the a$% if some of their algorihtms
depend on certain orders of actions.
No silver bullets in any way shape or form. Automatic parallelizationand in modern
Fortran, if I'm not mistaken, there are special constructs to
tell the compiler that certain operations can be parallelized.
And back some years ago, there was a fair amount of research
concerning automatic parallelization by the compiler; I don't
know where it is now.
sometimes works for a narrow type of algorithm. Usually, breaking up arrays
across multiple threads. But, the programmer is not out of the woods,
because they will still need to manually implement enhancements that are KEY
to scalability (e.g., cache-blocking.). No silver bullets indeed.
Absolutely.Of course, a lot depends on the application. In my server,
there's really nothing that could be parallelized in a given
transaction, but we can run many transactions in parallel. For
that particular model of parallelization , classical explicit
threading works fine.
Comment
-
Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire
"Daniel T." <daniel_t@earth link.netwrote in message
news:daniel_t-C81B2C.13001028 092008@earthlin k.vsrv-sjc.supernews.n et...IMO, CPS is WAY to high level to be integrated into the language. However,James Kanze <james.kanze@gm ail.comwrote:
>>>>Q: My worst fear about how multicore technology might evolve:>>A: Threads on steroids.>>Well, threads on steroids and proper distributed algorihtms
can address the scalability issue. Nothing wrong with
threading on steroids. Don't be afraid!!!!! I am a threading
freak, so I am oh so VERY BIASED!!! ;^|
>I'm not too sure what Stroustrup was getting at here, but having
>to write explicitly multithreaded code (with e.g. manual locking
>and synchronization ) is not a good way to achieve scalability.
Agreed. I have played around with Occam's expression of Communicating
Sequential Processes (CSP). I would like to see CSP explored further in
C++.
you can definitely use C++0x to fully implement Occam and/or CSP. If you
want to use CSP out of the box, well, C++ is NOT for you; period. Keep in
mind, C++ is a low-level systems language.
What I have found so far is
http://www.twistedsquare.com/cppcspv1/docs/index.htmlComment
Comment