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: Tenchusatsu who wrote (142318)	8/28/2001 6:11:48 PM
From: Saturn V	Read Replies (2) \| Respond to of 186894

Ref < Of course, the real trouble is debugging the processor design. Two simultaneously running threads can potentially increase the validation space by an exponential factor. > Touche ! You have the exact same problem at the software level. Multiply threaded software is a pain to debug, because the difference in the relative timing of the the two threads can dramatically increase the ways in which failures can happen. It is not uncommon for bugs in multiply threaded applications to surface years after the code was written. They only show up at certain processor speeds and timing conditions. Multiply threaded software is easy to write, but a pain to validate. The same will also hold for hardware, and it creates the possibility of a another Pentium FDIV problem.

To: Tenchusatsu who wrote (142318)	8/28/2001 6:18:48 PM
From: Jim McMannis	Respond to of 186894

RE:"Two simultaneously running threads can potentially increase the validation space by an exponential factor." How hard is it to optimize a couple of key apps and a benchmark for hyperthreading? Get that benchmark in circulation and the P4 smokes the competition! Jim

To: Tenchusatsu who wrote (142318)	8/29/2001 7:29:25 PM
From: Saturn V	Respond to of 186894

Ref < All I know is that it doesn't take that much more silicon to add another thread to the pipeline. Of course, the real trouble is debugging the processor design. > My take is that Willamette and Northwood chips already have the transistors needed for the Jackson technology. Intel is awaiting verification before enabling the multi threading capability, and it will gradually ramp the percentage of chips shipped with Jackson technology enabled. I think that Jackson technology will be a winner. Large amount of Application Software which fully utilizes this will be slow to appear, because of the difficulty in verification. However a large body of software already exists already written with multi threading in mind. All operating systems have been written for multi processor systems, and these will need a minor tweak for Jackson Technology. All server software will also benefit immediately. All operating system have a minimum of two threads: (a) One for at least one application, and (b) One for operating system housekeeping. For example the application can be processing data, while the operating system is updating the display,caused by changes in the user output. Thus the applications will indeed run faster, even though there been no change in source code. The improvement may not be the 40% number bandied around, but there will be a tangible improvement in speed. I hope that Windows XP has Jackson Technology already in mind. Another question about L3. The Intel slides show an L3. I presume that some Northwood versions will incorporate a cache controller for the OFF CHIP L3. I hope that SSE will now support L3 cache control instructions.