Thread

1. inlining

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-06-12T02:58:24Z

   Here is a list of usenet articles about inlining that just appeared in
   comp.compilers.
   
   
   -- 
   Bruce Momjian                          |  830 Blythe Avenue
   maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
     +  If your life is a hard drive,     |  (610) 353-9879(w)
     +  Christ can be your backup.        |  (610) 853-3000(h)
   

2. Re: [HACKERS] inlining

   David Gould <dg@illustra.com> — 1998-06-12T05:08:28Z

   > 
   > Here is a list of usenet articles about inlining that just appeared in
   > comp.compilers.
   
   Good discussion and I am happy to see you post it. I follow comp.arch
   regularly and there are often very interesting hints there too amid
   the dross. Actually it is not a high traffic group except for the
   occasional "sunspot cycle".
   
   > optimizing compiler. The code placement tool (ala Pettis & Hanson)
   > needs to be inlining-aware. Code growth is not that big of a problem
   > in many codes. Many very large codes have relatively small dynamic hot
   > spots. Database codes are a notable exception. Another big downside
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Database codes are the mothers heartbreak of both the compiler design and
   hardware architecture communities. They blow up caches, there are never
   5 instructions in a row before a branch, they whack at the whole working
   set (which blows up the tlb and bus), they have poor locality so when they
   miss cache you can't fix it with bandwith. Everything depends on everything
   so you can't parallize at small scales. Hopeless really.
   
   Btw, I sure wish someone would comment on the S_LOCK analysis even if only
   to tell me not to make such long posts as it wastes bandwidth. Or was it just
   too long to read?
   
   -dg
   
   
   David Gould            dg@illustra.com           510.628.3783 or 510.305.9468 
   Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
   "Don't worry about people stealing your ideas.  If your ideas are any
    good, you'll have to ram them down people's throats." -- Howard Aiken
   
   

3. RE: [HACKERS] inlining

   Stupor Genius <stuporg@erols.com> — 1998-06-12T11:50:34Z

   > Btw, I sure wish someone would comment on the S_LOCK analysis even if only
   > to tell me not to make such long posts as it wastes bandwidth. Or 
   > was it just too long to read?
   
   I read it all! Great analysis of the situation and not a waste, IMHO.
   
   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.
   
   Darren  aka  stuporg@erols.com
   
   

4. Re: [HACKERS] inlining

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-06-12T12:21:18Z

   > 
   > > Btw, I sure wish someone would comment on the S_LOCK analysis even if only
   > > to tell me not to make such long posts as it wastes bandwidth. Or 
   > > was it just too long to read?
   > 
   > I read it all! Great analysis of the situation and not a waste, IMHO.
   > 
   > 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.
   
   Yes, that is a good point.  When testing in a loop, the function is in
   the cache, while in normal use, the function may not be in the cache
   because of intervening instructions.
   
   -- 
   Bruce Momjian                          |  830 Blythe Avenue
   maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
     +  If your life is a hard drive,     |  (610) 353-9879(w)
     +  Christ can be your backup.        |  (610) 853-3000(h)
   
   

5. RE: [HACKERS] inlining

   Henry B. Hotz <hotz@jpl.nasa.gov> — 1998-06-12T20:19:56Z

   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.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu