Nanosekunden aus Megahertzen

Olaf Kaluza schrieb:

Solche Pestalozzi-Sprachen kommen bei mir quer.

Willkommen im Club.

Du sprichst mir aus der Seele. Vor einigen Wochen wieder: Man kauft (Staat zahlt ;-)) ein amriganisches Gerät der 150'000$ Preisklasse. Das erste, was man bei der Installation zu hören bekommt, ist, dass die Firmware gewisse "Unvollkommenheiten" aufweist. Bis jetzt hab ich mindestens ein halbes Dutzend Bugs gefunden. Seitens des Herstellers ist kein Wille erkennbar, dem abzuhelfen. After sales service, Updates, Modellpflege, Kundenpflege :-) usw. scheinen da Fremdworte zu sein.

Der Kunde als Störfaktor. Die muss man vergraulen, sonst kommen die immer wieder und wollen was.

Winfried Salomon schrieb:

Das ist aber ein merkwürdiger Vergleich :-]. Die Leute wollen nun mal C. Wahrscheinlich weil

- die Sprache hinreichend Konfus ist, um kaum nachvollziehbar zu sein

- der Compiler gratis ist (Riesenpunkt bei den Damagern)

- Aufgrund der Pufferüberläufe, Speicherlecks usw. die Folgeaufträge quasi garantiert sind.

Bei uns verwenden alle Numbercruncher Fortran. Ist etwa 3x schneller als GCC und 10x schneller als f2c-gcc.

Ob der 3+GHz Prozessor im Sekretariatsrechner jetzt im wesentlichen gebraucht wird, um schwule Büroklammern zu animieren (in der italienischen Version gerüchteweise mit Sonnenbrille), ist ja egal, da der Rechner sonst kaum ausgelastet wird. Bedenklich ist die Verwendung ungeeigneter Algorithmen, erstellt in ungeeigneten Programmiersprachen, welche dann Grossrechenzentren monatelang lahmlegen. Das läuft dann unter "Sparen mit Gratiscompilern", "Rasche Programmentwicklung mit Sprachen vierter Generation" usw.

Allerdings ist es einfacher, Forschungs-Millionenbeiträge für Studien zum sozioökonomischen Impact Brennstoffzellen- betriebener elektrischer Zahnbürsten [*] unter spezieller Berücksichtigung der psychodynamischen Visibilität in Ab- hängigkeit der Gerätefarbe zu erhalten, als 10% davon zur Entwicklung leistungsfähigerer CFD-Codes. Liegt wohl daran, dass die Komitees heutzutage keine Fachkompetenz mehr haben und dass man offenbar die existenzbedrohte Zahnbürsten- industrie mit staatlichen Geldern stützen muss.

Axel Schwenke schrieb:

Erklär das den Informatikern.

Genau. Informatiker entspricht Gärtner und Programmierer entspricht Biochemiker.

Sehr gut. Nur studieren viele Informatik (oder VWL), damit sie einen Bogen um die Mathematik machen können. Damit nimmt dann das Unheil seinen Lauf...

Leider hast Du da gar nicht so unrecht mit... Musste ich selber gerade feststellen.

Gruß Henning

"Rolf_Bombach" schrieb im Newsbeitrag news:458e6924$1 snipped-for-privacy@news.bluewin.ch...

Bloedsinn. Konfus sind Zahlen- und Druckformate in Fortran, ja. Gratis? Auf Grossrechnern gibt es meist kein C, nur Fortran und Colbol hingegen liegt gratis bei.

Der Rest IST ein Problem von C, aber wollen wir nicht vergessen, das viele Fortrans noch Probleme mit (eigentlich endenden!) Rekursionen haben und dabei einfach abstuerzen. Jede Sprache hat so ihre Probleme, auch Java.

Eben das ist oft der Grund: Man nimmt das, was fuer den Einsatzzweck besser geeignet ist. Und wenn es schnelle Mathematik sein muss, ist das oft Fortran. Was nicht an der Sprache liebt, sondern an den Compilern, weil auf Grossrechnern keine Sau irgendwelches Gehirnschmals in C steck. Weil sie es nicht koennen. Weil sie immer noch im Jahre 1965 feststecken. Die Programmierer wuerden lieber C nehmen wenn es genau so schnelle Mathematik koennte, denn C ist jenau das, was gute Sofware ausmacht: Minimal.

Das waeren? Deine Hirngespinste? Ein Excel-Spredsheet laeuft doch sowieso nch auf dem Grossrechner (obwohl, ...geht schon).

So ist das.

"Rolf_Bombach" schrieb im Newsbeitrag news:458e6a72$1 snipped-for-privacy@news.bluewin.ch...

Rolf, du steckst noch in der Zeit der Lochkarten fest.

Damals gas es die Leute, die die Lochkarten angefertigt haben. Coder, nicht weil die programmierten, sondern lesbares in Loecher umsetzten, also den Text im Code aenderten.

Die Programme entwarfen die damaligen Informatiker, die Systemanalytiker.

Heute muessen die eben auch das Programm eintippen, das ist wie beim Zeitungsredaktuer, dem heute auch der Setzer wegrationalisiert wurde. Man nennt das Fortschritt.

Es ist einfach ein glatter Irrtum anzunehmen, ein Dipl-Informatiker waere nicht zur Programmerstellung ausgebildet. Nur diejenigen, die es in ihrem Studium aufs peinlichste vermieden haben, jemals den Einschalter eines Rechners zu betaetigen, MUESSEN das von sich behaupten, aber es ist Unfaehigekeit, und nicht eine besondere Heldentat.

Ein Informatiker muss auch mal einen neuen moeglichst optimalen Algorithmus fuer etwas finden, was bisher unbekannt war, aber das ist die Nebentaetigkeit, ebenso wie nicht alle Mathematiker ihre Zeit staendig mit der Loesung von ein paar ewig offenen Beweisproblemem der Geschichte verbringen.

Moin!

Wieso dehen? Weihnachten fängt doch schon im Juli an...

Gruß, Michael.

Hallo Michael,

Nein, es ist das ganze Jahr:

Ein Geschaeft bei uns im Nachbardorf, das andere koennt Ihr besuchen auf einer Tour zum Yosemite Nationalpark. Liegt in Sonora, gleich nach der Kirche.

"Joerg" schrieb im Newsbeitrag news:COekh.37337$ snipped-for-privacy@newssvr25.news.prodigy.net...

Nussknacker fuer 300 US$ statt 40 EUR Original Erzgebirge wie hier ? Mann ist eure Waehrung schon verfallen, wenn du da nicht mindestens 500000 US$/Jahr verdienst, bleib ich lieber hier.

MaWin schrieb:

Früher gab es den Begriff der "eleganten Lösung": Die war dann gegeben, wenn mit minimalem Zeit- und Kostenaufwand die bestmögliche Lösung erzielt wurde. Bei den heutigen Schlipsträgern ist genau das aber nicht erwünscht, kostet es doch Monate satten Gehalts, wenn ein Problem vorzeitig und womöglich zur Zufriedenheit des Auftraggebers gelöst wird.

Unser Land lebt mittlerweile davon, Probleme zu züchten und zu verwalten, anstatt sie erfolgreich zu lösen.

Ciao...Bert

Es gibt für Höchstleistungsrechner mehrere gute Gründe für Fortran:

- Komplexe Zahlen werden _intrinsisch_ unterstützt (also nicht Klasse wie bei C++, in C sind komplexe Zahlen _das_ Argument für C++ ;-)

- Schleifen sind leichter zu vektorisieren, weil es weniger Möglichkeiten gibt, die der Optimierer berücksichtigen muss (teilweise _kann_ er sie in C garnicht berücksichtigen, weil die entsprechenden Aufgabenstellungen an den Optimierer mit Pointern prinzipbedingt nicht in endlicher Zeit lösbar sind, umgekehrt rechnen bestimmte Compiler sogar bei Fortran Gleichungssysteme zur Ermittlung der optimalen Indizierung).

Dazu zählen z.B. Berechnungen von Datenabhängigkeiten in verschachtelten Schleifen, hier liegt zwischen beiden Sprachen ein _grundlegender_ Unterschied vor: Fortran: Felder sind ein strukturierter Datentyp, die Implementierung obliegt dem Compiler-Konstrukteur, solange wie man von Pointern (F95) die Finger läßt. Ein Feld kann z.B. problemlos in einem Vektorregister in völlig anderer Art und Weise als im Speicher abgebildet werden, Hauptsache der Zugriff ist abstrakt über die Indizierung möglich. Zudem gibt es automatische/allozierbare Felder, bei denen die Performance aufgrund mehr Freiheitsgraden bei der Implementierung höher sein kann. C: Felder müssen aufgrund der Definition des Array- Zugriffsoperators a[i] *(a+i) in einer exakt vorgegebenen Form abgelegt werden, Pointer sind hier bei größenvariablen Feldern praktisch unvermeidlich und machen die Performance _auf_Vektorrechnern_ kaputt.

- Vektor-Operationen werden elementar durch Array- Assignments unterstützt, dto. Skalarprodukt usw.

- Parallelarchitekturen werden elementar unterstützt (HPF).

Das Fortran, was heute auf Großrechnern zum Einsatz kommt, hat mit dem Fortran, auf das Du anspielst, nicht mehr viel gemein.

Umgekehrt möchte man kein Betriebssystem und keine embedded CPU mit Fortran programmieren, die Gründe (Pointer, einfaches Runtime-System usw.) sind offensichtlich.

Unterschätze übrigens nicht, dass auch C-Compiler z.B. für DSP's Schleifen vektorisieren können, die TI Compiler sind in der Hinsicht sehr fortgeschritten, auch Intel C/C++ (der richtige Intel Compiler, nicht MS) aber richtige parallele Vektorrechner sind halt ein anderes Kaliber. Insofern ist es absolut nicht richtig, dass C-Compiler noch auf dem Stand von 1965 seien.

Zudem: Beim DSP schaut man sich nachher den Assemblercode an und stellt ggf. etwas um, damit es vektorisiert wird, bei einem Finite Elemente Programm zur Feldsimulation möchte man das eher nicht.

Es ist ganz einfach: Beide Sprachen, C wie Fortran, haben ihre Berechtigung für bestimmte Aufgabenstellungen, keine ist "besser" als die andere. Die Syntax ist dabei völlig nebensächlich, entscheidend sind die dahinter stehenden Konzepte.

Ein gutes neues Jahr wünscht mit

Gruß Oliver

P.s.: Literaturempfehlung. "Optimizing compilers for modern architectures, R. Allen & K Kennedy, Morgan Kaufmann."

Hallo Manfred,

Da ist wahrscheinlich ein satter Touristenaufschlag drin. Nussknacker gibt es hier weit unter $100. Ausser voll handgefertigte, doch die kosten auch im Erzgebirge dreistellig.

Ist wie beim Silikonfett fuer die Luftdruck Chose. So ein Toepfchen kann ich natuerlich beim Kosmetikladen fuer $19.99 kaufen. Oder eben beim Klempnerbedarf das gleiche fuer $2.99.

Wenn ich mir so die Preise fuer Alltagsgegenstaende wie Jeans ansehe, bleibe ich lieber hier :-)))

Die Haerte sind die Kuckucksuhren, die im Schwarzwald so den Touristen angedreht werden. Wir haben eine geschenkt bekommen. Jemand hatte sie als Soldat in Deutschland stationiert fuer beinahe $300 dort gekauft und sie ging kurze Zeit danach nicht mehr. Lag im Keller rum. Nun kuckuckt sie wieder, aber die Musik und Figuren konnte ich nicht in Gang setzen. Ausgerechnet fuer das anfaelligste Zahnrad, das vor der Luftbremse, hatten sie Nylon genommen. War natuerlich hin und hier unbeschaffbar.

In C99 gibt es 'complex double x', und auch den C++-Compiler hindert niemand daran, 'std::complex x' als intrinsischen Typ zu behandeln.

Dafür gibt's in C99 z.B. 'restrict'.

C++ hat dafür std::valarray.

Letztenendes haben die C-oiden Sprachen zumindest theoretisch alles, was man für Hochleistungsrechnen braucht. Sowas wie 'complex double' oder 'std::valarray' sind ja extra dafür eingeführt worden, Fortran das Wasser abzugraben. Zumindest syntaktisch wird das alles inzwischen auch unterstützt, aber eben offenbar qualitativ nicht so gut wie die Fortran- Äquivalente. Was wohl auch daran liegt, dass in so einem Fortran- Compiler gelegentlich schon mehrere Dutzend Jahre Erfahrung stecken.

Stefan

Henning Paul schrieb:

Das kommt etwas auf die Problemstellung an.

Guido

MaWin schrieb:

Genau so eben nicht.

Wunschdenken.

Wunschdenken=B2

wenden

Wunschdenken=B3: Hier redet ein Bilder von der Farbe.

Zusammenfassung: MaWin, der Poster ohne Realnamen zeigt mal wieder,=20 wovon er absolut keine Ahnung hat.

kein Gru=DF.

Andreas Eibach schrieb:

COmputer Brauchen Ordentlich Leistung.

scnr=B2

Guido

Am Wed, 27 Dec 2006 15:21:14 +0100 schrieb Guido Grohmann:

Ich finde, Bilder und Farbe passen ganz gut zusammen ;-)

Was war denn so falsch an MaWins Statement?

Lutz

Lutz Schulze schrieb:

Argh, danke, son Mist, ausgerechnet da mu=DF ich mich vertipseln.

Offenbar kennt er gr=F6=DFere EDV-Projekte nur vom H=F6ren-Sagen oder vom= =20 Meckern Anderer. Das f=E4ngt an beim Statement "weniger=20 Programmzeilen=3Dbesseres Programm" und h=F6rt auf bei dem Unsinn mit den= =20 Schnittstellen/Modulen.

Guido

C99 ist irgendwie in der Realität ein trauriges, weil kaum in den Compilern vertretenes Thema.

Hindern nicht, es ist nur "schwieriger".

Letztlich kann man _jede_ Syntax so hinbiegen, dass sie das _theoretisch_ packt. Wenn Du magst, auch Algol68_V2006 (tm ;-)

Ja, das ist der Punkt. Das eine ist eingebaut, das andere draufgesetzt, und bei Fortran liegt dto. mehr Erfahrung vor.

Zudem ist die Syntax dem Numerik-Anwender letztlich egal, solange er sie beherrscht. Und da spricht der Markt halt eine eindeutige Sprache, ebenso wie er für Betriebssysteme, Embedded und Standard-Applikationen eine klare Sprache spricht, kaum einer täte dafür Fortran hernehmen.

Gefragt ist heutzutage keine "Computersprachen-Religion" mehr, sondern einfach das passende Werkzeug. Das kann C sein, C++, oder eben auch Fortran oder ganz was anderes.

Gruß Oliver

P.s.: Du unterhälst Dich mit jemanden, der schon ettliche hundertausend Zeilen in C einer nicht ganz unbekannten Anwendung geschrieben hat ;-)