>>>
>>>I was hoping you'd jump in here. So basically, it is likely that that level of performance you might expect to see from the higher clock speed won't be present. Is that correct?
>>
>>Yep - stalls in the execution stream lose all the advantages of the new architecture, and you end up bound by RAM performance rather than CPU.
>
>It's been awhile since I read the article I referenced in the link, but I seem to recall thinking that file I/O might also be negatively impacted. If so, this could cause further performance degradation. Is this correct was well or did I mis-interpret something?

With most support chipsets, the actual I/O is handled off the processor by DMA; it does invalidate the processor cache content any time DMA updates data currently held in cache, but it's the same issue for earlier processors expected to maintain cache coherency. I'd expect that since the caches are smaller than the caches of the Athlon/PIII/Xeon processors, fewer cache invalidations should actually happen through DMA reads, and the context shift resulting from handling an IRQ where the service routine doesn't flush the cache won't mandate the negation of the cache content - the inter-process switch would force the refilling of the pipeline that delivers the execution advantages of the superscalar architecture, executing several op codes in parallel on what amounts to multiple ALUs and separate register images where there's no dependence on the result of a parallel operation preventing out-of-order execution. The partial wait states causing pauses in the separate executions is what causes the performance problems in the P4, so that it can't take advantage of out-of-order execution that could result in an apparent execution speed of more than one instruction per clock cycle executing code optimized for the P4 by not sharing register references where there's no dependency, adjusting some branching constructs and data alignments as noted in the referenced article. It's those partial pauses that kill the P4's performance.