Page 4 of 4 FirstFirst ... 234
Results 31 to 40 of 40

Thread: Executable's speed jumping between low and high in 13.1

  1. #31

    Default Submitted to Bugzilla

    Report to bugzilla submitted, # 859561

  2. #32

    Default New kernel, same problem

    Observed the same behavior with kernel 3.13.0-rc8-3.gf011587

    By the way, it looks like the program in Post # 10 still uses libm in some way. Here is what KDE System Guard is showing about the process:


    Code:
    Library Usage
    
    The memory usage of a process is found by adding up the memory usage of each of its libraries, plus the process's own heap, stack and any other mappings. 
    
    Private
    
    60 KB   [heap]
    40 KB   /usr/lib64/libstdc++.so.6.0.18
    24 KB   /lib64/libc-2.18.so
    16 KB   /home/user/a.out
    12 KB   [stack]
    8 KB    /lib64/libgcc_s.so.1
    8 KB    /lib64/libm-2.18.so
    8 KB    /lib64/ld-2.18.so
    
    Shared
    
    480 KB  /usr/lib64/libstdc++.so.6.0.18
    412 KB  /lib64/libc-2.18.so
    108 KB  /lib64/ld-2.18.so
    64 KB   /lib64/libm-2.18.so
    20 KB   /lib64/libgcc_s.so.1
    4 KB    [vdso]

  3. #33

    Default Re: Executable's speed jumping between low and high in 13.1

    On 2014-01-25, ZStefan <ZStefan@no-mx.forums.opensuse.org> wrote:
    >
    > Observed the same behavior with kernel 3.13.0-rc8-3.gf011587
    >
    > By the way, it looks like the program in Post # 10 still uses libm in
    > some way. Here is what KDE System Guard is showing about the process:
    >


    Hmm. I'm not sure it's actually using it. Consider the following `do nothing' program (a.cpp):


    Code:
    int main(int argc, char* argv[]) {
    return 0;
    }
    Now:

    Code:
    sh-4.2$ g++ a.cpp
    sh-4.2$ ./a.out
    sh-4.2$ ldd a.out
    linux-vdso.so.1 (0x00007fffc17fe000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f7680f2d000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f7680c2a000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7680a13000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f7680664000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f7681235000)
    sh-4.2$
    Now convert from C++ to C:

    Code:
    sh-4.2$ mv a.cpp a.c
    sh-4.2$ gcc a.c
    sh-4.2$ ./a.out
    sh-4.2$ ldd a.out
    linux-vdso.so.1 (0x00007fffa31b5000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f3fca218000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f3fca5c7000)
    sh-4.2$
    From this I infer that g++ (not gcc) includes libm as a library dependency even if it isn't explicity included or used
    in code.

  4. #34

    Default Re: Executable's speed jumping between low and high in 13.1

    I will re-program the code from C++ to C and see how the speed behaves. Will take a few days.

  5. #35

    Default Re: Executable's speed jumping between low and high in 13.1

    On 2014-01-28, ZStefan <ZStefan@no-mx.forums.opensuse.org> wrote:
    > I will re-program the code from C++ to C and see how the speed behaves.
    > Will take a few days.


    Of course, you're free to do so, but I don't think it will make any difference because you'll end up using libm in C
    anyway. My guess in C++ is that libstdc++ pulls in libm and so g++ will link to libm whether or not it's needed by your
    C++ code. Comparing the assembler outputs for the C and C++ versions of the `do nothing' program above shows identical
    machine instructions, and I strongly suspect the same will be the case after you translate your C++ to C.

  6. #36

    Default Same jumping of speed with C code and with bechmarks

    I translated the program into C, compiled and ran, and the same unstable behavior is observed.

    The executable does not use libm.

    I also ran a small benchmark called himeno, observed the same.

    Here's the code:

    Code:
    
    #include <stdio.h> 
    #include <stdlib.h>
    #include <time.h>
    
    //---------------------------------------------------------------------------
    static const volatile double COS2PI5  =  0.30901699437494745;
    static const volatile double SIN2PI5  =  0.95105651629515353;
    static const volatile double COS4PI5  = -0.80901699437494734;
    static const volatile double SIN4PI5  =  0.58778525229247325;
    
    //---------------------------------------------------------------------------
    void fft5(double* ro, double* io, double* ri, double* ii) {
    double sr1, sr2, si1, si2, dr1, dr2, di1, di2;
    double ar1, ar2, ai1, ai2, br1, br2, bi1, bi2;
    
    sr1 = ri[1] + ri[4]; si1 = ii[1] + ii[4];
    dr1 = ri[1] - ri[4]; di1 = ii[1] - ii[4];
    sr2 = ri[2] + ri[3]; si2 = ii[2] + ii[3];
    dr2 = ri[2] - ri[3]; di2 = ii[2] - ii[3];
    
    ar1 = ri[0] + sr1*COS2PI5 + sr2*COS4PI5;
    ai1 = ii[0] + si1*COS2PI5 + si2*COS4PI5;
    ar2 = ri[0] + sr1*COS4PI5 + sr2*COS2PI5;
    ai2 = ii[0] + si1*COS4PI5 + si2*COS2PI5;
    
    br1 = dr1*SIN2PI5 + dr2*SIN4PI5;
    bi1 = di1*SIN2PI5 + di2*SIN4PI5;
    br2 = dr1*SIN4PI5 - dr2*SIN2PI5;
    bi2 = di1*SIN4PI5 - di2*SIN2PI5;
    
    ro[0] = ri[0] + sr1 + sr2; io[0] = ii[0] + si1 + si2;
    ro[1] = ar1 + bi1;         io[1] = ai1 - br1;
    ro[2] = ar2 + bi2;         io[2] = ai2 - br2;
    ro[3] = ar2 - bi2;         io[3] = ai2 + br2;
    ro[4] = ar1 - bi1;         io[4] = ai1 + br1;
    }
    
    
    //---------------------------------------------------------------------------
    int main(int argc, char* argv[])
    {
    int i, j, n, N, M;
    M = 50;
    N = 50000000;
    n = 5;
    clock_t t0, t1;
    
    double* ri = (double*)(malloc(sizeof(double) * n));
    double* ii = (double*)(malloc(sizeof(double) * n));
    double* ro = (double*)(malloc(sizeof(double) * n));
    double* io = (double*)(malloc(sizeof(double) * n));
    
    for (i=0; i<n; i++) {ri[i]=(double)i; ii[i]=(double)(n-i);}
    
    fft5(ro, io, ri, ii);
    
    printf("Result: \n");
    for (i = 0; i<n; i++) 
     {
      printf("%5d:   (%12.8lf,  %12.8lf) \n", i, ro[i], io[i]);
     }
    
    for (j = 0; j<M; j++) {
     t0 = clock();
     for (i = N; i; i--) {fft5(ro, io, ri, ii);}
     t1 = clock();
     printf("j: %4d   Number of clock cycles = %12d\n", j, (int)(t1-t0));
    }
    
    free(ri); free(ii); free(ro); free(io);
    return 0;  
    }

  7. #37

    Default Re: Executable's speed jumping between low and high in 13.1

    On 2014-01-29, ZStefan <ZStefan@no-mx.forums.opensuse.org> wrote:
    > I translated the program into C, compiled and ran, and the same unstable
    > behavior is observed.
    >
    > The executable does not use libm.


    Ahh. I thought you were previously referring to your program (which calculates cosines and sines) not mine - I already
    had a C version of my program! But your experiment has me thinking - do you see the same behaviour when you compile as a
    32-bit executable (e.g. gcc -m32 code.c)? IIRC, gcc compiles 64-bit executables using SIMD instructions for many
    mathematical operations whereas 32 bit compiles with bog standard FPU instructions. Comparing the two may therefore help
    identify the problem area.

    I suppose the definitive test to exclude compilation issues entirely is to rewrite the mathematical function in
    inline assembler because that we bypass the compiler. However, it's at least 100 lines of assembler, whether you use
    SIMD or FPU instructions. My guess it's not worth it, because you also say...

    On 2014-01-29, ZStefan <ZStefan@no-mx.forums.opensuse.org> wrote:
    > I also ran a small benchmark called himeno, observed the same.


    ....which shows a precompiled benchmark program suffers a similar fate. Again, I think the problem is either the machine
    (unlikely if it's fine with other openSUSE versions) or its interaction with the kernel. Another possibility may be
    unwanted effects of openSUSE patches. To confirm the kernel is problem, I'd run the same benchmarks on another distro
    with the same kernel version (3.11) such as Mint Petra.


  8. #38

    Default 32 bit executable runs the same way: bistable speed

    Thanks for the advice.

    I compiled with -m32. The running executable shows the same bistable behavior. Overall, it is about 20% slower than the 64 bit executable.

  9. #39

    Default Re: Executable's speed jumping between low and high in 13.1

    On 2014-01-30, ZStefan <ZStefan@no-mx.forums.opensuse.org> wrote:
    >
    > Thanks for the advice.
    >
    > I compiled with -m32. The running executable shows the same bistable
    > behavior. Overall, it is about 20% slower than the 64 bit executable.


    Interesting. IIRC mathematical instructions in 32-bit are compiled by using FPU instructions rather than SSE/SSE2 (and
    that's why it's slower). You now have further evidence that the bistable performance is due to something outside the
    compiler (i.e. hardware/kernel/external processes). The definitive proof is of course writing the maths in assembler,
    but I don't think there's much point. I suspect any program you run will show bistable behaviour. My guess is the
    problem is related to the kernel's handling of your CPU. Can you try another distro that uses the same kernel (3.11)? If
    you can reproduce the same behaviour (any thereby exclude openSUSE patches), then I think it's a bug report to the
    kernel developers... if you can't then it's an openSUSE bugzilla.

  10. #40

    Default Same with Fedora

    Quote Originally Posted by flymail View Post
    My guess is the problem is related to the kernel's handling of your CPU.
    Yes, this is the most likely reason, with the current knowledge.


    Quote Originally Posted by flymail View Post
    Can you try another distro that uses the same kernel (3.11)? If you can reproduce the same behaviour (any thereby exclude openSUSE patches), then I think it's a bug report to the kernel developers... if you can't then it's an openSUSE bugzilla.
    I ran Fedora Live from a USB stick, observed the same bistable behavior. Kernel is 3.11.10-301.fc20.x86_64.

    This is the third kernel I test and the second computer (on the powerful computer, bistable behavior is now gone, after updates).

    I reported the finding to bugzilla. There was an exchange on bugzilla about the governor and CPU frequencies, but I don't understand much of it. During running, the frequency does not change.

Page 4 of 4 FirstFirst ... 234

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •