Wie schnell ist eine unwidersprochene Sperre?

Es gibt ein Projekt auf GitHub mit dem Zweck, dies auf verschiedenen Plattformen zu messen. Leider hatte ich nach meiner Masterarbeit nie wirklich die Zeit, dies zu verfolgen, aber zumindest ist der rudimentäre Code vorhanden.

Er misst Pthreads und OpenMP-Sperren im Vergleich zu __sync_fetch_and_add intrinsic.

Soweit ich mich erinnere, erwarteten wir einen ziemlich großen Unterschied zwischen Locks und atomaren Operationen (~ eine Größenordnung), aber der wirkliche Unterschied erwies sich als sehr klein.

Die Messung auf meinem System ergibt jedoch Ergebnisse, die meine ursprüngliche Vermutung widerspiegeln, nämlich dass (unabhängig davon, ob Pthreads oder OpenMP verwendet werden) atomare Operationen etwa fünfmal schneller sind und eine einzelne synchronisierte Inkrementierungsoperation etwa 35 ns benötigt die Sperre erwerben, das Inkrement ausführen und die Sperre aufheben).

Ich habe zufällig viele Low-Level-Geschwindigkeitstests herumliegen. Was genau Geschwindigkeit bedeutet, ist jedoch sehr unsicher, weil es sehr davon abhängt, was genau Sie tun (auch unabhängig von der Operation selbst).

Hier sind einige Zahlen von einem AMD 64-Bit Phenom II X6 3.2Ghz. Ich habe das auch auf Intel-Chips ausgeführt und die Zeiten variieren sehr (je nachdem, was gerade gemacht wird).

Ein GCC __sync_fetch_and_add , der eine vollständig eingezäunte atomare Addition wäre, hat einen Durchschnitt von 16 ns mit einer Mindestzeit von 4 ns. Die minimale Zeit ist wahrscheinlich näher an der Wahrheit (obwohl auch dort habe ich ein bisschen Overhead).

Ein unbestrittener Pthread Mutex (durch Boost) ist 14ns (was auch sein Minimum ist). Beachten Sie, dass dies auch ein bisschen zu niedrig ist, da die Zeit tatsächlich zunimmt, wenn etwas anderes den Mutex gesperrt hat, aber jetzt nicht unbestätigt ist (da es eine Cache-Synchronisierung verursachen wird).

Ein fehlgeschlagener try_lock ist 9ns.

Ich habe keine einfache alte atomare Inc, da dies auf x86_64 nur eine normale Austauschoperation ist. Wahrscheinlich nahe der minimal möglichen Zeit, also 1-2ns.

Das Benachrichtigen ohne einen Kellner auf einer Bedingungsvariablen ist 25ns (wenn etwas auf 304ns wartet).

Da jedoch alle Sperren bestimmte CPU-Bestellgarantien verursachen, wird die Größe des von Ihnen geänderten Speichers (was auch immer in den Speicherpuffer passt) die Dauer dieser Operationen ändern. Und natürlich, wenn du jemals einen Mutex hast, der deine schlimmste Zeit ist. Jede Rückkehr zu dem Linux-Kernel kann Hunderte von Nanosekunden betragen, selbst wenn kein Threadwechsel tatsächlich auftritt. Dies ist normalerweise der Fall, wenn atomare Sperren übertreffen, da sie niemals irgendwelche Kernel-Aufrufe beinhalten: Ihre durchschnittliche Fallleistung ist auch Ihr schlimmster Fall. Die Mutex-Entsperrung verursacht auch einen Overhead, wenn Threads warten, während ein Atomic nicht funktioniert.

HINWEIS: Solche Messungen sind mit Problemen behaftet, so dass die Ergebnisse immer fragwürdig sind. Meine Tests versuchen, Variationen zu minimieren, indem Sie die CPU-Geschwindigkeit fixieren, die CPU-Affinität für Threads festlegen, keine anderen Prozesse ausführen und über große Ergebnismengen mitteln.

hängt von der Sperrimplementierung ab, hängt auch vom System ab. Atomare Variablen können nicht wirklich wie eine Sperre umkämpft werden (auch nicht, wenn Sie akquirieren-release-semantik ), das ist der ganze Punkt der Atomarität, es sperrt den Bus, um den Speicher zu propagieren (abhängig vom Speicherbarrierenmodus), aber das ist eine Implementierung Detail.

Die meisten Benutzermodussperren sind jedoch nur atomare Ops, siehe dieser Artikel von Intel für einige Zahlen zu Hochleistungs-skalierbare Sperren mit atomaren Ops unter x86 und x64 (im Vergleich zu Windows ' CriticalSection locks, leider, Für das SWR Sperren, aber man sollte immer für das eigene System / Umgebung profilieren).