On Thu, 9 Feb 2006 20:09:41 +0100 Bernhard Auzinger <[EMAIL PROTECTED]> wrote:
> I mean, > how do you get the code of your forked bashes away from your cpu > cache to have it free for kernel code? Forked bash's all use the same image so don't stress the on-chip instruction cache any more than one bash does. You do lose memory for the data needed for each bash, of course - hence the loss of at least one page per process. However unless you actually start swapping to disc (which won't happen if Duncan has no swap set up :) ) this isn't a problem. > A long time ago . . ., I was testing some CFLAGS on my own programs. > I wrote a fast-fourier algorithm myself, only to see the "impressive" > difference between Os, O3 and some other optimisation flags. I fed my > fast-fourier algorithm with a large amount of input. But no matter > how hard I tried to get it faster by changing the flags, it didn't > work. The difference is marginal and not every flag brings > improvement for every program. The only thing that changed a lot was > the time gcc needs to perform those optimisations. I'd guess that your FFT was spending most of its time in unavoidable floating point ops which may explain how various options made little difference. You're right of course - in the end the only way to find out what's actually fastest on a given machine is to try various flags and see what happens. Multiple level caches, long instruction pipelines, paging architecture an a myriad of other things all go to make it difficult to predict exactly what will and won't be faster. P.S. When replying to Duncan's extensive posts, could we trim parts that aren't relevant to the reply? -- Kevin F. Quinn
signature.asc
Description: PGP signature
