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: Charles Gryba who wrote (170425)	8/30/2002 5:35:46 PM
From: wanna_bmw	Respond to of 186894

Constantine, Re: "An easy solution would be to have 2 Trace Caches and Two L2 Caches on board while keeping all the other cpu resource ( registers ) as is." That's a complex solution. You might as well go with a multicore if you're going that far. The whole point of multithreading is to not have to repeat CPU resources. My solution would be to have a context bit that tells the system which thread owns the line, thus enabling smarter LRU algorithms. wbmw

To: Charles Gryba who wrote (170425)	8/31/2002 8:31:55 PM
From: Tenchusatsu	Read Replies (2) \| Respond to of 186894

C, I think it's the L1 caches, especially the trace cache, that is suffering from thrashing. When you have multithreading, you want your caches to be large and flexible. That's easy for an L2 cache which is easily decoupled from the processor core. But for L1 caches, large and flexible go against the goal of high-speed, which requires the caches to be small and simple. It might help to duplicate the L1 caches to support multithreading in P4. But that would add a significant amount to the die size, and you're that much closer to going with a dual-core design anyway. Tenchusatsu