>> if gcc uses more memory than physically available it spends a >> _very_ long time swapping > > Swapping, what's that? Here's $20, go buy a gigabyte. You don't know whay swapping is? Shifting memory over from physical RAM to the hard drive when not in use, and putting it back in RAM when in use.
> Now, having said that, we do believe that it would make for > interesting research to try less memory intensive algorithms, or to > rearrange code so that the working set is reduced to help boost > cache hits. Currently gcc takes a cache miss every 20 > instructions, or some ungodly number, and that really saps > performance. Would it be possible for an option -fprofile-cache that allows GCOV to profile cache hits/misses? That would really pay off during a profiled bootstrap. And an option -ftry-keeping-on-stack that (on machines allowing random access[1] to the stack) attempts to use the upper part of the stack as a storage for automatic (or equivlent for programming langauge) variables on stack? That would help[2] reduce GCC's cache misses, because not only is it cached, it's there. Samuel Lauber [1] I don't know if any machines do, but last time I looked at `-1(%esp)', I thought so. [2] It would also have the disadvantage that if a program wrecks havoc on the stack or overflows it, some internal variables might get out of sync and cause the generated program to core-dump (a lesson to be learned from GCC 3.3.3's [flaky] SSA optimizer). -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
