# Welchen Computer kaufen - worauf achten?

## Midsommer

Hallo an alle,

ich hab mal eine Frage, wie ich herausfinden kann, welchen Computer ich am besten für mein Problem kaufen soll.

Also: ich muss Uni-bedingt Bandstrukturrechnungen (Physik) ausführen. Der Code selber ist nur auf Singelprozessoren ausgelegt, liegt v.a. in fortran 90 vor und hat g++ Anteile. Zum Compilieren verwende ich den Intel Fortrancompiler (Linux). Es sollen nur für diesen Zweck mehrere Rechner angeschafft werden und der Preis spielt nur bedingt eine Rolle. Es müssen aber AMD oder Intel Rechner sein. 

Welchen Prozessor sollte ich mir zulegen bzw. auf welchen Benchmark sollte ich achten? 

Zur Zeit läuft der Code auf meinem AMD64 3200+ mit 768MB RAM (brauch aber nur ca. 10% davon) stabil und braucht für eine Rechnung bis zu 2 Monate. Das Ergebnis wird in einer List von fließkomme Zahlen (concatinierter Datei) ausgegeben (ca. 200MB - 1.4 GB groß).

Bin dankbar für jeden Tipp, wie man 

  a) den Code beschleunigen kann (bzgl. des compilers) und 

  b) auswendigmachen kann, welche Hardware diesen Code beschleunigt, bzw. worauf ich beim Kauf achten sollte. 

Danke schon im Voraus

----------

## Freiburg

Naja viele Möglichkeiten bleiben wohl nicht, wenn von 768MB nur 10% genutzt werden dürfte mehr RAM/schnellere Festplatte nicht viel bringen. DAS einzige was mir einfällt wäre ein schnellerer Prozessor z.B. einen AMD Athlon FX oder ein Pentium EE, davon allerdings nicht die neusten Versionen da die Dualcore sind, was dir nichts bringt. Im Endeffekt ist das einzige was diese Rechnungen beschleunigt den Code so umzuschreiben das er auf Multiprozessorsystemen oder auf Clustern ausgeführt werden kann...

----------

## Pegasus87

 *Midsommer wrote:*   

> 
> 
> Bin dankbar für jeden Tipp, wie man 
> 
>   a) den Code beschleunigen kann (bzgl. des compilers) und 
> ...

 

Ich denke mal dazu müsste man den Code sehen und dann entscheiden, ob man evtl. die in oder andere Funktion beschleunigen könnte.

Grundsätzlich kommt es natürlich auch auf die compiler-optionen an, mit denen du das Programm compilierst.

----------

## caraboides

Moin, 

ich studiere Informatik und hoffe mal das ich dir helfen kann.  :Wink: 

Da der Code sehr klein zu sein scheint, versuche ihn so hinzu bekommen das alles in den Cache passt. Da wuerde ich dir gleich einen Xeon-CPU empfehlen. Schalte aber HT ab, das stört nur, da du nur einen Prozess hast.

Bist du dir sicher, dass das Problem nicht zu parallel rechnen zu bekommen ist? Weil bei so einer langen laufzeit, wäre das der erste punkt wo ich ansetzen wuerde. Bei uns in MOSI wird das recht gut gemacht. Im bereich Bio und Physik.

PS: Mehr infos sollten helfen. Und da du ja an einer Uni bist. Habt ihr keinen Lehrstuhl für Verteieltes Hochleistungsrechnen? Die sollte euch helfen koennen.

CU

----------

## caraboides

 *Quote:*   

> Zur Zeit läuft der Code auf meinem AMD64 3200+ mit 768MB RAM (brauch aber nur ca. 10% davon) stabil und braucht für eine Rechnung bis zu 2 Monate. Das Ergebnis wird in einer List von fließkomme Zahlen (concatinierter Datei) ausgegeben (ca. 200MB - 1.4 GB groß).
> 
> 

 

Ich hoffe, das du die ausgabe erst in einen Buffer in den RAM schreibst. Sonnst bremmst du den Code nur. Hatte oft das Problem das ein "cout <<" recht lange braucht.

----------

## Midsommer

Erst einmal danke für die Antworten - den Code kann sich jeder gerne einmal ansehen. Ist ja freeware, zumindest im Aubildungsbereich.

http://www.fkf.mpg.de/andersen/docs/lmtoart_programs.html

Bin leider nur Physiker mit Informatik-Grundstudiums niveau - also Assembler sagt mir was - aber nur auf Sparkarchitektur =(. Für mehr reichts dann auch nicht. Auch hatte ich nur Java, Oberon und C++.

Parallelisieren wird man den sicher können - die frage ist leider nur welchen Zeitaufwand man hierfür betreiben muss. 

Ansatzpunkt wäre die Selbstkonistenzschleife, die für jeden Netzpunkt laufen muss - das dauert am längsten und jeder Netzpunkt läuft unabhängig vom anderen. Die Idee ist die folgende: Man gibt sich die Kristallstruktur vor, unterteilt den Raum in Netzpunkte und Fouriertransformiert diese. Nun setzt man sich _nacheinander_ auf einen solchen Netzpunkt und lässt die Formeln darauf los. wenn alle Netzpunkte durch sind vergleicht man das Ergebnis mit den Anfangswerten und wenn diese differieren, nimmt man das Ergebnis und versucht es von neuem. Solange, bis das Ergebnis dem Endpunkt entspricht.

Thema Cluster: Das setzt voraus, dass der Code Paralellisiert ist - meines wissens ist er es aber nicht =( zumindest nicht laut Dokumentation - kann man das notfalls schnell am Code erkennen und wie muss ich den Code dann compilieren? Außerdem: Clusterzeiten zu bekommen ist immer eine pure Illusion... ich bin seit knapp zwei Wochen in der Warteschleife...=(

----------

## caraboides

Also an sich sollte der aufwand nicht zu hoch sein. Aber zeit wuerde es trotzdem brauchen.   :Confused: 

Ich habe leider viel um die ohren sonst wuerde ich mich mal dran setzen. 

Das was ich aber bisher erfahren habe spricht nicht viel dagegen.

z.B. die FFt der einzehlen knoten koennte mal ganz leicht in mehere prozesse packen. (Mache ich immer fuer mein Sonogram  :Wink: 

Dann brauchst du auch kein Cluster fuer. Bzw baust dir selbst eins (MPI ist dort das zauberwort)

Wenn du im augenblick 2monate brauchst. Nimm dir einen Rechner mit 4Cpus und das ganze würde in 2-3wochen fertig sein.

Nimmst du MPI kannst du dir auch einfach 12 billige Rechner max 6000 kaufen und der Effekt wäre noch hoeher.

Also potential ist da um die Sache zu beschleunigen. Also in in C reicht ja schon ein fork() aus um die sache parallel laufen zu lassen.

Hoffe ich konnte dir helfen.

Vieleicht melde ich mich noch mal wenn ich den Code mal gesichtet habe.

CU

Christian

----------

## Midsommer

..na das Problem ist, dass alles in Fortran ist =( da hört es halt bei mir auf. und fork() hat ich auch noch nicht =(... Gibs da ein gutes Buch für Parallele Programierung?

Aber mal auf den Punkt: "...es im Cach zu halten....":

Das Programm alloziiert nicht mehr als 2MB (laut Documentation). Heißt dass, ich bräuchte L1 Cach von 2MB min und alles läuft besser? (bitte nicht hauen, wenn dass jetzt doof war)... Muss ich spezielle Flags setzten? Kenn mich leider noch nicht so gut mit den ifort aus...

----------

## caraboides

Sorry, aber das ist fotran und da sehe ich nicht durch.

C oder Java wäre kein Problem ;-(. Mich wundert es aber das es tatsächlich nur mit einer CPU läuft. Am besten du schreibst mal an die Endwickler des Programms ob die daran arbeiten oder, aus welchem Grund es nicht geht.

Falls dein Problem nich zu komplex solltest du vielleicht darueber nachden ein eigenes Programm zu schreiben. Das kannst du dann ja drauf auslegen, das es in meheren Prozessen läuft.

Da gibt es recht gut bücher drüber. 

CU

----------

## caraboides

Genau, da auf aktuellen Rechner die Hit-raten des Caches bei 95% liegen (oder noch hoeher) solltest du 2-4mb cache nehmen.

Da das OS ja auch mal ab und zu was machen will  :Wink: 

----------

## caraboides

Buch:

Unix C-Programming Ein Kompendium; Bernhard Davignon

ISBN: 3-89362-087-7

Ist zwar recht alt, aber das Kapitel 7 erklärt recht gut was man alles so mit Prozessen machen kann. (Sollte es in der Uni-Bibo geben)

----------

## amne

Deutsches Forum  :Arrow:  Diskussionsforum.

----------

## Midsommer

...hm - also dann werd ich mal schaun was kommt. Savrasov seh ich erst in 6 Monaten und Profs antwortern bekanntlich nie auf emails  :Wink:  Und bzgl. Fragen ob Multiprozessor oder nicht: man arbeitet schon an einer C++ Portierung - nur die Frage ist immer wie lange das noch dauert. Man darf auch nicht vergessen, dass die keine Geld dafür bekommen.

Ich denk das beste wird sein, ich kauf ne Maschinen mit massig Cash. Irgendwelche Tipps? die Anschaffung kann noch einwenig warten - ich beginne erst im Sommer mit meiner Promotion. Was würdet ihr nehmen? Dualcore wirds wahrscheinlich eh werden - worauf sollte ich achten? Großer Cash (ab 2MB)?. FPU? (denke mal, die wird massiv beansprucht).

----------

## caraboides

http://store.sun.com/CMTemplate/CEServlet?process=SunStore&cmdViewProduct_CP&catid=143025

Das wuerde ich nehmen. Da die Kiste ja eh länger laufen soll greife lieber zu SUn. Die Rechner sind echt gut. Die Performance ist TOp. Und wenn du die Sache parrelle bekommst. Laufen die richtig gut. (und die haben 3mb Cache) fallst du den Ohne Platte fuer 3000$ nimmst lasse die per PXE booten. Und nimm Solaris als OS. 

Und meine Profs antworten auf mails  :Wink: 

----------

## Midsommer

.. hm schon gut - nur sollte es ne intel oder AMD-kiste sein, damit nach mir noch mal Windows darauf kann und der rest des Department damit normal arbeiten kann.

hab mal gegooglt... intel scheint 2x2MBs zu verbauen - AMD 2x1MB - sollt ich dann lieber den Intel nehmen? - macht der FSB (800 / 1060MHZ) was aus? ich meine wieder speziell für mein Problem (sollte ja max. 2MB alloziiert werden). 

Gibs bei der FPU nen Unterschied? wenn ja - welchen?

----------

## caraboides

Dann wohl lieber Intel.

Ein Xeon Intel als dualCore bzw 2 CPUs sollte es schon sein. Weil dann kannst du versuchen die Sache zum MP-Betrieb zu bekommen. Und schalte auf alle fälle das HT ab, mit der SPEC kann man gut sehen das HT beim NumberCrunching stört.

CU

----------

## Midsommer

ähm... ich hab keinen Intel bis dato.. wie schalt ich das HT ab? 

würde es jetzt einfach nur im Kernel rauslassen... 

sonst noch was, worauf ich achten sollte?

----------

## andix

AFAIK im BIOS, hab aber auch keinen Intel.

----------

## Hilefoks

 *Midsommer wrote:*   

> intel scheint 2x2MBs zu verbauen - AMD 2x1MB

 

Nicht Grundsätzlich. Die Dual-Core Opterons mit Denmark Kern haben 2MB, die mit Venus, Italy und Egypt Kerne aber "nur" 1MB. Auch bei Intel haben nicht alle Kerne 2MB, und nur der Pentium D 950 hat 4MB Cache.

 *Midsommer wrote:*   

> sollt ich dann lieber den Intel nehmen?

 

Nicht aufgrund der Caches. Wenn du wirklich Mehrprozessor-Unterstützung in dein Programm bekommst, dann würde ich dir eher ein 2 oder 4 Wege Opteron-System ans Herz legen. Xeons haben das Problem das ihre komplette Kommunikation über einen einzigen, langsamen FSB abläuft.

MfG Hilefoks

----------

## caraboides

Moin,

http://de.wikipedia.org/wiki/AMD_Opteron#Sledgehammer_B3

Habe leider noch nichts besseres an Infos gefunden.

Auf alle fälle scheint der Opteron Denmark pro Core ein L2-Cache zu haben, der ist aber nur 1mb gross. Das ist zwar nicht ganz so kritisch. Da ja die Hitraten ja eh recht hoch sind. Musst mal schauen wie sehr der Code auf den 2mb rum saut. Wuerde eher ne CPU mit mindestens 2mb nehmen.

und das mit der Schlechten anbindung von Intel bei den Cores sollte nicht so stoeren, da bei deinem Problem die Kommunikation unter den Cores nicht so gross sein sollte. Dieses Thema wird recht uberbewerte und sollte kein gegenargument sein.

PS: Dein Code nutz den Cache von ganz allein der kuemmert sich der Cache selbst drum. (in der Aktuellen IX steht das sich die CPUs um den Cache kuemmern muessen, das ist totaler bloedsin, Cache ist transparent an den Addressbus angebunden und jagt bei einem HIT einfach schneller als der Ram die Daten auf den Datenbus)

CU

----------

## Midsommer

Noch mal danke für die Hilfe - ich hab vorhin noch erfahren, dass wir Testrechner bekommen können - juhu. D.h. ich kann den code einfach mal auf den verschiedenen Rechnern installieren und selbst die Zeit messen =) - na da sagt man noch mal Service-wüste Deutschland...

Aber noch mal so am Rande: sollte ich den Code auf jeden Rechner neu compilieren? Oder reicht es wenn ich ihn auf einer Kiste compiliert habe um vergleichswerte zu erhalten. (zumindest wäre es doch eine gewisse Zeitersparnis).

Kann/Muss ich bei ifort überhaupt flags setzten oder liest auch der intelcompiler die make.conf (dacht die sei nur für die gnu-compiler...). Bzw. bringt flags setzten was bei ifort?

----------

## caraboides

kommt drauf an.

Wenn der Compiler nur 386 code erzeugt nicht.

Wenn er aber auf der arch optimiert natuerlich. Muesste im Makefile stehen oder du stellst es ueber flags an.

CU

----------

## furanku

Hallo,

bei Laufzeiten von 2 Monaten wird Dir ein schnellerer PC nur sehr begrenzt helfen, wenn Du in den Bereich von Tagen als Laufzeit kommen willst. Parallelisieren ist da die einzige Alternative. In meiner Festkörperabeitsgruppe berechen viele z.B. den Transport durch Quantenpunkte und ähnliches mit mittels MPI parallelisierten Fortran und C++ Programmen auf unseren (SUSE-)Arbeitsplatzrechnern bzw. auf dem Cluster unseres Rechenzentrums. Ich arbeite analytisch, bin also nicht so fit in MPI. Aber gerade zur Berechnung von Bandstrukuren (das Thema ist ja nicht gerade neu)  sollte es jede Menge Beispiel Implementationen geben und jedes UNI Rechnezentrum sollte auch Kurse in MPI anbieten, auch auf den MPI Seiten findest Du Tutorials. Auch Dein Prof. sollte ein paar Pakete kennen die Parallel Bandstrukturen berechnen.

MPI ist für viele Betriebssyteme und Rechnerachitekturen und Compiler verfügbar, fast jede Linuxdistribution hat die Libraries schon dabei und es ist auch das was Micosoft mit viel Tamtam zu einem 2003 Server hinzufügt und es dann als "Supercomputing solution Windows Compute Cluster" zu verkaufen. Wenn selbst Microsoft so überzeugt ist, daß sie zum ersten mal ein OpenSource Programm als offiziellen Bestandteil ihrer Betriebssysteme mitausliefern, sollte Dich das überzeigen: Es lohnt sich wirklich einen Monat zu investieren und MPI zu erlernen und zumindest die grundsätzlichsten Sachen zu parallelisieren, sonst frag doch Deinen Prof ob er bereit ist eine studentische Hilfskraft einzustellen, die Dir hilft den vorhandenen Code auf den "aktuellen Stand" der Bandkanten Rechnungen zu bringen  :Wink: 

----------

