Dean Michael Berris a écrit :
I'm a little weary about hiding these important issues to the people who understand the higher scheme of things. Which is why I personally don't think leaving the (non-C++ programming) domain experts in the dark about the inherent parallelism in their solution is a good idea.
No, we have to let them unaware of the *details*. Of course they shouldknwo about how many or how coarse is the inehrent aprallelism or if for a given paltform tasks parallelism performs better than data-aprallelism. We have to hide them the ugly gears.
As far as hiding the parallelism from them, the compiler is the perfect place to do that especially if your aim is to just leverage platform specific parallelism features of the machine. Even these domain experts once they know about the compiler capabilities may be able to write their code in such a way that the compiler will be happy to auto-vectorize -- and that's I think where it counts most.
Yes I fully agree if we lived in a perfect world. auto-whaterver-izing compilers are alas not the norm currently.
Actually, it's easy to say it -- it's a matter of acceptance that's a problem. Now if it was a library that forced users to change their code just to be able to leverage something that the compiler should be able to handle for them (like writing assembly code for instance) sounds to me like too much to ask for. After all, the reason we have higher level programming languages is to hide from ourselves the details of the assembly/machine language on which platform we're going to run programs on. ;-)
See my reamrks about NT2 previously. Librarie sliek NT2 are the way to go for users. I think Boost.SIMD has its usefulness (as said in the other thread) for library developeprs.
I agree, but if you're going to tackle the concurrency problem through a DSEL, I'd think a DSEL at a higher level than SIMD extensions would be more fruitful. For example, I'd think something like:
vector<huge_numbers> numbers; // populate numbers async_result_stream results = apply(numbers, [... insert funky parallelisable lambda construction ...]) while (results) { huge_number a; results >> a; cout << a << endl; }
I never said I'll tackle concurency with Boost.SIMD ;) Of course it'll need a far more expressive and abstarct DSEL.
In which case I think that DSEL for parallelism would be much more acceptable than even the simplest SIMD DSEL mainly because I'd think if you really wanted to leverage SIMD by hand, you'd just use the vector registers and use the vector functions directly from your code instead. At least that's in my case as both a user and a library writer.
Then again, one's tool is not what another one's need.
In which case I think a DSEL is clever, but a SIMD-only library would be too small in scope for my taste. But that's just me I think. ;-)
Patrick Mihelich seems to disagree ont he other thread ;)
I like thinking at a higher level first and solving the problems in the lower level with more specific focus but within a bigger context. Once you can recognize the patterns in the solution from a higher level can you really try solving problems at a lower level with better insight. Missing context is always hard to deal with.
Maybe. I'm not sure myself on how to tackle this. Le's try and see how it fares. If I ended up cornered then I'll see and go back to another approach. Heck, I'm even paid for doing exactly this (searchign not beign cornered ;)) The issue is large and arguments around how to do it properly are necessary as no one lay be able to find the definite answer alone. In my larger plan, there is a mix to find between exernal tools that preprocess source to source, DSEL at low level and other kind of tools.