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