Skip site navigation (1) Skip section navigation (2)

RE: [HACKERS] inlining

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] (view raw or whole thread)
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



In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-06-12 23:17:27
Subject: template names
Previous:From: Chris AlbertsonDate: 1998-06-12 18:30:31
Subject: dump/load

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group