Wie ist die Leistung von den zugrunde liegenden Datenwerten abhängig?

8

Ich habe das folgende C ++ - Code-Snippet (der C ++ - Teil ist die Profiler-Klasse, die hier weggelassen wird), kompiliert mit VS2010 (64-Bit-Intel-Maschine). Der Code multipliziert einfach ein Array von Schwimmern ( arr2 ) mit einem Skalar und setzt das Ergebnis in ein anderes Array ( arr1 ):

%Vor%

Der Lese-aus-Datei-Teil und die Profilierung (d. h. Laufzeitmessung) sind hier der Einfachheit halber weggelassen.

Wenn arr2 auf Zufallszahlen im Bereich [0 1] initialisiert wird, läuft der Code etwa 10 mal schneller im Vergleich zu einem Fall, in dem arr2 auf ein Sparse-Array initialisiert wird, in dem etwa 2/3 des Werte sind Nullen. Ich habe mit den Compiler-Optionen /fp und /O gespielt, was die Laufzeit ein wenig verändert hat, aber das Verhältnis von 1:10 wurde ungefähr eingehalten.

  • Wie kommt es, dass die Leistung von den tatsächlichen Werten abhängt? Was macht die CPU anders, was dazu führt, dass die spärlichen Daten ~ 10 mal langsamer laufen?
  • Gibt es eine Möglichkeit, die "langsamen Daten" schneller laufen zu lassen, oder wird eine Optimierung (zB Vektorisierung der Berechnung) auf beide Arrays die gleiche Wirkung haben (dh die "langsamen Daten" werden langsamer laufen als die "schnellen Daten ")?

BEARBEITEN

Der vollständige Code ist hier: Ссылка , die Befehlszeile zum Kompilieren befindet sich in einem Kommentar in test.cpp .

Die Datendateien sind hier:

Itamar Katz 25.01.2012, 15:00
quelle

3 Antworten

7

Wahrscheinlich liegt das daran, dass Ihre "schnellen" Daten nur aus normalen Gleitkommazahlen bestehen, aber Ihre "langsamen" Daten viele demormierte Zahlen enthalten.

Wie bei Ihrer zweiten Frage können Sie versuchen, die Geschwindigkeit zu verbessern (und alle denormierten Zahlen als exakte Nullen zu behandeln):

%Vor%     
Evgeny Kluev 25.01.2012, 15:50
quelle
2

Ich kann mir zwei Gründe dafür vorstellen.

Erstens kann der Verzweigungsprädiktor falsche Entscheidungen treffen. Dies ist eine mögliche Ursache für Leistungslücken, die durch Datenänderungen ohne Codeänderungen verursacht werden. In diesem Fall scheint es jedoch sehr unwahrscheinlich.

Der zweite mögliche Grund ist, dass Ihre "meist Nullen" -Daten nicht wirklich aus Nullen bestehen, sondern eher aus Nullen bestehen, oder dass Sie arr1 in dem Bereich von fast Null behalten. Siehe diesen Wikipedia-Link .

    
Borealid 25.01.2012 15:56
quelle
1

Es ist nicht verwunderlich, dass die Daten von I.Bin länger verarbeitet werden müssen: Sie haben viele Zahlen wie '1.401e-045 # DEN' oder '2.214e-043 # DEN', wobei #DEN bedeutet, dass die Zahl nicht möglich ist auf die Standard-Float-Genauigkeit normalisiert werden. Vorausgesetzt, dass Sie es mit 6.6e-14 multiplizieren werden Sie definitiv Unterlauf Ausnahmen haben, die Berechnungen erheblich verlangsamt.

    
Arty 25.01.2012 17:14
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Constructor Injection - Spritzen wir auch Fabriken ein?