Re: Dramatic speed effect of code-data proximity


spamtrap@xxxxxxxxxx wrote:
Can somebody please explain this effect, observed using a Pentium 4 HT?
The following 32-bit code executes at a dramatically different speed
depending on whether or not the address 'var' is in the same 1 Kbyte
memory page as the code accessing it:

mov ecx,10000000H
test:
mov [var],eax
loop test

The measured timing was about 250 ms when the address 'var' was not in
the same 1 Kbyte page as the code (above or below) but about 36000 ms
(i.e. more than 100 times slower!) when the address 'var' was in the
same 1 Kbyte page as the code. I didn't believe this when I first saw
it but it seems to be easily reproducible.

I'm guessing that the data write invalidates the code cache, requiring
it to be reloaded from main memory each time around the loop. That
would explain the dramatic effect, but I'm not too sure why it should
be necessary.


While I can't verify the effect for that particular processor, it's
quite common on CPUs that have split i- and d-caches. It also would
not surprise me that it's somewhat more expensive than usual on the P4
because of the trace cache. The reason it's done is to detect (and
handle) self-modifying code. Most commonly the conflicting area is the
size of a cache line (although the trace cache complicates that) - any
store into that area results in (at least) a flush of that cache line
from the i-cache. Could this be made less painful? Sure, although it
would clearly add complexity and slow down the i-cache. But why
bother? Code and modifiable storage shouldn't normally even be on the
same *page*.

.

Relevant Pages

  • K6-III "problem"
    ... This machine has an ASUS TVP4 MB with 66 MHz FSB, 512 KByte ... L2 cache, 128 MByte EDO. ... The resulting system is much faster, memory benchmarks show reads that ... The MB reports the ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: in memory data
    ... var can be used, IMO there is no big difference. ... then answer can be session cache. ...
    (microsoft.public.dotnet.framework.performance)
  • Dramatic speed effect of code-data proximity
    ... depending on whether or not the address 'var' is in the same 1 Kbyte ... (i.e. more than 100 times slower!) ...
    (comp.lang.asm.x86)
  • Re: checking cache
    ... i just want to ask if cache checking is possible in javascript? ... var start = new Date.getTime ... var totalTime = end - start ... assume it was in the cache. ...
    (microsoft.public.scripting.jscript)
  • Re: checking cache
    ... You could try to measure the loading time though. ... so cache checking is not possible, then how to measure the loading time? ... var start = new Date.getTime ... Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ ...
    (microsoft.public.scripting.jscript)