myCSharp.de - DIE C# und .NET Community (https://www.mycsharp.de/wbb2/index.php)
- Entwicklung (https://www.mycsharp.de/wbb2/board.php?boardid=3)
-- Rund um die Programmierung (https://www.mycsharp.de/wbb2/board.php?boardid=59)
--- Hohe und lange Laufzeiten bei großen mehrdimensionalen Arrays (https://www.mycsharp.de/wbb2/thread.php?threadid=121873)


Geschrieben von sylvio am 14.05.2019 um 16:58:
  Hohe und lange Laufzeiten bei großen mehrdimensionalen Arrays
Hallo Zusammen,

Ist es "nornal" das große float-Arrays (~300k elemente) im typ: "float a[,,] " unter VS2017 (unter 64bit) bei c# beim ersten Zugriff so extrem höhere Zugriffzeiten haben? Ich kann da auch keinen großen Unterschied zwischen 32 und 64bit merken; ebenso macht ein Ausschalten des debugs quasi fast nichts aus.

Ich habe das so definiert/allokiert:
float[,,] yy = new float[MAX_y, MAX_s, MAX_phi];

Wenn ich dann ~300'000 zugriffe haben; also jedem feld wert zuweise; dauert dies (1 thread) in Summe rund 90sec. Ohne Array-Wert zuweisen aber nur ~1sec. Wenn ich das selbe testweise mal unter c++ mache; dauert das dem gegenüber aber nur knapp 2sec (also nicht mal Ansatzweise 90sec).
Das "komische" ist; wenn ich dann (unter c#) mit dem Array arbeite, dann sind die Zeiten auch wieder fast normal. fast so als wenn der bei jeder ersten Zuweisung in einem Array immer noch "intensive bondary-checks .." macht..


MfG
S.


Geschrieben von MarsStein am 14.05.2019 um 17:29:
 
Hallo,

ich hab das gerade mal ausprobiert mit einem float[70,70,70], also 343000 Werten, die ich mit Zufallswerten befüllt habe.
--> dauert auf meiner Maschine hier 7 Millisekunden...

Ich vermute also, dass bei Dir eher das Besorgen der Werte so lange dauert. Wo kommen die denn her?

Gruß, MarsStein


Geschrieben von sylvio am 14.05.2019 um 17:58:
 
Die kommen aus rund 1000 einzelnen Datenfiles, die jeweils float-Punkte enthaten.
Aber das (laden und parsen) kann es "eigentlich" nicht sein. Denn wenn ich die Zeile mit der ersten Array-Zuweisung raus nehme (nur diese), dann ist die Lade-Zeit (einschliesslich des parsens der files) sofort unter ~1sec.
Gut, muß ich mir mal ein Testprojekt damit erstellen und dort versuchen mi dem Array zu "experimentieren". Der Effekt ist jedenfalls sehr mysteriös :/


S.


Geschrieben von sylvio am 14.05.2019 um 18:38:
 
-> DANKE!!!
Herje kann es fast nicht glauben; natürlich mein Fehler :)
Ich hatte ein j mit i "verdreht"; damit warf der zig Exception bei der Array-Zuweisung; die ich noch nicht vollständig abgefangen hatte. Hatte es daher nur nicht mitbekommen...


S.


Geschrieben von gfoidl am 14.05.2019 um 18:44:
 
Hallo sylvio,

multi-dimensionale Arrays sind in .NET per Design sehr langsam, da für jeden Zugriff ein Methoden-Aufruf durchgeführt werden muss (zusätzlich zu Bound-Checks).

Wesentlich performanter sind sz-Arrays (single dimensional zero based), da bei diesen der JIT direkte Speicherzugriffe -- also ohne Hilfs-Methoden -- erzeugt.
Für mehrdimensionale Tensoren kommen somit "jagged Arrays" in Frage. D.h. float[][][]

Achte dann beim Zugriff auf die Elemente darauf -- v.a. per Schleife -- dass zusammenhängende Daten im Speicher angesprochen werden (memory locality und cache friendlyness).

Zitat:
damit warf der zig Exception bei der Array-Zuweisung; die ich noch nicht vollständig abgefangen hatte

Wie ist das zu verstehen? Bzw. anders rum: wenn du die Exception nicht handeln kannst, so lass es -- dann bekommst du den Fehler wenigsten frühzeitig mit => "fail early".


mfG Gü


Geschrieben von sylvio am 15.05.2019 um 14:12:
 
Zitat:
multi-dimensionale Arrays sind in .NET per Design sehr langsam, da für jeden Zugriff ein Methoden-Aufruf durchgeführt werden muss (zusätzlich zu Bound-Checks).
Wesentlich performanter sind sz-Arrays (single dimensional zero based), da bei diesen der JIT direkte Speicherzugriffe -- also ohne Hilfs-Methoden -- erzeugt.
Für mehrdimensionale Tensoren kommen somit "jagged Arrays" in Frage. D.h. float[][][]

Achte dann beim Zugriff auf die Elemente darauf -- v.a. per Schleife -- dass zusammenhängende >Daten im Speicher angesprochen werden (memory locality und cache friendlyness).

Interessant - Danke . Ja muss ich mal mir mal in Ruhe anschauen (wenn die Anwendung erstmal soweit läut; ist halt wieder mal alles dringend^2). Ich komme eigentlich aus der c/c++/asm-welt; C# machte ich bisher immer nur "wenn zwingend verlangt" :/ Da ich solche "grossen" arrays bisher immer nur unter c/c++ machte, dachte ich schon das es durch evtl. c# und zig extra checks bedingt war :/

Zitat:
Wie ist das zu verstehen? Bzw. anders rum: wenn du die Exception nicht handeln kannst, so lass
es -- dann bekommst du den Fehler wenigsten frühzeitig mit => "fail early".

Ja, war an der Stelle halt noch alles "tricky" programmiert. Ein try/catch hatte hier "unbemerkt" "falsch" ausgelöst (schon vom code her richtig aber in der falschen schleife), nur weil ich da das "i" und "j" im Array verdreht hatte.
Ist halt wie meistens.. "der Bug sitzt idR vom Bildschrim" :-)


Danke nochmal an alle...



S.


© Copyright 2003-2019 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 24.08.2019 13:05