[prog] dual-core processors and threads
mhf at berlios.de
mhf at berlios.de
Sat Mar 5 18:27:13 EST 2005
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
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.
More information about the Programming