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: Joe NYC who wrote (151235)	12/5/2001 6:27:27 PM
From: wanna_bmw	Respond to of 186894

Jozef, Re: "Another thing I would be curious about is how exactly the case statement is executed, and how the table for it is built up. I see these 2 as valid concerns. If you have any other concerns, let us know." If you are interested in finding the real truth, I suggest you get Kap's program listed at the assembly level. Any debugger can give you this information. If you copy a portion of it, I can analyze it for you. wbmw

To: Joe NYC who wrote (151235)	12/5/2001 6:33:17 PM
From: Tenchusatsu	Read Replies (1) \| Respond to of 186894

Joe, Kap's program does a lot of pipeline flushes. Every time the pipeline is flushed, the processor has to restuff the pipeline with instructions. If the next pipeline flush comes soon after the last one, overall performance will be limited by the latency of the pipeline. Therefore, the results will be skewed by the number of cycles wasted by pipeline flushes. A more ideal test program would be one very long string of instructions with no inherent parallelism and no branches. Such a program will have no pipeline flushes whatsoever. Then the limiting factor will either be the decoder or the bandwidth of the L2 cache (or memory if the code can't fit inside the L2). Tenchusatsu