Prestatiemeting en profiling

Met prestatietellers bleek dat er zeer veel sprongvoorspellingsfouten zijn. Welke verbetermethode is geschikt?

  1. ANog meer sprongen aan de lus toevoegen
  2. BDe gegevens sorteren zodat het sprongresultaat beter voorspelbaar is, of sprongen zelf elimineren door voorwaardelijke selectie of berekening
  3. CDe cachecapaciteit verkleinen
Antwoord en toelichting tonen

Antwoord: B. De gegevens sorteren zodat het sprongresultaat beter voorspelbaar is, of sprongen zelf elimineren door voorwaardelijke selectie of berekening

Bij een verkeerde sprongvoorspelling gooit de CPU de speculatief uitgevoerde instructies weg en begint opnieuw, wat per keer meer dan een tiental cycli kost. Bij willekeurige gegevens is het resultaat van een sprong als “als de waarde ≥ 128” niet te voorspellen. Door de gegevens vooraf te sorteren worden de resultaten gegroepeerd en wordt de voorspelling vaker juist, en met voorwaardelijke selectie-instructies of bitbewerkingen verdwijnt de sprong zelf. De compiler kan ook worden aangezet tot dergelijke transformaties.

Dit onderwerp oefenen Naar de onderwerppagina

Meer vragen over Prestatiemeting en profiling

  1. Wat is bij top-downanalyse (Top-down Microarchitecture Analysis) met prestatietellers de juiste hoofdindeling van het gebruik van de slots waarin de CPU instructies verwerkt?
  2. Een programma was langzaam, hoewel het CPU-gebruik laag was, ongeveer 20 %. Wat is de meest waarschijnlijke oorzaak?
  3. 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?
  4. 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?
  5. Wat wordt met de STREAM-benchmark hoofdzakelijk gemeten?

Vergelijkingen bij dit onderwerp