[fpc-devel]Re: Latest status
Sebastian.Kaliszewski at softax.com.pl
Tue Nov 27 20:35:48 CET 2001
From: "Florian Klaempfl" <Florian.Klaempfl at gmx.de>
> I know all this discussions but here I see the iA64 from the view
> of the compiler designer :) and here the iA64 is brilliant. But I don't
> that the iA64 will be important the next years, but it will get
> when the transistor count of processors reaches 10^9 to 10^10. Having SMT
> the variable VLIW concept of the iA64 will be probably the only the
> to use a lot of execution units ...
With SMT (the one with shared resources) and especially DMT (speculative
threads) you could as well forget about VLIW at all (its an unneeded baggage
then). Anyway the problem will be not the number of transistors available
but designing CPU of such enormous dimensions. Processor designers will run
into funny problems with the amounts of transistors -- there might be just
too many transistors to use them as single CPU logic. Designing 20 isuue CPU
is hard not because of OoO logic (or lack of it) but by the sheer problem of
effectively dispatching and *sharing* data between all the execution units
(40 port regsiter file of 128 64bit registers would be incredible monster,
thats why such desings like Alpha EV6 are duplicating the register file, and
introduce delays when data has to be forwared between parts of CPU attache
to diferent register files -- but doing such stuff on inorder design raises
complexity to incredible amounts, and moving IA64 into OoO design is simply
funny thing -- the result would be a mosnster of vast proportions, VLIW
would be then unneeded baggabe left for backwards compatibility and
increasing complexity in the hard way.)
Maybe this amounts of transistor will be used as RAM on chip (EDRAM).
Scaling into bigger arrays of CPUs requires localising RAM, and NUMA designs
(Sun, EV7, Power4, Hammer) the next logical step would be to put ram on chip
as well and if you need more ram you just put more CPUs into the package --
speed gain is big as guys from embeded space and some GPU design ares say
(having 1024bit bus is not a problem then, and acces latency is reduced 5-10
fold (now moving dram controller on CPU itself promises 2-fold latency
reduction (EV7, Power4, Hammer).
> Regarding x86-64: It sounds interesting but I can't believe that AMD has
> the power to introduce it into the market.
Waht do you mean? The chips will be there in about one year time unless some
disaster happens, they will perform well in IA32 bit code, treat x86-64 as
added bonus which first will be utilised by Linux crowd (since Linux is
built from the sources, kernel support, at least for mixed mode is easy to
implement so it'll be there)
> 3DNow wasn't a success either and
> is dead
I would'nt consider it dead. It has specific purpose of accelerating games,
and it was used be quite a number of games and all top videocard drivers
(otherwiese Athlon would not be so good for gaming). It was of little use
for compiled code (SSE is not much better there, SSE II is the way to go).
Comparing initial acceptance of 3D-Now! and SSE the former enyoed better one
(no wonder -- Games are mainly for home market and then proportions of Intel
and AMD are oscilating around 50-50 for few years. Business market is the
Intel's stronghold, so thats why total proportions are now around 78-22
other player are rather unimportant, oscilating around 1% of the market).
Since FPC is rather for home market you (designers) should really consider
the ballance for this part of PC world. AMD is much bigger here!
> though it was much more compatible with existing architectures than
> will be and for certain applications it was very promising.
And it were used there quite alot. Now, since AMD added SSE, and is going to
use (extended to 16 regs) SSE II, bnalance shifts quickly to SSE, of course.
> What I suspect what happens is if the x86-64
> gets too big and the iA64 fails Intels extend the x86 architecture as well
> to 64 bit
> (of course in an AMD incompatible way) with some "reused" iA64 concepts
> 3DNow<->SSE and the i860/i486 story :) )
First of all any such move requires time, a lot of time. Design cycle of new
general purpose CPU microarchitecture is allmost never shorter than 3 years
(K7 is a noble exception but it was certainly death march project, extremely
well executed and based on very high motivation -- it was survive or die
thing for AMD, if it was 6 months late AMD would be probably bankrupt (they
were awfully close to taht, then)). Recent Intel's design cycles are 5 (PIV)
and 6-7 years (Itanium). The explicitly stated that the succsor of the
NetBurst microarchitecture won't come in earlier than 5 years after PIV. So
it won't -- projects of that size are never accelerated, they are rather
slipping, often as badly as Itanium (first it was expected in 1997, then
1998, then 1999, then 2000, now it is 2001 and it is "pilot release"),
sometimes they are cancelled (EV8). Eventual failure of IA64 won't be
realised earlier than in 2005, so any counteraction wont come earlier than
in 2007 probably. So it is about 4 years lead for x86-64 before any
incompatible 64bit extension comes. Anyway who knows how this market will
look by 2007?
> Keep the size of Intel and AMD in mind when discuss this issues!!
Of course! But sheer size is not a guarantee of sucess, and power balance
often shifts in this market. Intel in many ways looks like IBM at the middle
of eighties (Moving slower and slower, bulkier than ever and arrogant as
only could be -- well there are lately signs of some reasonable behaviour
lately, but they are still weak). What was DELL, Compaq or HP 16 years ago.
IBM was unable to regain it's possition from taht time up to date! Other
examples of such shits are in GPU market. Compare NVidia and 3DFx from 1998
(it's only 3 years), now where is 3DFx? (bought out be NVidia).
And were are here in the niche market, not majority, and here AMD has much
stronger representation than in overall picture. Anyway, why are you
supporting Linux or OS/2? Windows has 90% of the market (it's significantly
greater dominance that Intels in PC CPU business)? :)
More information about the fpc-devel