felix winkelmann wrote:
On 9/7/06, Brandon J. Van Every <[EMAIL PROTECTED]> 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
_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users
