From: | "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov> |
---|---|
To: | "Stupor Genius" <stuporg(at)erols(dot)com>, "Hackers" <pgsql-hackers(at)postgreSQL(dot)org> |
Cc: | "David Gould" <dg(at)illustra(dot)com> |
Subject: | RE: [HACKERS] inlining |
Date: | 1998-06-12 20:19:56 |
Message-ID: | v03130308b1a73bf1f186@[137.78.218.94] |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
>the cache.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-06-12 23:17:27 | template names |
Previous Message | Chris Albertson | 1998-06-12 18:30:31 | dump/load |