Re: [Chicken-users] optimization flags

[Brandon J. Van Every]

felix winkelmann wrote:
> On 9/7/06, Brandon J. Van Every <address@hidden> wrote:
> > For instance, Felix has this
> > "-Os" philosophy, that optimizing for size yields the best 
> > performance.  I'd
> > like to see hard evidence of that.  I certainly don't take it on 
> > faith, or
> > on principles.
>
> Brandon,
>
> Do you think I'm just doing this out of a spontaneous mood? Do you 
> think I
> haven't tested this? Yes, I'm sometimes susceptive to haphazard design
> decisions, but can't you just trust me on this? (Or, alternatively, 
> read the
> mailing list archives).

I made my early career on low-level ASM optimizations, on the DEC Alpha, 
the best CPU on the planet at the time.  I competed on benchmarks for a 
living.  I've also done plenty of x86 ASM work.  The reason I say, "I 
don't know," is because I've never studied the caching behavior of 
garbage collectors.  If that weren't in the picture, if it were just 
straight line looping code, I *do* know.  Optimizing for size is not how 
things get faster at the CPU instruction level.  I freely admit that 
garbage collectors may be an arena where memory footprint wins over CPU 
instruction cycles.  But generally it's the footprint of the data cache 
that matters, not the instruction cache.  Which is why you pad the 
instructions to get the alignment to get the fastest CPU cycles.  But 
then again, you're doing all sorts of weird things in your Scheme-to-C 
compilation that I don't know about, so maybe instruction size does 
matter.  Maybe maybe maybe.

Your benchmarking decisions about the stack size were completely wrong, 
both in their sampling rate (average of 3 samples?!?), and how they were 
incorporated into the build regime (user doesn't know he's benchmarking, 
checks his e-mail.)  So no, I do not quite trust your benchmarking 
methodologies.  I do not expect that you made things up about -Os, I 
imagine you tested it somehow.  But, you may have undersampled it.  But, 
I have not read the archives, nor am I going to read them at this time.  
Proving benchmark optimizations is a lot of work, something I'm not 
prepared to touch for quite awhile.  I went bankrupt on premature 
optimization, to the tune of $82K of debt.  It was a hard lesson, and in 
terms of quality of life I'm still paying for it.  When I have a game 
that's not fast enough, then I'll worry about rigorous benchmarks.

Every elite optimization jock thinks he knows better than the next one, 
so don't take it personally.  :-)


Cheers,
Brandon Van Every