PPC64 Compiler bug !!

[linas at austin.ibm.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 at 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


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/