[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

C++ inventor Bjarne Stroustrup answers the Multicore Proust Questionnaire

20 Answers

asm23

9/28/2008 3:40:00 AM

0

Ian Collins

9/28/2008 4:12:00 AM

0

Chris M. Thomasson wrote:
> "gremlin" <gremlin@rosetattoo.com> wrote in message
> news:v5KdncJt27DKykPVnZ2dnUVZ_oHinZ2d@comcast.com...
>> http://www.cilk.com/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Que...
>>
>
> 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.

Chris M. Thomasson

9/28/2008 4:12:00 AM

0

"gremlin" <gremlin@rosetattoo.com> wrote in message
news:v5KdncJt27DKykPVnZ2dnUVZ_oHinZ2d@comcast.com...
> http://www.cilk.com/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Que...

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?

Chris M. Thomasson

9/28/2008 4:22:00 AM

0

"Ian Collins" <ian-news@hotmail.com> wrote in message
news:6k8eftF6e1smU1@mid.individual.net...
> Chris M. Thomasson wrote:
>> "gremlin" <gremlin@rosetattoo.com> wrote in message
>> news:v5KdncJt27DKykPVnZ2dnUVZ_oHinZ2d@comcast.com...
>>> http://www.cilk.com/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Que...
>>>
>>
>> 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

9/28/2008 4:24:00 AM

0

Chris M. Thomasson wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:6k8eftF6e1smU1@mid.individual.net...
>> Chris M. Thomasson wrote:
>>> "gremlin" <gremlin@rosetattoo.com> wrote in message
>>> news:v5KdncJt27DKykPVnZ2dnUVZ_oHinZ2d@comcast.com...
>>>> http://www.cilk.com/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Que...
>>>>
>>>>
>>>
>>> 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.

Chris M. Thomasson

9/28/2008 4:31:00 AM

0


"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:GxDDk.13217$VS3.2126@newsfe12.iad...
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:6k8eftF6e1smU1@mid.individual.net...
>> Chris M. Thomasson wrote:
>>> "gremlin" <gremlin@rosetattoo.com> wrote in message
>>> news:v5KdncJt27DKykPVnZ2dnUVZ_oHinZ2d@comcast.com...
>>>> http://www.cilk.com/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Que...
>>>>
>>>
>>> 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.

blargg.h4g

9/28/2008 5:13:00 AM

0

In article <2GDDk.13223$VS3.730@newsfe12.iad>, "Chris M. Thomasson"
<no@spam.invalid> wrote:

> "Chris M. Thomasson" <no@spam.invalid> wrote in message
> news:GxDDk.13217$VS3.2126@newsfe12.iad...
> > "Ian Collins" <ian-news@hotmail.com> wrote in message
> > news:6k8eftF6e1smU1@mid.individual.net...
> >> Chris M. Thomasson wrote:
> >>> "gremlin" <gremlin@rosetattoo.com> wrote in message
> >>> news:v5KdncJt27DKykPVnZ2dnUVZ_oHinZ2d@comcast.com...
> >>>>
http://www.cilk.com/multicore-blog/bid/6703/C-Inventor-Bjarne-Stroustrup-answers-the-Multicore-Proust-Que...
[...]
> 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!!! ;^|

Sounds like Stroustrup wants to minimize extra notation in source code
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.

James Kanze

9/28/2008 7:35:00 AM

0

On Sep 28, 6:31 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> "Chris M. Thomasson" <n...@spam.invalid> wrote in
> messagenews:GxDDk.13217$VS3.2126@newsfe12.iad...
> > "Ian Collins" <ian-n...@hotmail.com> wrote in message
> >news:6k8eftF6e1smU1@mid.individual.net...
> >> Chris M. Thomasson wrote:
> >>> "gremlin" <grem...@rosetattoo.com> wrote in message
> >>>news:v5KdncJt27DKykPVnZ2dnUVZ_oHinZ2d@comcast.com...
> >>>>http://www.cilk.com/multicore-blog/bid/6703/C-Inventor-Bjar.......

[...]
> 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:james.kanze@gmail.com
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

Ian Collins

9/28/2008 7:46:00 AM

0

James Kanze wrote:
> On Sep 28, 6:31 am, "Chris M. Thomasson" <n...@spam.invalid> 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.

Szabolcs Ferenczi

9/28/2008 2:46:00 PM

0

On Sep 27, 5:55 pm, "gremlin" <grem...@rosetattoo.com> wrote:
> http://www.cilk.com/multicore-blog/bid/6703/C-Inventor-Bjar......

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