Panajev2001a
Veteran
from Ace's Hardware front-page about SUN's new processor roadmap...
...
Vince: no chips shipping in 2005 using 90nm? Look at the Sun
- Thread starter Panajev2001a
- Start date
Re: Vince: no chips shipping in 2005 using 90nm? Look at the
SUN = Toshiba, or Intel, or TSMC, or UMC since when.
Thats like saying that ATI will produce a 150nm part in early 2003, and thus nVidia can't make on at 90nm in the same time frame. A somewhat flawed analogy, but u get the idea.
Panajev2001a said:
SUN = Toshiba, or Intel, or TSMC, or UMC since when.
Thats like saying that ATI will produce a 150nm part in early 2003, and thus nVidia can't make on at 90nm in the same time frame. A somewhat flawed analogy, but u get the idea.
Panajev2001a
Veteran
man, I was making a joke
IMHO SUN chip capabilities are over-rated... and while Intel is at 90 nm NOW they will be in 2 years ( and by that time Intel, Sony and Toshiba might be at 65 nm )... that was my point hot blooded italian
I do not like personally Solaris ( I just do not like using it ) and I think their only stropng point is their ability of having quite dense server blades and more than decent I/O capabilities...
However I like Fujitsu's SPARC more than SUN's own SPARC offering...
IMHO SUN chip capabilities are over-rated... and while Intel is at 90 nm NOW they will be in 2 years ( and by that time Intel, Sony and Toshiba might be at 65 nm )... that was my point hot blooded italian
I do not like personally Solaris ( I just do not like using it
) and I think their only stropng point is their ability of having quite dense server blades and more than decent I/O capabilities...However I like Fujitsu's SPARC more than SUN's own SPARC offering...
Panajev2001a
Veteran
uhm... so only Intel and Sony, IBM and Toshiba will have access to a large scale 65 nm process in 2005 ?
That would not be bad for them...
That would not be bad for them...
Panajev2001a
Veteran
Solaris... bah everyone has its tastes... some people love it... some people do not ( me )
About US IV...
About US IV...
Panajev2001a said:Solaris... bah everyone has its tastes... some people love it... some people do not ( me )
About US IV...
ON A SIDE NOTE, what do these chips and OS's get used for??
Tagrineth said:
COOL.... so why don't any of these designs make it to producats available to mortal carbon-based organisms like NORMAL PEOPLE.....? guess its called MONEY...
london-boy said:
Simple, we have no use for them.
Few reasons off the top of my head:
UltraSPARC is completely incompatible with x86. No programmes you have will work. So as a gaming platform, have fun with your id games cos they're one of the only companies with Solaris ports...
Their video cards use SUN's proprietary interconnect, UPA.
Actually, unlike the 3Dlabs line, SUN's OpenGL-only accelerators are fast in games too - apparently Expert3D can run Quake3 at stereoscopic 1920x1440 (highest available res on SUN monitors) double-buffered with no problems at all (it could go higher, but it has 64MB dedicated frame buffer which can't be overflowed or upgraded).
But anyway, the main thing is application compatibility with SPARC... and of course, as you said, money
Panajev2001a
Veteran
bah... I'd replace a SPARC system with a Itanium 2 system any day... not to mention a sweet Alpha EV7 ( quad channel SDRAM eat yourself )...
Personally I think SUN makes good over-all workstations ( I used to prefer SGI's and Alpha's though when they were still "alive" ), but SUN's SPARC kinda sucks ( over-rated )... They sell it because they are SUN and their clients, as it always happens in the IT and high-end workstation market, are very reluctant to change their whole line to a different architecture...
FUJITSU makes better SPARC CPUs than SUN ( they already make a 64 bits OOOe SPARC and they are pretty good at large scale computers )...
IBM POWER line and Intel's IPF and Xeon lines are going to be attacking more and more SUN's margins from both ends of the market ( low-end, mid-end and high-end )...
( quad channel SDRAM eat yourself )...Personally I think SUN makes good over-all workstations ( I used to prefer SGI's and Alpha's though when they were still "alive" ), but SUN's SPARC kinda sucks ( over-rated )... They sell it because they are SUN and their clients, as it always happens in the IT and high-end workstation market, are very reluctant to change their whole line to a different architecture...
FUJITSU makes better SPARC CPUs than SUN ( they already make a 64 bits OOOe SPARC and they are pretty good at large scale computers
)...IBM POWER line and Intel's IPF and Xeon lines are going to be attacking more and more SUN's margins from both ends of the market ( low-end, mid-end and high-end )...
Panajev2001a
Veteran
one of SUN's problem and Intel and IBM advantages is the advanced manufacturing: IBM and Intel chip designer have access to much better technology than their SUN counterparts...
Intel is ready to ship in mass a 100 MTransistor ( with SMT and aggressive Out of Order Issue and Execution ) 3+ GHz ( it shoudl achieve 4-5 GHz ) processor realized in 90 nm... SUN is only 2 years behind...
Intel's own IPF teams ( together with the help of the HP teams responsible for Itanium 2 ) are already working very well and the Itanium roadmap is not looking that bad
Plus we have the Alpha EV8 team at the helm of a brand spanking new IA-64 core... I cannot wait to see what they can deliver
Intel is ready to ship in mass a 100 MTransistor ( with SMT and aggressive Out of Order Issue and Execution ) 3+ GHz ( it shoudl achieve 4-5 GHz ) processor realized in 90 nm... SUN is only 2 years behind...
Intel's own IPF teams ( together with the help of the HP teams responsible for Itanium 2 ) are already working very well and the Itanium roadmap is not looking that bad
Plus we have the Alpha EV8 team at the helm of a brand spanking new IA-64 core... I cannot wait to see what they can deliver
Panajev2001a said:Intel's own IPF teams ( together with the help of the HP teams responsible for Itanium 2 ) are already working very well and the Itanium roadmap is not looking that bad
Really ? The latest update to the IPF roadmap postponed the 0.13um Itanium II 6 months. Intel and HP had to promise new versions with more lvl 3 cache than previous planned.
One also has to wonder when IPF will break even. The low end will be completely dominated by Xeon and Hammer solutions. Recouping the 1B$ Intel+HP already sunk into IPF development is going to be hard with only the highend workstation and server market to pay for it, and here it faces stiff competition from Sparc (despite it's performance handicap), Power 4/5 and Alpha.
On a side note: Sun has the advantage of having a single OS from their low end machines all the way to their highest end. Probably one of the reasons why Sun enjoys good ISV support.
Cheers
Gubbi
Panajev2001a
Veteran
Gubbi, Intel and HP will deliver... Itanium II is no performance joke and it is only Intel's 2nd generation IA-64 implementation while the upcoming Prescott is 7th generation ( and like the third upgrade to the 7th generation IA-32 implementation )...
IPF has the same OS as IA-32 has... Windows XP ( yes the 64 bits version ) and that means uniform programming model ( WIN32 API, Direct X, etc... ) and tools ( MS VS.NET, Intel reference compiler, etc... )...
IPF in 130 nm will come and soon after that we will ( well relatively, 2005 ) receive the dual core revision with 9 MB of cache per core ( 90 nm, 18 MB total L3, 1 Billion of Transistors... it depends if they save the 65 nm process for the new IPF made by the ex Alpha guys or if they use it for the x86 platform.. internal rivarly of the IA-64 and IA-32 teams will play a role ) and the 130 nm Itanium 2 should ship at the end of this year with up to 6 MB of L3 cache and 1.5 GHz and then will be upgraded to 9 MB of L3 cache in 2004...
Process wise if you compare the, as some have done, the .18 um Itanium 2 with the .18 um Pentium 4 ( Willamette ) it is quite clear Itanium 2 is not sucking THAT hard...
People stopped laughing after Merced... Itanium 2 showed IA-64 is no joke... come on, they are the same guys who kept making miracles and miracles for the x86 platform, and the IA-64 ISA is a more recent and better developed ISA...
I do not believe the dealy will be too significant... POWER attacks the workstations and servers market from the high-end side, Intel is attacking with Xeons and Itanium 2 on the low-end and mid-end side...
Alpha is dead... I do not expect even the "would ahve been wonderful" EV7 to make a real dent in anyone's business...
I am not sure... we will see when IPF reaches the 130 nm and 90 nm sweet-spots and Intel's push migrating IPF down as well as developing better IPF solutions for the upper-end...
IPF doesn't need to break even NOW... I think Intel might have a chance of really substituting x86 with IPF in the long term... plus they seem to have plenty of vendors available to adveture with IPF once it is more than a demo version like Merced was... Dell and HP-Compaq are two of the several potential supporters of IPF...
IPF has the same OS as IA-32 has... Windows XP ( yes the 64 bits version ) and that means uniform programming model ( WIN32 API, Direct X, etc... ) and tools ( MS VS.NET, Intel reference compiler, etc... )...
IPF in 130 nm will come and soon after that we will ( well relatively, 2005 ) receive the dual core revision with 9 MB of cache per core ( 90 nm, 18 MB total L3, 1 Billion of Transistors... it depends if they save the 65 nm process for the new IPF made by the ex Alpha guys or if they use it for the x86 platform.. internal rivarly of the IA-64 and IA-32 teams will play a role ) and the 130 nm Itanium 2 should ship at the end of this year with up to 6 MB of L3 cache and 1.5 GHz and then will be upgraded to 9 MB of L3 cache in 2004...
Process wise if you compare the, as some have done, the .18 um Itanium 2 with the .18 um Pentium 4 ( Willamette ) it is quite clear Itanium 2 is not sucking THAT hard...
People stopped laughing after Merced... Itanium 2 showed IA-64 is no joke... come on, they are the same guys who kept making miracles and miracles for the x86 platform, and the IA-64 ISA is a more recent and better developed ISA...
I do not believe the dealy will be too significant... POWER attacks the workstations and servers market from the high-end side, Intel is attacking with Xeons and Itanium 2 on the low-end and mid-end side...
Alpha is dead... I do not expect even the "would ahve been wonderful" EV7 to make a real dent in anyone's business...
I am not sure... we will see when IPF reaches the 130 nm and 90 nm sweet-spots and Intel's push migrating IPF down as well as developing better IPF solutions for the upper-end...
IPF doesn't need to break even NOW... I think Intel might have a chance of really substituting x86 with IPF in the long term... plus they seem to have plenty of vendors available to adveture with IPF once it is more than a demo version like Merced was... Dell and HP-Compaq are two of the several potential supporters of IPF...
Panajev2001a said:
They haven't delivered yet. Merced was supposed to be faster than contemporary RISCs, it was about half the performance. Second generation IPF was supposed to greatly exceed the competition, it is (very) competitive on floating point, and just barely keeping up on integer performance.
And Microsoft still has to prove that they can produce an enterprise class OS. Furthermore, what's the point of a 64 bit chip when the API is 32 bit? I am fairly confident that the serious applications for Win64 will use the NT native API and not WIN32.
Panajev2001a said:
But these are just shrinks of the existing core. All their competitors will shrink their designs as well, Power 4 is already dual core, Sparc will be.
Panajev2001a said:
Apples and oranges. Granted, the I-2 is faster but it also has a vastly larger die (and produces more heat) and a more aggresive memory subsystem.
Panajev2001a said:
Actually they are not the same. I-2 was mostly developed by a former HP design team (now Intel). Of course the process people are all Intel.
As for IA-64 being a better ISA, time will tell. It was conceived at a time where people thought out of order schedulers wouldn't scale. This was proven wrong over time (the Pentium 4 being the prime example).
It was based on the premise that scheduling is BAD. So HP came up with EPIC, which esentially is compressed VLIW. Instructions are bundled together 3 at a time, template bits are used to describe where the instructions are supposed to be scheduled (what type of exec unit the individual instructions go to). Now, this only works if the processor has a full complement of exec units to match the different bundle types. This is why Merced sucks and McKinley doesn't: Merced lacks execution units and the instructions in the bundles has to be scheduled (extending the length of the pipeline) to the available exec units, and stalls are frequent.
McKinley has the exec units to match two whole bundles, hence bundles are fetched, template bits decoded and the instructions handed down to the execution units, - much faster.
I can see two problems in the future for IPF.
1.) Imagine you have profiled different applications and found that your IPF processor lacks integer performance. The problem is that you can increase performance by making the processor crack another bundle per cycle, -and to do that fast you need a full set of execution units. Hence you get an extra floating point unit, extra branch units and an extra load/store unit (demanding another port in the cache, impairing cycle time) which you don't really need or want.
2.) Future implementations are likely to be multithreaded. The apparatus needed to schedule and track which instructions belong to which context is very similar to the register renaming and OOO scheduling you find in OOO cpus, which is why the Hyperthreading in P4 only took an extra 5-10% die area (similar numbers from the Alpha people regarding EV8). IPF, however, has none of this. You can of course build an OOO multithreaded implementation of IPF, but then the template bits in the bundles are basically discarded (ie. baggage). And your compiler is stuck with generating code for the bundle instruction format, filling each bundle with NOPs for every slot that it can't use, which in turn wastes I-cache and fetch/decode bandwidth.
Full predication is also an artifact from the late 80s/early 90s when eager execution of fully predicated instructions looked like the way to go. But the last 10 year's improvements on branch prediction has made it evident that it is not so hot
Panajev2001a said:
Sadly, yes. Even though it appears to be sandbagged (low operating frequency), with a smaller die size and lower power consumption it still beats IPF on everything but some floating point applications (see recent SAP benchmarks ?
)Cheers
Gubbi