SI
SI
discoversearch

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)
INTC 36.15-0.6%Dec 24 12:59 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: kapkan4u who wrote (150443)11/29/2001 7:17:11 PM
From: wanna_bmw  Read Replies (2) of 186894
 
Kap, Re: "So the table is in L1 (which is too small for the table) but the code fragments are in TC. TC is also too small for the number of uops it has to fit."

So what's your point - that the trace cache is too small, or that a trace cache is a bad idea?

I don't think the size of the trace cache is important to this discussion, because you could easily increase the size of the switch statement in your code routine to effectively sabotage any size trace cache.

I don't think it's the trace cache itself, either, since your routine is specifically designed to create a large table of random instructions that will cause the processor to miss the trace cache and incur a high penalty on every load. Real applications aren't designed that way - not even those legacy applications that have a bad rap with the Netburst core.

So I finally see how clever your code is, but I don't see why you would bother asking me to use it as a benchmark, since it only proves that it is possible to engineer around performance as much as it is to engineer for it.

Big deal.

wbmw
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext