+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: DLL & externer Code (/Forum-DLL-externer-Code)
+---- Thema: MoveBlock oder SwapBlock (Benchmarktest) (/Thread-MoveBlock-oder-SwapBlock-Benchmarktest)
MoveBlock oder SwapBlock (Benchmarktest) - abrissbirne - 14.10.2011 12:16
Hallo,
hat von euch schonmal jemand einen Benchmarktest bzgl. der Funktionen MoveBlock bzw. SwapBlock gemacht? Mich würde interessieren, welche Funktion schneller arbeitet, oder ob es keinen Unterschied gibt.
Thx
RE: MoveBlock oder SwapBlock (Benchmarktest) - rolfk - 14.10.2011 12:26
(14.10.2011 12:16 )abrissbirne schrieb: Hallo,
hat von euch schonmal jemand einen Benchmarktest bzgl. der Funktionen MoveBlock bzw. SwapBlock gemacht? Mich würde interessieren, welche Funktion schneller arbeitet, oder ob es keinen Unterschied gibt.
Thx
Ohne jetzt viel Zeit darin zu investieren gehe ich davon aus dass MoveBlock deutlich schneller ist. Denn MoveBlock kopiert NUR von Source nach Destination, währenddem SwapBlock die Daten zwischen den Blöcken austauschen muss. Selbst wenn die Funktion explicit Inplace Swap-Operationen verwendet kann das nicht wirklich schneller sein als MoveBlock.
Move hat per Element ein Read und eine Write-Operation, Swap je nachdem ob entsprechende optimalisiert CPU Opcodes verwendet werden oder nicht, zwei Read-Modify Operationen oder aber zwei Read und zwei Write Operationen.
RE: MoveBlock oder SwapBlock (Benchmarktest) - abrissbirne - 14.10.2011 12:37
Danke für deine Erklärung.
Nehmen wir mal an ich habe eine DLL die Daten in einen Shared Memory Bereich (MapViewOfFile...) ablegt. Was wäre die schnellste Variante diese Daten einem LabVIEW Array zu übergeben (oder kann ich sogar den LabVIEW Datenbereich Mappen?).
Thx
RE: MoveBlock oder SwapBlock (Benchmarktest) - rolfk - 14.10.2011 13:00
(14.10.2011 12:37 )abrissbirne schrieb: Danke für deine Erklärung.
Nehmen wir mal an ich habe eine DLL die Daten in einen Shared Memory Bereich (MapViewOfFile...) ablegt. Was wäre die schnellste Variante diese Daten einem LabVIEW Array zu übergeben (oder kann ich sogar den LabVIEW Datenbereich Mappen?).
Thx
Hmmm mapping von LabVIEW Datenbereichen ist sehr tricky. Der Speicherbereich eines LabVIEW Handles ist nur garantiert während der Dauer des SharedLibrary Funktionsaufrufes. Danach ist es sehr schwierig um im LabVIEW Diagram zu garantieren, dass dieses Handle nicht im Speicher verschoben wird oder gar dealloziert. Es ist ganz sicher keine Möglichkeit für eine Funktionslibrary die Du an mehr oder weniger unbedarfte LabVIEW Programmierer zur Verfügung stellen willst. Sobald dieses Handle nämlich in irgendeiner Weise mit einer LabVIEW Funktion in Berührung kommt, kann diese das Handle grundsätzlich modifizieren, inklusive im Specher verschieben oder gar ganz deallozieren. Ob und wie eine LabVIEW Funktion ein Handle verändert ist zwar logisch definiert aber halt nicht sehr praktisch um einem Librarybenützer in Detail zu erklären. Zudem ist die Chance dass entweder Du eine Variante bei der Beschreibung übersiehst, oder der Benutzer diese vergisst, viel zu hoch. Ein Kopie des Speichers ist deshalb fast unvermeidlich. Ob MoveBlock dazu perfekt ist weiss ich nicht. Meiner Meinung nach ist es eine strikte Kopierloop. Die Performance ist deshalb hauptsächlich vom verwendeten C Compiler abhängig, aber ich bezweifle dass Du es besser machen kannst, ausser Du willst Dich mit Assembler rumschlagen.
RE: MoveBlock oder SwapBlock (Benchmarktest) - BNT - 14.10.2011 13:24
Hi
Du müsstes das LabVIEW-Array, das Du mappen möchtest, immer und überall auf allen Ebenen mit einem durchgehenden Draht in Shift-Registern festhalten. Dann geht es, hab ich schon mal gemacht.
Diese Vorgehen dient aber nicht der Wiederverwendbarkeit, sollte also nur in wichtigen Spezialfällen benutzt werden, um notwendige Perfomance zu erreichen. Wenn Du es Dir leisten kannst, solltest Du kopieren.
Gruß Holger
RE: MoveBlock oder SwapBlock (Benchmarktest) - rolfk - 14.10.2011 14:01
(14.10.2011 13:24 )BNT schrieb: Hi
Du müsstes das LabVIEW-Array, das Du mappen möchtest, immer und überall auf allen Ebenen mit einem durchgehenden Draht in Shift-Registern festhalten. Dann geht es, hab ich schon mal gemacht.
Diese Vorgehen dient aber nicht der Wiederverwendbarkeit, sollte also nur in wichtigen Spezialfällen benutzt werden, um notwendige Perfomance zu erreichen. Wenn Du es Dir leisten kannst, solltest Du kopieren.
Gruß Holger
Deshalb meine Bemerkung dass das nicht für mehr oder weniger unbedarfte LabVIEW Benützer geeignet ist. Und ein Shift-Register alleine ist nicht genügend. Du musst auch sicherstellen, dass Du das Array niemals an eine LabVIEW-Funktion anschliesst die dieses Array in irgendeiner Weise modifiziert, wenn Du nicht 100% sicher bist dass die DLL nicht noch irgendwo eine Referenz darauf hat. Das löst auch noch nicht das Problem des asynchronen Zugriffs. Selbst nur-Lesezugriffe in LabVIEW auf das Array, während die DLL im Hintergrund die Daten modifiziert hat im besten Fall hässliche kosmetische Effekte und eventuel gar schwerwiegendere Folgen.
RE: MoveBlock oder SwapBlock (Benchmarktest) - abrissbirne - 14.10.2011 15:17
Danke euch beiden für eure Erklärungen. Könnte ich mal ein Stück Code sehen, der das Mappen eines LV-Speicherbereichs übernimmt? Ich bin mir noch nicht zu 100% sicher ob ichb es wirklich unbedingt brauche, aber es könnte sein das ich nicht drumherum komme.
RE: MoveBlock oder SwapBlock (Benchmarktest) - rolfk - 14.10.2011 17:04
(14.10.2011 15:17 )abrissbirne schrieb: Danke euch beiden für eure Erklärungen. Könnte ich mal ein Stück Code sehen, der das Mappen eines LV-Speicherbereichs übernimmt? Ich bin mir noch nicht zu 100% sicher ob ichb es wirklich unbedingt brauche, aber es könnte sein das ich nicht drumherum komme.
Das habe ich so jetzt nicht direkt zur Verfügung. Grundsätzlich wirst Du simpelweg den DatenPointer des Arrays als Eingangspointer zu MapFileView übergeben müssen, und dann höllisch aufpassen dass Dir LabVIEW dieses Handle nie unter den Füssen wegzieht. Sonst krachst und das kann ziemlich krass werden da MapFileView grundsätzlich schon sehr nahe am Windows Kernel funktioniert. Und ein Speicherfehler im Kernel beendet halt nicht nur den aktuellen Prozess sondern kann das ganze Windowssystem in den Abgrund ziehen.