Re: A different performance measure

The new numbers look a lot more reasonable! I just could not see how a context
switch could take 100uS, except maybe on a 6-Mhz 80286.

On a related point, I saw this note on comp.linux.development.system and
thought I should pass it along:

> From: pjensen@csi.compuserve.com (Phil Jensen)
> Subject: code alignment - mod 16 vs mod 4
> Date: 19 Jan 1995 11:43:56 -0500
>
> As this may affect kernel efficiency, I thought I'd ask: in my (Slackware)
> 1.0.9 kernel, the compiler obviously used an alignment of 16, but the loader
> used 4. So as you read through zSystem.map, for a while all the entry points
> end in 4, then c, then 0... If 16-byte alignment is worth doing, it's worth
> doing right - this way just wastes space. So I ask - is this still
happening?

> Another compilation thing - has anyone ever actually benchmarked kernel speed
> with and without -fomit-frame-pointer? I haven't, but I've looked at SIZE,
> which is about 3% LARGER with -fomit... Why? Every frame reference is one
> byte longer (the "s-i-b" byte - necessary to get references off of %esp).

I have seen a lot of applications compiled for Linux where -fomit-frame-pointer
is a common optimization. Using s-i-b references are not particularly fast,
especial as Intel applied various RISC optimizations which speed up the simple
instructions (register-to-register, mem-displacement-to-register, and the
like).
Any of the complex indexing modes are penalized and tend to run slower. The
joys of overlapped instruction execution and its associated lockout problems.

-- 
David Koogler (koogler@bedford.progress.com)