Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire

Reply
Thread Tools

Re: C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire

 
 
Ian Collins
Guest
Posts: n/a
 
      09-28-2008
Chris M. Thomasson wrote:
> "gremlin" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed). ..
>> 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.

--
Ian Collins.
 
Reply With Quote
 
 
 
 
Chris M. Thomasson
Guest
Posts: n/a
 
      09-28-2008
"gremlin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed). ..
> 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?

 
Reply With Quote
 
 
 
 
Chris M. Thomasson
Guest
Posts: n/a
 
      09-28-2008
"Ian Collins" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Chris M. Thomasson wrote:
>> "gremlin" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed). ..
>>> 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.

;^/

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      09-28-2008
Chris M. Thomasson wrote:
> "Ian Collins" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Chris M. Thomasson wrote:
>>> "gremlin" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed). ..
>>>> 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.
>

Well it is running on windows

--
Ian Collins.
 
Reply With Quote
 
Chris M. Thomasson
Guest
Posts: n/a
 
      09-28-2008

"Chris M. Thomasson" <(E-Mail Removed)> wrote in message
news:GxDDk.13217$(E-Mail Removed)...
> "Ian Collins" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Chris M. Thomasson wrote:
>>> "gremlin" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed). ..
>>>> 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.

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      09-28-2008
On Sep 28, 6:31 am, "Chris M. Thomasson" <(E-Mail Removed)> wrote:
> "Chris M. Thomasson" <(E-Mail Removed)> wrote in
> messagenews:GxDDk.13217$(E-Mail Removed)...
> > "Ian Collins" <(E-Mail Removed)> wrote in message
> >news:(E-Mail Removed)...
> >> Chris M. Thomasson wrote:
> >>> "gremlin" <(E-Mail Removed)> wrote in message
> >>>news:(E-Mail Removed) om...
> >>>>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.


And what do you think simplifying the expression of potential
parallelism achieves, if not 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!!! ;^|


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.

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:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      09-28-2008
James Kanze wrote:
> On Sep 28, 6:31 am, "Chris M. Thomasson" <(E-Mail Removed)> wrote:
>
>> 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.
>

We along with Fortran and C programmers, can use OpenMP which from my
limited experience with, works very well.

--
Ian Collins.
 
Reply With Quote
 
Chris M. Thomasson
Guest
Posts: n/a
 
      09-28-2008

"James Kanze" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Sep 28, 6:31 am, "Chris M. Thomasson" <(E-Mail Removed)> wrote:
> > "Chris M. Thomasson" <(E-Mail Removed)> wrote in
> > messagenews:GxDDk.13217$(E-Mail Removed)...
> > > "Ian Collins" <(E-Mail Removed)> wrote in message
> > >news:(E-Mail Removed)...
> > >> Chris M. Thomasson wrote:
> > >>> "gremlin" <(E-Mail Removed)> wrote in message
> > >>>news:(E-Mail Removed) om...
> > >>>>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.


> And what do you think simplifying the expression of potential
> parallelism achieves, if not scalability?


Take one attempt at simplifying the expression of potential parallelism;
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!!! ;^|


> 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.


That's relative to the programmer. I have several abstractions packaged into
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!

;^(




> Futures are probably significantly easier to use,


They have some "caveats". I have implemented futures, and know that a truly
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.




> 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.


No silver bullets in any way shape or form. Automatic parallelization
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.




> 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.


Absolutely.

 
Reply With Quote
 
Chris M. Thomasson
Guest
Posts: n/a
 
      09-28-2008
"Daniel T." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)-sjc.supernews.net...
> James Kanze <(E-Mail Removed)> wrote:
>
>> > 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++.


IMO, CPS is WAY to high level to be integrated into the language. However,
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.html


 
Reply With Quote
 
Szabolcs Ferenczi
Guest
Posts: n/a
 
      09-28-2008
On Sep 28, 7:00*pm, "Daniel T." <(E-Mail Removed)> wrote:

> [...]
> Agreed. I have played around with Occam's expression of Communicating
> Sequential Processes (CSP). I would like to see CSP explored further in
> C++.
>
> What I have found so far ishttp://www.twistedsquare.com/cppcspv1/docs/index.html


Well, CSP is a very nice language concept and OCCAM is an interesting
instance of it.

However, CSP is not matching very well with objects and shared
resources. If you want to map processes in the CSP sense to objects,
you will end up with what you would call single threaded object. The
object has its private state space and any request comes via events.
The object can await several potential event but whenever one or more
event is applicable, it selects one non-deterministically and performs
the corresponding action on its own private data space.

It is worth mentioning that at the time CSP was published, there
appeared another elegant language concept: Distributed Processes (DP).
This is something that can be mapped very naturally to objects and
gives you high level of potential parallelism. In DP an object starts
its own thread which operates on its own data space and other objects
can call its methods asynchronously. The initial thread and the called
methods then are executed in an interleaved manner. If the initial
thread finishes, the object continues to serve the potentially
simultaneous method calls, i.e. it becomes a (shared) passive object.
http://brinch-hansen.net/papers/1978a.pdf

Well, both language proposals are much higher level with respect to
parallelism than what is planned into the new brave C++0x.

Best Regards,
Szabolcs
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: C++ inventor Bjarne Stroustrup answers the Multicore ProustQuestionnaire Szabolcs Ferenczi C++ 1 09-28-2008 08:51 PM
FA: (UK Only) Book: "The C++ Programming Language" 3rd Ed by Bjarne Stroustrup Mike C++ 1 09-20-2006 08:46 AM
Do You Want The Book C++ Programming Language By Bjarne Stroustrup? devser2006@gmail.com C++ 3 06-21-2006 06:24 PM
Has Bjarne Stroustrup finished his XTI(eXtended Type Information)? goer C++ 0 11-02-2005 02:59 AM
Bjarne Stroustrup says Teddy C++ 13 06-12-2005 11:07 AM



Advertisments