<snippety snip>
By the way, is it not true that 'pipelining' that's a feature of
x86 CPU's starting
with i586 which I have pointed out in one of my previous post is
(another name)
implementation of 'parallel' processing ?
So, in this way there is true parallelism in x86 arch.
Holy shit! You are soooo off base here its not funny. 'More than one
thing per clock cycle' -> What do clock cycles have to do with
parallelism? Nothing. Concurrency means 'concurrent'. If two operations
complete in one clock cycle *in series*, then its not parallel. Its
fast, but not parallel.
Have a look at the intel documentation on Intel IA-32 Architecture -
Series x86. You
will be pleasantly surprise.
Just about every CPU in existence is pipelined. It's an implementation
technique, nothing more. It doesn't change the programmer-visible model
of the CPU, which is a machine which will execute instructions one at
time. The programmer doesn't have to change their software to account
for various pipelining structures. As far as the programmer is
concerned, instructions go through one at a time, in order.
Patterson and Hennessy's "Computer Organisation and Design" covers this
pretty well in chapter 5, "The Processor: Datapath and Control".
Most discussion around parallelism nowadays is with the aim of
increasing total application performance by adding processing units.
Parallelism is not a desirable attribute on its own. The parallelism you
refer to within the CPU manifests itself as greater CPU performance
(more instructions executed per unit of time). Using multiple CPUs
together to achieve greater aggregate performance is a fairly difficult
problem nowadays due to the interactions between threads, and is most
definitely programmer-visible (despite what Intel and Sony will assert
in their marketing material).
Ian
(not a CPU engineer, but I play one on TV)
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
