Weche Programmiersprache Physik?
-
C++ scheint derzeit die Sprache im Bereich des Scientific-Computings zu sein. Man findet aber noch sehr viel FORTRAN und C. Sehr interessant und neu in dem Bereich ist zB Crays Chapel. Matlab, R, Mathematica, und haufenweise Domänenspezifischsprachen haben auch ihre Verbreitung aber natürlich ihre Grenzen bei größeren Modellen.
Steffo schrieb:
Java. Ist plattformunabhängig, sehr verbreitet und es gibt viele Bibliotheken dafür.
Ja und? Java hat Stärken in anderen Bereichen. Aber für Scientific Computing ist es nicht wirklich brauchbar. Sprachen in dem Bereich sollten sind entweder Domänenspezifisch oder bieten zumindest Operatorüberladung und ähnliche Geschichten. Matrix.add(m,Matrix.mul(a,b)) ist halt einfach deutlich schlechter lesbar als m+a*b.
Mechanics schrieb:
Wobei es erstaunlicherweise (zumindest für mich) sehr viele wissenschaftliche Programme in Java gibt. Da braucht man nur auf sourceforge suchen, ich glaube, allein da ist schon das meiste aus der Kategorie "Wissenschaft" in Java.
Sourceforge? Also letzter Commit von Anfang 2003 ;). Naja, natürlich findet man Programme die mit Java geschrieben sind. Das liegt wohl vor allem an der Ausbildungspolitik der Unis in den letzten 10 Jahren. Aber ist es wirklich eine gute Wahl für wissenschaftliche Berechnungen? Ich meine nicht. Java hat halt andere Aufgabenbereiche. Wenn man JVM nutzen will, dann kann man sich zB Fortress (oder X10?) anschauen. Wobei ich nicht weiß, wie es um Fortress steht, seit dem sie aus dem HPC-Sprachen Wettbewerb geflogen sind und Sun von Oracle übernommen wurde. Das Wiki begrüßt einen zumindest mit Fehlermeldungen. Aber immerhin arbeitet da Guy Steele dran (der Typ der bei C, Scheme, Java, Common Lisp, Emacs, Fortran, etc. beteiligt war)
audacia schrieb:
R finde ich übrigens stark unterbewertet.
R ist schon sehr nett. Aber es hat sehr starke Limitierungen. Es ist einfach nicht für große Modelle/Simulationen ausgelegt. Ein Freund von mir, der mehr im Bio-Bereich arbeitet, hat mir neulich erzählt, dass da jemand eine 4GiB CSV-Datei laden wollte. Das hat halt 2 Tage auf dem ziemlich teuren Cluster gebraucht und hunderte GiB RAM benötigt. Man stößt damit also schnell an seine Grenzen.
gastfrage schrieb:
Witzbold, und auf was für einem Cluster hab/brauch ich eine Grafikkarte? ...
Guten morgen. Mittlerweile sind Grafikkarten im Scientific-Computing-Bereich weit verbreitet. Schau dir einfach mal die Top500 Liste an. Die aktuelle Nr. 2 ist zB hauptsächlich auf Tesla-Karten gebaut.
-
rüdiger schrieb:
R ist schon sehr nett. Aber es hat sehr starke Limitierungen. Es ist einfach nicht für große Modelle/Simulationen ausgelegt. Ein Freund von mir, der mehr im Bio-Bereich arbeitet, hat mir neulich erzählt, dass da jemand eine 4GiB CSV-Datei laden wollte. Das hat halt 2 Tage auf dem ziemlich teuren Cluster gebraucht und hunderte GiB RAM benötigt. Man stößt damit also schnell an seine Grenzen.
Was für Schlüsse ziehst du jetzt daraus? Dass das an R liegt? Könnte aber genauso an den Programmierern gelegen haben...
-
Meine Erfahrungen mit R: Kleine Sachen Ok, grosse Sachen nicht Ok. Das trifft auf die meisten Scriptsprachen zu.
-
Steffo schrieb:
Was für Schlüsse ziehst du jetzt daraus? Dass das an R liegt? Könnte aber genauso an den Programmierern gelegen haben...
Wie genau? read.csv ist Teil der Standardlibrary von R. Was soll ein Anwenderfehler sein können, wenn das versagt?
Ich hatte mit R auch schon meine Schwierigkeiten, wenn die Datenmengen nur groß genug wurden.
-
Steffo schrieb:
Java. Ist plattformunabhängig, sehr verbreitet und es gibt viele Bibliotheken dafür.
Java ist nicht plattformunabhängig sondern im Gegenteil an die JVM gebunden. Das ist im Scientific Computing ein großer Hinderungsgrund (abgesehen von den anderen genannten Gründen).
-
R ist einfach nicht für große Datenmengen ausgelegt. (Wie nman bereits gesagt hat, ist das lesen von CSV-Dateien Bestandteil der Standardbibliothek) Ich glaub die offiziellen Pakete enthalten sogar nur das Referenz BLAS (bei Debian/Ubuntu ist es immerhin Atlas). Es wird wohl daran gearbeitet, dass die Performance von R verbessert wird. Mittlerweile gibt es glaube ich sogar einen Bytecodecompiler.
Das Problem ist halt, dass viele Leute im wissenschaftlichen Bereich nicht programmieren können. Gerade Biologen haben oft nicht mal eine Programmiervorlesung im Studium. Wenn sie dann für ihre Diss oder Masterarbeit in die echte Forschung kommen, dann müssen sie auf einmal programmieren können. Dann nehmen sie eben die paar Tools, die sie vielleicht im Studium kennen gelernt haben, zB R weil man einen Statistikkurs hatte oder man lässt Perl-Programme auf sau teuren Supercomputern laufen.
-
von den genannten gründen für/gegen java mal abgesehen, sei gesagt, dass ich durchaus einige simulationen an unserer uni kenne, die in java geschrieben wurden.
ob das ganze so optimal ist, ist wieder eine andere frage, aber jedenfalls darf man java nicht unterschätzen.
ein grund ist sicher, dass java an den unis gelehrt wird. wenn man stattdessen mehr c++ lernen würde, wäre java wahrscheinlich viel weniger vertreten.
-
Fürs Backend ist in jedem Fall C++, C oder Fortran Standard, für kleinere Sachen und Prototypen Matlab. Sachen wie CUDA oder OpenCL etc. kommen nur in Frage, wenn es das zu lösende Problem zulässt. Ich würde mal konkret nach vorhandenen Libraries schauen, denn alleine so etwas programmieren ist oft nicht ratsam. Worum geht es denn konkret?
-
Worum geht es denn konkret?
Nichts konkretes, ich wollte blos wissen, auf welche Programmiersprache ich umlernen soll, denn mit RealBasic und Visual Basic lässt sich in dem Bereich Physik und Simulation halt nicht viel machen. Jetzt habe ich mich für C++ entschieden, da sind die Aussichten besser
-
Walli schrieb:
Fürs Backend ist in jedem Fall C++, C oder Fortran Standard, für kleinere Sachen und Prototypen Matlab.
Lasst doch bitte FORTRAN aus dem Spiel. Bis in die 80er Jahre war FORTRAN für wissenschaftliche Anwendungen, Physiker und Ingenieure die Sprache der Wahl. Mit der Verfügbarkeit von C sind die meisten FORTRAN-Anwender auf C umgestiegen, weil C einfach mehr Möglichkeiten bietet.
Mit C++ triffst du eine gute Wahl und C ist komplett enthalten. Simulationen können sehr aufwendig sein. Der Rechenteil mit den Algorithmen steht im Vordergrund, die GUI interessiert weniger. Man braucht eine solide Programmiergrundlage, auch wenn man vorhandene Libraries einsetzen möchte. Auch die Plattformunabhängigkeit ist für alle C-Sprachen gross.
-
berniebutt schrieb:
Walli schrieb:
Fürs Backend ist in jedem Fall C++, C oder Fortran Standard, für kleinere Sachen und Prototypen Matlab.
Lasst doch bitte FORTRAN aus dem Spiel. Bis in die 80er Jahre war FORTRAN für wissenschaftliche Anwendungen, Physiker und Ingenieure die Sprache der Wahl. Mit der Verfügbarkeit von C sind die meisten FORTRAN-Anwender auf C umgestiegen, weil C einfach mehr Möglichkeiten bietet.
Ich habe lediglich gesagt, was Standard ist. Eine ganze Menge wissenschaftlicher Simulationscodes die heute und in den nächsten Jahren verwendet werden basieren auf Fortran, das ist Fakt. Neuentwicklungen sind meist in C++, aber das ändert nichts an der Tatsache, dass Fortran und C im wissenschaftlichen Rechnen durchaus noch weit verbreitet sind. Anhand der Reihenfolge in der ich die Sprachen genannt habe, hättest Du durchaus auch eine Präferenz meinerseits ablesen können, wenn Du nur gewollt hättest. Reg Dich mal lieber über die Leute auf, die hier Java vorschlagen. Bis auf sehr sehr wenige Ausnahmen ist diese Sprache im Gegensatz zu Fortran ziemlich irrelevant im scientific computing. Nebenbei bemerkt ist Fortran für manche Dinge nicht so verkehrt. OOP usw. ist auch in neueren Versionen ein ziemlicher Krampf, wenn man aus der C++-Ecke kommt, aber manchmal hat man auch Simulationen nach dem Motto "input - number crunching - output" ohne viel Spielerei, die man sehr schön in Fortran implementieren kann. Ich würd's ohne Not trotzdem nicht tun. Den einzigen wirklichen Vorteil den ich heute noch durchgehen lassen würde ist, dass man es wirklich auf jedem Toaster der letzten 20 Jahre ans Laufen bekommt, wohingegen man mit manchen aktuellen C++-Codes schon auf dem GCC 4.4 Probleme bekommt. Aber da wäre auch die Frage erlaubt, ob man wirklich aktuelle Codes auf veralteten Clustern laufen lassen möchte.
-
Aber Fortran ist nicht Fortran und Fortran ist performant:
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=all
http://shootout.alioth.debian.org/u32q/benchmark.php?test=threadring&lang=all
http://www.rz.uni-osnabrueck.de/Zum_Nachlesen/Skripte_Tutorials/Programmieren_In_Fortran_77/pdf/fortran1.pdf
http://www.opengl.org/resources/libraries/glut/C und Fortrancompiler + Vi für die Windowskonsole gibt es hier:
http://www.openwatcom.com/index.php/Main_Page
(C++ ist auch dabei, viel falsch machen kann man da nicht)
(fehlt eigentlich nur noch ein Lisp-Dialekt, aber den kann man sich ja noch für die Uni aufheben, und sei es nur als Sündenbock oder als Übung für Scala, weil man ja Java bestimmt irgendwo (heutzutage) an der Uni reingedrückt bekommt.Ein gutes kostenloses Computeralgebrasystem zum Anschauen und Lernen wäre z.B. Octave http://www.gnu.org/software/octave/ (C/Unix-Syntax).
C++ würde ich eher auf die Unizeit verschieben, nachdem man sowieso schon Java pauken musste. Neben Cuda kann man C auch noch mit Scriptsprachen wie Lua http://www.lua.org/about.html erweitern. Den Luacompiler/Interpreter kann man am unkompliziertesten mit dem tcc http://bellard.org/tcc/ (auf Windows) compilieren.
-
Was ich so auf den Konferenzen mitbekommen habe, wird wohl dort viel Fortran und C++ verwendet.
Der Trend soll eher zu C++ gehen. Wobei das auch aufs Institut ankommt, wo sie ihre Codebasis haben.
-
berniebutt schrieb:
Walli schrieb:
Fürs Backend ist in jedem Fall C++, C oder Fortran Standard, für kleinere Sachen und Prototypen Matlab.
Lasst doch bitte FORTRAN aus dem Spiel. Bis in die 80er Jahre war FORTRAN für wissenschaftliche Anwendungen, Physiker und Ingenieure die Sprache der Wahl. Mit der Verfügbarkeit von C sind die meisten FORTRAN-Anwender auf C umgestiegen, weil C einfach mehr Möglichkeiten bietet.
Fortran ist immer noch weit verbreitet. Je nach Forschungsgruppe wird auch noch immer fleißig in Fortran programmiert. Ich würde Fortran nicht nutzen wollen und auch nicht empfehlen. Aber so zu tun, als wäre Fortran seit den 80ern irrelevant ist schlicht und einfach falsch.
nachtfeuer schrieb:
C und Fortrancompiler + Vi für die Windowskonsole gibt es hier:
http://www.openwatcom.com/index.php/Main_Page
(C++ ist auch dabei, viel falsch machen kann man da nicht)
(fehlt eigentlich nur noch ein Lisp-Dialekt, aber den kann man sich ja noch für die Uni aufheben, und sei es nur als Sündenbock oder als Übung für Scala, weil man ja Java bestimmt irgendwo (heutzutage) an der Uni reingedrückt bekommt.OpenWatcom -> Latest Release (June 2010). Sowohl für Fortran 2008 wurde 2010 publiziert und sowohl C als auch C++ haben 2011 einen neuen Standard bekommen. Ich wage mal zu bezweifeln, dass der OpenWatcom da sinnvollen Support bietet. GCC ist da sicher eine bessere Alternative wenn es kostenlos sein soll.
nachtfeuer schrieb:
Ein gutes kostenloses Computeralgebrasystem zum Anschauen und Lernen wäre z.B. Octave http://www.gnu.org/software/octave/ (C/Unix-Syntax).
Octave ist kein CAS. Octave ist einfach eine Matlab-ähnliche Programmiersprache die hauptsächlich für numerische Sachen entworfen wurde. Lua und Scala sind für physikalische Probleme glaube ich wirklich uninteressant.
-
rüdiger schrieb:
OpenWatcom -> Latest Release (June 2010). Sowohl für Fortran 2008 wurde 2010 publiziert und sowohl C als auch C++ haben 2011 einen neuen Standard bekommen. Ich wage mal zu bezweifeln, dass der OpenWatcom da sinnvollen Support bietet. GCC ist da sicher eine bessere Alternative wenn es kostenlos sein soll.
Für Linux-Nerds bestimmt. Mingw ist aber gelegentlich fummelig, auch nicht immer aktuell, buggiger, beim Runterladen beschweren sich Sicherheitswächter, gas keine Standard asm Syntax, kommt nicht automatisch in die Windows Shell, weniger gut dokumentiert als Watcom, kein Windowshell-Vi, kein Profiler, keinen systemeigenen Debugger, wenig Windowsbezüglichen Detail-Infos und dies und das. die Vorteile überwiegen zum großen Teil die Nachteile von aktuell und standard. Für neuere Standards brauchts letztlich auch die passende Literatur, und wenn da eine einsteigerfreundliche dabei ist, wird sie vielleicht auf Mingw eingehen oder Linuxbenutzung nahelegen.
rüdiger schrieb:
nachtfeuer schrieb:
Ein gutes kostenloses Computeralgebrasystem zum Anschauen und Lernen wäre z.B. Octave http://www.gnu.org/software/octave/ (C/Unix-Syntax).
Octave ist kein CAS. Octave ist einfach eine Matlab-ähnliche Programmiersprache die hauptsächlich für numerische Sachen entworfen wurde. Lua und Scala sind für physikalische Probleme glaube ich wirklich uninteressant.
hm, ja, hätte ich vielleicht nicht so schreiben sollen. Nichtsdestotrotz hat Octave eine C-Schnittstelle, ist flexibel erweiterbar z.B. http://octave.sourceforge.net/packages.php, auch mit symbolic, ist teilweise flexibler als Matlab, gerade bei speziellen Einzelanwendungen und ist eine gute Einstiegsdroge (für Matlab(an der Uni))sowieso.
Lua war hier mehr als Vertiefung für C und als praktische Skriptsprachenhilfe für dies und das genannt, Scala als funktionale (und angenehmere?)Schnittstelle zur JVM, etwa für Java-Applets->( http://jim-mcbeath.blogspot.com/2008/08/stringart-scala-applet.html ; http://www.schulphysik.de/java/physlet/ ), aber das auch nur zur Vertiefung von Unikursen mit Java und funktionalen Sprachen.
-
rüdiger schrieb:
Fortran ist immer noch weit verbreitet. Je nach Forschungsgruppe wird auch noch immer fleißig in Fortran programmiert. Ich würde Fortran nicht nutzen wollen und auch nicht empfehlen. Aber so zu tun, als wäre Fortran seit den 80ern irrelevant ist schlicht und einfach falsch.
Ich hatte auch nicht gemeint, dass FORTRAN vollkommen tot ist. Es ging um die Frage, was soll ich mir für Physik aneignen? Da empfehle ich klar C und C++. Kriegt man einen vorhandenen FORTRAN-Code vorgelegt, sollte man diesen mit geringer Einarbeitung leicht verstehen und bei Bedarf auch ändern können. Alles was in FORTRAN vorhanden ist, findet sich in C und C++ wieder - nur anders.
-
Hier ist glaube ich eine etwas ausgewogenere Beitragsseite zum Thema:
http://lambda-the-ultimate.org/node/2720
Allerdings wird hier Cuda und Opencl (C, aber auch Schnittstellen zu anderen Sprachen) vermutlich wegen dem Alter der Seite gar nicht angesprochen. Von 2008 halt.Der eigentliche Herausforderer für Fortran ist Haskell. Aber Fortran ist halt etwas performanter. Und wenn es dann eben schnell sein soll, gehts dann halt wieder über Cuda, C, Fortran und für Fortran gibt es natürlich auch Cuda-Anbindungen, wie für andere Sprachen http://www.nvidia.de/object/cuda_fortran_de.html
Und http://chapel.cray.com/ ...vielleicht auch einen Blick wert.
-
nachtfeuer schrieb:
Hier ist glaube ich eine etwas ausgewogenere Beitragsseite zum Thema:
http://lambda-the-ultimate.org/node/2720Äh, das wirkt eher ein bisschen merkwürdig. Hab von Boo noch nichts gehört. Das letztes Release ist 1.5 Jahre alt und für .NET. Also nicht wirklich wonach man bei einer SciComp-Sprache sucht. Er erwähnt nicht einmal X10, Fortress oder Chapel. Und C++ hält er für "not promising"
Ich glaube das ist eher ein weniger sinnvoller Artikel.nachtfeuer schrieb:
Der eigentliche Herausforderer für Fortran ist Haskell. Aber Fortran ist halt etwas performanter.
Haskell ist nicht wirklich für Numerik ausgelegt. Außerdem ist die Sprache zu kompliziert für Leute die ohnehin nicht gut programmieren. Mathematiker mögen Haskell vielleicht, aber das heißt nicht, dass es für Numerik taugt.
-
rüdiger schrieb:
nachtfeuer schrieb:
Der eigentliche Herausforderer für Fortran ist Haskell. Aber Fortran ist halt etwas performanter.
Haskell ist nicht wirklich für Numerik ausgelegt. Außerdem ist die Sprache zu kompliziert für Leute die ohnehin nicht gut programmieren. Mathematiker mögen Haskell vielleicht, aber das heißt nicht, dass es für Numerik taugt.
Wüsste jetzt nicht, wieso nicht, zumal man auch Schnittstellen zu C und Cuda hat und Haskell ist parallelfreundlich, wie eben auch Chapel.
Ich glaube, Haskell ist nicht komplizierter als C++ oder C. Vielleicht etwas schwerer als Basic, Haskell hat ja auch mehr Möglichkeiten Kniffe, aber Fortran hat einen gewissen Basic-Charm, so gesehen hätte Fortran jetzt einen Bonuspunkt.
Rein didaktisch könnte man (als Haskellvorläufer) ja zuerst Lisp lernen, denn Lisp ist auch einfach
http://www.amazon.de/Land-Lisp-Lisp-Programmierung-programmieren-Professional/dp/3826691636/
aber der TO wollte bestimmt nicht noch eine nicht so performante(relativ!) Interpretersprache lernen
(dann wohl eher was mit .net und directx?)Du hattest ja Chapel schon weiter oben angesprochen, hast du schon Erfahrung sammeln können, auch im Vergleich mit anderen Parallellösungen (Cuda, OpenCl, Mpi usw.)?
-
nachtfeuer schrieb:
Du hattest ja Chapel schon weiter oben angesprochen, hast du schon Erfahrung sammeln können, auch im Vergleich mit anderen Parallellösungen (Cuda, OpenCl, Mpi usw.)?
Ich hab mit Chapel ein bisschen gespielt und mir ein paar der Vorträge durchgelesen. Leider habe ich es nicht groß einsetzen können bisher und meine Spielereien haben die hpc Features noch nicht wirklich ausgenutzt. Aber im Vergleich zu MPI ist es deutlich einfacher. Man hat eben eine globale und nicht lokale Perspektive. Ich kann mir aber vorstellen, dass man mit Chapel teilweise das Problem hat, abzuschätzen wie viele Daten nun über das Netzwerk gehen.
