Page 1 of 4 123 ... LastLast
Results 1 to 10 of 40

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

  1. #1

    Unhappy Executable's speed jumping between low and high in 13.1

    I have an executable which is doing math calculations and array operations, using about 1 GB of RAM. The executable is similar to the one described in https://forums.opensuse.org/showthre...-opensuse-12-3

    It appears that the execution speed can get two values, differing three times from each other! The speed changes perhaps depending on reboot, compilation, user. There are no intermediate speeds: only the slow and quick one. Same is observed with libm version 15, which I check by using LD_PRELOAD.

    The CPU's frequency is fixed. The computer is not otherwise loaded.

    I cannot figure out when the executable starts is slow mode and when in quick mode; it looks random.

    I wonder what is the reason and how to proceed with diagnostics and correction.

  2. #2

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

    On 2014-01-14, ZStefan <ZStefan@no-mx.forums.opensuse.org> wrote:
    > I have an executable which is doing math calculations and array
    > operations, using about 1 GB of RAM. The executable is similar to the
    > one described in http://tinyurl.com/pgzwclo


    To diagnose any optimisation issue, you'll need the provide the code, and specify whether it's compiling in a 32- or 64-
    bit environment.

    > It appears that the execution speed can get two values, differing three
    > times from each other! The speed changes perhaps depending on reboot,
    > compilation, user. There are no intermediate speeds: only the slow and
    > quick one. Same is observed with libm version 15, which I check by using
    > LD_PRELOAD.


    I can think of two likely causes of bistable benchmarks from the same compile:

    1. Stack alignment. Either the stack is aligned for a given execution or not. IIRC GNU's C/C++ compiler only guarantees
    a constant stack offset but not stack alignment. To guarantee alignment, you have to code it yourself inline.

    2. Data alignment. If you're using (directly or indirectly) SIMD intrinsics, then your data is either aligned according
    to 128-bit boundaries or not. If not, performance will be seriously degraded (although I'm told this is less of an issue
    with modern processors... but I don't believe it).

    I can think of few more exotic causes, but I wouldn't like to guess without seeing the code.


  3. #3

    Default Conditions for slowdown are unclear

    I don't want to bring the whole code here, but it is similar to the code in Post # 20 of https://forums.opensuse.org/showthre...-opensuse-12-3

    There is a call to a function, executed in a loop. The function does math calculations similar to the Post 20. Nothing fancy; just a computation with several math functions like sin, cos, rand, and arithmetic.

    Somehow, in the years before there was no need to program stack alignment and data alignment, and the program ran normally.

    In opensuse 12.3 there was a major bug in libm slowing down computation by a factor of 3. In opensuse 13.1, I observe these jumps in speed. Never seen such a thing before, in any computer. Three times is too much.

    I compiled and ran the code in opensuse 12.2. Runs normally every time. Don't remember any slowdowns with several previous versions.

    With opensuse 13.1, in one computer I observe mostly normal running (99% of time, but right after installation it was 50%). In another computer, I observe mostly slow running, 95% of time.

    Did somebody again screwed up gcc, g++, glibc, kernel, opensuse or something else, in an attempt to improve?

    I will try to figure out conditions under which the program runs normally. Looks like more chances for normal run are fresh after reboot, and when there is external storage connected.

    I have checked the RAM with memtest. The OS is updated often. Swap is not used. This is 64 bit computer running 64 bit opensuse 13.1. gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux). Kernel 3.11.6-4-desktop, 64 bit.

  4. #4

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

    On 2014-01-15, ZStefan <ZStefan@no-mx.forums.opensuse.org> wrote:
    >
    > I don't want to bring the whole code here, but it is similar to the code
    > in Post # 20 of http://tinyurl.com/pgzwclo


    Without being to compile your specific code myself, I can't really test and work out why you are seeing problems.

    > There is a call to a function, executed in a loop. The function does
    > math calculations similar to the Post 20. Nothing fancy; just a
    > computation with several math functions like sin, cos, rand, and
    > arithmetic.


    A loop calling a leaf function isn't as efficient as incorporating the loop within the leaf function, and I don't think
    external looping improves branch point prediction either. Anyway, varying performances has little to do with branch
    point prediction, unless the number of loop iterations is data (or data-sign)-dependent.

    > Somehow, in the years before there was no need to program stack
    > alignment and data alignment, and the program ran normally.


    This is not true. In years before, if your data wasn't aligned and SSEn instructions were executed, you'd get a
    segmentation fault. Some compilers using intrinsics like to try and hide this from you, but in my opinion this approach
    is counterproductive.

    > In opensuse 12.3 there was a major bug in libm slowing down computation
    > by a factor of 3. In opensuse 13.1, I observe these jumps in speed.
    > Never seen such a thing before, in any computer. Three times is too
    > much.


    I don't think it's ever been called a `bug' because it gets the right answer. The libm modification has the benefit that
    the result is less CPU architecture-dependent but at the cost of taking a longer time.

    > I compiled and ran the code in opensuse 12.2. Runs normally every time.
    > Don't remember any slowdowns with several previous versions.
    > With opensuse 13.1, in one computer I observe mostly normal running (99%
    > of time, but right after installation it was 50%). In another computer,
    > I observe mostly slow running, 95% of time.


    If the same compiled executable gives bistable performance with constant background processes running, this can only
    result one or more of three issues:

    1. Data: different floating point data can dramatically affect performance (e.g. with the introduction of Infs/NaNs).
    2. Data: some data addresses read within the executable are more quickly accessed than others typically due to
    differences in address alignment (or address distances from related data).
    3. Data: data processing outside the executable (e.g. external processes, swap memory) can very easily impact variably
    on the performance of the binary machine instructions running inside the executable.

    Since you found everything was `normal' under 12.2, #1 is unlikely.

    > Did somebody again screwed up gcc, g++, glibc, kernel, opensuse or
    > something else, in an attempt to improve?


    It's not the compiler or library - if something really was screwed up you'd never see a `good' run. I don't know enough
    about the kernel or openSUSE to comment on whether it's anything do with them, but I suspect not.

    > I will try to figure out conditions under which the program runs
    > normally.


    Again, please specify whether your compiling architecture (e.g. 32 vs 64 bit) as this changes the shortlist of likely
    causes.

    > Looks like more chances for normal run are fresh after reboot,
    > and when there is external storage connected. I have checked the RAM.
    > The OS is updated often. Swap is not used.


    Comes back to likely cause being data-addressing issues as the memory burden changes from startup. Can't help you
    without the code though.

  5. #5

    Default A sample program with bistable speed

    This is the simplified program. When I compile and run it on a computer, the speed of one iteration appears to be bistable, with durations varying about 2.5 times. Sometimes the speed changes in the middle of run (looping), say, after 10th iteration.

    Code:
    #include <iostream>
    #include <string>
    #include <stdio.h>
    #include <math.h>
    #include <stdlib.h>
    #include <sys/time.h>
    using namespace std;
    
    float do_calculation(double y)
    {
     float   z1 = 33.33; 
     double  z2 = 400.077;
     double  z3;
     double  sum = 0.0;
     
     for(int i=0; i<1000000; i++)
     {
       z1 = sin(z1+z2+i) / (fabs(z1) + 4.6);
       z2 = cos(z1*i + y);
       z3 = atan2(z1+i, z1+z2-i/(i+30));
       z3 += z1/(i+4) + fabs(rand()*z1 + z2 - cos(i*3.06));
       z3 = exp(-fabs(z3 + 2.7*y + z1 - z2/5.7)); 
       sum += -y + z3/(fabs(z3) + 2.0 + i/(i+4.7));
     }
     return sum;
    } 
    
    
    
    int main() {
     const int ONE_MILLION = 1000000;
     const int LOOP  = 8;
     struct timeval  tv;        struct timezone tz;
     long   dtm;
     double starttm, endtm, how_long;
     double tmpsum = 0.0;
    
     for(;;) {
      gettimeofday(&tv, &tz);  dtm = tv.tv_sec; 
      gettimeofday(&tv, &tz); 
      starttm = (tv.tv_sec - dtm) + (1.0/ONE_MILLION)*tv.tv_usec;
     
      for(int i=0; i<LOOP; i++) tmpsum += cos(2.0*i) * do_calculation(2.2);
      tmpsum = (fabs(rand()*tmpsum) - 4000.66) / (fabs(tmpsum) + 0.006);
    
      gettimeofday(&tv, &tz); 
      endtm   = (tv.tv_sec - dtm) + (1.0/ONE_MILLION)*tv.tv_usec;              
      how_long = endtm - starttm; // = time one iteration takes, in seconds
      printf("Time of one iteration = %9.4lf s, computation result = %e\n", how_long, tmpsum); 
     }
    return 0;
    }
    This looks like a bug, but I cannot figure out where. I have written many programs in C and C++ and have never observed such a behavior of the compiled program. The computer is not loaded with any other processes.

    This is 64 bit computer running 64 bit opensuse 13.1, updated.

  6. #6

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

    On 2014-01-17, ZStefan <ZStefan@no-mx.forums.opensuse.org> wrote:
    >
    > This is the simplified program. When I compile and run it on a computer,
    > the speed of one iteration appears to be bistable, with durations
    > varying about 2.5 times. Sometimes the speed changes in the middle of
    > run (looping), say, after 10th iteration.
    >

    <SNIP>
    >
    > This looks like a bug, but I cannot figure out where. I have written
    > many programs in C and C++ and have never observed such a behavior of
    > the compiled program. The computer is not loaded with any other
    > processes.
    >
    > This is 64 bit computer running 64 bit opensuse 13.1, updated.


    Thank you for posting the code. This is the result of my first run (openSUSE 13.1 x86_64 KDE, fully updated):

    Code:
    sh-4.2$ g++ a.cpp
    sh-4.2$ ./a.out
    Time of one iteration =    2.6495 s, computation result = 9.366910e+08
    Time of one iteration =    2.6481 s, computation result = 5.707878e+08
    Time of one iteration =    2.6480 s, computation result = 4.978989e+08
    Time of one iteration =    2.6479 s, computation result = 1.190977e+09
    Time of one iteration =    2.6481 s, computation result = 9.298645e+08
    Time of one iteration =    2.6478 s, computation result = 1.552897e+08
    Time of one iteration =    2.6478 s, computation result = 1.710884e+09
    Time of one iteration =    2.6477 s, computation result = 2.023878e+09
    Time of one iteration =    2.6482 s, computation result = 1.185668e+09
    Time of one iteration =    2.6480 s, computation result = 1.627396e+09
    Time of one iteration =    2.6479 s, computation result = 1.285587e+09
    Time of one iteration =    2.6479 s, computation result = 1.284789e+09
    Time of one iteration =    2.6480 s, computation result = 5.410588e+07
    Time of one iteration =    2.6480 s, computation result = 8.577717e+08
    Time of one iteration =    2.6479 s, computation result = 1.333628e+09
    Time of one iteration =    2.6480 s, computation result = 6.056444e+08
    Time of one iteration =    2.6482 s, computation result = 1.130641e+09
    Time of one iteration =    2.6480 s, computation result = 8.075440e+08
    Time of one iteration =    2.6480 s, computation result = 1.071738e+09
    Time of one iteration =    2.6481 s, computation result = 1.497799e+09
    Time of one iteration =    2.6482 s, computation result = 6.832906e+08
    Time of one iteration =    2.6480 s, computation result = 1.850542e+09
    Time of one iteration =    2.6479 s, computation result = 2.099904e+09
    Time of one iteration =    2.6479 s, computation result = 6.601369e+08
    Time of one iteration =    2.6480 s, computation result = 1.654135e+09
    Time of one iteration =    2.6482 s, computation result = 1.265377e+09
    Time of one iteration =    2.6480 s, computation result = 7.491475e+08
    Time of one iteration =    2.6481 s, computation result = 1.618072e+09
    Time of one iteration =    2.6479 s, computation result = 9.804571e+08
    Time of one iteration =    2.6482 s, computation result = 9.666316e+08
    Time of one iteration =    2.6481 s, computation result = 1.076384e+09
    Time of one iteration =    2.6480 s, computation result = 1.915146e+09
    Time of one iteration =    2.6481 s, computation result = 1.325639e+09
    Time of one iteration =    2.6479 s, computation result = 1.309158e+09
    Time of one iteration =    2.6481 s, computation result = 1.040363e+09
    Time of one iteration =    2.6480 s, computation result = 8.497754e+08
    Time of one iteration =    2.6481 s, computation result = 2.008792e+09
    Time of one iteration =    2.6480 s, computation result = 3.436796e+08
    Time of one iteration =    2.6480 s, computation result = 4.997928e+08
    Time of one iteration =    2.6477 s, computation result = 1.252841e+09
    Time of one iteration =    2.6481 s, computation result = 1.206959e+09
    Time of one iteration =    2.6478 s, computation result = 1.049436e+09
    Time of one iteration =    2.6480 s, computation result = 9.855468e+07
    Time of one iteration =    2.6482 s, computation result = 1.643193e+09
    Time of one iteration =    2.6480 s, computation result = 1.217729e+09
    Time of one iteration =    2.6482 s, computation result = 4.503854e+08
    Time of one iteration =    2.6479 s, computation result = 1.326227e+09
    Time of one iteration =    2.6479 s, computation result = 1.415164e+09
    Time of one iteration =    2.6479 s, computation result = 9.095195e+08
    Time of one iteration =    2.6477 s, computation result = 1.485605e+09
    Time of one iteration =    2.6481 s, computation result = 4.506785e+08
    Time of one iteration =    2.6480 s, computation result = 1.261918e+09
    Time of one iteration =    2.6480 s, computation result = 2.026706e+09
    Time of one iteration =    2.6481 s, computation result = 7.786600e+08
    Time of one iteration =    2.6481 s, computation result = 1.524530e+09
    Time of one iteration =    2.6476 s, computation result = 1.570667e+09
    Time of one iteration =    2.6481 s, computation result = 1.206787e+09
    Time of one iteration =    2.6478 s, computation result = 1.250838e+09
    Time of one iteration =    2.6480 s, computation result = 2.095063e+09
    Time of one iteration =    2.6481 s, computation result = 1.865386e+09
    Time of one iteration =    2.6480 s, computation result = 3.281944e+08
    Time of one iteration =    2.6480 s, computation result = 1.132857e+09
    Time of one iteration =    2.6478 s, computation result = 6.180122e+08
    Time of one iteration =    2.6479 s, computation result = 6.900676e+08
    Time of one iteration =    2.6479 s, computation result = 1.615849e+09
    Time of one iteration =    2.6481 s, computation result = 1.126033e+09
    Time of one iteration =    2.6479 s, computation result = 2.139742e+09
    Time of one iteration =    2.6478 s, computation result = 1.894477e+08
    Time of one iteration =    2.6477 s, computation result = 1.631572e+09
    Time of one iteration =    2.6479 s, computation result = 8.535685e+08
    Time of one iteration =    2.6481 s, computation result = 1.273882e+09
    Time of one iteration =    2.6482 s, computation result = 1.660796e+08
    Time of one iteration =    2.6482 s, computation result = 1.038502e+09
    Time of one iteration =    2.6482 s, computation result = 5.600697e+07
    Time of one iteration =    2.6482 s, computation result = 1.619022e+09
    Time of one iteration =    2.6481 s, computation result = 6.123897e+08
    Time of one iteration =    2.6481 s, computation result = 8.961824e+08
    Time of one iteration =    2.6483 s, computation result = 1.648120e+09
    Time of one iteration =    2.6481 s, computation result = 1.074455e+09
    Time of one iteration =    2.6481 s, computation result = 1.626155e+09
    Time of one iteration =    2.6482 s, computation result = 1.550417e+09
    Time of one iteration =    2.6483 s, computation result = 1.369261e+08
    Time of one iteration =    2.6479 s, computation result = 2.025879e+09
    Time of one iteration =    2.6481 s, computation result = 4.188721e+08
    Time of one iteration =    2.6482 s, computation result = 1.167625e+09
    Time of one iteration =    2.6483 s, computation result = 1.395522e+09
    Time of one iteration =    2.6480 s, computation result = 1.273302e+09
    Time of one iteration =    2.6481 s, computation result = 1.901946e+09
    Time of one iteration =    2.6478 s, computation result = 9.852336e+08
    Time of one iteration =    2.6482 s, computation result = 1.411876e+09
    Time of one iteration =    2.6481 s, computation result = 1.194318e+09
    Time of one iteration =    2.6479 s, computation result = 9.078349e+07
    Time of one iteration =    2.6480 s, computation result = 3.560195e+08
    Time of one iteration =    2.6480 s, computation result = 1.043311e+08
    Time of one iteration =    2.6480 s, computation result = 8.975936e+08
    Time of one iteration =    2.6482 s, computation result = 1.611007e+09
    Time of one iteration =    2.6481 s, computation result = 1.073908e+09
    Time of one iteration =    2.6480 s, computation result = 1.342637e+09
    Time of one iteration =    2.6482 s, computation result = 8.293112e+08
    Time of one iteration =    2.6482 s, computation result = 2.042515e+09
    Time of one iteration =    2.6481 s, computation result = 1.620367e+09
    Time of one iteration =    2.6481 s, computation result = 9.631723e+08
    Time of one iteration =    2.6481 s, computation result = 1.870537e+09
    Time of one iteration =    2.6480 s, computation result = 2.074187e+09
    Time of one iteration =    2.6481 s, computation result = 9.977173e+08
    Time of one iteration =    2.6482 s, computation result = 1.094236e+09
    Time of one iteration =    2.6484 s, computation result = 2.101217e+09
    Time of one iteration =    2.6481 s, computation result = 4.879628e+08
    Time of one iteration =    2.6483 s, computation result = 1.372519e+08
    Time of one iteration =    2.6480 s, computation result = 1.352022e+09
    Time of one iteration =    2.6480 s, computation result = 1.427920e+09
    Time of one iteration =    2.6480 s, computation result = 8.491647e+08
    Time of one iteration =    2.6480 s, computation result = 1.062124e+09
    Time of one iteration =    2.6480 s, computation result = 4.722387e+08
    Time of one iteration =    2.6480 s, computation result = 9.563156e+08
    Time of one iteration =    2.6481 s, computation result = 1.815737e+09
    ^C
    sh-4.2$
    As you can see there's very little variation in time of each iteration (out of >100). Unfortunately I cannot reproduce
    your problem despite trying the following:

    1. Running it as a different user.
    2. Rebooting repeatedly.
    3. Disabling/re-enabling swap.

    At the very least, the results suggest this is unlikely to be a bug. Unfortunately this isn't very helpful in
    identifying the cause of your results. I suspect this is a tough one to solve. While we are running the same openSUSE
    version, our configurations are likely to differ. It would be helpful if anyone else can try out your code to see if my
    configuration or your configuration is the odd one out. I would also be interested to see if can reproduce the problem
    you see running the code at runlevel 2.



  7. #7
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    4,654

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

    136 lines calculated, the times are
    min = 2.5894
    max = 2.7090
    not really a large variation.
    Calculated on i3 2.3 GHz.

    --
    PC: oS 13.1 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.11 | GTX 650 Ti
    ThinkPad E320: oS 13.1 x86_64 | i3@2.30GHz | 8GB | KDE 4.11 | HD 3000
    HTPC: oS 13.1 x86_64 | Celeron@1.8GHz | 2GB | Gnome 3.10 | HD 2500

  8. #8

    Default Likely conditions

    Thank you for testing in your machines.

    The code I posted is a cut-out emulation from a larger program. The large program and this small piece display the same behavior: when one runs slow, the other one would also run slow.

    Currently, I observe that the likely conditions of getting bistable behavior are the following ones. But none is decisive factor:

    - Boot after a long (more than a few minutes) shutdown. This is the main factor.
    - Upgrade.
    - Mounted external storage present.
    - Old computer, new opensuse.
    - Running in runlevel 3.

    The following does not have an effect on bistable behavior (leaves the speed at one value, whatever it was):

    - Running as root or user.
    - Other processes loading other cores of the CPU.
    - Swap present or absent.
    - Compilation options (none, -O2, -O, --fast-math).
    - Using older math library libm-2.15.so.
    - Running the executable which was compiled on another 64 bit computer.

    I am now thinking that this bistable behavior is not limited to my small program. Likely, most programs of opensuse 13.1 are bistable. But I am not sure how to test. Is there a simple package to test the CPU's productivity?

    I think that the possible culprits might be:
    - Wrong throttling of the processor or parts of it. The frequency does not change, though.
    - Processor switching the execution thread between cores in wrong ways.
    - Defective microcode.

  9. #9

    Default It is the same at runlevel 2

    Quote Originally Posted by flymail View Post
    I would also be interested to see if can reproduce the problem
    you see running the code at runlevel 2.
    Same bistable behavior observed at runlevel 2.

  10. #10

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

    On 2014-01-17, ZStefan <ZStefan@no-mx.forums.opensuse.org> wrote:
    > I am now thinking that this bistable behavior is not limited to my small
    > program. Likely, most programs of opensuse 13.1 are bistable. But I am
    > not sure how to test. Is there a simple package to test the CPU's
    > productivity?


    Let's first exclude your belief that it's libm fault. Please compile and run the following libm-independent (but still
    mathematical) C++ code and post the output:

    Code:
    //---------------------------------------------------------------------------
    # include <iostream>
    # 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;
    
    //---------------------------------------------------------------------------
    using namespace std;
    
    //---------------------------------------------------------------------------
    void fft5(double* ro, double* io, double* ri, double* ii);
    
    //---------------------------------------------------------------------------
    int main(int argc, char* argv[])
    {
    int i, j, n, N, M;
    M = 50;
    N = 50000000;
    n = 5;
    clock_t t0, t1;
    
    double* ri = new double[n];
    double* ii = new double[n];
    double* ro = new double[n];
    double* io = new double[n];
    
    for (i = 0; i<n; i++) {
    ri[i] = (double)i;
    ii[i] = (double)(n-i);
    }
    
    fft5(ro, io, ri, ii);
    
    cout << "Result: " << endl;
    for (i = 0; i<n; i++) {
    cout << i << ": (" << ro[i] << ", " << io[i] << ");" << endl;
    }
    
    for (j = 0; j<M; j++) {
    t0 = clock();
    for (i = N; i; i--) {
    fft5(ro, io, ri, ii);
    }
    t1 = clock();
    cout << j << ": number of clock cycles = " << t1-t0 << ";" << endl;
    }
    
    delete[] ri;
    delete[] ii;
    delete[] ro;
    delete[] io;
    }
    
    //---------------------------------------------------------------------------
    void fft5(double* ro, double* io, double* ri, double* ii) {
    double sr1, sr2, si1, si2;
    double dr1, dr2, di1, di2;
    double ar1, ar2, ai1, ai2;
    double 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;
    }
    
    //---------------------------------------------------------------------------
    .... apologies for the rubbish indenting, but the openSUSE forum sucks when it comes to preserving indentation of code
    posts from NNTP; at least we're not talking about Python!

    On 2014-01-17, ZStefan <ZStefan@no-mx.forums.opensuse.org> wrote:
    > I think that the possible culprits might be:
    > - Wrong throttling of the processor or parts of it. The frequency does
    > not change, though.
    > - Processor switching the execution thread between cores in wrong ways.
    > - Defective microcode.


    I don't understand - what is `defective microcode'?


Page 1 of 4 123 ... LastLast

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
  •