So verwenden Sie x64 Interlocked-Operationen gegen MemoryMappedFiles in .net

Ich muss Interlocked Operations (CompareExchange, Increment usw.) gegen Speicher in MemoryMappedFile s in .NET verwenden.So verwenden Sie x64 Interlocked-Operationen gegen MemoryMappedFiles in .net

Ich fand diese answer zu einer sehr ähnlichen Frage. Das Problem besteht darin, dass Interlock-Operationen nicht aus der kernel32-DLL (oder einer anderen) auf einem 64-Bit-Betriebssystem exportiert werden (siehe z. B. http://blog.kalmbachnet.de/?postid=46).

Gibt es eine andere Möglichkeit, wie ich Interlocked-Funktionen auf einem Speicherblock in einem 64-Bit-.NET-Prozess aufrufen kann?

Quelle

2014-09-23 Jan

Ich würde versuchen, meine eigene C Dll mit exportierten Funktionen zu schreiben, die verriegelte Funktionen aufrufen, und PInvoice es von .NET. –

@AlexFarber Ausgezeichneter Punkt! Ich wollte nur nachfragen :) Wissen Sie zufällig, ob ich die ASM-Implementierung der intrinsischen Interlocked-Funktionen des Compilers (z. B. [http://msdn.microsoft.com/de-de/library/2ddez55b(v = vs.80) .aspx] (http://msdn.microsoft.com/en-us/library/2ddez55b (v = vs.80) .aspx))? Damit ich den ASM-Code nicht neu erfinden muss – Jan

Sie müssen dies nicht tun, rufen Sie nur erforderliche Funktionen von nativen Dll, Compiler wird den Rest erledigen. Ich meine, für jede verriegelte Funktion, die Sie benötigen, exportierte DLL-Funktion schreiben, die Interlocked-Funktion aufruft. –

Schreiben Sie sich eine kleine C++/CLI-Hilfsbibliothek, die verschlüsselte Operationen bietet, die mit verwaltetem Code konsumierbar sind.

Ich glaube, der schnellste Interop-Pfad wäre, eine verwaltete Klasse offenzulegen, die intern in eine nicht verwaltete Funktion aufruft, die selbst auf die interlocked intrinsics verwendet. Auf diese Weise müssen Sie nicht einmal PInvoke durchlaufen.

Quelle

2014-10-16 10:43:34 usr

Leider ist dies nicht wahr - C++/CLI ist langsamer als P/Invoke mit unterdrückten Prüfungen - siehe z.B. hier: http://www.codeproject.com/Articles/253444/PInvoke-Performance?msg=4551831#xx4551831xx oder hier: http://www.xinterop.com/index.php/2013/05/01/ccli- vs-pinvoke-performance-part-one/ Also P/Invoke ist der Weg zu gehen (leider gibt es immer noch mehr als ein Dutzend Anweisungen pro Aufruf) – Jan

Der erste Artikel scheint zu zeigen, dass der C++ Wrapper schneller ist. Im zweiten Artikel ist der C++ - Wrapper so viel langsamer, dass ich anfange, verdächtig zu werden. Vielleicht wurden Optimierungen nicht aktiviert oder zusätzliche Arbeit wurde ausgeführt (tatsächlich - der C++ - Wrapper ruft sqrt nur über eine Zwischenklasse auf. Warum?). In beiden Artikeln waren die Benchmark-Zeiten sehr gering. Eine Menge Lärm. DateTime.Now ist auch nicht sehr präzise. Normalerweise erhöht es sich in 15ms Schritten. Seine Tests lagen im Bereich von 10-30ms. Ich traue keinem Artikel und ich werde nicht die Zeit investieren, um mehr zu untersuchen. – usr

Ich stimme Ihren Ergebnissen zu. Der Hauptpunkt ist, dass, wenn Sie maximale Geschwindigkeit wollen, Sie Supers alle Stack-Trace-Probing etc. mit verwalteten <-> nativen Übergängen verbunden sind. Mit P/Invokes können Sie dies tun, indem Sie das SuppressUnmanagedCodeSecurity-Attribut angeben. Mit C++/CLI-Wrapper erhalten Sie standardmäßig alle diese Checks und meines Wissens können Sie sie nicht abkürzen. – Jan

So verwenden Sie x64 Interlocked-Operationen gegen MemoryMappedFiles in .net

Antwort

Verwandte Themen