SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Politics : Formerly About Advanced Micro Devices

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Paul Engel who wrote (82665)12/11/1999 3:55:00 PM
From: kash johal  Read Replies (1) of 1571427
 
Paul,

Re:"Legacy x86 software (current applications) would support only 32 bit addressing, wouldn't they ?

Then of what use would the 64 bit addressing be to these 32 bit legacy programs?"

Well my understanding is that sledgehammer will have leading edge 32 bit performance coupled with the switched fabric for multiple CPU's. In addition the closck speeds should be well over 1Ghz at that stage.

Now folks purchasing such a server will get blistering performance with existing 32 apps. In addition as a portion of the apps get moved to 64 bits the performance will be excellent.

With Itanium the performance will be much higher for 64 bits apps. than with sledgehammer. But it has been speculated that porting the software to use EPIC is non-trivial. And legacy apps will run much slower as this code is being emulated.

So depending upon when sledgehammer systems are available, I can see a large market. If AMD can deliver in mid 2001 a dual sledgehammer die then I see they have a very good chance. If they slip by a year or two then Itanium die size/costs will come down and the apps performance will be more compelling.

The other issue is the ease of moving 32 bits apps to use 64 bits of memory space. Not being a software guy I have assumed it is trivial with the appropriate compilers.

regards,

Kash.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext