Hilfe. Möcht das Programieren anfangen
Johannes Formann
Ich würde gerne anfangen auf meinen LCII zu Programmieren.
Ich habe aber bisher nur ein wenig Turbo Pascal (Dosen) programiert.
Ich würde mich freuen wenn mir jemand Tips gibt mit welcher
Sprache,welchen Programmen (Compiler) ich anfangen sollte.
Literaturtips wären auch willkommen.
Vielen Dank im Vorraus
Johannes Formann
Bernd Froehlich
> Hallo
> Ich würde gerne anfangen auf meinen LCII zu Programmieren.
> Ich habe aber bisher nur ein wenig Turbo Pascal (Dosen) programiert.
> Ich würde mich freuen wenn mir jemand Tips gibt mit welcher
> Sprache,welchen Programmen (Compiler) ich anfangen sollte.
> Literaturtips wären auch willkommen.
Versuch mal RealBasic (www.realsoftware.com).
Ich finds genial.
Dirk Theisen
Hallo, Johannes!
Johannes Formann <jfor...@muenster.de> wrote:
> Ich würde gerne anfangen auf meinen LCII zu Programmieren.
> Ich habe aber bisher nur ein wenig Turbo Pascal (Dosen) programiert.
> Ich würde mich freuen wenn mir jemand Tips gibt mit welcher
> Sprache,welchen Programmen (Compiler) ich anfangen sollte.
> Literaturtips wären auch willkommen.
Kurzfassung:
Eigentlich muß man heutzutage Java lernen.
Gosling (der Erfinder; sinngemäß): "Die beste Voraussetzung, Java zu
lernen ist, kein C++ zu können."
Ich nehme an, Du erfüllst die.
Nur mit Deinem Rechner wird das allerdings nix. Zumindest nicht
ernsthaft.
Apple hat gerade ein neues Entwicklerprogramm für Studenten aufgelegt
(bist Du einer?) und Metrowerks verkauft seine Entwickungsumgebung nun
auch in einer Nur-Java-Version (die gibt's bei o.G. Programm dazu)
preiswert: www.metrowerks.com
M.E. derzeit die ernsthafteste Sache (nach Mac OS X Server, aber dazu
brauchst Du mindestens einen 604-PCI-Mac, vielleicht einen G3).
Die Zukuft von Apple liegt meiner Meinung nach in der YellowBox (die
OO-Api von Mac OS X), programmiert in Java. Hab's probiert. Ist genial.
Alles da, was man braucht und ausgereifter als pure Java. Erscheint zu
95% im Januar offiziell.
Gruß
Dirk
--
No RISC - No fun
Stefan Witzgall
Vor Jahren hatte ich mir mal einen Pascal-Compiler von Metrowerks für
meinen LCII gekauft. Im Buch mit zwei Disketten, ca. 100DM.
_Richtig_ für Macs programmieren war nicht so der tolle Renner, aber
ISO-Pascal ging grob.
Ich werde mal bei Metrowerks anfragen, ob ich diesen Minimal-Compiler frei
wegegeben darf. Falls die Antwort positiv ist, sage ich Bescheid.
Oder kennt hier jemand einen anderen so bescheidenen (LCII !) Compiler?
Ach ja, REALBasic geht ja auch auf zwei Disketten :-)
Viele Grüße, Stefan
b> Johannes Formann <jfor...@muenster.de> wrote:
b>
b> > Hallo
b> > Ich würde gerne anfangen auf meinen LCII zu Programmieren.
b> > Ich habe aber bisher nur ein wenig Turbo Pascal (Dosen) programiert.
b> > Ich würde mich freuen wenn mir jemand Tips gibt mit welcher
b> > Sprache,welchen Programmen (Compiler) ich anfangen sollte.
b> > Literaturtips wären auch willkommen.
b>
b> Versuch mal RealBasic (www.realsoftware.com).
b> Ich finds genial.
Stefan Kuhlmann
Ich dachte er wollte Programmieren erlehrnen.
Mit RB kann man genauso gut Programmieren wie in VB 5.0 unter Windows.
Ist Unübersichtlich und wenn man nicht jede Procedure kommentiert weiß man nach
einigen Stunden schon nicht mehr was man macht.
Ich würde mir Code Warrior Light anschaffen gib es irgentwo im Netz.
Lieber gleich C lehrnen, dann hat man gleich was anständiges.
mfg Stefan
Dietmar Plassmann
Ich auch. War zwar erst etwas gewöhnungsbedürftig sich auf die
objektorientierte Programmierung umzustellen, aber es wird immer besser. Das
Programm selber hat noch ein paar kleinere Macken, mit denen man bei einer
1.0 aber auch rechnen sollte.
Gruß, Dietmar
Bernd Froehlich
> Ich dachte er wollte Programmieren erlehrnen.
>
> Mit RB kann man genauso gut Programmieren wie in VB 5.0 unter Windows.
>
> Ist Unübersichtlich und wenn man nicht jede Procedure kommentiert weiß man
> nach einigen Stunden schon nicht mehr was man macht.
>
> Ich würde mir Code Warrior Light anschaffen gib es irgentwo im Netz.
>
> Lieber gleich C lehrnen, dann hat man gleich was anständiges.
Ich hatte vorher den CodeWarrior und bin immer wieder an der
Programmierung der Oberfläche gescheitert. 1000ende von Events, die man
selbst in 1000enden von Zeilen Code abfragen muss. Gräßlich. War mir
jedenfalls zuviel Fleißarbeit, man konnte sich nicht auf das Wesentliche
konzentrieren. RealBasic nimmt einem die ganze Oberflächenprogrammierung
ab und man kann sich um das eigentliche Projekt kümmern. (Meine Meinung)
Uwe Sander
> Ist Unübersichtlich und wenn man nicht jede Procedure kommentiert weiß man
> nach einigen Stunden schon nicht mehr was man macht.
> Lieber gleich C lehrnen, dann hat man gleich was anständiges.
Unübersichtlichkeit scheint ein Manko moderner Programmiersprachen zu
sein. C bzw. Codewarrior sind da imho nicht besser.
Gruß, Uwe.
Hado Hein
SCHNIPP
> Nur mit Deinem Rechner wird das allerdings nix. Zumindest nicht
> ernsthaft.
> Die Zukuft von Apple liegt meiner Meinung nach in der YellowBox (die
> OO-Api von Mac OS X), programmiert in Java. Hab's probiert. Ist genial.
> Alles da, was man braucht und ausgereifter als pure Java. Erscheint zu
> 95% im Januar offiziell.
Dirk hat schon Recht.
Wenn Du nur ein wenig was machen willst dann bleib doch einfach bei
Pascal. THINK Pascal von Syantec kann ich empfehlen, das kanns auch OO.
Oder schau mal bei www.pascal-central.com.
Das Think Pas würde auf einem LC II auch laufen - du mußt dich
allerdings mit den Eigenheiten von 68k-Code rumschlagen. Das Stichwort
lautet A5-World - damit wirst Du dich früher oder später
auseinandersetzen <ggg> müssen. Dafür gehen LDEFS und andere
CodeResourcen in Pascal einfacher - meiner Meinung nach.
Wenn Du es Dir dann auch noch Object Orientated geben willst, ziehst Du
Dir von www.devworld.apple.com oder www.apple.com/devworld/ die Apple
Class Library (ACS). Die gab es -glaube ich- auch für Pascal.
Oder (das kostet aber auch richtig) Du befolgst Dirks Rat und holst Dir
eine Kiste die auch OS X vertragen wird. Dann hast Du wenig Sorgen. Kauf
Dir einen CodeWarrior und zieh dir MacApp von Apple.
Für das eigentliche Programmieren solltest Du dir erst einmal in Ruhe
die MacAPI-Dokumentation reinziehen. (NewInsideMacinosh). Gibts im ftp
in /TechnicalDocumentation/. Sind nur 400MB html. <ggg>
Oder Du schaust Dir das erwähnte Developerprogramm an. Dann kriegst Du
das auf CD. Ist eigentlich sehr angenehm - und Du hast keine Sorgen
mehr. Kost aber auch.
Hado
--
YOU, you are NOT allowed to use this email address
for ADVERTISAL purposes !
___Homepage and PGPkey in X-Header___
Reinhard Maier
DT>Eigentlich muß man heutzutage Java lernen.
Die Idee von Java ist im Prinzip schon genial. Außerdem sollte Java relativ
leicht zu lernen sein (BTW, das Java-Tutorial von sun (http://www.java.sun.com)
ist hervorragend, viele Applets, Sourcen usw.)
Allerdings kommt man um die neuen Swing-Klassen (JFC) wohl nicht herum, wenn
man alle Möglichkeiten von Java und von plattformunabhängigkeit verwenden
möchte.
Dafür ist der Mac aber etwas gehandicapt: die MRJ (Macintosh Runtime for Java)
unterstützt erst den Befehlssatz von JDK 1.1.x, nicht JDK 1.2 und liegt - mit
Swingunterstützung - erst in einer Betaversion vor (2.1 Early Access 3, Swing
1.1 Beta). Die Geschwindigkeit beim Starten von Applets oder Programmen ist
recht langsam, dafür werden mathematische Berechnungen sehr schnell ausgeführt.
Die Stabilität der Betaversion ist leider mäßig (das SwingSetApplet, das
sämtliche Swing-Klassen enthält, stürzt regelmäßig ab).
CodeWarrior unterstützt in älteren Versionen nur das eigene Java
(MetrowerksJava, das entspricht AFAIK JDK 1.0.x). Damit muß man auf die
modernere Eventverwaltung des JDK 1.1 verzichten.
DT>Apple hat gerade ein neues Entwicklerprogramm für Studenten aufgelegt
Mit welcher Entwicklungsumgebung?
DT>Zukuft von Apple liegt meiner Meinung nach in der YellowBox
AFAIK soll doch mit MacOS X nur der G3 laufen, die ebenfalls sehr schnellen
604e PPCs nicht...
BTW, wann soll denn eine Final Release der MRJ 2.1 erscheinen?
Gruß,
Reinhard
Dirk Theisen
Reinhard Maier <Reinhar...@b.maus.de> wrote:
> CodeWarrior unterstützt in älteren Versionen nur das eigene Java
> (MetrowerksJava, das entspricht AFAIK JDK 1.0.x). Damit muß man auf die
> modernere Eventverwaltung des JDK 1.1 verzichten.
Die muß man ja nicht benutzen.
> DT>Apple hat gerade ein neues Entwicklerprogramm für Studenten aufgelegt
> Mit welcher Entwicklungsumgebung?
Einem aktuellen CW/Java.
> DT>Zukuft von Apple liegt meiner Meinung nach in der YellowBox
> AFAIK soll doch mit MacOS X nur der G3 laufen, die ebenfalls sehr schnellen
> 604e PPCs nicht...
Lt. Apple sind diese Machinen "unsupported", nicht unmöglich. Das
spekulieren jedenfalls die meisten.
> BTW, wann soll denn eine Final Release der MRJ 2.1 erscheinen?
Kurz nach Weihnachten. Swing wird aber sicher immernoch langsam sein,
wie auf allen Plattformen. AWT dafür umso schneller.
Andreas Mayer
Hier bei mir vergammelt noch eine 8er Version von CW. Hab ich nie was mit
zustande gebracht. Mein erstes REALbasic-Programm dagegen ist schon im
Einsatz.
bye. Andreas.
Stefan Kuhlmann
BF>RealBasic nimmt einem die ganze Oberflächenprogrammierung ab und man
BF>kann sich um das eigentliche Projekt kümmern. (Meine Meinung)
das ist wohl richtig, wenn ich schnell ein Programm zusammen hacken will.
Aber wenn ich von Programmieren rede dann mit Sicherheit nicht von RB o. VB.
Ich muß in unserer Firma zwar auch mit VB Arbeiten aber begeistert bin ich
nicht.
CW ist etwas zu aufgeblasen was das drum herum angeht, aber es gib ja auch noch
andere C Compiler z.B. Turbo C auf Atari ST (MagiCMac) o.ä.
mfg Stefan
Stefan Kuhlmann
Bei CW hast du wohl recht, aber es gib ja auch noch andere C Compiler.
Und wo ist C unübersichtlich? Strukturierte Programmierung!
mfg Stefan
Stefan Witzgall
t> > DT>Apple hat gerade ein neues Entwicklerprogramm für Studenten
aufgelegt
t> > Mit welcher Entwicklungsumgebung?
Ich habe mir die Web-Seite mal angesehen
http://www.apple.com/pr/library/1998/doc/09student.html
Für Amis sehr interessant (für D wg. Dollar mit Kurven)! Ich tippe mal
einen Abschnitt:
---------------------schnipp-------------------
...
As part of the program, participants receive aStudent Orientation Kit
which
includes a customized ToolSampler CD. The CD contains essential software
for developing great Macintosh and Internet applications, including full
versions
of CodeWarrior Academic for Java from Metrowerks Corp., and Macintosh
Programmer`s Workshop from Apple. The CD also contains demo versions of
4th Dimensions from ACI US, Inc., BBEdit from Bare Bones Software, Inc.,
AppMaker from Bowers Development Corp., CodeWarrior Lite from
Metrowerks, Installer Vise from MindVision Software, REALbasic from REAL
Software, Inc., MachTen CodeBuilder from Tenon Intersystems, and Tools
Plus
libraries + framework from Water's Edge Software
...
Students around the world can join the ADC Student Program today via
Apple's
website (http://developer.apple.com/programs/students.html). The cost of
the
program is U.S. $99 per year. Students who sign up before Jannuary 31.
1999
receive U.S. $10 off the standard annaul fee, and the first 100 students
to sign up
receive a copy of FileMaker Pro Developer Edition from FileMaker, Inc.
...
---------------------schnapp-------------------
Nun denn, klingt nicht so schlecht. Apple D wird's an den Unis schon
promoten :-|
Ciao, Stefan
Johannes Formann
Wenn ich das richtig verstanden habe ist RealBasic einfacher aber Code
Warrior Light ist auch für größere(bessere?) Programme geeignet da C ?
Ich freue mich auf weitere Beiträge.
Gruß
Johannes Formann
Bernd Froehlich
> Wenn ich das richtig verstanden habe ist RealBasic einfacher aber Code
> Warrior Light ist auch für größere(bessere?) Programme geeignet da C ?
> Ich freue mich auf weitere Beiträge.
So ungefähr. Mit welcher Entwicklungsumgebung man die "besseren"
Programme schreibt, hängt aber wohl stark vom Programmierer ab. Wenn Du
nicht völlig in den Tiefen der Hardware abtauchen willst reicht
RealBasic allemal. Schau Dir einfach mal die Demo an und arbeite das
Tutorial durch. Sind ca. 2-3 Stunden Zeit, die Du investierst. Ich war
danach von RB überzeugt.
Uwe Sander
> Und wo ist C unübersichtlich?
Unzählige Header-, Include- und Wasweißichfür-Dateien, etliche
Compileroptionen und eine kryptische Schreibweise, die entwickelt wurde,
um schneller Compilerlaufzeiten zu erhalten und nicht, um
benutzerfreundlich zu sein.
Als ich (Hobbyprogrammierer) damals von der Assemblerprogrammierung auf
Turbo C (Trarari) umsteigen wollte, empfand ich das nicht gerade als
Erleichterung. Da konnte auch später der Code Warrior (5) nichts daran
ändern.
>Strukturierte Programmierung!
Also ich habe den Eindruck, daß einige Vorteile, nämlich schneller und
kompakter Code, damit eleminiert werden. Wenn ich mir da z.B. den
Leibesumfang des Mac OS von heute anschaue ...
Gruß, Uwe.
Heio Maevers
SK>z.B. Turbo C auf Atari ST (MagiCMac)
ist aber immernoch (und vermutlich auf ewig) relativ instabil beim
debuggen,
*ich* habe deshalb gerade meinen alten Mega STE wieder rausgekramt!
Schönen Tag noch.... Heio
Reinhard Maier
DT>>Damit muß man auf die modernere Eventverwaltung des JDK 1.1
DT>>verzichten. DT> Die muß man ja nicht benutzen.
Wenn man Swing verwenden möchte schon. Außerdem sollten moderne Browser
Java 1.1 unterstützen (Communicator 4.5 für den Mac ist da eine
unerfreuliche Ausnahme). Aber demnächst soll es von Apple ja ein
Java-Plugin (Java 1.2) geben (BTW, wann? Wurde immerhin schon im April
angekündigt).
DT>Einem aktuellen CW/Java.
Welche Javaversion unterstützt der aktuelle CW?
DT>Lt. Apple sind diese Machinen "unsupported", nicht unmöglich. Das
DT>spekulieren jedenfalls die meisten.
Ich bin da eher skeptisch. Außerdem kann "unsupported" auch
Instabilität/langsame Geschwindigkeit bedeuten. Und viele ältere Macs sind
dann ganz aus dem Rennen.
DT>Swing wird aber sicher immer noch langsam sein
Das kann ich bei der momentanen Swing-Version (1.1 beta) bestätigen (läuft
außerdem sehr instabil).
DT>Zukuft von Apple liegt meiner Meinung nach in der YellowBox
Gibt es dazu schon eine Doku?
Gruß,
Reinhard
Dirk Theisen
Reinhard Maier <Reinhar...@B.maus.de> wrote:
> DT>>Damit muß man auf die modernere Eventverwaltung des JDK 1.1
> DT>>verzichten. DT> Die muß man ja nicht benutzen.
> Wenn man Swing verwenden möchte schon. Außerdem sollten moderne Browser
> Java 1.1 unterstützen (Communicator 4.5 für den Mac ist da eine
> unerfreuliche Ausnahme). Aber demnächst soll es von Apple ja ein
> Java-Plugin (Java 1.2) geben (BTW, wann? Wurde immerhin schon im April
> angekündigt).
Ich meinte einen alten CW mit Java 1.0 muß man nicht benutzen... :-)
> DT>Einem aktuellen CW/Java.
> Welche Javaversion unterstützt der aktuelle CW?
Die Version, die MRJ unterstützt. Das ist im Falle von MRJ 2.0
JDK 1.1.3 und vom letzten EA-Release (sehr zu empfehlen, da AWT VIEL
schneller) von MRJ 2.1 JDK 1.1.6.
Wann wir Java 2 bekommen steht in den Sternen. Ich denke es wird früher
für Mac OS X Server verfügbar sein, als für classic Mac OS, da es viel
leichter zu portieren ist.
> DT>Lt. Apple sind diese Machinen "unsupported", nicht unmöglich. Das
> DT>spekulieren jedenfalls die meisten.
> Ich bin da eher skeptisch. Außerdem kann "unsupported" auch
> Instabilität/langsame Geschwindigkeit bedeuten. Und viele ältere Macs sind
> dann ganz aus dem Rennen.
Es kann insbesondere bedeuten, daß einige der "alten" Karten nicht
ausreichend/voll unterstützt werden. Z.B. habe ich derzeit keinerlei
Beschleunigung an meiner TwinTurbo, was schon ziemlich schmerzt.
Ich hoffe zwar, daß sich das ändert, aber glaube nicht daran.
Beschleunigte Grafik kommt IMHO erst mit dem "neuen Diplay Model" von
Mac OS X.
> DT>Swing wird aber sicher immer noch langsam sein
> Das kann ich bei der momentanen Swing-Version (1.1 beta) bestätigen (läuft
> außerdem sehr instabil).
>
> DT>Zukuft von Apple liegt meiner Meinung nach in der YellowBox
> Gibt es dazu schon eine Doku?
Ja. Sogar kürzlich aktualisiert:
Solltest Du via diesem Link hin kommen (bin gerade offline):
http://developer.apple.com/macosx/server/
Johannes Formann
> RealBasic allemal. Schau Dir einfach mal die Demo an und arbeite das
> Tutorial durch. Sind ca. 2-3 Stunden Zeit, die Du investierst. Ich war
> danach von RB überzeugt.
Ich habe jetzt RB heruntergeladen!
Gibt es auch eine Dokumentation auf Deutsch?
Ich habe in der Schule zwar schon 4.5 Jahre Englisch aber es ist
trotzdem sehr schwierig.
Ich wäre für Tips Dankbar.
Tschau
Johannes
Thomas Tempelmann
JF>Deutsch?
ASH hat den dtsch. Vertrieb übernommen und hat vermutlich schon oder bald eine
dtsch. Anleitung dazu. Siehe http://ash.sww.net
TT
Bernd Froehlich
> Ich habe jetzt RB heruntergeladen!
> Gibt es auch eine Dokumentation auf Deutsch?
Application Systems Heidelberg vertreibt die Deutsche Version.
(www.ash.de oder so ähnlich)
Guido Mocken
> Apple hat gerade ein neues Entwicklerprogramm für Studenten aufgelegt
> (bist Du einer?) und Metrowerks verkauft seine Entwickungsumgebung nun
> auch in einer Nur-Java-Version (die gibt's bei o.G. Programm dazu)
Weiß jemand, ob bei diesem Studenten-Programm auch MacOS-X-Server dabei
ist? Da steht nur was von "a selection of developer CDs", aber nichts
über deren Inhalt. Und gesetzt den Fall, es ist dabei - ist bei MacOS X
dann eine Entwicklungsumgebung für objective-c & Yellowbox dabei?
Ich frage mich nämlich, ob ich mir einen CW Academic (für c++ und MacOS
8.x) holen soll, oder eine Chance besteht, über dieses
Studenten-Programm schonmal an MacOS X ranzukommen. Java ist für meinen
Bereich völlig uninteressant, deshalb brächte mir das sonst nix, da
würde ich dann lieber bei C unter MacOS 8.x bleiben.
Guido
--
Guido Mocken ** "In nur vier Zeilen was zu sagen,
moc...@physik.uni-kl.de ** erscheint zwar leicht, doch ist es schwer,
finger mocken@maitre. ** man braucht ja nur mal nachzuschlagen,
physik.uni-kl.de for PGP ** die meisten "signatures" brauchen mehr!"
Dirk Theisen
Hallo, Guido!
> Weiß jemand, ob bei diesem Studenten-Programm auch MacOS-X-Server dabei
> ist?
Guido Mocken <moc...@physik.uni-kl.de> wrote:
Bei /diesem/ wohl nicht. Allerdings wurde auf dem BOF-Report auf
www.stepwise.com angedeutet, daß es eine "academic" version von Mac OS X
Server geben könnte. Feedback an leade...@apple.com wird dort
empfohlen.
Sobald ich etwas weiß, melde ich mich hier nochmal.
> Da steht nur was von "a selection of developer CDs", aber nichts
> über deren Inhalt. Und gesetzt den Fall, es ist dabei - ist bei MacOS X
> dann eine Entwicklungsumgebung für objective-c & Yellowbox dabei?
Bei Mac OS X Server ist alles dabei. Bei der Entwickler-Version könnte
WebObjects fehlen oder kastriert sein.
> Ich frage mich nämlich, ob ich mir einen CW Academic (für c++ und MacOS
> 8.x) holen soll, oder eine Chance besteht, über dieses
> Studenten-Programm schonmal an MacOS X ranzukommen.
Das kann im Moment keiner mit Sicherheit sagen. Alle, die das
interessiert sollten den Report auf Setpwise lesen und feedback geben.
> Java ist für meinen
> Bereich völlig uninteressant,
Ooch?
> deshalb brächte mir das sonst nix, da
> würde ich dann lieber bei C unter MacOS 8.x bleiben.
OOPs?
Ich nie nie wieder...
Heiko Kretschmer
GM> Weiß jemand, ob bei diesem Studenten-Programm auch MacOS-X-Server dabei
GM> ist?
Imho nur Mac 68K.
Tschö, Heiko (mit Mac Philipp)
Guido Mocken
> Bei Mac OS X Server ist alles dabei. Bei der Entwickler-Version könnte
> WebObjects fehlen oder kastriert sein.
Das kann ruhig fehlen - brauch' ich nicht.
> > Java ist für meinen
> > Bereich völlig uninteressant,
>
> Ooch? OOPs? Ich nie nie wieder...
Ich bin (angehender) Physiker - das ist diese Spezies, die größtenteils
noch Fortran-77 programmiert ... :-)
Gut, da gibt's auch seine Gründe dafür, aber jedenfalls braucht
unsereins v.a. eine schnelle Numerik, und das mit Java? Lieber nicht ...
Reinhard Maier
GM>eine schnelle Numerik, und das mit Java? Lieber nicht ...
Habe ich auch zuerst gedacht. Bis neulich: ein Benchmarktest mit einer
Sinusberechnung (double-Precision) und Grafikausgabe ergab:
C (CodeWarrior): 2.2 Sekunden
Java (MRJ 2.1EA3): 2.4 Sekunden
Der Unterschied ist also doch gering. Allerdings stand einmal in einer
Newsgroup, daß es Probleme mit der Rechengenauigkeit in Java geben könnte
(kann ich aber bisher nicht bestätigen).
Gruß, Reinhard
Christian Mittendorf
RM> Allerdings stand einmal in einer Newsgroup, daß es Probleme mit der
Rechengenauigkeit in Java geben könnte (kann ich aber bisher nicht bestätigen).
Was sich aber wohl mehr auf den JIT Compiler von M$ bezog.
Christian
Guido Mocken
> Habe ich auch zuerst gedacht. Bis neulich: ein Benchmarktest
Ich mag keine Benchmarks, die ich nicht selber geschrieben habe. Da weiß
man doch nie, ob's für den eigenen Fall relevant ist oder nicht.
Okay, vielleicht unterschätzt man Java im Allgemeinen. Ich kann mir aber
beim besten Willen nicht vorstellen, wie Java-Code auch nur annähernd so
schnell abgearbeitet werden kann wie ein gut compilierter C-Code
(welcher sich nicht mehr wesentlich von direkt geschriebenem
Assemblercode unterscheiden sollte).
Guido
Dirk Theisen
Guido Mocken <Guido....@physik.uni-kl.de> wrote:
> Okay, vielleicht unterschätzt man Java im Allgemeinen. Ich kann mir aber
> beim besten Willen nicht vorstellen, wie Java-Code auch nur annähernd so
> schnell abgearbeitet werden kann wie ein gut compilierter C-Code
> (welcher sich nicht mehr wesentlich von direkt geschriebenem
> Assemblercode unterscheiden sollte).
Was bei Java langsam ist, ist das messaging, also Methodenaufrufe etc.
Berechnungen ohne diese laufen dank just-in-time compilern komplett in
native code ab. Das Problem ist nur, daß die JITs sich nicht viel zeit
für die optimierung nehmen können, denn der Benutzer wartet ja
schließlich darauf, daß das Programm startet... :-)
Ich hab' mir kürzlich einige Ergebnisse von Java2C convertern angesehen
und bei den Berechnungs-Benchmarks war Java mit aktuellem JIT
*höchstens* 1.5 mal langsamer als konvertierter, compilierter C code.
Gruß
Dirk
Guido Mocken
> Berechnungen ohne diese laufen dank just-in-time compilern komplett in
> native code ab.
Laufen diese JITs nur einmal kurz vor Programmstart, oder machen die das
häppchenweise während des Ablaufs?
> *höchstens* 1.5 mal langsamer als konvertierter, compilierter C code.
Interessant. Ich hatte zugegebenermaßen an JIT gar nicht mehr gedacht,
und von Interpretern halte ich geschwindigkeitsmäßig halt nicht so viel.
Guido
Dirk Theisen
Guido Mocken <Guido....@physik.uni-kl.de> wrote:
> Laufen diese JITs nur einmal kurz vor Programmstart, oder machen die das
> häppchenweise während des Ablaufs?
üblicherweise beim Laden einer Klasse. Das heißt bei deren erster
Benutzung.
> > *höchstens* 1.5 mal langsamer als konvertierter, compilierter C code.
>
> Interessant. Ich hatte zugegebenermaßen an JIT gar nicht mehr gedacht,
> und von Interpretern halte ich geschwindigkeitsmäßig halt nicht so viel.
Sind ja auch vergleichsweise ägmlich (so Faktor 10 und im Vergleich zu C
sind da keine Seltenheit).
Dirk
Klaus Garms
GM>Ich kann mir aber beim besten Willen nicht vorstellen, wie Java-Code
GM>auch nur annähernd so schnell abgearbeitet werden kann wie ein gut
GM>compilierter C-Code
Letzteres ist leider Wunschdenken...
GM>(welcher sich nicht mehr wesentlich von direkt geschriebenem
GM>Assemblercode unterscheiden sollte).
Die Basis für die zunehmende Verbreitung dieser Legende liegt weniger
daran, daß die Compiler wesentlich besser geworden wären, als daran, daß
es immer weniger Leute gibt, die Erfahrung mit Assembler-Code haben.
Der Unterschied liegt immer noch mindestens bei einem Faktor von 2.
Grüße, Klaus
Christian Grunenberg
> Der Unterschied liegt immer noch mindestens bei einem Faktor von 2.
Bei einem guten Compiler und einem schlechten Assembler-Programmierer
;-))
Criss
Guido Mocken
> Bei einem guten Compiler und einem schlechten Assembler-Programmierer
> ;-))
Könnt Ihr das etwas genauer erklären?
Ich hab' eine Menge Assembler programmiert, ist allerdings schon eine
Weile her (6502/65816). Wenn ich mir heute mit ResEdit
compiler-generierten 68k-Assembler-Code anschaue, sieht das alles nicht
viel anders aus, als ich es auch direkt schreiben würde. Ganz im
Gegensatz zu Kompilaten (nennt man das so?), die ich mir früher
angesehen habe - das war nur wildes hin- und her-ge-JMP/JSR-e über
Sprungtabellen in irgendwelche Libraries ... kaum wiederzuerkennen.
Also *wo* kann man eurer Meinung nach auch *heute* noch soooo viel
herausholen?
Christian Grunenberg
> Wenn ich mir heute mit ResEdit
> compiler-generierten 68k-Assembler-Code anschaue, sieht das alles nicht
> viel anders aus, als ich es auch direkt schreiben würde.
Komisch. Wenn ich mir den 68k-Code (PPC-Assembler kann ich nicht
vergleichen) des CodeWarriors ansehe, dann wird mir immer schlecht ;-)
>Also *wo* kann man eurer Meinung nach auch *heute* noch soooo viel
>herausholen?
1. Schnellere/Leistungsfähigere Befehle verwenden
2. Schleifen ausrollen
3. Inline-Routinen
4. Profiling von Schleifen und Routinen
(was wird wann wie oft ausgeführt?)
5. Registernutzung (häufig verwendete Daten in Registern,
Speicherzugriff über Register usw.)
6. Routinen und Speichernutzung an Cachegrößen anpassen
7. Datenstrukturen ausrichten (Wort, Langwort, usw.)
8. Selbstgenerierender/modifizierender Code
9. Intuition ;-)
10. OS/Bibliotheks-Funktionen vermeiden bzw. durch eigene Routinen
ersetzen (z.B. Standard-C-String-Funktionen)
11. usw.
Tatsächlich sehen manche optimierte Routinen auf den ersten
Blick deutlich aufwendiger aus als gute Compiler-Routinen. Letztlich
liegt es aber wahrscheinlich auch den Programmierern und den modernen
Entwicklungsumgebungen. Unter Visual C++ mache ich mir z.B. überhaupt
nicht die Mühe, an die Geschwindigkeit zu denken. Ist das Programm zu
langsam, sollen sich die Leute halt nach dem MS-Credo einen neuen
Rechner kaufen ;-))
Criss
Ivo Boehme
>
> Guido Mocken <moc...@physik.uni-kl.de> wrote:
> [...]
>
> >Also *wo* kann man eurer Meinung nach auch *heute* noch soooo viel
> >herausholen?
>
> 1. Schnellere/Leistungsfähigere Befehle verwenden
> 2. Schleifen ausrollen
> 3. Inline-Routinen
> 4. Profiling von Schleifen und Routinen
> (was wird wann wie oft ausgeführt?)
> 5. Registernutzung (häufig verwendete Daten in Registern,
> Speicherzugriff über Register usw.)
> 6. Routinen und Speichernutzung an Cachegrößen anpassen
> 7. Datenstrukturen ausrichten (Wort, Langwort, usw.)
> 8. Selbstgenerierender/modifizierender Code
> 9. Intuition ;-)
> 10. OS/Bibliotheks-Funktionen vermeiden bzw. durch eigene Routinen
> ersetzen (z.B. Standard-C-String-Funktionen)
> 11. usw.
>
Die Punkte 2, 3, 5, 7 werden von diversen Compilern beachtet. Der erste Punkt
sicher häufig auch. Selbstmodifizierender Code (8) ist sicher einer der schlechtesten
Wege, eine höhere Geschwindigkeit zu erreichen.
Intuition (9) als Tool für die Geschwindigkeitsoptimierung stehe ich ebenfalls
skeptisch gegenüber. Ich habe bereits zuviele Helden über Performance-
Problemstellen einer Applikation schwadronieren hören, die sich dann später im
Profiler als doch nicht so bedeutend outeten.
OS-Routinen (10) lassen sich häufig nicht "ersetzen" (Library-Funktionen hingegen
schon). Das liegt in der Natur der Sache.
Die Probleme des SE liegen heute woanders. Es kann (insbesondere bei der technisch/
mathematischen Informatik) durchaus sein, dass optimale Performance gefordert wird.
Die entsprechenden Stellen sucht man dann mit einem Profiler heraus, um sie zunächst
in der entsprechenden Hochsprache zu optimieren (besserer Algorithmus, optimale
Umsetzung in der jeweiligen Sprache). Erst dann lohnt es sich überhaupt, den generierten
Code zu betrachten und ggf. durch ein Assemblerstück zu ersetzen.
Häufig hilft auch einfach ein anderes Konzept.
Grüsse,
Ivo
Christian Grunenberg
>Die Punkte 2, 3, 5, 7 werden von diversen Compilern beachtet. Der erste
>Punkt sicher häufig auch.
Letztlich schon. Und doch läßt sich immer etwas herausholen.
>Selbstmodifizierender Code (8) ist sichereiner der schlechtesten
>Wege, eine höhere Geschwindigkeit zu erreichen.
Selbstgenerierende Code kann selbst gegenüber allgemeinen, optimierten
Assemblerroutinen um Welten schneller sein. Bei nur wenigen Fällen
kann man noch jeweils eine spezielle Routine schreiben. Aber wenn sie
von äußeren Faktoren und Einstellungen abhängen und es massenhaft
Varianten gibt, bleibt man meistens bei der allgemeinen und langsamen
Routine.
> Intuition (9) als Tool für die Geschwindigkeitsoptimierung stehe ich ebenfalls
> skeptisch gegenüber.
Damit meinte ich mehr, daß es oft nicht so einfach ist, eine kritische
(s. 4. Profiling) und vom Compiler bereits optimierte Stelle DEUTLICH zu
beschleunigen. Nach einem gewissen Schema geht es jedenfalls nicht.
>OS-Routinen (10) lassen sich häufig nicht "ersetzen"
Jein. Die Anzahl der Aufrufe läßt sich meistens erheblich reduzieren
(okay, hat nichts mit Assembler zu tun, bringt aber bei vielen
Anwendungen doch einiges)
>Häufig hilft auch einfach ein anderes Konzept.
Oder ein schnellerer Rechner ;-)) Daß man natürlich zuerst in einer
Hochsprache vernünftige Algorithmen und Konzepte entwickelt und dann
die kritischen Stellen sucht, ist klar. Nur kann man manchmal in
Assembler völlig andere Wege gehen (je nach Sprache und Compiler).
Criss
Guido Mocken
> > 8. Selbstgenerierender/modifizierender Code
Hmm, ist Code nicht durch die MMU schreibgeschützt? Hab' ich irgendwo
mal gelesen, glaube ich. Falls es stimmt: Dann läuft sowas auf'm MacOS
sowieso nicht. Und wenn sie den Speicherschutz noch ausbauen, wird sich
das sicher auch nicht ändern.
Guido
Klaus Garms
KG> Der Unterschied liegt immer noch mindestens bei einem Faktor von 2.
CG>Bei einem guten Compiler und einem schlechten Assembler-Programmierer
CG>;-))
Genau! 8-)
Grüße, Klaus
Reinhard Maier
GM>Ich mag keine Benchmarks, die ich nicht selber geschrieben habe.
Das war auch keine exakte Benchmark, sondern nur eine Teilportierung eines
C-Programmes nach Java.
Man könnte den Versuch ja auch einmal mit einer Schleife mit Sinusberechnungen
und der Systemclock durchführen. Ich denke, daß Java da nicht viel schlechter
abschneiden wird. Der Bytecode der JVM kann offenbar sehr effizient in
Maschinensprache umgesetzt werden. Lästig ist aber die Wartezeit beim
Programmstart.
Wirklich langsam ist momentan Swing, auf dem Mac kann man damit IMO nicht
vernünftig arbeiten (von den vielen Abstürzen der MRJ 2.1EA3 einmal abgesehen).
PowerPlant ist im Vergleich dazu weit überlegen, dafür aber kompliziert und (im
Vergleich zu Visual C++) recht umständlich zu programmieren.
Ein Problem ist auch, daß man eine Java-Runtime Umgebung (abgesehen von
Browsern) beim Anwender nicht vorraussetzen kann. Browser auf dem Mac
unterstützen z.T. immer noch das veraltete Eventmodell von Java 1.0
(Communicator...).
Dennoch, wenn man mit Minimalaufwand eine graphisch akzeptable Oberfläche bei
guter Ausführungsgeschwindigkeit haben möchte, kommt man an Java nicht vorbei.
mfg, Reinhard
Tibor Pausz
> Selbstgenerierende Code kann selbst gegenüber allgemeinen, optimierten
> Assemblerroutinen um Welten schneller sein.
Das mag vielleicht bei CISC CPUs noch der Fall sein, bei superskalaren
RISC CPUs handelt man sich mit selbst modifzierendem Code sehr viel
Ärger ein. Es ist leider vor der Programmausführung die
Ausführungsreihenfolge der Assemblerbefehle nicht determiniert, d.h. ein
superskalarer RISC Prozessor sortiert während der Programmausführung
Befehle nach eigenem Ermessen um. Das wird auch noch durch Ereignisse
anderer Programme mit beeinflußt, so daß man durch selbst
modifizierenden Code sich Kohärenz Probleme ergeben. Bei "normalen" Code
verhindert das die SC RISC CPU durch spezielle Mechanismen.
Der Vorteil von Assembler Code ist bei einem SC RISC eher gering und
lohnt die Mühe nur bei ganz ganz wenigen Spezialfällen. Die Qualität der
Compilers ist dagegen enorm wichtig - noch erheblich mehr als bei CISC
CPUs. Eine der wenigen in PowerPC Assembler geschriebenen Libraries ist
LibMoto. Darin werden einige wenige Mathefunktionen ersetzt.
Klaus Garms
CG>1. Schnellere/Leistungsfähigere Befehle verwenden
CG>2. Schleifen ausrollen
CG>3. Inline-Routinen
CG>4. Profiling von Schleifen und Routinen
CG> (was wird wann wie oft ausgeführt?)
CG>5. Registernutzung (häufig verwendete Daten in Registern,
CG> Speicherzugriff über Register usw.)
CG>6. Routinen und Speichernutzung an Cachegrößen anpassen
CG>7. Datenstrukturen ausrichten (Wort, Langwort, usw.)
CG>8. Selbstgenerierender/modifizierender Code
CG>9. Intuition ;-)
CG>10. OS/Bibliotheks-Funktionen vermeiden bzw. durch eigene Routinen
CG> ersetzen (z.B. Standard-C-String-Funktionen)
CG>11. usw
IB>Die Punkte 2, 3, 5, 7 werden von diversen Compilern beachtet.
Der Witz liegt viel weniger darin, *ob* man es tut, sonden *wann* und
*wo*. Und genau diese Entscheidungen fallen Compilern auch heute noch
ziemlich schwer.
Register-Nutzung ist auch immer noch ein ziemlich trauriges Kapitel. Da
bleiben die Compiler nach wie vor deutlich hinter den Möglichkeiten
zurück.
IB>Der erste Punkt sicher häufig auch.
Das wäre sehr schön, ist aber leider nicht so. Compiler arbeiten auch
heute noch eher nach einfachen Ersetzungs-Schemata als mit der Suche nach
optimalen Befehlssequenzen.
Ein weiteres Problem ergibt sich damit, daß in den meisten "Hochsprachen"
eine ganze Reihe von Befehlen überhaupt nicht *formulierbar* sind (z.B.
Berechnungen mit Übertrag, Rotieren, Bit-Felder!) und bisher noch jeder
Compiler mit dem Erkennen und Rückübersetzen der notwendigen
Hilfskonstruktionen völlig überfordert ist.
Wenn man sich zum Beispiel mal den Befehlssatz des PowerPC ansieht, dann
ist offensichtlich, daß zum Beispiel die Shift-Befehle wohl kaum jemals
von einem C-Compiler ausgenutzt werden können (von den Rotier-Befehlen
ganz zu schweigen).
IB>Selbstmodifizierender Code (8) ist sicher einer der schlechtesten
IB>Wege, eine höhere Geschwindigkeit zu erreichen.
Nein. Dort, wo sehr hohe Anteile der Rechenleistung verbraten werden, ist
dynamischer Code gelegentlich unersetzbar ("selbstmodifizierend" ist da
in der Regel auch keine korrekte Bezeichnung). *Nur:* Es ist dabei
*extrem* *wichtig*, *sauber* mit den Code-Caches umzugehen! Wenn man dies
berücksichtigt, ist dynamisch erzeugter oder modifizierter Code
vollkommen sauber und korrekt. Und oft *deutlich* schneller als
statischer Code.
(Übrigens: Auch das Betriebssystem selbst tut beim Laden und Starten von
Programmen nichts anderes!)
IB>Intuition (9) als Tool für die Geschwindigkeitsoptimierung stehe ich
IB>ebenfalls skeptisch gegenüber. Ich habe bereits zuviele Helden über
IB>Performance- Problemstellen einer Applikation schwadronieren hören,
IB>die sich dann später im Profiler als doch nicht so bedeutend outeten.
Hat miteinander nichts zu tun. Spätestens beim Optimieren, meist auch
schon beim regulären Debuggen, ist Intuition schwer zu ersetzen.
IB>Die Probleme des SE liegen heute woanders.
Selbstverständlich gibt es *zusätzlich* auch noch andere Probleme.
IB>Es kann (insbesondere bei der technisch/ mathematischen Informatik)
IB>durchaus sein, dass optimale Performance gefordert wird.
Tatsächlich? Wo wir doch alle wissen, daß eigentlich alle Anwender über
unbegrenzte Zeitreserven verfügen... B-)
IB>Die entsprechenden Stellen sucht man dann mit einem Profiler heraus,
IB>um sie zunächst in der entsprechenden Hochsprache zu optimieren
Natürlich gibt es diese Vorstufen. Was nichts daran ändert, daß irgendwo
letztendlich doch die "eigentliche Arbeit" gemacht werden muß. Und
spätestens beim Bearbeiten größerer Datenmengen gehört dort guter
Assembler-Code hin.
Sauberkeit ist selbstverständlich immer oberstes Gebot; Aber das gilt
schließlich ebenso für alle anderen Sprachen.
Grüße, Klaus
Klaus Garms
GM>Hmm, ist Code nicht durch die MMU schreibgeschützt?
Für den statischen PowerPC-Code gilt das in der Tat. Allerdings steht es
dem Code völlig frei, irgendwoanders hinzuspringen. Sollte der
Speicherschutz sinnloserweise Code und Daten nochmal voneinander
abschotten (separate Adreßräume), dann würde es in der Tat schwieriger.
Aber nach wie vor möglich (dynamisch generierte Library-Files).
Grüße, Klaus
Georg Bauer
>spätestens beim Bearbeiten größerer Datenmengen gehört dort guter
>Assembler-Code hin.
Klar. Deshalb haben auch alle wirklich _schnellen_ Betriebssysteme so
wahnsinnig viel Assembler-Anteil. Guck dir mal den Linux-Kernel an. Guck
dir mal den FreeBSD-Kernel an.
Assembler ist nur noch in Ausnahmefällen notwendig. Der Anteil an
Assembler-Source sollte grundsätzlich reduziert werden, da er immer mit
Wartungsproblemen und Portabilitätsproblemen behaftet ist. Moderne
Compiler sind nicht perfekt, was die Codegenerierung angeht, aber sie sind
gut genug, um auf der Hochsprachenebene zu bleiben.
Worauf man allerdings nicht verzichten kann, ist Assembler-_like_ zu
programmieren - eine ganze Menge Code im Linux-Kernel ist zwar C, aber im
"Mindset" eines Assembler-Programmierers erstellt. An den Stellen hat
übrigens C tatsächlich mal einen Vorteil gegenüber anderen Sprachen: die
Low-Level-Befehle sind relativ nahe an einer hypothetischen CPU, weshalb
speziell C-Compiler eine ganze Menge der
Shift-Rotier-And-Sonstwas-Kombinationen auch tatsächlich ausnutzen können.
Und gelegentlich kommt man auch nicht umhin, sich mal den generierten
Assembler-Source anzugucken (und für bestimmte Sondersituationen gibt es
auch noch gperf).
Man sollte auch nicht vergessen, wie und wieso RISC-Prozessoren entstanden
sind (und der PPC _ist_ eine RISC-CPU). Nur weil man vom auf den
Befehlssatz gucken meint, die Befehle würden nicht genutzt, muß das noch
lange nicht stimmen. Schnapp dir mal den Motorola-C/C++-Compiler für den
PPC auf dem Mac - der macht deutlich besseren Code als die anderen
Compiler, die es zur Zeit gibt (speziell der CW blamiert sich da eher als
sich mit Ruhm zu bekleckern).
bye, Georg
Klaus Garms
> Selbstgenerierende Code kann selbst gegenüber allgemeinen, optimierten
> Assemblerroutinen um Welten schneller sein.
TP>Das mag vielleicht bei CISC CPUs noch der Fall sein, bei superskalaren
TP>RISC CPUs handelt man sich mit selbst modifzierendem Code sehr viel
TP>Ärger ein. Es ist leider vor der Programmausführung die
TP>Ausführungsreihenfolge der Assemblerbefehle nicht determiniert, d.h.
TP>ein superskalarer RISC Prozessor sortiert während der
TP>Programmausführung Befehle nach eigenem Ermessen um. Das wird auch
TP>noch durch Ereignisse anderer Programme mit beeinflußt, so daß man
TP>durch selbst modifizierenden Code sich Kohärenz Probleme ergeben.
TP>Bei "normalen" Code verhindert das die SC RISC CPU durch spezielle
TP>Mechanismen.
Genau dafür gibt's ja die entsprechenden Synchronisations-Mechanismen
(die vom Betriebssystem ja auch für exakt denselben Zweck benutzt
werden). Es ist absolut kein Problem, dynamisch generierten Code auch auf
superskalaren und/oder auf RISC-CPUs vollkommen sauber zu implementieren.
TP>Der Vorteil von Assembler Code ist bei einem SC RISC eher gering und
TP>lohnt die Mühe nur bei ganz ganz wenigen Spezialfällen.
Vergiß es! Der Unterschied ist praktisch genauso groß wie auf anderen
CPUs. Was ich bisher an PPC-Code gesehen habe (CodeWarrior, alle
Optimierungen auf Maximum) ist immer noch genauso traurig wie zu CISC-
Zeiten. Die Kiste ist halt per se schon rattenschnell; Der compilierte
Code ist es leider nicht annähernd!
TP>Die Qualität der Compilers ist dagegen enorm wichtig - noch erheblich
TP>mehr als bei CISC CPUs.
Ich kenne diese Theorie auch. Nur ist sie eben eine solche geblieben.
Was als Vorteil bleibt, ist der Umstand, daß es etwas *billiger* sein
dürfte, einen Compiler für eine RISC-CPU zu entwickeln. Die Code-Qualität
ist aber nicht unbedingt gestiegen.
Das liegt zum Teil schon an den Sprachdefinitionen, die das Optimieren
erschweren (C!). Zum anderen war das, was immer als Hauptproblem bei
den CISC-Compiler hingestellt wurde, nämlich eine vernünftige Ausnutzung
der diversen (bei CISC zahlreichen) Adressierungsarten, für die
Ausführungsgeschwindigkeit eben nicht wirklich ausschlaggebend.
Wesentlich wichtiger beim direkten Assembler-Programmieren ist es, von
vorneherein *andere* *Implementierungsstrategien* beim Umsetzen von
Algorithmen oder sogar *andere* *Algorithmen* zu verwenden, die in
Assembler-Code möglich sind, in der "Hochsprache" aber nicht.
Und /das/ automatisch in einem Compiler umzusetzen, klappt bis heute
immer noch nicht. Solange sich das aber noch so verhält, wird der
Performance-Faktor C zu Assembler sich auch auf längere Sicht nicht
großartig verbessern.
Grüße, Klaus
Klaus Garms
GB>Klar. Deshalb haben auch alle wirklich _schnellen_ Betriebssysteme so
GB>wahnsinnig viel Assembler-Anteil. Guck dir mal den Linux-Kernel an.
GB>Guck dir mal den FreeBSD-Kernel an.
Die nutzen die *strukturellen* Möglichkeiten besser aus als andere; Der
*Code* ist immer noch langsam. Man sollte nicht vergessen, daß die *CPUs*
heute unglaublich schnell sind! Die konnten die deutlich gesunkene
Performance der Software zum großen Teil abfangen.
(Natürlich bieten Betriebssysteme heute erheblich erweiterte
Funktionalitäten gegenüber den früheren Systemen. Es wäre deshalb
logischerweise Unsinn, einfach die "gute alte Zeit" wieder
herbeizuwünschen.)
GB>Assembler ist nur noch in Ausnahmefällen notwendig.
Wenn Performance Nebensache ist (und das ist bei der heutigen Rechner-
Performance bei etlichen *Applikationen* in der Tat der Fall), dann kann
man das in der Tat so sehen.
*Betriebssysteme* sind aber eine andere Geschichte: Da Performance-
Probleme des Betriebssystems den kompletten Rechner 'runterbremsen, sind
fehlende Optimierungen hier weitaus schwerwiegender. Was das bedeutet,
sieht man an Windows oder am MacOS. Bei letzterem spielen natürlich auch
die 68K-Artefakte noch eine Rolle. Aber optimierter 68K-Code ist oft auch
emuliert noch schneller als so mancher nativer C-Code.
GB>Der Anteil an Assembler-Source sollte grundsätzlich reduziert werden,
GB>da er immer mit Wartungsproblemen und Portabilitätsproblemen behaftet
GB>ist.
Dieses Problem wird oft deutlich überschätzt. Im übrigen dürfte es in der
Welt erheblich mehr unportablen C-Code geben als Assembler-Sourcen. 8-)
C ist ja alleine schon (aber nicht nur deshalb) durch die schlampigen
Typdefinitionen zunächst einmal unportabel. Man *kann* unter bestimmten
Umständen tatsächlich portablen C-Code erzeugen; Aber es ist keinesfalls
so einfach, wie oft angenommen wird.
GB>Moderne Compiler sind nicht perfekt, was die Codegenerierung angeht,
GB>aber sie sind gut genug, um auf der Hochsprachenebene zu bleiben.
Das ist einfach eine Frage des Anspruchs. "Good enough Quality" mag im
Moment der Standard sein; Ich persönlich versuche eigentlich immer, so
gut wie *möglich* (und vertretbar) zu arbeiten.
Und das bedeutet eben auch, an den entsprechenden Stellen direkten
Assembler-Code zu verwenden.
GB>Worauf man allerdings nicht verzichten kann, ist Assembler-_like_ zu
GB>programmieren - eine ganze Menge Code im Linux-Kernel ist zwar C, aber
GB>im "Mindset" eines Assembler-Programmierers erstellt.
Was meinst Du denn damit??
GB>An den Stellen hat übrigens C tatsächlich mal einen Vorteil gegenüber
GB>anderen Sprachen: die Low-Level-Befehle sind relativ nahe an einer
GB>hypothetischen CPU, weshalb speziell C-Compiler eine ganze Menge der
GB>Shift-Rotier-And-Sonstwas-Kombinationen auch tatsächlich ausnutzen
GB>können.
Sehe ich nicht. Ich wüßte nicht, wo C da Vorteile gegenüber anderen
Sprachen hätte - von den Pointern abgesehen. Und es fehlt so einiges, was
wirklich wichtig wäre.
GB>Man sollte auch nicht vergessen, wie und wieso RISC-Prozessoren
GB>entstanden sind (und der PPC _ist_ eine RISC-CPU).
GB>Schnapp dir mal den Motorola-C/C++-Compiler für den PPC auf dem Mac -
GB>der macht deutlich besseren Code als die anderen Compiler, die es zur
GB>Zeit gibt (speziell der CW blamiert sich da eher als sich mit Ruhm zu
GB>bekleckern).
Wäre wirklich mal 'ne Maßnahme. Wie wird der vertrieben? Oder gibt's den
nur unter LINUX? (Hab' ich noch nicht installiert.)
Grüße, Klaus
Tibor Pausz
> Genau dafür gibt's ja die entsprechenden Synchronisations-Mechanismen
> (die vom Betriebssystem ja auch für exakt denselben Zweck benutzt
> werden). Es ist absolut kein Problem, dynamisch generierten Code auch auf
> superskalaren und/oder auf RISC-CPUs vollkommen sauber zu implementieren.
Hast Du das schon mal im realen Leben ausprobiert? Die Ergebnisse die
mir zu Ohren gekommen sind besagen, daß solcher Code auf einem RISC
langsamer ist.
DER Vorteil eines RISC ist sein Pipelining und das wird durch
selbstmodifzierendem Code sehr effektiv gestört. Unnötiges Herumrödeln
auf dem Systembus wird ebenso gnadenlos bestraft. Da macht es schon eher
Sinn verschiedene Versionen des Algorithmus im Programm unterzubringen
und einzukopmpilieren. Das verbrät zwar Arbeitsspeicher. Aber das ist eh
meist nicht das Problem und die Wahrscheinlichkeit, daß alles gecacht
ist, ist weitaus größer. Branch Prediction heißt das Zauberwort und das
funktioniert recht gut. Die neusten CPU werten beide Äste bei einem
bedingten Sprung aus.
> Vergiß es! Der Unterschied ist praktisch genauso groß wie auf anderen
> CPUs. Was ich bisher an PPC-Code gesehen habe (CodeWarrior, alle
> Optimierungen auf Maximum) ist immer noch genauso traurig wie zu CISC-
> Zeiten. Die Kiste ist halt per se schon rattenschnell; Der compilierte
> Code ist es leider nicht annähernd!
Nochmal, der Code den der Compiler rauswirft ist bei einem superskalaren
RISC nicht der Code der ausgeführt wird! Das ist eine der Unterschiede
zu einem CISC.
Hast Du Testergebnisse von Programmläufen? Nur die lohnen sich bei RISC
CPUs überhaupt zu vergleichen. Was da an Code steht interssiert nicht
allzu sehr - oder kennst Du die CPU Interna aus dem ff für alle
PowerPCs?
Ich kenne unter anderem die LibMoto von Motorola, sie bringt einen
Performancegewinn und ist von ausgewiesenen PowerPC Profis programmiert
worden (in Assembler handoptimiert). Unter MkLinux ist der
Performancegewinn gewaltig gewesen, aber der gcc 2.7.2.x erzeugt auch
den schlechtesten PowerPC Code den ich kenne. Mit einem egcs 1.1.1 sind
die Unterschiede schon erheblich geringer. Unterm MacOS ist das ganze
schon unspektakulärer. Es gibt immer noch einen Performancegewinn, aber
der ist nicht mehr so groß wie zu einem altem Apple oder Metrowerks
Compiler.
> Ich kenne diese Theorie auch. Nur ist sie eben eine solche geblieben.
> Was als Vorteil bleibt, ist der Umstand, daß es etwas *billiger* sein
> dürfte, einen Compiler für eine RISC-CPU zu entwickeln. Die Code-Qualität
> ist aber nicht unbedingt gestiegen.
Das ist auch kein wirklicher Vorteil eines RISC. Die Vorteile liegen bei
der konstanten Befehlswortlänge, die ein viel effektiveres Pipelining
als bei einem CISC ermöglicht, die fast gleich lange Ausführungszeit der
Befehle und die parallelen Verarbeitung.
> Wesentlich wichtiger beim direkten Assembler-Programmieren ist es, von
> vorneherein *andere* *Implementierungsstrategien* beim Umsetzen von
> Algorithmen oder sogar *andere* *Algorithmen* zu verwenden, die in
> Assembler-Code möglich sind, in der "Hochsprache" aber nicht.
Die Argumente finde ich immer hoch interessant, zumal die
Ausführungszeiten für verschiedene CPU Befehlskategorien extrem zwischen
CISC und RISC schwanken.
Also was meinst Du mit anderen Algorithmen?
Klaus Garms
TP>Hast Du das schon mal im realen Leben ausprobiert? Die Ergebnisse die
TP>mir zu Ohren gekommen sind besagen, daß solcher Code auf einem RISC
TP>langsamer ist.
Ich wüßte keinen Grund dafür. Wenn der Code-Cache selektiv gelöscht wird,
was bei den moderneren CPUs möglich ist, dann hält sich der Overhead
sehr in Grenzen. Zumal der erzeugte Code ja sowieso nicht gecached
gewesen sein kann, da er gerade neu erzeugt wurde.
TP>DER Vorteil eines RISC ist sein Pipelining und das wird durch
TP>selbstmodifzierendem Code sehr effektiv gestört.
Das ist nicht korrekt. RISC-CPUs kommen heute mit deutlich kürzeren
*Opcode*-*Fetch*-Pipelines aus als z.B. der Pentium, der den Rekord an
Pipeline-Länge halten dürfte.
Eine lange Pipeline hat ja enorm viele Nachteile und wird beim Pentium
nur durch die völlig verbastelte Code-Struktur erzwungen.
Bei RISC-CPUs ist die Dekodierung der Befehle sehr viel einfacher, was
eine kürzere Pipeline erlaubt.
Das Pipelining der Befehls-*Ausführung* ist davon unabhängig und bleibt
von dynamischem Code sowieso unberührt.
TP>Unnötiges Herumrödeln auf dem Systembus wird ebenso gnadenlos bestraft.
TP>Da macht es schon eher Sinn verschiedene Versionen des Algorithmus im
TP>Programm unterzubringen und einzukopmpilieren. Das verbrät zwar
TP>Arbeitsspeicher. Aber das ist eh meist nicht das Problem und die
TP>Wahrscheinlichkeit, daß alles gecacht ist, ist weitaus größer.
Wo soll da der Vorteil des konventionellen Codes liegen?
TP>Branch Prediction heißt das Zauberwort und das funktioniert recht gut.
Die hat doch damit nichts zu tun!
TP>Die neusten CPU werten beide Äste bei einem bedingten Sprung aus.
Das ist eigentlich nur eine Notlösung, wenn die branch prediction zu
schlecht ist. Immerhin muß ja die doppelte Menge an Code geholt und
bearbeitet werden.
TP>Nochmal, der Code den der Compiler rauswirft ist bei einem
TP>superskalaren RISC nicht der Code der ausgeführt wird! Das ist eine
TP>der Unterschiede zu einem CISC.
Aber natürlich wird der Code ausgeführt! Die Opcodes werden geholt und
die Operationen ausgeführt. Es wird lediglich parallelisiert und
eventuell sogar die Reihenfolge verändert; *Ausgeführt* wird der Code
dennoch ganz normal.
TP>Hast Du Testergebnisse von Programmläufen?
Noch nicht genug. Aber es wird mehr....
TP>Es gibt immer noch einen Performancegewinn, aber der ist nicht mehr so
TP>groß wie zu einem altem Apple oder Metrowerks Compiler.
Interessant ist aber eben der Vergleich mit handoptimiertem Code. Und das
ist immer noch was völlig anderes als ein heutiger "handoptimierter"
*Compiler*.
KG>Ich kenne diese Theorie auch. Nur ist sie eben eine solche geblieben.
KG>Was als Vorteil bleibt, ist der Umstand, daß es etwas *billiger* sein
KG>dürfte, einen Compiler für eine RISC-CPU zu entwickeln. Die Code-
KG>Qualität ist aber nicht unbedingt gestiegen.
TP>Das ist auch kein wirklicher Vorteil eines RISC. Die Vorteile
TP>liegen bei der konstanten Befehlswortlänge, die ein viel effektiveres
TP>Pipelining als bei einem CISC ermöglicht, die fast gleich lange
TP>Ausführungszeit der Befehle und die parallelen Verarbeitung
Es ging aber eigentlich nur um die Auswirkungen für den *Compiler*, nicht
um die anderen Unterschiede zu CISC.
KG>Wesentlich wichtiger beim direkten Assembler-Programmieren ist es,
KG>von vorneherein *andere* *Implementierungsstrategien* beim Umsetzen
KG>von Algorithmen oder sogar *andere* *Algorithmen* zu verwenden, die
KG>in Assembler-Code möglich sind, in der "Hochsprache" aber nicht.
TP>Die Argumente finde ich immer hoch interessant, zumal die
TP>Ausführungszeiten für verschiedene CPU Befehlskategorien extrem
TP>zwischen CISC und RISC schwanken.
Das hat aber nichts damit zu tun.
TP>Also was meinst Du mit anderen Algorithmen?
Das betrifft vor allem Befehlssequenzen, die eine bestimmte Aufgabe in
Assemblercode sehr einfach lösen können, die sich aber z.B. in C
überhaupt nicht oder nur sehr umständlich beschreiben lassen. (z.B.
Blits!)
Grüße, Klaus
Klaus Garms
OB>Performanceprobleme von Betriebssystemen haben eher konzeptionelle
OB>Gründe und sind nicht Folge der gewählten Programmiersprache.
Es ist *beides* der Fall. Nicht, daß ich es für praktikabel halten würde,
alle Betriebssysteme grundsätzlich und ausschließlich in Assembler zu
programmieren; Durch gezielten Einsatz ließe sich aber durchaus einiges
erreichen.
Natürlich *zusätzlich* zu den notwendigen strukturellen Verbesserungen!
;-)
OB>Heutige Prozessoren arbeiten mit Pipelining, Prefetch und anderen
OB>Techniken, die kaum ein Assembler-Programmierer vollständig versteht.
Ich bitte Dich! /So/ kompliziert ist der ganze Kram nun wirklich nicht!
Das wichtigste ist, *Abhängigkeiten* zwischen Operationen so weit wie
möglich auseinanderzuziehen (das gilt auch und insbesondere für bedingte
Sprünge) und Zugriffe auf Hardware oder Shared Memory explizit zu
*sequentialisieren*.
Die prinzipiellen Compiler-Probleme sind dagegen offenbar geblieben; Und
die hat man in der Regel als Assembler-Programmierer nicht.
Grüße, Klaus
Klaus Garms
GB>Entsprechend war die Reaktion als letztens einer auf der Linux-Kernel-
GB>Liste vorschlug, den Kernel dadurch schneller zu machen, daß weite
GB>Teile in Assembler reimplementiert werden sollten. Und dann guckt der
GB>beleidigt, wenn er reihum ausgelacht wird :-)
Oh, man sollte keineswegs beleidigt sein, sondern einfach den Beweis
antreten! Gerade beim Kernel lohnt sich's am ehesten.
GB>Bei der Anzahl an unterstützten RISC-Plattformen eine durchaus
GB>verständliche Reaktion (das Gelächter) ...
Da ist leider viel naiver Wunderglaube im Spiel. ("RISC heilt alle
Wehwehchen... kauft Dr. Hypes Wunderelixier..." 8-) )
Grüße, Klaus
Georg Bauer
>antreten! Gerade beim Kernel lohnt sich's am ehesten.
Gerade beim Kernel ist es _völlig_ fehl am Platze. Der Kernel muß auf
allen
Plattformen vernünftig laufen, gleich sein (damit Treiber portiert werden
könne) und hat nun wirklich nichts mehr mit den alten handgestrickten
Kernels
der Urzeit zu tun. Klar, es gibt einige wenige Stellen, an denen Assembler
benutzt werden. Und es gibt ein paar mehr Bereiche, wo C wie ein Assembler
benutzt wird. Aber der ganz überwiegende Teil ist reines pures C, ohne
große
Hacks.
>Da ist leider viel naiver Wunderglaube im Spiel. ("RISC heilt alle
>Wehwehchen... kauft Dr. Hypes Wunderelixier..." 8-) )
Habe ich das behauptet? Es geht darum, _daß_ so viele Plattformen
unterstützt
werden. Und da die Erzeugung von gutem Maschinencode für RISC-Plattformen
sehr
aufwendig ist, ist es einfach nur albern, es zu versuchen - selbst wenn
marginale Vorteile herauskommen, überwiegen die Nachteile gewaltig.
Der Kernel kann natürlich noch optimiert werden - man schaue sich nur mal
den
Paging-Algorithmus von FreeBSD gegenüber dem von Linux an. Aber das hat
nichts
mit handgestricktem Assembler zu tun, sondern mit der Auswahl besserer
Techniken.
Den Linux-Kernel in Assembler schreiben zu wollen ist Unsinn. Und da kann
man
Linux durch jeden anderen Desktopsysteme-Kernel ersetzen. Zumindestens
wenn
man mehr als nur zwei oder drei Plattformen bedienen will.
(ein noch krasseres Beispiel als der Linux-Kernel ist der NetBSD-Kernel,
der
auf noch mehr verschiedenen Systemen läuft)
Wer heute noch davon träumt, Systemkernel in Assembler zu hören, hat die
letzen 10 Jahre der EDV verschlafen.
Klaus Garms
GB>Gerade beim Kernel ist es _völlig_ fehl am Platze. Der Kernel muß auf
GB>allen
GB>Plattformen vernünftig laufen, gleich sein (damit Treiber portiert
GB>werden könne) und hat nun wirklich nichts mehr mit den alten
GB>handgestrickten Kernels
Das ist nur dann ein Problem, wenn der Kernel nicht stabil ist, sondern
sehr häufig verändert wird (also derzeit vor allem bei LINUX). Ansonsten
lohnt sich der Mehraufwand für die plattform-abhängigen Assembler-
Implementierungen durchaus. Schließlich skaliert gerade die Performance
des Kernels direkt die Performance des Gesamtsystems.
GB>Und da die Erzeugung von gutem Maschinencode für RISC-Plattformen sehr
GB>aufwendig ist,
Schon mal probiert?
GB>ist es einfach nur albern, es zu versuchen - selbst wenn marginale
GB>Vorteile herauskommen, überwiegen die Nachteile gewaltig.
Hängt unter anderem vom Einsatzgebiet ab. Das ist wie bei allem im Leben:
"Es kommt 'drauf an"! 8-)
GB>Wer heute noch davon träumt, Systemkernel in Assembler zu hören, hat
GB>die letzen 10 Jahre der EDV verschlafen.
Das Wissen um das *wann* und *wie* beim Einsatz von Assembler-Code geht
einfach immer stärker verloren. Das hat sehr viel weniger mit *realen*
Vor- oder Nachteilen zu tun als mit schierer Gewöhnung an den Status Quo.
Grüße, Klaus
(Sorry wegen der Verzögerung; War wegen Grippe 'ne Woche offline.)