At 4:50 AM -0700 6/12/98, Stupor Genius wrote:
>One comment...when you ran the tests in succession, could the cache be
>responsible for the timing groupings in the same test? Should a
>little program be run in between to "flush" the cache full of garbage
>so each real run will miss? Seem to recall a little program, in CUJ,
>I think, that set up a big array and then iterated over it to trash
Obviously I'm commenting at second hand, and perhaps this problem is
handled properly, but:
Many CPU's have independent data and instruction caches. Setting up a big
array and moving through it will flush the data cache, but most benchmark
anomalies are likely to be due to the instruction cache, aren't they?
Also, if you have a process (program) stop and then restart is the OS smart
enough to reconnect the VM state in such a way that the cache isn't flushed
anyway? Can it even preserve cache coherence through a fork (when the VM
state is mostly preserved)? I doubt it.
That said if you are testing multiple SQL statements within a single
connection (so the backend doesn't fork a new process) then I could see
some anomalies. Otherwise I doubt it.
Anyone know better?
Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h(dot)b(dot)hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 1998-06-12 23:17:27|
|Subject: template names|
|Previous:||From: Chris Albertson||Date: 1998-06-12 18:30:31|