Parallelism of the future

Hey folks,

as I'm currently working on some form of automatic parallelism in software engineering, I'd like to share my perspective of solving this problem on machines of tomorrow.  As I've already mentioned in the post on "Multicore programming - but what comes next" the multicore era of today already belongs to the past, and the future being "manycore" already is the present.
We as software engineers have to think about it today to be able to close the gap that currently exists between the hardware potential and the software engineering expertise. In my studies I find that we need to be able to offer a development environment to the software developer that takes care of certain parallel situations itself. To my mind it's the wrong decision to burden every developer with parallelism specifics. Instead, we as parallel researchers need to figure out a handy way to achieve a certian form of parallelism semi-automatically or even automatically. This is what I'm focusing on.

In the same way virtual machines have been taking over a large part of business software development, AutoParallelism has to be achieved. And just like native code is faster than IL-code, an automatic parallelized application won't be able to speed up just like an applicaion that is developed by a parallel specialst - which is totally OK. If you walk the extra mile you can get the extra speed.

Currently the parallelisation frameworks are very fine-grained: They offer statement-based parallelisation together with statement-based locks. Also, the compiler experts work on automatic compilers that are able to detect parallelizable loops. I'm heading in another direction: Don't detect small jobs and roll them out on multiple processors, but detect large jobs and schedule those. Intel's TechParallel Talk undermines my thesis.

Let's wait and see what I can tell you next time