Re: [HACKERS] inlining

>
> 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