Re: [boost] [OT?] SIMD and Auto-Vectorization (was Re: How to structurate libraries ?)

Subject: Re: [boost] [OT?] SIMD and Auto-Vectorization (was Re: How to structurate libraries ?)
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2009-01-18 08:50:58

Dean Michael Berris a écrit :
> Please don't misunderstand that I'm disagreeing with you here because
> I do agree that there is a need to address the parallelism problem
> when implementing considerably demanding solutions at a level where
> you don't really have to worry about the architecture below on which
> the code you're running on is like. However given the reality of the
> situation with a myriad of available platforms on which to compile/run
> C++, the pressure from both sides of the equation (library writers and
> tool developers on one side, hardware vendors on the other) to come up
> with a solution is immense -- especially since the industry has got to
> adapt to it sooner than later. ;-)
>   
We agree then.
> ... I think there is a market for precisely this kind of thing/work
> now -- helping domain experts be able to recognize and utilize the
> inherent parallelism in their solutions and the tools they are using.
> :-)
>   
Best is to have them benefit of parallelism without them knowing about 
it really.
> Libraries OTOH are more components to me rather than tools. Maybe I'm
> being too picky with terms, but if you meant libraries to be tools,
> then I feel that simply doesn't work with how my brain is wired. It
> doesn't make you wrong, but it just doesn't feel right to me. ;-)
>   
Beware that Embedded DSL are nto more than DSL in disguise
inside a library, hence the confusion I keep between tools and libraries.
> I think I understand what you mean, but I don't think it's a failure
> of the libraries that they're not known/used by the people doing the
> programming. Much like how you can't blame the nailgun if a carpenter
> didn't know about it that's why he's still using traditional hammers
> and nails.
>
>   
My point was : it is not that easy to say to people "use X".
> True, but libraries also require that users write code that actually
> use the library. If the users already had code that didn't use your
> library, how is it an advantage if they can get the auto-vectorization
> from a future version of a compiler anyway without having to butcher
> their code to use your library? And what if they find a bug in the
> code using the library or (god forbid) find a bug in the library?
>   
Same can be said for any library out there. What if tomorrow new C++ 
compiler will extract code from source and built top-notch threads from 
it ? Should we prevent people to use Boost.Threads from now ?
> Actually, DSELs require that you write code in the domain language --
> and here is where the problem lies
Well, if parallelism is outsourced behind the scene, it's not a problem.
> If this were the case then maybe just having this DSEL may be good to
> give to parallelism-savvy C++ programmers, but not necessarily still
> the domain experts who will be doing the writing of the
> domain-specific logic. Although you can argue that parallel
> programming is a domain in itself, in which case you're still not
> bridging the gap between those that know about parallel programming
> and the other domain experts.
>   
Parallel programming is a domain in itself but not a domain for user but 
for tool writer.
A user domain si things like math, finance, physics, anything. We agree
> Yes, not all platforms are Intel platforms, but I don't know if you've
> noticed yet that Intel compilers even create code that will run on AMD
> processors -- yes, even SSE[0..3] -- as per their product
> documentation. If your target is CotS machines, I think Intel/GCC is
> your best bet (at least in x84_64). I haven't dealt with other
> platforms though aside from Intel/AMD, but it's not unreasonable to
> think that since everybody's moving the direction of leveraging and
> exploiting parallelism in hardware, that the compiler vendors will
> have to compete (and eventually get better) in this regard.
>   
Well, we can't let Altivec and its offspring on the side of the road. 
Cell processor use it and I
considering the Cell as a simili-COtS as a PS3 cost something like only 
half a kidney.
I don't target COTS or not-CotS, my goal is cover the basics and the 
SIMD absics involves old Motorola enabled PPC and Intel machines.
So the strict minimum is Altivec+SSE flavors. I hope that one day (AVX 
v2), both will converge tough.
> Why do I get the feeling that you're saying:
>
>  compiler writing != software engineering
>
> ? :-P
>   
No I mean that *I* feel more confortabel writing stuff on this side of 
the compiler than on the other ;)
> Anyway, I think if you're looking to contribute to a compiler-building
> community, GCC may be a little too big (I don't want to use the term
> advanced, because I haven't bothered looking at the code of the GCC
> project) but I know Clang over at LLVM are looking for help to finish
> the C++ implementation of the compiler front-end. From what I'm
> reading with Clang and LLVM, it should be feasible to write
> language-agnostic optimization algorithms/implementations just dealing
> with the LLVM IR.
>   
Well, as I work like half a miel from Albert Cohen office, I'll 
certainly have a discussion about Clang someday ;)
The C++->C++ tools is on my todo task list, but not for  now as I think 
DSEL in C++ still have untapped ressources.
> In that case, I think that kind of library (DSEL) would be nice to
> have -- especially to abstract the details of expressing parallelism
> in general a the source code level.
>
>   
Except it is like ... friggin hard ?
My stance is to have applciation domain specific library that hide all 
parallelism tasks by
relying on small scale parallel library themselves like Thread or my 
proposition.
> Nice! I would agree that something like *that* is appropriate as a domain-specific language which leverages parallelism in the details of
> the implementation.
>   

> I however think also that there are some details that would be nice to
> tackle at the appropriate layer -- SIMD code construction is, well,
> meant to be at the domain of the compiler (as far as SSE or similar
> things go). OpenCL is meant to be an interface the hardware and
> software vendors are moving towards supporting for a long time coming
> (at least what I'm reading from the press releases) so I'm not too
> worried about the combinatorial explosion of architectures and
> parallelism runtimes.
>   
Except some people (like one of the poster in the previosu thread) daily 
deals with code that need this level of abstraction and not more.
Hence the rationale behind "Boost.SIMD"
> I agree completely, but I'm afraid if the DSEL is for expressing
> parallelism in C++, the goal of "giving domain experts tools that knew
> about the parallelism" wouldn't be met readily. For C++ developers
> that want to leverage parallelism in general sure, but I don't think
> I'd be particularly compelled to use a SIMD-only DSEL.
>   
I think we can't just wake up and say "ok today I just sole the 
parallelism problem in C++ using DSEL".
I think that, on the contrary, a concrete, reasonable roadmap would be 
"tiling" the parallel problem world by small scale software solution 
that can inter-operate and interact freely. Then when the basic blocks 
of such tools have been done, we can start cementing them into higher one.

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