Ich benoetige ein float-Array der Dimension [64][64][64][3][3], bekomme aber "segmentation fault". Mit z.B. [64][64][32][3][3] gibt es keine Probleme. Wie kann man diese Beschraenkung umgehen? (64-Bit-Linux mit 8 GB RAM)
Gast
#3059098
Maxim S. schrieb: > Ich benoetige ein float-Array der Dimension [64][64][64][3][3], bekomme > aber "segmentation fault". Mit z.B. [64][64][32][3][3] gibt es keine > Probleme. ein segmentation kommt aber nicht von einem Array. Wo tritt der fehler genau auf? Oder Versucht du das array auf dem Stack anzulegen?
Gast
#3059105
Zeig mal den kompletten Code im Kontext. Im Prinzip sollte das gehen.
Peter II schrieb: > Maxim S. schrieb: >> Ich benoetige ein float-Array der Dimension [64][64][64][3][3], bekomme >> aber "segmentation fault". Mit z.B. [64][64][32][3][3] gibt es keine >> Probleme. > > ein segmentation kommt aber nicht von einem Array. Wo tritt der fehler > genau auf? Oder Versucht du das array auf dem Stack anzulegen? Ja, ich lege es auf dem Stack an. Allerdings nur, weil ich nicht wirklich weiss, wie man es auf dem Heap anlegt. Es muss auf jeden Fall ein zusammenhaengender Speicherbereich sein. Thorsten schrieb: > Zeig mal den kompletten Code im Kontext. Im Prinzip sollte das gehen. Diese Zeile fuehrt zu segmentation fault:
1 | |
Gast
#3059110
> weil ich nicht wirklich weiss, wie man es auf dem Heap anlegt
new [] regelt.
Gast
#3059111
Mehr Kontext. Auf dem Stack könnte das schon problematisch werden, je nach eingestelltem Stack Limit.
Gast
#3059114
Maxim S. schrieb: > Ja, ich lege es auf dem Stack an. Allerdings nur, weil ich nicht > wirklich weiss, wie man es auf dem Heap anlegt. dann solltest du eventuell erstmal anfangen C zu lernen.- Auf dem Stack legt man nicht so viele Daten an.
Ich denke, ich werde aus dem [64][64][64][3][3]-Array einfach neun [64*64*64]-Arrays machen, die jeweils fuer sich zusammenhaengend im Speicher liegen muessen, was ja mit new gehen sollte.
Gast
#3059131
Maxim S. schrieb: > Ich denke, ich werde aus dem [64][64][64][3][3]-Array einfach neun > [64*64*64]-Arrays machen, die jeweils fuer sich zusammenhaengend im > Speicher liegen muessen, was ja mit new gehen sollte. das andere muss auch mit new gehen.
Peter II schrieb: > Maxim S. schrieb: >> Ich denke, ich werde aus dem [64][64][64][3][3]-Array einfach neun >> [64*64*64]-Arrays machen, die jeweils fuer sich zusammenhaengend im >> Speicher liegen muessen, was ja mit new gehen sollte. > > das andere muss auch mit new gehen. So, dass ich neun zusammenahengende Speicherbereiche der Groesse 64^3 habe?
Gast
#3059147
Maxim S. schrieb: > So, dass ich neun zusammenahengende Speicherbereiche der Groesse 64^3 > habe? das sollte auch gehen, aber das ganze geht auch als ein speicherbereich. Es sind doch nur 18Mbyte. Dafür braucht man auch kein 64bit system. Das ganze passt nur nicht auf den Stack. Im Heap ist das doch kein Thema.
Gast
#3059150
Wenn die neun 64^3 Arrays gleichzeitig auf dem Stack liegen, fliegt dir das Ganze wieder um die Ohren.
Gast
#3059151
> So, dass ich neun zusammenahengende Speicherbereiche der Groesse 64^3 > habe? Kannst auch einen großen machen. new[] regelt immernoch.
Gast
#3059161
Kleiner Tipp: Cramersche Regel für Arrays. Dann braucht man nicht diese abartigen vielen Klammern.
Hier mein Lösungansatz:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
Das ist natürlich nur ein Beispiel. Im eigentlichen Quellcode soll eine Funktion (FFT-Bibliothek) die neun Nz*Ny*Nx großen Blöcke nacheinander bekommen und verarbeiten. Das habe ich in diesem Beispiel mit der Funktion Helper::print() simuliert. Ist das alles programmiertechnisch sauber?
Die maximale Stack-Größe kannst du mit "ulimit -a" nachgucken. Rechne doch mal, ob du die überschreitest -- ich schätze schon, bei dem Riesen-Array. Wie schon erwähnt wurde legt man sowas nicht auf dem Stack an.
Gast
#3060439
Maxim S. schrieb: > float theArray[64][64][64][3][3]; Hmm.. wenn ich mich recht erinnere, dann kann C keine mehrdimensionalen Felder. Stattdessen sieht das so aus: theArray = [64 pointer], die jeweils auf folgendes zeigen: ---> array[64 pointern], die jeweils auf folgendes zeigen: ---> array[64 pointern], die jeweils auf folgendes zeigen: ---> array[3 pointern], die jeweils auf folgendes zeigen: ---> array[3 floats]. Du solltest besser 1 Array definieren: float theArray[64*64*64*3*3]; und deine Zugriffslogik selber organisieren. Alternativ kannst du FreePascal nehmen, denn Pascal kann nativ mehrdimensionale Felder. W.S.
Gast
#3060444
W.S. schrieb: > Hmm.. wenn ich mich recht erinnere, dann kann C keine mehrdimensionalen > Felder. Stattdessen sieht das so aus: dann erinnerst du dich falsch. Das geht ohne Probleme in C. er macht dann das gleich wie du manuell machen willst.
Gast
#3060505
Wenn Du nur das Stack-Problem hast, und Du auch nur eine Instanz des Arrays im lokalen Funktionsbereich benutzt, dann ist die "einfachste" Lösung: static float array[64][64][64][3][3] ; Damit bist Du wieder im (nicht initailisierten) Datensegment, anstatt auf dem Stack. Oder einfach global deklarieren. Ansonsten, die Idee mit der Indizierung über eine (Hilfs-)klasse sieht gut aus! Mach es doch konsequent und lass die Klasse auch gleich die Größe des Arrays zurückgeben. Oder ganz konsequent und die Klasse das Array verwalten. Achja, bei Deiner index Methode statt "...+2*(j+3*k)" besser "...+3*(j+3*k)"? Über const, size_t, c'tor Initialisierung etc. lass ich mal nicht aus: Das ist eher Schönheitswettberwerb... ^^ Vielleicht noch der Hinweis auf boost: http://www.boost.org/doc/libs/1_53_0/libs/multi_array/doc/user.html. Das ist in Deinem Fall aber wohl überdimensioniert. ^^ Grüße, Steffen
Gast
#3061769
Peter II schrieb: > dann erinnerst du dich falsch. Das geht ohne Probleme in C. er macht > dann das gleich wie du manuell machen willst. Huch? Was für eine seltsame Argumentation deinerseits. Also hab ich mich doch richtig entsonnen: C kann keine mehrdimensionalen Felder, stattdessen werden daraus Felder von Pointern auf Felder von Pointern auf Felder von Pointern.... draus. Und nochwas : ICH will sowas überhaupt nicht manuell machen, sondern hab nur das mal explizit dargestellt, was bei C aus so einer Deklaration entsteht. Also lies bitte etwas gründlicher. W.S.
Gast
#3061837
W.S. schrieb: > Huch? Was für eine seltsame Argumentation deinerseits. Also hab ich mich > doch richtig entsonnen: C kann keine mehrdimensionalen Felder, > stattdessen werden daraus Felder von Pointern auf Felder von Pointern > auf Felder von Pointern.... draus. STOP! Natürlich kann C mehrdimensionale Felder. Und auch Pointer auf Felder, wenn man's entsprechend deklariert. Kommt mir bloss nicht mit Hinterlassenschaften wie Pascal. Es soll offensichtlich immer noch rudimentäre (nicht ANSI-fähige) Compiler geben, die obigen Käse produzieren. Im Zweifelsfall vor dem voreiligen Posten: Einfach mal den Disassembler anschmeissen. Zum eigentlichen Problem: die mehrdimensionale Indizierung erzeugt u.U. sehr ineffizienten Code, und zwar meist so, wie wenn man die Indizierung von Hand rechnet (d.h. (x0, .., xn) -> Speicheradresse). Einer hat schon den "Cramer" eingeworfen... - Boeserfisch
Brater schrieb: > Kleiner Tipp: Cramersche Regel für Arrays. Dann braucht man nicht diese > abartigen vielen Klammern. Kannst du das bitte genauer erklären. Habe ich noch nie gehört und auch nichts dazu im Netz gefunden. Mir ist natürlich klar, was die Cramersche Regel ist, aber wie man sie auf Arrays anwenden kann ist mir unklar. Gruß Oliver
W.S. schrieb: > stattdessen werden daraus Felder von Pointern auf Felder von Pointern > auf Felder von Pointern.... draus. Ist mir bei normal deklarierten Arrays noch nicht untergekommen. > C kann keine mehrdimensionalen Felder Formal syntaktisch nicht, weil es sich in C anders als in Pascal um verschachtelte eindimensionale Arrays handelt. Aber trotzdem werden im Speicher keine Pointer abgelegt und in der Praxis ist der Unterschied bei letztlicher Operation mit Skalaren wirklich nur syntaktischer Natur.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.