Re: [boost] How to structurate libraries ?

Subject: Re: [boost] How to structurate libraries ?
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2009-01-19 15:12:47

> Did I say it was done?  A compiler is not going to be able take complex 
> pointer-chasing code and parallelize it automatically.  With some of the new 
> parallel languages it has a better chance but in most cases the information 
> just isn't there.  But your library didn't strike me as supporting general 
> parallelization along the lines of futures or such things.  Structuring 
> high-level parallelism has almost[1] nothing to do with the minute machine 
> details you've talked about so far.
>   
Then again I didn't say it was meant to, I presented it as a building 
blocks for DEVELOPERS needing to write code at this level of abstraction 
on this kind of hardware.

> You're taking this way too personally.  I'm not suggesting that researchers 
> close up shop.  I'm suggesting that researchers should make sure they're 
> tackling the correct problems.  
Sorry if I sound like this but since I started this thread it seems that 
half the community
> My experience tells me the problem is not the use of vector instructions[2] but rather lies in how to express high-level, task-based parallelism
>   
Except maybe 90% of current HPC needs are simple data-parallelism. But 
of course, I may be wrong yet again as the following trend showed.

> [2] Except for special-purpose fields like graphics where a general-purpose 
> compiler probably hasn't been given the smarts because it's not worth it to 
> the general-purpose compiler vendor.
>   
graphics, Computer Vision, physics, cryptography etc ... you name it.
If i have a machien with X level of hadrware parallelism, I want to take 
advantage of all of them as they fit the algorithm.
> Because gcc is not an optimizing compiler.  That's not its focus.  It's 
> getting better but I would encourage you  to explore compilers from Intel, 
> PGI and Pathscale.  All of these easily beat gcc in terms of performance.
>   
They beat gcc for sure, except they still don't beat hand written code 
in some simple case.
Let ICC optimize a 2D convolution kernel, and it'll still be 5x too slow 
even the optimisation
required to do it is perfecly doable by a machine.
> Probably the biggest mistake academic researchers do is compare their results 
> to gcc.  It's just not a valid comparison.
>   
It's just what the rest of the community use anyway ...
> Well, one would expect the author of a library to enumerate what it can do.  
> If you have these kinds of constructs, that's great!
>   
*points at thread title*
The fact the thread was about structuring them *before* the proposal may 
be a good hint.

> Your claim was that compilers would not be able to handle it.  I countered the 
> claim.  I'm interested in any other examples you have.
>   
As I said : convolution kernel.
> I can't find a reference for HTA specifically, but my guess from the name of 
> the concept tells me that it's probably already covered elsewhere, as you say.  
>   
David Padau is the key name.
> A Cell-based development library wouldn't be terribly useful.  Something that 
> provided the same idioms across architectures would be.  As you say, the 
> architecture abstraction is important.
>   
Go say that to half the video game comapny that still use the Cell as a 
strange PPC and neglect the SPEs
> I look forward to it.  I think there's value here but we should figure out the 
> focus and drop any unnecessary things.
The focus was what I said : homogene interface to SIMD extensions no 
more no less.
I never came and told I want to tackle down C++ parallel programming 
with only this library.

I consider this thread closed as it won't go further than slapping 
academic reference on this and that without actual content.
20+ posts of off topic is already enough. I have my answer from post 4. 
Thanks.

-- 
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : [phone]