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: SisterMaryElephant who wrote (109175)	9/5/2000 10:09:22 AM
From: pgerassi	Read Replies (1) \| Respond to of 186894

Dear Steve: For short pipeline CPUs like K6, task switching is less of a problem because the pipeline stalls lose very little in CPU cycles. In EPIC these effects are increased greatly because the optimization is fixed while in a normal RISC or CISC computer where the optimization is dynamic (the CPU figures out where it can speculatively execute, go out of order, etc. and this can optimise for these type of environments like keeping some internal registers open instead of filled with data prefetched (internally rather than explicitly)), in EPIC it does what it is told and whenever there is a conflict, it waits. Most RISC processors with register windows, like SPARC, can suffer an interrupt without any penalty due to very infrequent register save restores required. Embedded markets do have applications that are almost never interrupted or the interrupts are handled by an I/O CPU while the calculations are free running on a seperate CPU. Also in these applications one can design interrupts to minimize the disruptions because you know the few that can or will interrupt the CPU. This is very different in a general purpose server box where literally thousands of different interrupts (software and hardware) need to be handled from all over the system. It is not atypical to have ten thousand (or more) process threads running simultaneously in a multiuser server system. Third, Itanium must be designed as a general purpose CPU instead of a single task CPU like the Nvidea GPU or a TI DSP. This was to replace IA-32 which all are general purpose CPUs. Now, if Intel did design IA-64 to be single task, why include the ability to run IA-32 instructions but at a lower rate? Why would anyone replace an IA-32 CPU in general purpose applications like serving, RDBMS, decision support, spreadsheets, AI, and the like? Are you implying that Intel would give up this market to AMD's Hammer series? Nearly 100% of their operating profits come from general purpose CPUs. If they did this, Intel's stock would tank below book value and management would be strung up by their thumbs. No! I think that Itanium has failed to do what it was meant to do. This is a failure of management. There have been many signs of a project in trouble. They should have nipped it in the bud, admitted that it was not working out as they had planned (hey these things happen when you are on the bleading edge (where do you think the blood comes from? (taking a chance))), and tried something else. In the drug business (which is also high tech as well), this thing happens a lot as unexpected side effects occur and effectiveness does not pan out in further development. It is managements fault when they push something that just isn't "there". Fourth, many web pages require JAVA script run in the server to look up stuff in databases, calculate results, compressing the resulting data into a form easily sent as a few packets of data, figure the ten highest reponses, etc. Most of these requests are dynamic as the parameters are chosen at run time and sometimes which parameters are used. This requires dynamic code (data driven coding). This code is interpreted and as such highly variable (like the old spaghetti code). When general purpose (read has to take all possible cases), many computed branches (read jump tables) and much conditional code (hey error handling can be a bitch especially when expected half the time (you want a database lookup to return no rows a lot of the time)) is passed through. Thus many unexpected pipeline stalls occur. This is also something that will not run well in a deeply pipelined CPU like Willie. If the branches are predicted at compile time do not happen a lot in the real world, this code will run exceptionally bad on an EPIC CPU where a run time optimized CPU would have very little trouble with it. If the compiler guesses wrong, it will always be bad in an EPIC CPU where a normal CPU like an Athlon, P3, or P4 would have little trouble adjusting to be mostly good. I think that should clear it up. Pete