[prog] dual-core processors and threads

[mhf at berlios.de]

On Thursday 03 March 2005 22:34, ed orphan wrote:
> I just read that Intel will be releasing 64-bit dual-core
> Pentiums ( Pentium-D 2-thread, Pentium Extreme Edition
> 4-thread ). Does this mean a new, stronger emphasis on
> multi-thread programming? I hate threads. They are a real
> pain to debug. If my worries are true, does Linux have
> any special debuging tools for multi-threaded apps?
> Threads! Yuk!
>

This explanation focuses on the CPU disregarding main 
memory and IO issues.

Increasing throughput per CPU has been accomplished mainly 
by: 
1. increasing clock frequency 
2. increasing parallelism of instruction execution
3. Moving faster memory closer to the CPU by adding 
   cache on die

Increasing clock frequency is more difficult than ever as 
physical limits are approached. 

Increasing parallelism of instruction execution has been 
accomplished by making pipelines deeper and "understanding" 
the instruction stream in order to execute multiple 
instructions per clock. The complexity of this approach 
increases exponentially, and there is not much to gain. 

Thus, it will take a long time to reach for example 10 GHz 
clock and there won't be much more throughput per CPU in
the near future.

Process shrinkage will continue for a while and the
space required per CPU-core decreases and more cores and
cache fit on a die improving the throughput per die. 

Therefor can we expect multi-core CPU's with a few MB of cache
running at a few GHz be common in a few years.

10MB cache for 4-8 cores at 5GHz  would not be too bad :-)

As to programming, I love threads and use multi-threaded 
programming for more than 20 years in embedded applications.

IMO threads make design much easier and also make complex
programs easier to understand.

On linux gdb can debug threads and it is useful to add
a debug thread to complex programs which monitors other
threads and records/prints debug info. 

	Regards
	Michael