Re: PPC64 Compiler bug !!

[linas at austin dot ibm dot com]

Hi,

Well, there still remains the performance issue, that this 
"optimization" can slow things down, due to the FPU lazy save/restore, 
and I guess the soon-to-come vector-unit lazy save/restore.  The 
performance gain from this feature is questionable, and may be 
a performance loss, depending on the number of context switches 
per second, vs. the number of times an app uses implicit floats. 
If its used infrequently, its a net performance loss.  (Ditto 
for the vector-unit usage).

Lets do the math:
Assume 1000 ctx's/second on a loaded system.  Assume 1000 cycles
burnt on each lazy-restore.  We have to gain a lot to make up for
this loss.  Each process gets 1 millisec time slice. On a 1GHz
machine, that's about 1 M cycles. To pay for the lazy-restore,
this optimization needs to be "worth it" more often than once per
thousand insn's.   Its not clear to me that that is the case.
If its not, its a net performance loss.

We can argue whether my numbers are off by a factor of 5 or 10,
but the point is, the less frequently this 'optimization' is 
actually used or is useful, the more of a performance hit it 
becomes.  Turning it off completely and thoroughly would 
actually improve performance in this case; I find it curious 
how it gets inverted like this.


Ditto for  Geert Bosch's response:
>> Well, that belies the point. I think I can safely state that most
>> programmers, when faced with an all-integer program, would assume
>> that the compiler generated pure-integer code,
>
> On modern machines with modern compilers, this is no lnoger
> a reasonable assumption. In the future, GCC might even use
> vector registers while the programmer writes pure scalar code.

If the linux kernel is going to handle vector units with a lazy
save/restore scheme, the performance benefit of using the vector
regs might be (easily) overcome by the performance hit to save the 
context.

--linas

p.s.  The rest of this reply is off-topic and political ....

On Tue, Jun 17, 2003 at 02:07:16PM -0700, Mike Stump wrote:
> 
> On Tuesday, June 17, 2003, at 09:28 AM, linas@austin.ibm.com wrote:
> >
> > Well, that belies the point. I think I can safely state that most
> > programmers, when faced with an all-integer program, would assume
> > that the compiler generated pure-integer code, and thus it would
> > never occur to them to study or take interest in any float-point
> > flags.
> 
> Most programmers don't have a clue about what the compiler can and

One of these fabled programmers was sent to me for help with thier kernel 
crash...

> If the kernel requires it and the guide doesn't mention it, that is a
> bug in the guide.

What kernel guide?  I've been poking at the Linux kernel for years,
and have yet to see something called 'the kernel guide'.  There's
megabytes of documentation out there; I haven't read it all, I doubt
anyone has.  Besides, grep -r soft-float Documentation/* comes up 
empty.  (there's 6MB of stuff there, and its not even the 'good' 
kernel docs.)

> I understand sympathize with your pain.  :-(  It sounds as if
> -mno-implicit-fp matches the programmers expectations from your point
> of view.

Well, it wasn't my pain, it was someone elses.   And it wasn't just
my point of view; more'n half-a-dozen other kernel programmers heard
about this problem and not a single one of them knew about this 'feature.' 
I'm just reporting on how others seem to see the world.


--linas