Multithreading Not The Way For Multicore, software-hardware ne'er shall meet

According to EDA companies, multithreading may not be the way for multicore processors in the near future.

I also read this paper, and it simply makes no sense.

Willing to put a monothread software on a multicore processor? This shall be the future? Fine! It saves power as the other cores do nothing.

Unless somebody finds a way to make efficient single-thread chips, mutitasking is a necessity. Sure, software producers dislike it.

Pity we have no really good and simple computer architecture to make use of the many gates available on a chip - many more than one processor needs.

Vector computers have been built. Very nice, efficient, relatively easy to program - but they work only on vectors. Superscalar (mmx, sse...) are just a small step in this direction. Anything between 16 (Cray-1) or 17 (BSP) components vectors and 1 million monobit processors (MPP) has been built.

The other way is multithreading on multicore. Somewhat more flexible.

And I know no other possibility usable right now. And much less so with little effort from the programmers, as this is the whole point here... The whole evolution of Pentium et al was thought to allow programming them as if they were 80386, but the limit is crossed for a long time now.

Just for clarity: increasing processor clock would be highly desirable, and might become possible again if somebody achieves optical communications within a chip (not between chips, useless), but as the amount of gates is available, we'll never go back to monocore scalar processors.

The proportion of gates that compute is already so small in a CPU! Less ridiculous in a GPU, and dX10 GPU are on their way to replace CPU more and more. Then, programmers won't have to deal with 2 or 4 cores, but 100+. About time to learn it.

The issue is not with multithreading itself, but the single processor architecture they're trying to fit into a multithreaded system. If you have fine enough threads and efficient hardware to handle the overhead, it's a matter of software engineering to extract the potential from the hardward (the capabilities of hardware are outstripping the ability of software engineers to take full advantage of - reconfigurable computing is a good example of hardware that is capable of providing very large increases in speed and efficiency, but it takes a very skilled engineer to realize these potentials - software typically written for a PC is very inefficient).

The most efficient large scale manner of performing computations is to have a diverse array of computation specific processors and effectively time-share applications on them. There might be a day that instead of buying a new program, you have a single application specific computer built to perform some computations and then people network to use it (much like a classical terminal/mainframe approach). Of course, this would be best suited for applications with low bandwidth, higher latency and computational loads. In the EDA arena, they could, for example, instead of writing a single program to be distributed and run independently on many PCs, design a custom hardware engine (likely deeply pipelined) that could quite easily run thousands of times faster than a single PC for limited applications and then simply multithread requests from different users (as an extreme example, imagine a 100 deep hardware pipeline with each stage carrying individual user data - now that's a bit better idea of what multithreading is capable of - it's not multithreading, that's the problem but trying to take typical single thread coding written for a general purpose processor and convert it into multiple threads of execution. You really need to start from something closer to scratch in terms of hardware and software design to take good advantage of parallel processing, but there aren't good industral standards for people to agree upon and many software engineers would require quite a bit time to relearn coding for parallel applications).

Very true. The overhead of getting the data you want to the hardware processor you desire at the right time, is what most the hardward is devoted to doing. An application specific redesign removes much of this overhead and allows for a lot of optimization to the computations to be performed as well.

This post has been edited by StevenA on Jun 23 2008, 06:10 PM

Worth pointing out: multithreading != multitasking

Multitasking = multiple processes, CPU swaps between them, etc.
Multithreading = splitting up a single process into multiple 'lightweight' processes so that different functions in a single program are multitasked

So the other cores wouldn't be doing nothing, they'd be running other processes.

(the article is still bunk, though)

This post has been edited by dwk on Jun 24 2008, 10:11 AM

What is anoying that when there is processors with multicores then need new program OS, unlike in GPU. And don't have evidence about fastelity. Many years many cores wasn't needed until frenquency of processors stop grew. Better it would be some twice weaker celerons and pentiums and not 2 or 4 cores and 1... Or like in GPU, can be celeron, bullshiton and pentium...

multithreading != multitasking

But I want my computer to push ONE application quickly at a time. Have a look at your task manager, only one program at a time needs CPU power.

Maybe we find more comfortable to run an antivirus through all files while making urgent tasks directly for the user, but this is not very important, and we're at one-and-a-half tasks then. Though, processors already have 4 cores and would have hundreds of cores - like on GPUs - if only software were written for that.

So yes, we need heavy multithreading, because I'm interested in only one result at a time.

I echo Enthalpy. Good job.