3. Laufzeitunterschiede eines Programmes

Laufzeitunterschiede eines Programmes

  • G

    Ich hab gerade starke Unterschiede in der Laufzeit eines Programms gemessen. Soweit ich das beurteilen kann waren die Bedingungen bei beiden Programmaufrufen gleich.
    Folgendes habe ich gemessen:

    36281,096582      task-clock (msec)         #    0,417 CPUs utilized          
           573.680      context-switches          #    0,016 M/sec                  
                20      cpu-migrations            #    0,001 K/sec                  
             1.108      page-faults               #    0,031 K/sec                  
    83.665.418.381      cycles                    #    2,306 GHz                      (34,89%)
    58.030.765.178      stalled-cycles-frontend   #   69,36% frontend cycles idle     (38,44%)
    29.051.574.180      stalled-cycles-backend    #   34,72% backend cycles idle      (43,87%)
    21.377.126.682      instructions              #    0,26  insn per cycle         
                                                  #    2,71  stalled cycles per insn  (52,59%)
     1.851.723.096      branches                  #   51,038 M/sec                    (55,66%)
        38.634.107      branch-misses             #    2,09% of all branches          (54,61%)
     7.115.369.559      L1-dcache-loads           #  196,118 M/sec                    (27,88%)
       192.363.330      L1-dcache-load-misses     #    2,70% of all L1-dcache hits    (23,69%)
        81.994.885      LLC-loads                 #    2,260 M/sec                    (20,26%)
        10.754.903      LLC-load-misses           #   13,12% of all LL-cache hits     (25,51%)

      86,992727931 seconds time elapsed

    und:

    23909,709295      task-clock (msec)         #    6,933 CPUs utilized          
           583.871      context-switches          #    0,024 M/sec                  
                23      cpu-migrations            #    0,001 K/sec                  
             1.108      page-faults               #    0,046 K/sec                  
    86.227.883.497      cycles                    #    3,606 GHz                      (38,19%)
    58.464.767.356      stalled-cycles-frontend   #   67,80% frontend cycles idle     (37,82%)
    29.589.604.814      stalled-cycles-backend    #   34,32% backend cycles idle      (37,73%)
    22.455.145.015      instructions              #    0,26  insn per cycle         
                                                  #    2,60  stalled cycles per insn  (47,63%)
     1.858.591.606      branches                  #   77,734 M/sec                    (46,99%)
         5.416.352      branch-misses             #    0,29% of all branches          (48,49%)
     7.098.454.126      L1-dcache-loads           #  296,886 M/sec                    (30,00%)
       166.669.209      L1-dcache-load-misses     #    2,35% of all L1-dcache hits    (23,47%)
        48.194.111      LLC-loads                 #    2,016 M/sec                    (22,60%)
            37.446      LLC-load-misses           #    0,08% of all LL-cache hits     (29,61%)

       3,448674623 seconds time elapsed

    Die gesamte Prozessorauslastung lag während des ersten Programmlaufs bei etwa 14% und während des zweiten bei 94%. Wie kann so was passieren?

    0
  • R

    Gruum schrieb:

    ISoweit ich das beurteilen kann waren die Bedingungen bei beiden Programmaufrufen gleich.

    vs

    Die gesamte Prozessorauslastung lag während des ersten Programmlaufs bei etwa 14% und während des zweiten bei 94%. Wie kann so was passieren?

    entweder falsch/unterschiedliches gemessen, oder die bedingungen waren nicht gleich. mehr moeglichkeit sehe ich nicht, aufgrund der mageren beschreibung.

    0
  • M

    Beim zweiten Mal war das Programm ja auch viel schneller fertig. Denkbar wäre, dass in größerem Umfang Dateien gelesen werden, und die beim zweiten Mal vom OS gecacht waren. Oder, da das Programm multithreaded zu sein scheint, vlt. hat sich da irgendwie die Synchronisation zwischen den Threads verschluckt durch schlampige Programmierung?

    0
  • S

    Mr X schrieb:

    Beim zweiten Mal war das Programm ja auch viel schneller fertig. Denkbar wäre, dass in größerem Umfang Dateien gelesen werden, und die beim zweiten Mal vom OS gecacht waren. Oder, da das Programm multithreaded zu sein scheint, vlt. hat sich da irgendwie die Synchronisation zwischen den Threads verschluckt durch schlampige Programmierung?

    Ja, klingt stark danach, dass I/O im ersten Lauf sehr lange gebraucht hat (und dementsprechend die Prozesserauslastung niedrig war, weil nur gewartet wurde).

    Always do warm up before performance tests.

    MfG SideWinder

    0
Anmelden zum Antworten