Ein grafischer Vergleich verschiedener Benchmarks und Programmiersprachen: http://scienceblogs.com/catdynamics/2014/04/21/why-fortran-lives/
Och, warum nicht. Ich mußte FORTRAN auch noch lernen. Erstes Semester EDV, da kam niemand dran vorbei. Aber es ist bereits eine Hochsprache, und man muß sich nicht mehr mit Assembler plagen. Einige wenige Kommilitonen hatten damals 386-er mit und ohne Coprozessor. Nicht alle FORTRAN-Compiler boten eine Emulation des Coprozessors. Das war damals auch so ein Ding. Dann funktionierte ein Compiler gar nicht, der unbedingt den Coprozessor benötigte. Ab 486 war das aber gegessen.
Angehängte Dateien:
-
04260001.jpg
220 KB
Ein Elektroniker schrieb: > Einige wenige Kommilitonen hatten damals 386-er mit und ohne > Coprozessor. FORTRAN auf Kleinrechnern? Pillepalle...
Klaus Wachtler schrieb: > Ein Elektroniker schrieb: >> Einige wenige Kommilitonen hatten damals 386-er mit und ohne >> Coprozessor. > > FORTRAN auf Kleinrechnern? Pillepalle... Mit Lochkarten hatte ich es nie mehr, aber der Compiler geht auf einem Notebook mit Vista bestimmt ab wie die Sau. Vielleicht probiere ich noch mal einen in der virtuellen DOS-Maschine DOSbox 0.74, wenn er direkt in Vista nicht läuft.
Klaus Wachtler schrieb: > FORTRAN auf Kleinrechnern? Pillepalle... Ja, aber die aufgedruckten Codezeilen sind doch für Weicheier. Da entsteht doch überhaupt keine Herausforderung, wenn der Stapel mit ein paar Tausend Karten mal auf den Boden fällt ;-)
Naja, die echten Weicheier konnten in den Spalten 73...80 (die ja von FTN ungeutzt waren) fortlaufende Nummern automatisch stanzen lassen (mit wählbarem Abstand, um später noch etwas einfügen zu können. Dadurch konnte man von einem rein mechanischen Sortierer die Karten wieder sortieren lassen :-) Ein Elektroniker schrieb: > Mit Lochkarten hatte ich es nie mehr, aber der Compiler geht auf einem > Notebook mit Vista bestimmt ab wie die Sau. Der obige Kartenstapel war von einem Übungsprogramm aus meiner Vorlesung. Später habe ich auf demselben Rechner (Control Data Cyber 76) noch als HiWi mit einer Simulation gearbeitet, die nur am Freitag abend gestartet werden durfte, weil sie 8-10 Stunden (!) CPU-Zeit brauchte, also unter der Woche nicht den Betrieb ausbremsen durfte. Jahre später fiel mir der Quelltext dann nochmal in die Hand (inzwischen auf einem Band) und ich habe es spaßeshalber mal auf einem Pentium III zum Laufen gebracht mit dem g77. Übersetzungszeit: mehrere Minuten, Laufzeit: 0.5 sec bei fast identischen Ausgabeverläufen. Der Originalrechner kostete damals mehrere Millionen, und wird 25 oder 30 Jahre später von einem PC haushoch geschlagen.
Klaus Wachtler schrieb: > Naja, die echten Weicheier konnten in den Spalten 73...80 (die ja von > FTN ungeutzt waren) fortlaufende Nummern automatisch stanzen lassen (mit > wählbarem Abstand, um später noch etwas einfügen zu können. > Dadurch konnte man von einem rein mechanischen Sortierer die Karten > wieder sortieren lassen :-) Aber durften die, die sich solch unlauterer Hilfsmittel bedienten, sich überhaupt guten Gewissens Fortran-Programmierer nennen? Das ist ja fast noch schlimmer als ein Rennradfahrer mit Elektrounterstützung: https://www.youtube.com/watch?v=1pgnSZvg_1o
Mich würde da eher mal ein Vergleich des erzeugten Codes in C und Fortran interessieren. Wenn Fortran etwas besser macht, ist die Frage, weshalb es der C-Compiler nicht genauso hin bekommt.
Ich kann dir die Simulation gerne geben. Wenn du 7000 Zeilen F77 nach C umschreiben möchtest...
PS: Wahrscheinlich geht es aber mit C++ leichter. Ein Teil der Laufzeit bleibt in C nämlich schon auf der Strecke, weil alles per call by value übergeben wird (wenn man es nicht mühsam alles über Zeiger macht). FORTRAN macht dagegen generell call by reference, was Rekursion verhindert, aber ansonsten häufig schneller ist. In C++ könnte man das dann als Referenz (ggf. sogar const&) übergeben.
> Ich mußte FORTRAN auch noch lernen.
Ich auch, aber sag' das nicht so laut.
Da lachen Dich die modernen Visual... "Programmierer" sonst aus.
Grüße Löti
Dass Fortan schneller als C halte ich für ein ein Märchen (urban legend). Wenn man in C genau so "primitiv" programmiert wie in Fortran, dann ist da kein großer Unterschied. Nur haben sich halt vor allem die C++ Programmierer einen Programmierstil angewöhnt der die Komplexität, zumindest für den Prozessor, deutlich erhöht.
Von DEC gab es mal ein "Visual Fortran", das war irgendwie mit dem Developer Studio verquickt, wenn ich mich recht entsinne :-)
> Wenn man in C genau so "primitiv" programmiert wie in Fortran
Ich würde eher sagen geradlinig.
Grüße Löti
The determined Real Programmer can write FORTRAN programs in any language. :-)
Klaus Wachtler schrieb: > Der Originalrechner kostete damals mehrere Millionen, und wird 25 oder > 30 Jahre später von einem PC haushoch geschlagen. Tja, die damaligen Kernspeicher hatte eine physikalische Grenze, die bei ca. 1.2 µs lag. Schneller den Code auslesen ging eben nicht. Es war ja immer ein zerstörendes Lesen und wieder Hineinschreiben. Lochkarten hab ich allerdings nur noch in Zusammenhang mit Algol erlebt, Fortran war bei uns nicht Mode. Etwas später gab's dann jede Menge Lochband - und das Wiederaufrollen desselben. Wenn man sich überlegt, daß sowas wie TAR heutzutage immer noch von den *ixern und *uxern benutzt wird, obwohl man den Lochband-Vorspann bei einer Datei garnicht braucht und auch die Bezeichnung (oktal) nicht mehr anhand der Löcher selber lesen kann. W.S.
Helmut S. schrieb: > Dass Fortan schneller als C halte ich für ein ein Märchen (urban > legend). Fortran gegen die schnellsten C++ Programme http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=ifc&lang2=gpp&data=u64q und gegen C http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=ifc&lang2=gcc&data=u64q Viel Spaß beim Schreiben schnellerer Programme
Gradlinige Programmierung ist der richtige Ausdruck. Beschränken auf das Wesentliche und das schnell und präzise. Für hübsche GUIs ist Fortran nicht gemacht. Unschlagbar sind die numerischen Bibliotheken, die weltweit existieren. Da kommen die C Bibliotheken beiweiten nicht mit. Eine Hochsprache, die komplexe Zahlen, Hyperbolische Funktionen und Bessel in der Grundversion beherrscht. Meine Hochachtung! Bei mir an der Uni wurde über Jahrzehnte ein Programm entwickelt, dass den Antenngewinn beliebig komplexer Antennen berechnen und optimieren konnte (2.6 Millionen Programmzeilen! als ich ging). Die Software ist immer noch in Verwendung und das Beste was es wohl weltweit geben soll. Die Berechnungen laufen heute unter Fortran auf Grafikkarten, benötigen aber trotzdem Stunden. Also im Bereich Numerik ist Fortran bis heute unschlagbar gut und flott.
Didi S. schrieb: > Also im Bereich Numerik ist Fortran bis heute unschlagbar gut und flott. Richtig. Bekanntlich soll man ja die Programmiersprache danach auswählen, ob sie zu dem geforderten Anwendungszweck passt. Also manchmal (selten) Fortran, öfter was anderes. ;-)
W.S. schrieb: > Klaus Wachtler schrieb: >> Der Originalrechner kostete damals mehrere Millionen, und wird 25 oder >> 30 Jahre später von einem PC haushoch geschlagen. > > Tja, die damaligen Kernspeicher hatte eine physikalische Grenze, die bei > ca. 1.2 µs lag. Schneller den Code auslesen ging eben nicht. Es war ja > immer ein zerstörendes Lesen und wieder Hineinschreiben. Die Cyber 76 hatte bereits einen Halbleiterspeicher und sogar schon einen Cache. Allerdings waren die Halbleiterspeicher anfangs auch nicht viel schneller als die zu der Zeit schon sehr ausgereiften Kernspeicher.
Yalu X. schrieb: > Die Cyber 76 hatte bereits einen Halbleiterspeicher und sogar schon > einen Cache. M.W. hatte die noch Ringkernspeicher, zumindest haben die vom RZ das so gesagt. PS: Wenn ich das Handbuch auf die Schnelle richtig interpretiere, gab es wohl Halbleiterspeicher als Option: http://bitsavers.trailing-edge.com/pdf/cdc/cyber/cyber_70/60367200D_Cyber70-76_Jul75.pdf
Klaus Wachtler schrieb: > PS: Wenn ich das Handbuch auf die Schnelle richtig interpretiere, gab es > wohl Halbleiterspeicher als Option: > http://bitsavers.trailing-edge.com/pdf/cdc/cyber/cyber_70/60367200D_Cyber70-76_Jul75.pdf Ja, da scheint es unterschiedliche Varianten gegeben zu haben:
1 | Late models of the CYBER 70 Model 76 series contain a semiconductor memory. |
Der Halbleiterspeicher war etwa doppelt so schnell wie der Ringkernspeicher:
1 | Memory cycle times for the two types of banks are: |
2 | |
3 | o Semiconductor Memory |
4 | * 110 Nanoseconds - Read |
5 | * 165 Nanoseconds - Write |
6 | |
7 | o Small Core Memory - 275 Nanoseconds, Read or Write |
Ich fase es nicht: es gibt sogar einen Emulator für einen Verwandten, der die Original-Binaries ausführen können soll: http://members.iinet.net.au/~tom-hunter/
@Klaus Wachtler (mfgkw) >Ich fase es nicht: es gibt sogar einen Emulator für einen Verwandten, >der die Original-Binaries ausführen können soll: >http://members.iinet.net.au/~tom-hunter/ Sowas gibt's auch für 370er bzw. 390er IBM-Hardware namens Hercules http://www.hercules-390.org/
Wahnsinn! Da muss einer diese Kisten wohl SEHR gemocht haben, dass er sich diese Mühe gemacht hat. Jetzt fehlt eigentlich nur noch ein Betriebssystem und natürlich ... ... ein FORTRAN-Compiler :)
> Viel Spaß beim Schreiben schnellerer Programme
Jetzt mach den Computer Kids ihr Selbstbewusstsein doch nicht
vollständig kaputt.
Lothar S. schrieb: >> Ich mußte FORTRAN auch noch lernen. > > Ich auch, aber sag' das nicht so laut. > > Da lachen Dich die modernen Visual... "Programmierer" sonst aus. Lass die Weicheier lachen. Das hält nicht an.
Visual Programme sind mehr als lahm. Das kann ich aus eigener Erfahrung sagen, meine liebe Kollegen programmieren damit. Fortran ist wirklich der Number-Cruncher erster Wahl! Bin zwar überzeugter Anhänger von C (den OOP-Scheiße haben wir schon Anfang der 80er besser gelöst), aber im Punkt numerischer Berechnungen ist und bleibt Fortran die erste Wahl. Ich spreche nicht von PC-Hardware, die ehe der reinste Müll ist, sondern von echten Rechnern, die mehr als 4 GB (100 ps Accesstime) Cache je CPU haben. Also keine bunten Bilder. Sondern Leistung pur. Die gibt es eben nicht für 2,50 beim Aldi.
NoOne schrieb: > ...blablabla... Mag sein dass sowas für dich ein "richtiger" Rechner ist. Trotzdem eher ein Exot. Für Lieschen Müller und 98,76% Der Menschheit reicht aber die 2 Mark fünfzig Rechenpower ausn Aldi. Bist du verbittert dass heute "jeder" einen Computer besitzen/bedienen kann? Ich würd mir ein ruhiges Hobby suchen. Leg dir doch einen Gemüsegarten an? (Ich mag keine Opis)
> Für Lieschen Müller und 98,76% Der Menschheit reicht aber die 2 Mark > fünfzig Rechenpower ausn Aldi. Die brauchen Fortran 77, oder jetzt 90, aber auch nicht, da sie oft schon Probleme haben den im i-Phone integrierten Taschenrechner richtig zu bedienen... . Wer wirklich schnelle wissenschaftliche Berechnungen machen muss ist mit Fortran aber immer noch, oder erst recht, sehr gut beraten. Grüße Löti
Lothar S. schrieb: > Fortran 77, oder jetzt 90 "jetzt" ist Fortran 2008 (und bald Fortran 2015) ;-) Ich selber bin – wie viele andere auch – fortranmäßig auf den Stand von Fortran 77 stehengeblieben. Danach kam C, was ich insgesamt besser fand, auch wenn ich darin ein paar coole Features von Fortran bsi heute vermisse. Das heutige Fortran ist aber im Vergleich zu damals grundlegendst überarbeitet worden, so dass man fast wieder einmal einen Blick darauf schmeißen sollte. Es bietet u.a. eine starke Unterstützung für den Einsatz auf Vektor-/Parallelrechnern (das wird auch auf PCs immer mehr ein Thema), darüberhinaus OOP und viel andere Dinge, die man von einer modernen Programmiersprache erwartet.
Welche Gründe gibt es denn dass ein Fortran Programm besser optimiert werden kann als ein C-Programm? Ich kenne Fortran nur als dem Wikipedia Artikel, und da ist z.B. die Besonderheit bei Schleifen (Indexvariable) aufgeführt. Aber reicht das allein schon für den Geschwindigkeitsvorteil bei dem oben verlinkten Benchmark gegenüber C aus?
> Welche Gründe gibt es denn dass ein Fortran Programm besser optimiert > werden kann als ein C-Programm? Ich kenne zwar Fortran auch blos bis "90" aber der Hauptgrund für die Schnelligkeit ist die, vom Compiler erzwungene, Geradlinigkeit. Das erschwert die Programmierung, vor allem für jüngere Semester, bringt aber Speed. Fortran ist ursprünglich von Physikern für Physiker geschrieben worden da das, zu der Zeit gebräuchliche, Cobol für naturwissenschaftliche Berechnungen vollkommen ungeeignet war. Alle anderen Hochsprachen, incl. Basic, kamen erst später. Grüße Löti
Yalu X. schrieb: > Danach kam C, was ich insgesamt besser fand, > auch wenn ich darin ein paar coole Features von Fortran bsi heute > vermisse. Lass mich raten: arithmetisches IF zum Beispiel, oder? :-))
Um die unschlagbare Stärke der Optimierung von FORTRAN zu verstehen, muß man sich mal genauer die Entwicklung der letzten 60 Jahre anschauen. Nach wie vor werden die schnellsten Fortran Compiler von Intel, Oracle (Sun) und DEC (HP) verkauft oder günstig bereit gestellt. Jeder Compiler ist optimal auf eine bestimmte Hardware abgestimmt, optimaler als etwa C oder C++ Compiler. Nicht weil man es nicht könnte, sondern weil es in der Regel nicht so tief optimiert wird! Nicht so bei FORTRAN. Hier werden sogar Meisterschaften ausgetragen. Und dann wären da noch numerischen Bibliotheken passend zu den Compilern - Bibliotheken, die im Laufe der letzten 60 Jahre programmiert und optimiert wurden. Beides zusammen ist bis heute unschlagbar - vorausgesetzt man benötigt diese Power auch. Meine nächsten Berechnugen zum expandieren mehrdimensionalen Quantenschaum werde ich auf jeden Fall wieder in Fortran programmieren ;-) lesenswert: http://www.zid.tuwien.ac.at/zidline/zl23/fortran/
Didi S. schrieb: > Um die unschlagbare Stärke der Optimierung von FORTRAN zu verstehen Große Worte, gelassen ausgesprochen — hätte mein Vater gesagt. ;-) Letztlich beschreibst du ein Phänomen, das sowas wie Windows bei den Betriebssystemen ist: weil diejenigen, die sowas machen, schon immer nur FORTRAN gemacht haben (und vermutlich teilweise gar nicht in der Lage wären, ihre Algorithmen in einer anderen Sprache neu zu formulieren), genau deshalb werden die FORTRAN-Compiler von den Herstellern passend optimiert, denn dann treffen die Hersteller damit die Zielgruppe, auf die es ankommt. Damit wiederum bleibt der Mythos erhalten, dass man das nur mit FORTRAN so machen könne, denn der praktische Beweis ist ja da. ;-) Im Gegenzug sind generische Compiler (wie GCC) mit ihrem FORTRAN-Frontend natürlich nicht besser als der äquivalente C-Compiler. Oder anders gesagt: würden sich die genannten Hersteller mit gleichem Eifer an die Optimierung eines Compilers für andere Sprachen werfen, wäre der "unschlagbare" Vorteil von FORTRAN zu großen Teilen dahin. Nur, sie haben dafür keine Veranlassung, weil es ja niemanden gibt, den es dort als zahlende Kundschaft interessieren würde.
Ist bei Anweisungen mit arithmetischen Ausdrücken beim GCC denn noch so viel Optimierungspotenzial? Wenn ich zumindest für den AVR-GCC mal gelegentlich in den generierten Assemblercode reinschaue, ist bei solchen Anweisungen auch mit handgeknüppeltem Assembler nicht mehr viel rauszuholen. Kann natürlich sein, dass dieses "nicht mehr viel" gerade das Quäntchen ist was C im Vergleich zu Fortran fehlt. Und ob der Aufwand so groß ist dass man es nicht mehr implementieren kann. Ich meine, gegenüber Fortran sieht mir C so auf den ersten Blick relativ komfortabel aus. Und C hat bewiesen dass man damit so gut wie alle Probleme die sich in der IT-Technik stellen lösen lassen.
Thomas schrieb: > Wenn ich zumindest für den AVR-GCC mal gelegentlich in den generierten > Assemblercode reinschaue, ist bei solchen Anweisungen auch mit > handgeknüppeltem Assembler nicht mehr viel rauszuholen. > Kann natürlich sein, dass dieses "nicht mehr viel" gerade das Quäntchen > ist was C im Vergleich zu Fortran fehlt. Und ob der Aufwand so groß ist > dass man es nicht mehr implementieren kann. Wobei dieses Stückchen Potential bei der populäreren x86 Architektur noch viel kleiner ist. C ist auch schon 40 Jahre alt. Kaum zu glauben, dass sich da noch was rausholen lässt.
photon schrieb: > Mich würde da eher mal ein Vergleich des erzeugten Codes in C und > Fortran interessieren. Wenn Fortran etwas besser macht, ist die Frage, > weshalb es der C-Compiler nicht genauso hin bekommt. Der Vorteil von Fortran gegenüber C im nummerischen Bereich waren lange Zeit bewährte und optimierte Bibliotheken für mathematische Algorithmen. Erst mit den "Numerical Recipes" entwickelte sich für C eine ähnliche Basis. http://de.wikipedia.org/wiki/Numerical_Recipes
Die Numerical Recipes sind eine tolle Bibliothek und auch auf µC unter C einsetzbar. Die Funktionen sind speziell und erweitern math.h um Dimensionen. http://freecomputerbooks.com/Numerical-Recipes-in-C-Second-Edition.html Aber auch hier wieder die gleiche Blickrichtung : Die Routinen existierten in Fortran und wurden erst später in C realisiert und publiziert. Wenn dann richtig gecruncht werden soll, geht nichts an der LAPACK Bibliothek (in Zusammenarbeit mit INTEL Math Kernel Library) vorbei. Die Routinen sind für FORTRAN 90 optimiert, aber es gibt einen Zugang von C, sogar von Visual aus. Aber auch hier wieder das gleiche : Optimiert für FORTRAN und für C benutzbar gemacht. http://www.netlib.org/ http://www.netlib.org/lapack/index.html http://www.netlib.org/lapack/lapacke.html
Bootes schrieb: > http://scienceblogs.com/catdynamics/2014/04/21/why-fortran-lives/ Die Ergebnisse in diesem Diagramm müssen etwas relativiert werden, da sie auf Grund von Bugs in der Auswertesoftware nicht alle stimmen. Hier sind zum besseren Vergleich die Werte aus dem Diagramm numerisch aufgelistet: http://julialang.org/ Die Auswertesoftware nimmt nach Aussage von julia.org von allen Optimierungsstufen (-O0 bis -O3) das beste Ergebnis, also die minimale Zeit von allen Testläufen. Richtig ist aber: Die Auswertesoftware nimmt das Minimum aller Zeiten, die größer als 0 sind. Die Tests "fib" und "mandel" absolviert C bei entsprechender Optimierung im Rahmen der Messauflösung in der Zeit 0, weil der Compiler den größten Teil des Benchmarks wegoptimiert (typisches Problem bei solchen Mikrobenchmarks). Fortan wäre also nach diesen Tests um den Faktor unendlich langsamer als C. Da aber diese Nullzeiten bei der Auswertung fälschlicherweise nicht berücksichtigt werden, werden stattdessen die Ergebnisse der Optimierungsstufen -O0 (bei "fib") bzw. -O1 (bei "mandel") genommen. Dass diese Ergebnisse deutlich schlechter sind als in Fortran, wo die Ergebnisse von -O3 genommen werden, verwundert nicht. Ich habe die Tests deswegen wiederholt, wobei folgende Unterschiede zu berücksichtigen sind: - Der Prozessor ist ein Pentium 4 3,2 GHz (julia.org: Xeon E7-8850 2,0 GHz). - GCC-Version (für C und Fortran): 4.8.2 (julia.org: 4.8.1). - Die Tests "quicksort" und "rand_mat_mul" führten bei der Ausführung zu einem Segfault und wurden deswegen weggelassen. - "fib" ist so modifiziert, dass der Compiler auch bei -O2 und -O3 nicht den meisten Code wegoptimiert. Der vierte Punkt führt natürlich zu einer Benachteiligung des C-Compilers, aber nur damit konnten einigermaßen sinnvolle Ergebnisse gemessen werden. "mandel" habe ich ebenfalls versucht, mit volatiles u.ä. so zu modifizieren, dass die Optimierungsstufen -O2 und -O3 genutzt werden können, jedoch wurden die Zeiten dadurch verschlechtert, so dass ich das möglichweise schlecht optimierte Ergebnis für -O1 in die Tabelle eingetragen habe. Und hier sind die Ergebnisse:
1 | Laufzeit Fortran / Laufzeit C: |
2 | |
3 | julialang.org eigene Messung |
4 | ———————————————————————————————————————————— |
5 | fib 0.26 0.55¹ |
6 | parse_int 5.03 7.56 |
7 | quicksort 1.11 -- ² |
8 | mandel 0.86 0.62³ |
9 | pi_sum 0.80 0.97 |
10 | rand_mat_stat 0.64 1.46 |
11 | rand_mat_mul 0.96 -- ² |
12 | ———————————————————————————————————————————— |
13 | |
14 | ¹) modifizierter C-Code zur Verhinderung von zu viel Optimierung |
15 | ²) Segfault im C-Programm |
16 | ³) Optimierungstufe -O1 |
Aber beim den anderen Tests ("parse_int", "pi_sum" und "rand_mat_stat")
habe ich den Eindruck, dass sie nicht sehr viel Aussagekraft haben. Denn
auch dort besteht für den Compiler die prinzipielle Möglichkeit, Teile
des Codes wegzuoptimieren. Außerdem verwenden die Tests Hilfsfunktionen
(bspw. Zufallsgeneratoren zur Generierung von Testdaten), die in C und
in Fortran unterschiedlich implementiert sind, deren Laufzeit aber mit
gemessen wird.
Deswegen sollte das obige Diagramm für euch nicht Anlass sein,
panikartig all eure C-Programme in Fortran umzuschreiben ;-)
> und vermutlich teilweise gar nicht in der > Lage wären, ihre Algorithmen in einer anderen Sprache neu zu > formulieren Das aber auch gleich gar nicht erst wollen da es vollkommen unnötig ist. Grüße Löti
Ach ja, darauf wollte ich auch noch antworten: Jörg Wunsch schrieb: > Yalu X. schrieb: >> Danach kam C, was ich insgesamt besser fand, >> auch wenn ich darin ein paar coole Features von Fortran bsi heute >> vermisse. > > Lass mich raten: arithmetisches IF zum Beispiel, oder? :-)) Das ist natürlich das Allerwichtigste :) Nein, in Ernst: Ich dachte dabei vor allem an die Ausgabeformatierung, die IMHO um ein Vielfaches besser als in C und erst recht als das Streamgedöns in C++ ist. Beispiel: Es soll das Double-Array a komplett ausgegeben werden, wobei immer maximal 10 Zahlen in einer Zeile stehen (die letzte Zeile ist kürzer, wenn die Anzahl der Arrayelemente kein Vielfaches von 10 ist). C:
1 | for(int i = 0; i < sizeof a / sizeof *a; i++) { |
2 | if(i && i % 10 == 0) |
3 | printf("\n"); |
4 | printf("%5.1f", a[i]); |
5 | }
|
6 | printf("\n"); |
Fortran:
1 | print '(10F5.1)', a |
Gerade zum Debuggen, wenn man mal temporär einen Array-Inhalt auf dem Bildschirm oder in einer Datei ausgeben möchte, ist das in C schon etwas lästig.
Auf der anderen Seite... vielen Wissenschaftlern fehlt es an einer guten Ausbildung im Bereich Softwaretechnik. Programmieren ist eben auch ein Handwerk und die genaue Kentniss welche Datenstruktur man wann und wo einsetzt muss man auch erstmal lernen. Hier besteht meiner Erfahrung nach großer Nachholfbedarf.
Yalu X. schrieb: > print '(10F5.1)', a So ist es aber kaum lesbar, weil die Zahlen direkt aneinander kleben. Besser wäre print '(10(1X,F5.1))', a oder so ähnlich. Aber dein Vergleich ist etwas unfair, weil die C-Version in C++ wesentlich kompakter sein könnte, und dann zudem beliebige Datentypen (auch eigene) gleich mit erschlagen wären.
> vielen Wissenschaftlern fehlt es an einer guten Ausbildung im Bereich > Softwaretechnik. Informatik ist nicht umsonst ein eigener Studiengang. Außerdem, wird gerade in den wissenschaftlichen Studiengängen, selbst verantwortetes Lernen erwartet, auch bei der Auswahl der Lerninhalte. Die von den Fakultäten verlangten Pflichtfächer/-kurse können immer nur ein Grundgerüst des Studiums darstellen. Grüße Löti
ben schrieb: > Bist du verbittert dass heute "jeder" einen Computer besitzen/bedienen > kann? > Ich würd mir ein ruhiges Hobby suchen. Leg dir doch einen Gemüsegarten > an? > (Ich mag keine Opis) Mit der Aussage hast Du Dich als eng denkender als der Durchschnitts "Opi" geoutet. ;O)
Klaus Wachtler schrieb: > So ist es aber kaum lesbar, weil die Zahlen direkt aneinander kleben. > Besser wäre print '(10(1X,F5.1))', a oder so ähnlich. Ich bin davon ausgegangen, dass die Zahlen maximal 2 Vorkommastellen und kein Vorzeichen haben. Um dies auszudrücken, sollte man besser '(10(1X,F4.1))' schreiben, da hast du schon recht. Im Normalfall haben aber beide Formate den gleichen Effekt. Ein Unterschied entsteht erst dann, wenn eine Zahl wider Erwarten eine zusätzliche Vorkommastelle hat. Mit '(10F5.1)' wird die Zahl immer noch korrekt dargestellt, klebt aber an ihrem Vorgänger. Mit '(1X,10F4.1)' wird die Zahl als "##.#" dargestellt (weil sie nicht ins Format passt), dafür bleibt das vorangehende Leerzeichen garantiert erhalten. Wenn die Ausgabe nur vom Menschen gelesen wird, finde ich '(10F5.1)' besser, da man mit etwas Geschick auch noch diejenigen Zahlen lesen kann, die die vorgesehenen Länge um 1 Ziffer überschreiten. Zudem ist hier weniger zu tippen ;-) Wird die Ausgabe hingegen in eine Datei geschrieben, die später von einem anderen Programm wieder eingelesen wird, das Leerzeichen als Delimiter erwartet, ist '(1X,10F4.1)' besser, da damit verhindert wird, dass zwei aneinanderklebende Zahlen als eine einzige interpretiert werden. Stattdessen stolpert die Einleseroutine über die "##.#" und gibt einen Fehler aus, was in diesem Fall genau die richtige Aktion ist.
http://stackoverflow.com/questions/146159/is-fortran-faster-than-c
1 | The languages have similar feature-set. The performance difference comes |
2 | from the fact that fortran says aliasing is not allowed. Any code that has |
3 | aliasing is not valid fortran but it is up to the programmer and not the |
4 | compiler to detect these errors. Thus fortran compilers ignore possible |
5 | aliasing of memory pointers and allows them to generate more efficient |
6 | code. Take a look at this little example in C: |
Seit Aufnahme von "restrict" in C ist dieser Fortran-Vorteil dahin. Fortran lebt (meine Behauptung) vom legacy code, also von mehreren millionen Quellcode-Zeilen die keiner Anfassen wird.
Daniel -------- schrieb: > Fortran lebt (meine Behauptung) vom legacy code, also von mehreren > millionen Quellcode-Zeilen die keiner Anfassen wird. So sehe ich das auch.
Noch eine Bemerkung: Daß ein Programmierer mit FORTRAN sozialisiert wurde erkennt man sogar an seinen COBOL Programmen. (Strukturiert, viele Unterprogramme und Indexierungen aller Wege) In der IBM360 Welt (und ihrer Nachkommen) kann ein Programm beliebiger Sprache ein Programm einer andereren beliebigen Spache ohne Änderung aufrufen. Also FORTRAN MATH.Lib's konnten von z.B. PL/1 Programmen benutzt werden. Diese Eigenschaft und die Transparenz der Betriebssysteme vermisse ich auf dem PC Sektor seit 30 Jahren.
Klausb schrieb: > In der IBM360 Welt (und ihrer Nachkommen) kann ein Programm beliebiger > Sprache ein Programm einer andereren beliebigen Spache ohne Änderung > aufrufen. Also FORTRAN MATH.Lib's konnten von z.B. PL/1 Programmen > benutzt werden. Diese Eigenschaft und die Transparenz der > Betriebssysteme vermisse ich auf dem PC Sektor seit 30 Jahren. Wieso? Mit .NET hat Microsoft deinen Wunsch doch erfüllt ;-) Dieses direkte Mischen von Programmteilen in unterschiedlichen Sprachen ohne zwischengeschaltete Wrapper-Funktionen funktioniert aber nur dann, wenn sich diese Sprachen vom Laufzeitmodell her so ähnlich sind, dass für sie ein gemeinsames ABI definiert werden kann. C# und VB.NET sind einander sehr ähnlich, deswegen kann VB.NET-Code problemlos mit C# gemischt werden. C und C++ hingegen passen nicht in dieses Schema, deswegen werden sie von .NET nicht unterstützt. Fortran und PL/I liegen auch nicht weit auseinander, deswegen sind sie miteinander interoperabel, Cobol möglicherweise ebenfalls. Andere Sprachen, die nicht in dieses Schema passten (z.B. Algol und Lisp), wurden von IBM einfach abgelehnt. Die Marktmacht der Firma machte dies möglich.
Nur der Ordnung halber. Es gab einen IBM ALGOL Compiler. Nicht sicher bin ich, ob es ein IBM Produkt war oder Arbeit einer UNI.
Klausb schrieb: > Es gab einen IBM ALGOL Compiler. > Nicht sicher bin ich, ob es ein IBM Produkt war oder Arbeit einer UNI. Von IBM kam der ziemlich sicher nicht. IBM hat damals Fortran gepusht, wo es nur ging. Deswegen wurde Fortran sehr erfolgreich und Algol (das von vielen als die "bessere" Programmiersprache angesehen wurde und wird) überhaupt nicht.
Yalu X. schrieb: > Klausb schrieb: >> Es gab einen IBM ALGOL Compiler. >> Nicht sicher bin ich, ob es ein IBM Produkt war oder Arbeit einer UNI. > > Von IBM kam der ziemlich sicher nicht. IBM hat damals Fortran gepusht, > wo es nur ging. Hmm. Ich hatte da eher an PL/1 gedacht. War meiner Erinnerung nach ein IBM Entwurf auf irgendeine Ausschreibung (DoD?) Aber egal. Ich war mal in einem Projekt auf meinem Lieblingsrechner, einer VAX, in der ein Teil in Lisp gemacht wurde und von Fortran aus aufgerufen wurde. Überhaupt: Bei DEC konnte man fast alles mit allem mischen.
Karl Heinz schrieb: >> Von IBM kam der ziemlich sicher nicht. IBM hat damals Fortran gepusht, >> wo es nur ging. > > Hmm. Ich hatte da eher an PL/1 gedacht. Auch, das kam aber etwas später.
Naja, PL/1 hat immerhin die Block Sprachelemente (Begin) von ALGOL übernommen. Unbestritten, IBM hatte nicht für ALGOL übrig. Meiner Erinnerung nach ist ALGOL in Deutschland in der Umgebung Prof. Bauer in Tübingen entwickelt worden. Kann auch falsch sein!
Bauer und Tübingen? AFAIR war er in München, dann in Mainz und dann wieder München (TUM).
Klausb schrieb: > Naja, > > PL/1 hat immerhin die Block Sprachelemente (Begin) von ALGOL übernommen. > Unbestritten, IBM hatte nicht für ALGOL übrig. Meiner Erinnerung nach > ist ALGOL in Deutschland in der Umgebung Prof. Bauer in Tübingen > entwickelt worden. Kann auch falsch sein! Das war nicht Bauer, das war Wirth. Das war auch nicht ALGOL, sondern PASCAL. Tübingen stimmt ebenfalls nicht, es war Zürich. Alles andere stimmt.
Das schließt aber nicht aus, daß ein gewisser Friedrich L. Bauer maßgeblich an ALGOL 58 und 60 beteiligt war :-) http://de.wikipedia.org/wiki/Friedrich_L._Bauer
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.