Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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 -- Ignore unavailable to you. Want to Upgrade?

To: ptanner who wrote (85080)	1/5/2000 2:06:00 AM
From: Process Boy	Read Replies (2) \| Respond to of 1573954

ptanner - <CE who enjoys computers and have CAD to thank for the opportunity to buy hot-rods.)> What's your take on the OCUS R20 benchmark suite? Did you read the Anandtech ProENGINEER vs. PIII vs. Athlon review? Any comment appreciated. PB

To: ptanner who wrote (85080)	1/5/2000 2:10:00 AM
From: Scumbria	Read Replies (2) \| Respond to of 1573954

PT, How about changing the way the software programs are written (hm... IA-64?) Better compiler technology always helps. If compilers ran trace analysis on real memory subsystems, they could improve performance considerably. or providing for high capacity memory bandwidth (RDRAM) for data intensive apps or the use of dedicated hardware for specialized tasks (old FP co-processors or graphic cards) provided they don't compete with the main memory path. RDRAM improves bandwidth, but is not very good for latency. Unfortunately, latency is the problem here, and Rambus is not the solution. perhaps the use of FP registers instead of stacks? x86 FPU stacks are a significant performance problem for some applications. I'm not sure how you address this problem and remain backwards compatible. If you are willing to give up backwards compatibility, you could also add large numbers of integer registers to store intermediate results, and reduce accesses to the cache. Scumbria