Re: [boost] How to structurate libraries ?

Subject: Re: [boost] How to structurate libraries ?
From: David A. Greene (greened_at_[hidden])
Date: 2009-01-19 15:35:27

On Monday 19 January 2009 14:12, Joel Falcou wrote:

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

Did I lose a bit of your message?

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

HPC codes are getting very complex.  Task parallelism is very important.  
Happily, that coincides with the commodity community finally having to grapple 
with parallelism.

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

Sure, a library for some of these special purpose areas could be valuable.

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

The correct answer here is to file a bug with the compiler vendor.  There's no 
way a library is going to be able to keep up with advances in compiler 
technology.  That's because a library-based solution is essentially based on 
pattern-matching while a compiler solution is based on a more powerful 
dataflow and dependence abstraction.

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

No, it isn't.  It's what some of the community uses.  A compiler/software 
performance paper that compares results to gcc is next to useless.

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

That approach seems backward to me.  Why would one try to figure out how to 
structure a library befone one even knows what's in it?

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

Ok, so you found a good example where a compiler produced suboptimal code but 
admitted it would be readily vectorizable automatically.  Again, the answer is 
to fix the compiler.

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

Ok, thanks for the info.

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

We're talking about Boost here.  Cell libraries for specific development 
communities could be very useful.  But I don't think it's appropriate for 
Boost.

> > 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 guess I need to see more of what you mean.  I still don't have a good 
picture of what this would provide beyond current or near-future compiler 
capabilities.

Doesn't gcc provide such extensions already?

                                                -Dave