.net and multicores

Question

From the .net 4.0 previews I have read until now there has been lots of talk on how the next .net version will handle and use cpus with multiple cores. We will have additions like plinq that will help us make use of multiple cores. My question is why should I have to bother my mind with handling multiple cores when all I want is to make my application run faster. Why can't there be a kind of virtual cpu layer that exposes all cores as 1 core to my application?

Edit: I would like to rephrase my question to avoid misunderstanding, Could there be made a software that would expose a virtual thread to my application that would be 10 times faster because underlaying it was using 10 cores. I do not want to have different threads doing things in paralell, I just want my one thread running faster. I guess this is not a big problem today but soon we'll have 80 core processors to play with and then I would feel a bit shorthanded only using 1 of them.

Answer 1

You are misunderstanding the point of multiple cores in the first place.

With more than one core, you can perform two or more different operations in parallel (at the same time). This is called threading.

This can't be done automatically because the "normal" programs you write are linear. You can't easily convert one series of instructions into several series of instructions without taking into consideration side effects.

GPU's (specialized CPU's on graphics cards), for example, may contain hundreds of "cores" (stream processors) which operate in parallel to render the pixels on your screen. With only one processor, you'd have to render pixel-by-pixel on a super-fast processor to achieve the same effect.

The reason CPU manufacturers moved to more than one core was because manufacturing a single core at higher speeds was getting more difficult and expensive, and that a single core would suck up more power and produce more heat than two cores at half the speed (basically; this isn't true in all cases).

Answer 2

Because parallelisation just can't be done without the aid of a human.

There's a certain amount which can be done - and already is done within a single core. Microparallelism is a lot easier than "analyse this whole program and make it run in parallel" for obvious reasons. In general, many of the difficult decisions which have to be made when writing a parallel program depend on what you want the program to do, and how it should behave under various conditions.

It's possible that more will be able to be parallelised automatically over time, but I'm happy with the advance of making it significantly easier to do manually for the moment.

EDIT: Having seen the edit in your question, there's no way of making it go faster. There's a really easy physical metaphor for this: a pregnancy takes 9 months. If you have 9 pregnant women, you can end up with 9 babies after 9 months, but you can't make 9 women have 1 baby in 1 month. It just doesn't work like that. Not all problems are parallelisable. (Fred Brooks: “The bearing of a child takes nine months, no matter how many women are assigned.” (The Mythical Man Month, p. 17))

Answer 3

Yes and no.. If you want to be able to program as normal, but having the system 'magically' use multiple threads, then you need to look at some of the multi-processing frameworks out there. For example: OpenMP.

If you want to run through an array, using all your cores, code similar to this:

int main(int argc, char **argv) {
    const int N = 100000;
    int i, a[N];

    #pragma omp parallel for
    for (i = 0; i < N; i++)
        a[i] = 2 * i;

    return 0;
}

Just adding the #pragma makes your code magically multi-threaded. Now, you will have to understand some restrictions, eg. you cannot use the value of one element in the processing of the next (ie you cannot set a[0] to 1, then a[1] to a[0]+1, etc as they'll no doubt be processed by different threads, and therefore may not be computed when you need them) or you'll get an error from the openmp compiler, but if you work within these restrictions (and there are many) then you can get what you want.

The restrictions are what makes your ultimate goal of making your code impossible. As in my example, you simply cannot compute 1 element based on another unless the first element is already computed. This effectively means code like that can only be single-threaded, no matter how many cores you have.

It also means that 80-core chips will not really take off anytime soon, not unless they are all 3Ghz general purpose processors, so you don't need to worry too much about having to code for them. Now, add-on co-processors that can crunch arrays coded like in my example, that's another matter, and I expect to see more of that in the future. You'll probably use the graphics card for that kind of thing and have thousands of 'cpus' instead of a mere 80.