Segmentation fault

AH

Hallo,

ich habe folgendes Problem: Ich möchte eine für mich aussergewoehnlich große Datenmenge speichern. Es handelt sich um die Raumkoordinaten (x,y und z) von 1,3 mio. Teilchen, also insgesamt 3,9 mio. Zahlen. Ich habe also einen array erzeugt, mit 1,3 mio. Zeilen und 3 Spalten. Beim Compilieren keine Fehlermeldung, aber eben das "Segmentation fault", wenn ich das Programm starte.

Laut Internetrecherche bedeutet die Fehlermeldung, dass ich auf Speicher zugreifen möchte, der nicht zur Verfügung steht. Ich vermute, dass es daran liegt, dass meine array Laufvariable ein integer ist, und das System (I Mac: 3.33 Ghz DualCore Intel, 8 GB Arbeitsspeicher) oder die Xcode Umgebung auf 16 bit laufen und deshalb einfach nicht bis 1,3 mio. zählen kann?

Ist die Art und Weise diese Daten in ein array abzulegen überhaupt sinvoll? Ich will Anhand der Veränderung der Koordinaten die Teilchen im Raum verschieben, d.h. die Datensätze sollen nur mit trivialer Mathematik behandelt werden.

Wäre für Anregungen und eine erste Richtung bei diesem Speicherproblem dankbar.

Gruß, Alex

l'abra d'or

Du legst das array aber nicht auf dem Stack ab, oder? Ich nehms aber an...
Entweder legst du dein Array im Freispeicher ab, oder besser gleich std::vector verwenden.

krümelkacker

AH schrieb:

ich habe folgendes Problem: Ich möchte eine für mich aussergewoehnlich große Datenmenge speichern. Es handelt sich um die Raumkoordinaten (x,y und z) von 1,3 mio. Teilchen, also insgesamt 3,9 mio. Zahlen. Ich habe also einen array erzeugt, mit 1,3 mio. Zeilen und 3 Spalten.

Wie?

AH schrieb:

Beim Compilieren keine Fehlermeldung, aber eben das "Segmentation fault", wenn ich das Programm starte.

Laut Internetrecherche bedeutet die Fehlermeldung, dass ich auf Speicher zugreifen möchte, der nicht zur Verfügung steht. Ich vermute, dass es daran liegt, dass meine array Laufvariable ein integer ist, und das System (I Mac: 3.33 Ghz DualCore Intel, 8 GB Arbeitsspeicher) oder die Xcode Umgebung auf 16 bit laufen und deshalb einfach nicht bis 1,3 mio. zählen kann?

Überprüf mal Deine Vermuting:

#include <iostream>  // std::cout
#include <climits>   // INT_MAX Makro

int main() {
  std::cout << INT_MAX << '\n';
}

Ein int hat garantiert mindestens 16 Bit, üblich sind aber auf heutigen Architekturen 32 Bit.

AH schrieb:

Ist die Art und Weise diese Daten in ein array abzulegen überhaupt sinvoll? Ich will Anhand der Veränderung der Koordinaten die Teilchen im Raum verschieben, d.h. die Datensätze sollen nur mit trivialer Mathematik behandelt werden.

Das ist eine sehr vage Beschreibung. Die Frage, ob ein Array hier sinnvoll ist, kann man so nicht beantworten.

AH schrieb:

Wäre für Anregungen und eine erste Richtung bei diesem Speicherproblem dankbar.

Anregung: Dein Problem auf ein komplettes Minimalbeispiel reduzieren und Code zeigen.

kk

AH

Danke für die lichtschnellen Antworten zunächst mal.

Ich arbeite auf 32 Bit und der Rechner kann signed int bis 2,1... mia. zählen, das ist ja schonmal erfreulich.

Das mit den Vektoren werde ich jetzt erstmal ausprobieren, wenn es geklappt hat sag ich bescheid, wenn nicht sag ich auch bescheid.

Ich denke schon, dass ich das alles in den Stack geschrieben habe.

Den Code werde ich dann beim nächsten Problem direkt mit einfügen.

Gruß, Alex

benötigt bei mir ca 30-60 mb ram und läuft ohne große Probleme.

#include <vector>
#include <iostream>
#include <stdlib.h>
using namespace std;

#define xMax 1300000
#define yMax 3

int main() {
  vector<vector<double> > xyData;

  xyData.resize(xMax);
  for (int x = 0; x < xMax; x++)
  {
    xyData[x].resize(yMax);
    for (int y=0;y<yMax;y++)
    {xyData[x][y]=rand();
        }
  }
   cout<<xMax<<" x "<<yMax<<" Matrix erstellt.";
   int i;

  return 0;
}

Anmerkung:
-Ich benötige max 100 mb ram.
-Der Wechsel Vertauschen der dimenstionen spart recht viel Zeit.
-vector<vector<double>> ist inneffektiv. Vielleicht wäre double** besser

AH schrieb:

Ich arbeite auf 32 Bit

AH schrieb:

DualCore Intel, 8 GB Arbeitsspeicher

wtf

krümelkacker

skki schrieb:

vector<vector<double>> ist inneffektiv.

Kann man so pauschal nicht sagen.

skki schrieb:

Vielleicht wäre double** besser

Sicher nicht.
Vielleicht wäre vector<teilchen> mit selbstdefinierter Klasse teilchen besser.

kk

SeppJ

krümelkacker schrieb:

skki schrieb:

vector<vector<double>> ist inneffektiv.

Kann man so pauschal nicht sagen.

Hatte ich auch gedacht, aber meine eigenen Benchmarks bestätigen dies. Deutlich. Ca. um Faktor 2 langsamer (beim Durchiterieren) als double** auf recht neuem GNU Compiler mit O3.

Athar

SeppJ schrieb:

Hatte ich auch gedacht, aber meine eigenen Benchmarks bestätigen dies. Deutlich. Ca. um Faktor 2 langsamer (beim Durchiterieren) als double** auf recht neuem GNU Compiler mit O3.

Mit welcher Testmethode?
Diese gibt folgende Ergebnisse (gcc 4.4.1/O3):

Array: 1721 ms
Vector: 1602 ms

Die Funktionen machen jeweils das naheliegende.

int main()
{
  const int loops=1000;
  volatile int v_size=1000;
  const int size=v_size;

  vector<vector<double> > vec(size,vector<double>(size,1));
  double** arr=new double*[size];
  for (int i=0;i<size;i++)arr[i]=new double[size];
  for (int i=0;i<size;i++)for (int j=0;j<size;j++)arr[i][j]=1;

  uint start_v=mclock();
  double sum=0;
  for (int x=0;x<loops;x++)foreach(iv,vec)foreach(v,iv)sum+=v;
  uint end_v=mclock();

  uint start_a=mclock();
  double sum2=0;
  for (int x=0;x<loops;x++)for (int i=0;i<size;i++)for (int j=0;j<size;j++)sum2+=arr[i][j];
  uint end_a=mclock();

  cout << "Array: " << end_a-start_a << " ms" << endl;
  cout << "Vector: " << end_v-start_v << " ms" << endl;

  assert(sum==sum2);
  return int(sum+sum2)%10;

Ich habe testweise durch Übergabe per Referenz des Vectors/Arrays an externe Funktionen nach jedem vollständigen Durchiterieren sichergestellt, dass keine Zwischensummen des letzten Durchgangs zwischengespeichert werden.

SeppJ

Athar schrieb:

Mit welcher Testmethode?

Einfach durchiteriert und gemessen:

#include <vector>
#include <iostream>
#include <cstdlib>
#include <ctime>
#include <sys/time.h>
using namespace std;

typedef unsigned int uint;

const uint xMax = 1300000;
const uint yMax = 3;

int main() {
  srand(time(0));
  {
    vector<vector<double> > xyData;

    xyData.resize(xMax);
    for (uint x = 0; x < xMax; ++x)
      {
        xyData[x].resize(yMax);
        for (uint y=0;y<yMax;++y)
          xyData[x][y]=rand();
      }

    cout<<xMax<<" x "<<yMax<<" vector-Matrix erstellt."<<endl;
    double d=0;

    timeval start;
    gettimeofday(&start, NULL);

    for (uint j=0; j<1000; ++j)
      for (uint x = 0; x < xMax; x++)
        for (uint y=0;y<yMax;++y)
          d+=xyData[x][y];

    timeval end;
    gettimeofday(&end, NULL);

    cout<<"Antioptimierungsausgabe: "<<d<<endl;

    long seconds  = end.tv_sec  - start.tv_sec;
    long useconds = end.tv_usec - start.tv_usec;

    long mtime = ((seconds) * 1000 + useconds/1000.0) + 0.5;

    cout<<"Dauer: "<<mtime  <<" ms"<<endl;

  }
  {
    double **xyData;

    xyData = new double*[xMax];
    for (uint x = 0; x < xMax; ++x)
      {
        xyData[x]=new double[yMax];
        for (uint y=0;y<yMax;++y)
          xyData[x][y]=rand();
      }

    cout<<xMax<<" x "<<yMax<<" double**-Matrix erstellt."<<endl;

    double d=0;

    timeval start;
    gettimeofday(&start, NULL);

    for (uint j=0; j<1000; ++j)
      for (uint x = 0; x < xMax; x++)
        for (uint y=0;y<yMax;++y)
          d+=xyData[x][y];

    timeval end;
    gettimeofday(&end, NULL);

    cout<<"Antioptimierungsausgabe: "<<d<<endl;

    long seconds  = end.tv_sec  - start.tv_sec;
    long useconds = end.tv_usec - start.tv_usec;

    long mtime = ((seconds) * 1000 + useconds/1000.0) + 0.5;

    cout<<"Dauer: "<<mtime  <<" ms"<<endl;

    for (uint x = 0; x < xMax; x++)
      delete[] xyData[x];
    delete[] xyData;

  }
}

GCC 4.4.1, O3 gab auf meinem alten Core2 14.000 ms und 8.000 ms.

Ich habe es auch mal auf einem wesentlich neueren i7 laufen lassen, da bekomme ich 12.000 ms und 10.000 ms also einen deutlich kleineren Unterschied. Und der i7 ist tatsächlich langsamer als der Uraltrechner!

edit: Das war wohl nur ein Ausreißer. Mach ich mehr Messungen bekomme ich 11.000 ms und 8.000 ms auf dem i7. Trotzdem ganz schön lahm für einen 5(?) Jahre neueren Prozessor.

Und es sind natürlich noch wesentliche Verbesserungen drin, wenn man xMax und yMax vertauscht. Es ist nun einmal günstiger die längere Dimension zuinnerst zu haben. Am qualitativen Unterschied zwischen vector und Pointer ändert es bei mir aber nichts.

Und ja: Ich bin auch schwer verwundert. Bei den vielen kleinen 3-er Vectoren hätte ich auch mit Overhead gerechnet aber nach Vertauschung der Dimensionen eigentlich nicht.

Vermutlich lässt sich das so eh nicht messen, da der Code optimiert wird.

SeppJ

,,, schrieb:

Vermutlich lässt sich das so eh nicht messen, da der Code optimiert wird.

Guck nochmal genauer hin.

Athar

Dann noch mal meine Messungen:

Vector: 8925 ms
Array:  7549 ms

Mit folgender Abänderung (verhindert Optimierungen, die darauf basieren, dass die Größen bereits zur Kompilierzeit bekannt sind):

volatile uint v_xMax=1300000;
const uint xMax = v_xMax;
volatile uint v_yMax=3;
const uint yMax = v_yMax;

Vector: 10753 ms
Array:  9834 ms

Und jetzt wird's interessant, bei vertauschtem xMax und yMax, womit die vielen kleinen Vektoren wegfallen:

Vector: 7053 ms
Array:  7089 ms

Mit volatile:

Vector: 7112 ms
Array:  6520 ms

(ohne die 10-er-Schleife war es genau anders herum... da stimmt was nicht)

Hängt wohl recht stark vom System ab.

Edit: Durchschnittswerte von jeweils 10 Durchgängen genommen.

So, dann muss ich auch noch mal meinen Senf dazu geben. Ich habe SeppJs Code um ein boost::multi_array ergänzt:

#include <vector>
#include <iostream>
#include <cstdlib>
#include <ctime>
#include <sys/time.h>

#define BOOST_DISABLE_ASSERTS
#include "boost/multi_array.hpp"

using namespace std;

typedef unsigned int uint;

const uint xMax = 1300000;
const uint yMax = 3;

void runVec()
{
  vector<vector<double> > xyData;

  xyData.resize(xMax);
  for (uint x = 0; x < xMax; ++x)
    {
      xyData[x].resize(yMax);
      for (uint y=0;y<yMax;++y)
	xyData[x][y]=rand();
    }

  cerr<<xMax<<" x "<<yMax<<" vector-Matrix erstellt."<<endl;
  double d=0;

  timeval start;
  gettimeofday(&start, NULL);

  for (uint j=0; j<1000; ++j)
    for (uint x = 0; x < xMax; x++)
      for (uint y=0;y<yMax;++y)
	d+=xyData[x][y];

  timeval end;
  gettimeofday(&end, NULL);

  cerr<<"Antioptimierungsausgabe: "<<d<<endl;

  long seconds  = end.tv_sec  - start.tv_sec;
  long useconds = end.tv_usec - start.tv_usec;

  long mtime = ((seconds) * 1000 + useconds/1000.0) + 0.5;

  cout<<"Vector: "<<mtime  <<" ms"<<endl;

}

void runMultiArray()
{
  typedef boost::multi_array<double, 2> array_type;
  typedef array_type::index index;
  array_type xyData(boost::extents[xMax][yMax]);

  for (uint x = 0; x < xMax; ++x)
    for (uint y=0;y<yMax;++y)
      xyData[x][y]=rand();

  cerr<<xMax<<" x "<<yMax<<" MultiArray erstellt."<<endl;
  double d=0;

  timeval start;
  gettimeofday(&start, NULL);

  for (uint j=0; j<1000; ++j)
    for (uint x = 0; x < xMax; x++)
      for (uint y=0;y<yMax;++y)
	d+=xyData[x][y];

  timeval end;
  gettimeofday(&end, NULL);

  cerr<<"Antioptimierungsausgabe: "<<d<<endl;

  long seconds  = end.tv_sec  - start.tv_sec;
  long useconds = end.tv_usec - start.tv_usec;

  long mtime = ((seconds) * 1000 + useconds/1000.0) + 0.5;

  cout<<"MultiArray: "<<mtime  <<" ms"<<endl;

}

void runArray()
{
  double **xyData;

  xyData = new double*[xMax];
  for (uint x = 0; x < xMax; ++x)
    {
      xyData[x]=new double[yMax];
      for (uint y=0;y<yMax;++y)
	xyData[x][y]=rand();
    }

  cerr<<xMax<<" x "<<yMax<<" double**-Matrix erstellt."<<endl;

  double d=0;

  timeval start;
  gettimeofday(&start, NULL);

  for (uint j=0; j<1000; ++j)
    for (uint x = 0; x < xMax; x++)
      for (uint y=0;y<yMax;++y)
	d+=xyData[x][y];

  timeval end;
  gettimeofday(&end, NULL);

  cerr<<"Antioptimierungsausgabe: "<<d<<endl;

  long seconds  = end.tv_sec  - start.tv_sec;
  long useconds = end.tv_usec - start.tv_usec;

  long mtime = ((seconds) * 1000 + useconds/1000.0) + 0.5;

  cout<<"Array: "<<mtime  <<" ms"<<endl;

  for (uint x = 0; x < xMax; x++)
    delete[] xyData[x];
  delete[] xyData;

}

int main() {
  srand(time(0));

  runArray();
  runVec();
  runMultiArray();
}

Damit erhalte ich auf einem Phenom 9850 mit OpenSuse 11.3 64Bit und gcc 4.5 folgende Ergebnisse:

64Bit
Array: 8752 ms
Vector: 12746 ms
MultiArray: 7452 ms

32Bit
Array: 8390 ms
Vector: 13476 ms
MultiArray: 12459 ms

AH

Hallo,

ich habe das Problem mit dem großen Speicher also folgendermaßen gelöst. Ich habe eine Struktur (kann/soll ruhig public sein) für die Raumkoordinaten geschrieben. Dann lasse ich einen array erstellen, der aus dem Datentyp der Struktur besteht. Dieser Array wird dynamisch erstellt, da ich vorher noch nicht genau sagen kann, wieviele Einträge er speichern soll (Ist jetzt schon die erste Weiterentwicklung).

Als Zählvariable habe ich dem Array zunächst einfach ein int zugeordnet. Hat auch gut funktioniert, dann auf ein unsigned int gegangen, um die Nummerierungskapazität zu verdoppeln und schließlich gedacht, komm nimmste direkt ein unsigned long int, dann ist es auch Zukunftssicher.

Wenn ich allerdings die Teilchenzahl weiter erhöhe, also die Elemente deas arrays, dann kommt folgende Fehlermeldung bei der Ausführung des Programms, compilieren tut er ohne meckern:

Programm(1415) malloc: *** mmap(size=9229386903556096) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Abort trap
logout

Was will mir das sagen und woran könnte es liegen?

Der Code, der den Fehler auslösen müsste:

speicherlaeufer=(partikelvolumen/atomvolumen)+1;
cout << speicherlaeufer <<'\n';
part_koord* partikelkoordinaten = new part_koord[speicherlaeufer];

speicherlaeufer ist besagte unsigned long int variable, die sollte doch bis ein paar Trilliarden zählen können?

Gruß, Alexander

SeppJ

Nein, long kann nicht bis ein paar Trilliarden zählen, zumindest nicht auf den üblichen Systemen. Und selbst wenn, das heißt noch lange nicht, dass dein System genügend Speicher für ein paar Trilliarden part_koord hat. Die Fehlermeldung sagt nämlich genau dies.

Für solche Sachen müsstest du dir einen Spezialrechner mit 128 Bit Adressbereich und mehreren Zetabyte Hauptspeicher zulegen. Das dürfte an der Grenze des technisch machbaren liegen, aber ein paar hundert Millionen Dollar müsstest du schon investieren. Jedenfalls gibt es keinen Rechner auf der Welt der derzeit so etwas kann.

Da du uns aber offensichtlich verarschen willst, frag ich jetzt auch mal nicht weiter nach, wofür du ein paar Trilliarden Koordinaten brauchst.

edit: Hab ich hunderte Millionen Dollar gesagt? Habe mich um ein paar Größenordnungen vertan. Korrigiere: ein paare hundert Milliarden Dollar, wahrscheinlich sogar ein paar zig Billionen. Das Projekt wäre eine weltweite Anstrengung wie es sie noch nie zwischen den Nationen gegeben hat. Aber meiner Einschätzung nach durchaus machbar. Viel Spaß bei der Organisation .

AH

Verarschen ist jetzt ein sehr hartes Wort.

Wenn man ich sag mal ein Stoffteilchen abbilden wollte. Sagen wir mit einem Radius von 10 Mikrometern, so würde dieses Teilchen, sofern es aus Gold bestünde (Atomradius von ca. 0,1375 Nanometern), aus etwa 3,85 * 10^14 Teilchen. In Normaldeutsch also, sofern ich mich nicht verrechnet habe, 385 Billionen Atomen bestehen.

Es ist eine experimentelle Herangehensweise an ein Problem und mein einziger Fehler hierbei ist bislang, dass ich mit der Programmierung noch nicht gut genug auskenne um diesen offensichtlichen Engpaß an Rechenleistung zu kennen. Ich war tatsächlich der Annahme, dass moderne Rechner so weit zählen und es lag mir sehr fern jemanden zu verarschen.

Im Gegenteil war ich sehr begeistert und erfreut, so schnell Antworten bekommen zu haben, die mich ja auch auf gute Ideen gebracht haben soweit.

Frage an dieser Stelle, sofern jemand so etwas Banales überhaupt beantworten möchte: Bis zu welcher Größe könnte ein durchschnittlicher Rechner (Intel Core duo 3,33 GHz mit 8 GB Ram) denn sowas verwalten und damit rechnen? Wenn das erheblich weniger ist muss nämlich die Abbildung des Problems grundsätzlich überdacht werden.

Mit der nochmaligen Versicherung, dass ich nicht kichernd vor dem Rechner sitze und Leute in Foren verarschen möchte, die ihre Zeit opfern um mir zu helfen.

Gruß Alexander

SeppJ

Naja, zwischen Billionen und Trilliarden ist schon ein kleiner Unterschied . Billionen von Teilchen sind machbar.

Jedoch für Simulationen dieser Größe musst du trotzdem ganz andere Kaliber als einen Schreibtischrechner auffahren. Mit einem Heimrechner kannst du ein paar hundert Millionen Teilchen simulieren. Zumindest theoretisch von der RAM-Größe her. Teilchensimulationen sind aber eher durch Rechenleistung beschränkt, Erfahrungsgemäß kannst du auf einem flotten Heimrechner ein paar Tausend bis mehrere Zehntausend Teilchen noch einigermaßen vernünftig simulieren (d.h. mit ein paar Tagen bis Monaten Laufzeit für vernünftige Ergebnisse).

Für das was du so machen willst, brauchst du aber echte Rechenpower, das wäre State of the Art auf den besten Großrechnern der Welt mit den besten parallelen Algorithmen. Wenn du keine Erfahrung mit Simulationsphysik hast, dann frag jemanden der sich damit auskennt (ich kenne mich zwar auch aus, aber das Forum ist nicht die richtige Plattform). Arbeitest du im akademischen Umfeld? An den meisten Universitäten gibt es Computerphysikgruppen die sich immer freuen wenn sie mal etwas mit konkretem Praxisbezug machen dürfen. Die kennen sich auch mit Modellierung aus. Es ist nämlich fast nie nötig, so sehr ins Detail zu gehen wie du es vor hast. Es gibt zahlreiche sehr gute Vergröberungsstrategien die die Computerphysikleute kennen und sie kenne sich auch mit effizienten Simulationsalgorithmen aus (denn es gibt viele Fallstricke und Verbesserungsmöglichkeiten an naiven Algorithmen an die man als Anfänger nicht denkt). Selbst wenn du nicht an einer Uni arbeitest, könntest du mal an einer fragen, die freuen sich über Verbindungen zur Privatwirtschaft.

Th69

Solange du nur (wie von dir geschrieben) 32bit verwendest, kannst du eh nur (2 hoch 32 Byte) ~= 4 GB Speicher verwalten.
Wenn deine Teilchenstruktur sagen wir mal (3 * 4 Byte) = 12 Byte groß ist, dann kannst du damit MAXIMAL 357,9 Mio. Datensätze im Speicher gleichzeitig halten (wobei du je nach Betriebssystem evtl. auch nur max. 3 GB Speicher für deine Anwendung zur Verfügung hast).

Es kommt natürlich drauf an, was du mit diesen Daten anstellen willst, zur Datenhaltung würde ich dir dann aber eine Datenbank empfehlen (am besten unter 64 bit!), damit du dann nur von Festplattenspeicher abhängig bist, dann kannst du auch einige Terra-Byte benutzen.

Die generelle Frage wäre jedoch, brauchst du überhaupt die Position jedes einzelnen Atoms? Und was fängst du dann damit an?

AH

Also...

Ich arbeite an einer Universität und wir haben auch irgedwo einen Rechencluster.

Auf Trillionen bin ich ja auch nur gekommen, weil Wikipedia das als theoretischen Wertebereich eines unsigned long int angibt. Ich hab ja wie gesagt über 300 Billionen Atome, mit je drei Raumkoordinaten, und das ist ein eher kleines Teilchen. Da gehen die Zahlen schon schnell ab. Es ist schonmal was in der Richtung gelaufen, und da hatte die unrealistisch kleine Partikel halt wie am Anfang geschrieben etwas über 1,3 mio. Atome. Aber man möchte ja auch weiterentwickeln.

Die Teilchen sollen nicht direkt simuliert werden (also nicht so CFD mäßig mit Teilchenbewegungen oder so). Die Idee ist, die Kräfte, die zwischen diesen Teilchen wirken zu simulieren und zwar aufgrund der Kräfte der Atome. So soll es geforscht werden und ich werde nicht umhin kommen es zumindest so zu versuchen.

Mit dem Abstand der einzelnen Atome zu den Nachbaratomen eines anderen Teilchens nimmt natürlich die Anziehungskraft ab. Daher brauche ich eigentlich nur einen Riesenhaufen Koordinaten, die dann in die Kräfteberechnungen einfließen, ist also ein statischer Zustand.

Die Abstände sollen sich irgendwann eventuell verändern, aber auch hier wird diskret gerechnet und dann in Kurven dargestellt, also immer noch quasi statisch. Für mich ist es jetzt in einem ersten Schritt sehr interessant wie groß diese Teilchen dann maximal werden können. 10 Mikrometer ist eher klein, 1-100 Mikrometer wäre wünschenswert (ist dann aber wohl nicht machbar).

Mit euren Antworten kann ich jetzt aber zumindest abschätzen, was da an Teilchengröße so geht. Werde wohl die Berechnungen zunächst für sehr kleine Teilchen durchführen und wenn der Ansatz vielversprechend aussieht kann ich immer noch Leute mit Zugriff auf Rechencluster behelligen

Als Quereinsteiger in die Kunst des Programmierens traue ich mir jetzt allerdings nicht zu eine Datenbank einzurichten, da mach ich lieber die Partikeln kleiner, das sollte schneller gehen.

SeppJ

Auch Trillionen ist ein bisschen kleiner als Trilliarden . Und ja, das ist die übliche maximale Größe eines long.

Meine Einschätzungen zur Rechenzeit abhängig zur Systemgröße gelten aber trotz deiner Einschränkungen zur Reichweite der Kräfte. Diese habe ich nämlich ohnehin schon implizit angenommen, weil das ein üblicher Trick ist um die Rechenzeit drastisch zu reduzieren (von O(n²) zu O(n*log(n))). Und auch reine Kraftberechnungen brauchen sehr lange, denn das ist erfahrungsgemäß das was am meisten Rechenzeit verschlingt. Die Einschätzung von ein paar Zehntausend Teilchen pro CPU-Kern gilt daher immer noch.