Boost logo

Boost :

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 : (+33)1 69 15 66 35

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk