[Linux-ia64] strange performance behaviour with floats

[Linux-ia64] strange performance behaviour with floats

[Volker Birk]

[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]

Hello,

I'm wondering about the strange behaviour of the Linux scheduling on my
rx5670:

---------------------------- snip --------------------------------------
bronto:~ # cat dingens.c
#include <stdio.h>

int main()
{       
        int i;
        double x, y;

        x = rand(); y = rand();

        printf("x = %.2g, y = %.2g\n", x, y);

        for (i=0;i<1000000000;i++) {
                x *= y;
//              y /= x;
        }
}

bronto:~ # gcc -O2 -o dingens dingens.c
bronto:~ # time ./dingens
x = 1.8e+09, y = 8.5e+08

real    0m1.486s
user    0m1.485s
sys     0m0.001s
bronto:~ # time ./dingens
x = 1.8e+09, y = 8.5e+08

real    0m4.450s
user    0m4.450s
sys     0m0.000s
bronto:~ # 
---------------------------- snap --------------------------------------

There is really no I/O while that time (so it may not be a problem with
the scheduling on the CPU which handles the interrupts).

No load at all, time and dingens are the only processes which do not
sleep.

Sometimes that computing consumes 1.5 sec. CPU time, sometimes 4.5 sec.
I cannot find a rule for that, nor can I predict when it will last how
long.

Some machine info:

---------------------------- snip --------------------------------------
bronto:~ # uname -a
Linux bronto 2.4.19 #11 SMP Sat Nov 2 18:47:02 CET 2002 ia64   GNU/Linux
bronto:~ # head -n 13 /proc/cpuinfo 
processor  : 0
vendor     : GenuineIntel
arch       : IA-64
family     : Itanium 2
model      : 0
revision   : 7
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 900.000000
itc MHz    : 900.000000
BogoMIPS   : 1346.37
bronto:~ # grep ^processor /proc/cpuinfo
processor  : 0
processor  : 1
processor  : 2
processor  : 3
bronto:~ # 
---------------------------- snap --------------------------------------

Does anybody know what's up with that machine?

Volker Birk
-- 
*** ebios Informationssysteme, Germany      ***
*** Gut-Betha-Platz 1, 88339 Bad Waldsee    ***
*** Phone +49-7524-93421 Fax +49-7524-93423 ***
*** mailto:vb@ebios.de                      ***

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Linux-ia64] strange performance behaviour with floats

[Hideki Yamamoto]

 Hello.

 This is really strange as you said.

 Firstly, I suspected the ldd. I mean this is caused by
 the dinamic library(glibc) is on the cache when the ldd running.
 When your attached program compiled with -static
 switch is running, it seems the strange behaviour is disappered.

 However, I have changed the source you attached as follows.
 The strange behaviour is also disappered.

 Hmm...

#include <stdio.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>

int main()
{
        int i;
        double x, y;
        struct rusage r;
        double usec, ssec;

        x = rand(); y = rand();

        printf("x = %.2g, y = %.2g\n", x, y);

        for (i=0;i<1000000000;i++) {
                x *= y;
//              y /= x;
        }
        getrusage(RUSAGE_SELF,&r);
        //usec = (double)r.ru_utime.tv_sec+((double)r.ru_utime.tv_usec/1000000.);
        //ssec = (double)r.ru_stime.tv_sec+((double)r.ru_stime.tv_usec/1000000.);
        //printf("time = %f(%f+%f)\n", usec+ssec, usec, ssec);
}

End of my email
--
Yours faithfully,
Hideki Yamamoto   (V).v.(V) # Empowered by Innovation

At Fri, 14 Feb 2003 10:02:57 +0100,
Volker Birk wrote:
> 
> [1  <text/plain; iso-8859-1 (quoted-printable)>]
> Hello,
> 
> I'm wondering about the strange behaviour of the Linux scheduling on my
> rx5670:
> 
> ---------------------------- snip --------------------------------------
> bronto:~ # cat dingens.c
> #include <stdio.h>
> 
> int main()
> {       
>         int i;
>         double x, y;
> 
>         x = rand(); y = rand();
> 
>         printf("x = %.2g, y = %.2g\n", x, y);
> 
>         for (i=0;i<1000000000;i++) {
>                 x *= y;
> //              y /= x;
>         }
> }
> 
> bronto:~ # gcc -O2 -o dingens dingens.c
> bronto:~ # time ./dingens
> x = 1.8e+09, y = 8.5e+08
> 
> real    0m1.486s
> user    0m1.485s
> sys     0m0.001s
> bronto:~ # time ./dingens
> x = 1.8e+09, y = 8.5e+08
> 
> real    0m4.450s
> user    0m4.450s
> sys     0m0.000s
> bronto:~ # 
> ---------------------------- snap --------------------------------------
> 
> There is really no I/O while that time (so it may not be a problem with
> the scheduling on the CPU which handles the interrupts).
> 
> No load at all, time and dingens are the only processes which do not
> sleep.
> 
> Sometimes that computing consumes 1.5 sec. CPU time, sometimes 4.5 sec.
> I cannot find a rule for that, nor can I predict when it will last how
> long.
> 
> Some machine info:
> 
> ---------------------------- snip --------------------------------------
> bronto:~ # uname -a
> Linux bronto 2.4.19 #11 SMP Sat Nov 2 18:47:02 CET 2002 ia64   GNU/Linux
> bronto:~ # head -n 13 /proc/cpuinfo 
> processor  : 0
> vendor     : GenuineIntel
> arch       : IA-64
> family     : Itanium 2
> model      : 0
> revision   : 7
> archrev    : 0
> features   : branchlong
> cpu number : 0
> cpu regs   : 4
> cpu MHz    : 900.000000
> itc MHz    : 900.000000
> BogoMIPS   : 1346.37
> bronto:~ # grep ^processor /proc/cpuinfo
> processor  : 0
> processor  : 1
> processor  : 2
> processor  : 3
> bronto:~ # 
> ---------------------------- snap --------------------------------------
> 
> Does anybody know what's up with that machine?
> 
> Volker Birk
> -- 
> *** ebios Informationssysteme, Germany      ***
> *** Gut-Betha-Platz 1, 88339 Bad Waldsee    ***
> *** Phone +49-7524-93421 Fax +49-7524-93423 ***
> *** mailto:vb@ebios.de                      ***
> [2  <application/pgp-signature (7bit)>]
> 

Re: [Linux-ia64] strange performance behaviour with floats

[Volker Birk]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

On Fri, Feb 14, 2003 at 07:50:19PM +0900, Hideki Yamamoto wrote:
>  This is really strange as you said.
>  Firstly, I suspected the ldd. I mean this is caused by
>  the dinamic library(glibc) is on the cache when the ldd running.
>  When your attached program compiled with -static
>  switch is running, it seems the strange behaviour is disappered.

It does not disappear.

Also with linking with -static, that strange behaviour is still there.
Does anybody else has that problem? Does anyone know what's up?

VB.
-- 
*** ebios Informationssysteme, Germany      ***
*** Gut-Betha-Platz 1, 88339 Bad Waldsee    ***
*** Phone +49-7524-93421 Fax +49-7524-93423 ***
*** mailto:vb@ebios.de                      ***

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Linux-ia64] strange performance behaviour with floats

[David Mosberger]

Hi Volker,

>>>>> On Fri, 14 Feb 2003 10:02:57 +0100, Volker Birk <vb@ebios.de> said:

  Volker> Hello, I'm wondering about the strange behaviour of the
  Volker> Linux scheduling on my rx5670:

Can you reproduce the behavior with a standard 2.4.xx ia64 kernel (not
with Red Hat's heavily patched kernel)?

	--david

Re: [Linux-ia64] strange performance behaviour with floats

[David Mosberger]

>>>>> On Thu, 20 Feb 2003 09:35:02 +0100, Volker Birk <vb@ebios.de> said:

  Volker> On Wed, Feb 19, 2003 at 11:09:36AM -0800, David Mosberger
  Volker> wrote: Hello, I'm wondering about the strange behaviour of
  Volker> the Linux scheduling on my rx5670:

  >> Can you reproduce the behavior with a standard 2.4.xx ia64 kernel
  >> (not with Red Hat's heavily patched kernel)?

  Volker> That is a standard 2.4.xx ia64 kernel (with ia64 patches
  Volker> from kernel.org).

  Volker> bronto:~ # uname -a Linux bronto 2.4.19 #11 SMP Sat Nov 2
  Volker> 18:47:02 CET 2002 ia64 GNU/Linux bronto:~ #

Hmmh, that's really strange.  I assume you realize that your
test-program doesn't really do what the source code suggests (the
loop-body gets optimized away), but regardless the high variation
you're seeing seems wrong.  Are you re-directing the kernel console to
a serial line?  If so, make sure there is no logging activity when the
program runs slower (especially a slow baud-rate can "stall" the
kernel for non-trivial amounts of time).

	--david

Re: [Linux-ia64] strange performance behaviour with floats

[Volker Birk]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Thu, Feb 20, 2003 at 09:52:43AM -0800, David Mosberger wrote:
> Hmmh, that's really strange.  I assume you realize that your
> test-program doesn't really do what the source code suggests (the
> loop-body gets optimized away), but regardless the high variation
> you're seeing seems wrong.

I think, optimazation does not matter on that point.

> Are you re-directing the kernel console to
> a serial line?

No.

VB.
-- 
*** ebios Informationssysteme, Germany      ***
*** Gut-Betha-Platz 1, 88339 Bad Waldsee    ***
*** Phone +49-7524-93421 Fax +49-7524-93423 ***
*** mailto:vb@ebios.de                      ***

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Linux-ia64] strange performance behaviour with floats

[David Mosberger]

>>>>> On Thu, 20 Feb 2003 20:59:47 +0100, Volker Birk <vb@ebios.de> said:

  Volker> On Thu, Feb 20, 2003 at 09:52:43AM -0800, David Mosberger
  Volker> wrote:

  >> Hmmh, that's really strange.  I assume you realize that your
  >> test-program doesn't really do what the source code suggests (the
  >> loop-body gets optimized away), but regardless the high variation
  >> you're seeing seems wrong.

  Volker> I think, optimazation does not matter on that point.

I looked into this a bit more.  Your test program is basically a
1-cycle loop:

4000000000000770:       0a 00 00 00 01 00       [MMI]       nop.m 0x0
4000000000000776:       00 00 00 02 00 00                   nop.m 0x0
400000000000077c:       00 00 04 00                         nop.i 0x0
4000000000000780:       1c 00 00 00 01 00       [MFB]       nop.m 0x0
4000000000000786:       00 00 00 02 00 a0                   nop.f 0x0
400000000000078c:       f0 ff ff 48                         br.cloop.sptk.few 40
This is because gcc optimizes away to loop-body.  If you change the loop
to:

        for (i=0;i<1000000000;i++) {
		asm volatile ("nop 0;;");
        }

you'll get a 2-cycle loop which will execute consistently in 2 seconds
(on a 1GHz McKinley), which is what you'd expect.  1-cycle loops are
never optimal on McKinley (that's why the Linux bogomips comes out at
1438 instead of 2000, for example), though I don't know the exact
micro-architectural details that cause this.

	--david