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.

Technology Stocks : Intel Corporation (INTC) -- Ignore unavailable to you. Want to Upgrade?

To: Paul Engel who wrote (104862)	6/25/2000 11:36:00 AM
From: Cirruslvr	Read Replies (2) \| Respond to of 186894

Paul - RE: "When Willamette is released, we're going to hear no end of the AthWiper becoming - VERY RAPIDLY - the Price-Performance leader - as the PRICE comes tumbling down." Athlon already IS the price-performance leader. I don't understand why you seem to have something against that claim. Dell uses the same propaganda to sell some their Intel based products.

To: Paul Engel who wrote (104862)	6/26/2000 10:07:00 AM
From: pgerassi	Read Replies (1) \| Respond to of 186894

Dear Paul: The benchmarks posted clearly state that Williamette does x87 FPU instructions at 800Mhz no faster than a Celeron at 550Mhz. Intel even stated in their comments that to get high FPU performance you need to recode for SSE2, therefore acknowledging that there will be a performance gap using the traditional x87 instructions (read all current software except for games). Using x87 instructions, a 1Ghz Coppermine (about 2x as fast as a 550MHz Celeron), would match a 1.5GHz Williamette. Since a 700MHz Duron in x87 instructions runs as fast as a 1GHz Coppermine, Williamette at 1.5GHz gets outrun by a value 700MHz Duron using today's workstation grade software (Single precision does not cut it in this market). Recoding in SSE2 may double the performance at most, making the 1.5GHz Williamette no faster than a 1.4GHz Tbird and probably slower. Notice, this covers FPU instructions only and Tbird performance may be greater given further time to optimize for that architecture. Integer operations may be a different story but, here too (if the post was to be believed) Williamette performance was less than an equivalently clocked Tbird. Now it is possible that Williamette may need to go through additional spins of silicon to enhance performance and that is why is may slip further out (I believe that Elmer claims it takes 8 weeks minimum to do a silicon respin). In any case, Williamette needs to prove that its design allows for higher real performance at the same point in time. We will debate facts when the Williamette is benchmarked by the usual sites in both absolute and clock matched performance. I am sure that Intel will recode some programs and drivers to use SSE2 to shrink any FPU related deficiencies. By the way, in the 5% Sledgehammer debate, I think you forget that the internals of RISC based designs like Athlon and even Coppermine, have 64 bit datapaths in the FPU portion (actually 80 bit for x87 and 128 bit for SSE), within the integer units for multiply and divide, and any stuff L1 and beyond. Thus only the integer registers, integer add and address generation units would need to be doubled in size. The control logic will require little additional size. Only three integer data buses and 5 address buses (3 int AGUs, 1 FPU, 1 instruction) need to be increased. Since the integer data buses will be short (they are close to the data L1) and the address ones are also short (4 are close to the data L1 and 1 is close to the instruction L1) the only real die size increaser for the bus portion is the L1 to L2 to FSB address bus. So 5% is not too far out of range. The instructions that will be extended to 64 bit integers also will play how small the increase may be. Since in the old 8080 from which all this started, BC, DE, and HL were paired for 16 bit addresses in the 8 bit MPU, if AMD is only referring to 64 bit addressing and not 64 bit integer processing, then 5% increase is easy to do. 64 bit addressing gets you almost all of the advantages for server work since most data never needs 64 bit integer processing (remember the FPU could do the little 64 bit integer work required (it has to do the 64 bit x87 mantissas)) without having to go to a full 64 bit design. The EV6 bus already has 64 bit addressing so that does not need to change. Although, the chipsets may need to be modified. If the Athlon is a 64 bit RISC unit with 32 bit addresses, 5% is also easy since, only the addressing units need changing with a redo of the control logic. In either case, one of the great extensions would be a portal to the underlying RISC CPU instructions thereby, making a path away from the dated x86 set while maintaining full x86 compatibility. Customers like to evolve their code and like the adage "if it is not broke, do not fix it". x86 evolved from x80, the next move will probably need to evolved from x86 rather than a complete makeover (software companies HATE to recompile and test for FREE). Pete