Prestatiemeting en profiling

Een programma was langzaam, hoewel het CPU-gebruik laag was, ongeveer 20 %. Wat is de meest waarschijnlijke oorzaak?

  1. ADe CPU rekent te snel
  2. BHet programma heeft te weinig instructies
  3. CEr wordt lang gewacht zonder de CPU te gebruiken, bijvoorbeeld op schijf- of netwerk-I/O of op locks
Antwoord en toelichting tonen

Antwoord: C. Er wordt lang gewacht zonder de CPU te gebruiken, bijvoorbeeld op schijf- of netwerk-I/O of op locks

Als het CPU-gebruik laag is en het programma toch langzaam, wordt het grootste deel van de tijd waarschijnlijk besteed aan wachten op iets buiten de CPU. Voorbeelden zijn schijf lezen en schrijven, netwerkantwoorden en het vrijgeven van een lock die door een andere thread wordt vastgehouden. In dat geval heeft een snellere CPU of het optimaliseren van de rekencode nauwelijks effect. Effectief zijn het bundelen van I/O, het asynchroon maken zodat tijdens het wachten andere verwerking doorgaat, en het verkleinen van het bereik van locks.

Dit onderwerp oefenen Naar de onderwerppagina

Meer vragen over Prestatiemeting en profiling

  1. Om te controleren of een programma rekengebonden of geheugengebonden is, werd de uitvoeringstijd gemeten bij een gewijzigde CPU-frequentie. Welk resultaat is bij geheugengebonden programma’s in het algemeen te verwachten?
  2. Wat is de juiste richting om de prestaties te verhogen wanneer met het roofline-model blijkt dat een bewerking zich in het gebied bevindt dat door de geheugenbandbreedte wordt begrensd?
  3. Wat wordt met de STREAM-benchmark hoofdzakelijk gemeten?
  4. Welke methode is het meest geschikt om de schaalbaarheid van een parallel programma te onderzoeken?
  5. Bij parallelle uitvoering op 8 cores werd het programma 6 keer zo snel als met 1 core. Wat is de parallelle efficiëntie?