# Technikentscheidung



## nocturn (17. Jun 2009)

Liebes Forum,

ich stehe vor einer Technikentscheidung für eine Entwicklungsmaschine habe da aber keine Erfahrung.
Es besteht der Rahmen zwischen 500 und 1000 EUR.

Die Lasten für den PC Wären (strongest-on-top):
- JBoss 6jdk ee
- JSF/RichFaces/IceFaces
- Struts
- Hibernate
- AOP
- JMS
- Verschlüsselung

Erstmal dachte ich an Xeon (mehr als dualcore brauche ich nicht, ich greife als einziger im Entwicklungsprozess auf den Rechner zu), dann habe ich benchmark-resultate von Opteron gesehen. 
Ich schätze ich entscheide mich für Opteron, der hat auch höheren ramdac.


----------



## maki (17. Jun 2009)

Bekommst doch einen Quadcore für weit unter 1000,- € mit 4GiB Ram, die Grafikarte kann die beste sein die man für 30,- € kaufen kann, schnelle Platten sind imho wichtig.
Kenne die Becnhmarks vom Opteron und Xeon nicht.


----------



## nocturn (17. Jun 2009)

maki hat gesagt.:


> Bekommst doch einen Quadcore für weit unter 1000,- € mit 4GiB Ram, die Grafikarte kann die beste sein die man für 30,- € kaufen kann, schnelle Platten sind imho wichtig.
> Kenne die Becnhmarks vom Opteron und Xeon nicht.



Quadcore brauche ich doch nur für lastenintensives ausführen.
Ich will aber doch nur lastenintensiv kompilieren.


----------



## maki (17. Jun 2009)

Wenn du nicht vorhast einen automatischen Build mit automatischen Integrationstests (starten des JBoss Servers) auszuführen, dann hast du eigentlich nicht soviel "Lastenintensives", würde persönlich trotzdem für einen Quadcore optieren.
Ein Duo Core tut es aber natürlich auch.


----------



## schalentier (17. Jun 2009)

Viel wichtiger als CPU ist doch so viel RAM wie nur irgendwie moeglich (min. 4GB) und so schnelle Platten, wie nur irgendwie moeglich (am besten im Raid0 oder 5). Teile des RAM kannst du auch als RAM-Disk nutzen und dort compilieren.

Bei der CPU wuerd ich inzwischen primaer auf den Stromverbauch achten. Lieber 2 Minuten im Stillen warten, als im Laerm zu arbeiten...


----------



## nocturn (23. Jun 2009)

Java SciMark Benchmark: Contributed Results

Wie geil ist das denn?
Also mir wurde von QuadCore abgeraten zum Entwickeln. Aber die Werte sind ja echt Riesig.


----------



## maki (23. Jun 2009)

nocturn hat gesagt.:


> Java SciMark Benchmark: Contributed Results
> 
> Wie geil ist das denn?
> Also mir wurde von QuadCore abgeraten zum Entwickeln. Aber die Werte sind ja echt Riesig.


Kann die Werte nicht nachvollziehen (Vista am schnellsten? LMFAO! Weil es so lahm war hab ich zu Ubuntu gewechselt), aber Flieskommaoperationen sind für's entwickeln auch meist egal.


----------



## nocturn (23. Jun 2009)

Eigentlich hast du recht, aber flieskommaoperationen war wohl nur ein Beispiel.
Da werden ja viele Speicherbewegungen getestet und so.

Könnte daran liegen dass es sich um eine java VM Early-Access (ea) (also Beta oder so) handelt.


----------



## sliwalker (23. Jun 2009)

Meiner Meinung nach ist das allerwichtigste die Festplatte.
Großer RAM ist unwichtig, da zum Kompilieren sowieso nicht alle Datenein auf einmal in den RAM geladen werden, um sie von dort zu kompilieren. CPU ist zweitrangig, weil es keine Festplatten gibt, die die Daten so schnell schreiben können, wie die CPU rechnet.
Deshalb ist und bleibt das Nadelöhr die Festplatte. SolidState ist nicht unbedingt schneller, wenn es um mehrere tausend Zugriffe in einer kurzen Zeit geht. 
Die höchste Geschwindigkeit bieten hier SAS-Platten an, siehe Wiki: Serial Attached SCSI ? Wikipedia.

Aber was willst Du damit Kompilieren?
Musst Du 1000 Auslieferungen an einem Tag mit jeweils anderen Paramtern erstellen, oder willst Du einfach nur darauf kompilieren? Wir haben build-Server, die einfach nur eine schnelle LAN-Anbindung haben. Auftrag abschicken, und eine E-Mail kommt wo und wann der Server fertig deployed ist.


----------



## nocturn (23. Jun 2009)

Konkret geht es um online-crm's/cms's (vorerst). Massendaten werden von Produktivserver übernommen, darauf ist also vorerst nciht zu achten.

Wichtig ist das on-the-run-compilation von JSP seiten in .class dateien und das laden von Java-Frameworks wie AspectJ, Hibernate, Richfaces, Struts, BCEL-Wrapper und so weiter.

Das größte unüberwindbare hindernis ist das class-dateien (beim debuggen) keine kompletten methodenstrukturen ersetzen können. (Fehlermeldung: Methode replacement is not yet implemented).

Auch classloader-hierarchieren spielen eine große Rolle.

Das Pattern also ist generisch, was die Versions-Kontrolle angeht (releaseoptimiert). 

Bestimmte Float-comma-operations sind eherer irrelevant. Wichtig sind WebNavigation (u.a. AJAX) und code-injection nach Hot-Deployment-Methode. Also das Ant-Basierte Kompilieren von Jsp-Seiten nach Java, nach class. 

Tatsächlich werde ich mich in sachen Dateisystem für Fat32 entscheiden, und Raid0 (siehe Schalentier und maki). Ramdrive ist ne gute Idee.


----------

