Thema: Ist C und Unix nur ein Joke?

[Svenska]

Und schon wieder nicht vernüntig. Also ich hoffe wirklich das du nicht so proggst und nicht testest. Das wäre nämlich nicht so doll.

Jetzt weiß ich wenigstens, was du meinst. Na gut, lass ich die Originalposter eben weg, wenn die Forensoftware zu blöd dazu ist ... ich mach es eigentlich überall so und bin halt davon ausgegangen, dass es funktioniert. Tut mir Leid.

Na ja, du sagst wieso Assembler benutzen. Aber unten beschwärst du dich über die heutige Art der meisten Progger. Ich gebe dir unten recht, und damit beantwortest du gleichzeitig die Frage, warum ASM.

Assembler macht die Nachteile von C noch schlimmer (kompliziert/komplex, schwierig, fehleranfällig, langsam). Damit sage ich nicht, dass man mit Assembler bessere Ergebnisse erzielt - denn das glaube ich nicht - noch, dass der Code übersichtlicher und damit gut wartbar ist.

Und ich stimme taljeth vollkommen zu; der kann sich besser ausdrücken als ich.

Übrigens: Es ist nachgewiesen, dass jemand, der noch die vorm PC gesessen hat, mit OS/2 bedeutend besser klarkam, als mit Windows (sowohl 3.1 als auch 95) und diejenigen, die mit OS/2 begonnen haben, nach wie vor die WPS (Workplace Shell) allem anderen vorziehen. Aber OS/2 ist so gut wie tot. Das mal ohne Kommentar.

ich frage mich immer wieder wie sich das denn äußert, also die instabilität oder die unsicherheit

Das liegt teilweise in der Architektur begraben - einerseits, wie ein Treiber oder Anwendungsprogramm, welches nicht zum System selbst gehört, fremde Prozesse beeinflussen kann, andererseits, inwiefern Programme Amok laufen dürfen. Je nachdem, wie dies in unvorhergesehener Weise möglich ist, ist das eine Stabilitätsfrage.
Beispiel: Windows 3.1 im Standard-Modus schaltet für DOS-Anwendungen in den Real-Mode des Prozessors zurück (80286) und somit den Speicherschutz effektiv aus. Dieses DOS-Programm kann sämtliche Windows-Daten seinerseits zerstören, ohne, dass Windows da etwas gegen tun kann. Das geht im V86-Modus natürlich nicht mehr.

Unsicherheit liegt in der Implementation begraben, denn durch schlampige Programmierung kann man auf Innereien eines Programmes zugreifen, die eigentlich verborgen bleiben sollten. Damit kann man Programme entweder zum Absturz bringen (die Grenze Instabilität/Unsicherheit ist also fließend) oder zu unvorhergesehenen Aktionen treiben (a.k.a. Daten klauen, Rechte kriegen, Daten bewusst zerstören).

(Nahezu) fehlerfreie Software läuft meist stabil und ist sicher, sofern der Unterbau (Bibliotheken, OS) entsprechend ausgerüstet ist. Windows 2000 ist in der Hinsicht schon ganz gut dabei. Allerdings gibt es auch da noch Probleme. Wenn ich einen TV-Kartentreiber installiere, friert mir gelegentlich das System ein - auch unter Windows 2000.

Die WinAPI ist eine binäre Programmierschnittstelle (also eher ein ABI) zu den Systemfunktionen und damit eine Architekturschwäche (bzw. je nach Auslegung auch eine Stärke): Einerseits weiß man, dass das Interface stabil bleibt und man es damit auch benutzen kann, ohne Gewissensbisse zu haben, andererseits ist es nicht erweiterungsfähig, ohne die Kompatiblität zu gefährden. Aus diesem Grund ist die Winapi auch so furchtbar komplex - und sei es nur, um Win16api-Programme auszuführen. Somit ist jede damalige Funktion vorhanden und die neue auch. Dann gibt es immer verschiedene Versionen für ANSI (1-Bit-Strings), DBCS (2-Bit-Strings unter Win16) und Unicode (2-Bit-Strings unter Win32). Dazu kommen dann noch die API-Funktionen für Win64, was an und für sich zu einer enormen Masse an Funktionen geführt hat, die man unterstützen muss.

Praktisch ist sie dagegen schon - man weiß, wie man sie aufruft und weiß damit alles, was man wissen muss. Wie sie funktioniert, bleibt verborgen. Ob das nun gut oder schlecht ist, muss jeder für sich entscheiden.

Ich schweife ab, aber wir sind ja hier im OT... :p

Gruß,
Svenska

[kevin]

Jetzt weiß ich wenigstens, was du meinst. Na gut, lass ich die Originalposter eben weg, wenn die Forensoftware zu blöd dazu ist ...

Probier mal [quote author=xyz]...[/xyz].

Edit: Doofe Forensoftware, hast recht. Nichtmal das klassische Escapen von BBCode funktioniert richtig...

[bitmaster]

@maumo: Ich meinte damit auch nicht Windows. ^^ loooool

@taljeth: Nein, auch mit Knoppix, SuSE, Ubuntu bekommen die nicht mal eine Installation hin (nicht das OS installieren sonder ein Programm dafür).

Aber gut, dann meinst du also Benutzerfreundlichkeit der GUI.

Nein, ich meine nicht nur die GUI.

Gut, ich muss dir zustimmen, Hochsprachen sind einfacher und vermeiden Fehler. Aber für einen guten Progger der alles gut durchdenkt, alles gut testet und gut in ASM ist dürfte das nicht viel ausmachen.

@Svenska: Mit dem vollgepumpten Windows gebe ich dir recht. Die haben das wohl nicht mehr unter Kontrolle. ^^ Aber mit ASM lassen sich bessere Ergebnisse erzielen. Das kann keiner leugnen. Ob jemand das kann ist was anderes.

lol

text

geht doch, also die " nicht vergessen ^^


bitmaster

[kevin]

@taljeth: Nein, auch mit Knoppix, SuSE, Ubuntu bekommen die nicht mal eine Installation hin (nicht das OS installieren sonder ein Programm dafür).

Da habe ich bisher aber immer das Gegenteil gehört. Synaptic (bei Ubuntu) wird eigentlich bei Linux-Neulingen immer sehr gut aufgenommen.

Nein, ich meine nicht nur die GUI.

Was dann?

Gut, ich muss dir zustimmen, Hochsprachen sind einfacher und vermeiden Fehler. Aber für einen guten Progger der alles gut durchdenkt, alles gut testet und gut in ASM ist dürfte das nicht viel ausmachen.

Du gehst davon aus, daß jemand, der Fehler macht, diese macht, weil er nicht schlau genug ist. Das ist Blödsinn. Der Großteil aller Fehler sind Flüchtigkeitsfehler, die jedem passieren - egal wie gut er die Sprache beherrscht oder wie intelligent er ist.

Und selbst wenn er so gut testet, daß er jeden Fehler findet und beheben kann, hat es ihn Zeit gekostet. In der Wirtschaft hast du nicht viel Zeit, da muß alles möglichst bis vorgestern fertig sein.

Dazu kommt mir übrigens auch folgendes Zitat in den Sinn: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

[bitmaster]

@taljeth: Hmm... genau das sagt man von Mathe ja auch immer. Aber wieso habe ich in den letzten 3 Jahren nie schlechter als 2+ eine Arbeit geschrieben? Weil ich unter Zeitdruck stehe und nicht alles ganz gründlich nachschauen kann. Sonst wären meine viele einsen noch mehr und keine zweien mehr. Dies ist kein schwäzen. Ich will nur verdeutlichen das man wenn man gut ist und alles genaustens testet so gut wie keine Fehler macht.

Ich gebe dir recht das die meisten Progger heute unter Zeitdruck stehen und deswegen Fehler zu finden sind. Aber ich stehe nicht unter Zeitdruck und lasse mich auch nicht vom wachsenden Markt unter diesen bringen. Dann mag es sein das ASM in diesem "alles schnell aber nicht genug getestet Markt" nicht mithalten kann. Aber genau dazu möchte ich nicht zählen. Egal ob mein OS dann nie in diesem Markt landen wird. Ich werde doch nicht Schnelligkeit auf Kosten von Stabilität setzen.


bitmaster

[kevin]

@taljeth: Hmm... genau das sagt man von Mathe ja auch immer. Aber wieso habe ich in den letzten 3 Jahren nie schlechter als 2+ eine Arbeit geschrieben? Weil ich unter Zeitdruck stehe und nicht alles ganz gründlich nachschauen kann. [...] Ich will nur verdeutlichen das man wenn man gut ist und alles genaustens testet so gut wie keine Fehler macht.

Schon richtig, Qualität kostet Zeit. Aber das ist hier nicht der Punkt. Du kannst dieselbe Qualität je nach Sprache in kürzerer oder längerer Zeit erreichen.

Übertragen auf dein Mathe-Beispiel: Wenn du alles im Binärsystem oder vielleicht besser noch in römischen Zahlen rechnen müßtest, würdest du bei gleichem Zeitaufwand auch mehr Fehler machen. Das hätte nichts damit zu tun, daß du plötzlich dümmer wärst, sondern damit, daß es römische Zahlen umständlicher machen als es nötig ist.

Bei konstantem Zeitaufwand und konstanter Intelligenz des Programmierers wird die Qualität von Software mit der zunehmenden Abstraktion der Programmiersprache steigen.

[bitmaster]

@taljeth: Wenn die Ausgabe von einer Hochsprache genauso klein und schnell wäre ja. Aber wie gesagt mischt der Compiler immer was unnötiges dabei.

bitmaster

[kevin]

Im Zweifelsfall ist mir Korrektheit wichtiger als das letzte Prozent Geschwindigkeit oder Dateigröße.

(An dieser Stelle sage ich normal auch immer, daß mein Assembler-Code von der Geschwindigkeit her sicher auch dann nicht an die Compilerausgabe mit -O3 rankommt, wenn ich überflüssiges weglasse, aber du kannst es ja offenbar so gut, daß dieses Argument für dich nicht gilt)

[hannibal]

Eine Frage: Wenn ihr so richtige Programmierer seid - und natuerlich in einem (explizit: ein (1)) Assembler programmiert -, was weiss ich wie intelligent seid und nie Fehler macht.. wie kommts, dass C scheinbar gar nicht verstanden wird? C ist ein dicker fetter Makroassembler. Immer schon gewesen, und wird auch immer so bleiben. Nur weil man mit einer flexiblen Schreibweise nicht zurechtkommt, und meint alles besser machen zu koennen als Jahrzehnte alte Compiler, die wirklich gut optimieren koennen, heisst das noch lange nicht, dass Hochsprachen keine "richtigen" Programmiersprachen sind. Ganz im Gegenteil: es geht darum ein Problem auf moeglichst einfachem und effizienten Weg zu loesen, nicht sich damit herumzuschlagen wie zum Geier man jetzt eine verkettete Liste auf einer spezifischen Architektur mit Opcodes implementiert.

Und um nochmal ganz klar und persoenlich Stellung zu nehmen bezueglich deiner Aussage, bitmaster:

Für richtige Progger wie mich ist das aber so besser. Wenn euch Register nicht passen dann proggt nicht lowlevel sondern Fenster für Vista oder was weiß ich, am besten noch in Delphi. ^^

Ich wuerde deine Arroganz ablegen und ein wenig reflektieren. Vielleicht kommst du ja dann auf ein klitzekleines Detail - ja genau, der riesige Zaunpfahl mit dem ich in meinem vorigen Post schon gewinkt habe, und mit welchem ich jetzt wieder winke. Es ist ein Unterschied zwischen loesungsorientiertem Entwickeln, und Entwickeln um des Entwickeln Willens. Was du hier versuchst, ist den Oberchecker raushaengen zu lassen, weil du ein Betriebssystem in Assembler programmierst. Ich frage mich nur.. "Ja.. und?" - das haben schon einige vor dir geschafft, nur war das vor 20 oder mehr Jahren aktuell . Abgesehen davon: Ich nehme nicht an, dass du mit deinen Qualifikationen versuchst einen Job als Programmierer zu bekommen, oder? Wenn doch: mutig, mutig. Ich wuerd' mich gar nicht mal trauen eine Bewerbung loszuschicken.

Svenska: Intelligentes (System)Design ist natuerlich die Voraussetzung fuer Portierbarkeit. Aber ich denke, das sollte dir bewusst sein.

Abschliessend moechte ich noch anmerken.. oder besser ersuchen.. bitte, bitte erfuellt nicht immer die Stereotypen von engstirnigen und dummen Informatikern - es gibt schon viel zu viele. Danke.

[Svenska]

@taljeth: Hmm... genau das sagt man von Mathe ja auch immer. Aber wieso habe ich in den letzten 3 Jahren nie schlechter als 2+ eine Arbeit geschrieben?

Du wirst es nicht glauben, aber so habe ich auch einmal gedacht. Bis zur 10. hatte ich grundsätzlich einen Schnitt von 1,0-1,2 in Mathe.
Dann kam pünktlich zur 12.Klasse (ich bin jetzt 13.) ein Lehrerwechsel. Seitdem freue ich mich über jede 2. Das hat, finde ich, nichts mit Dummheit zu tun, sondern mit der Art und Weise, in der ich bisher gearbeitet habe und mit dem Stoff an sich, der sich sehr geändert hat.

Weil ich unter Zeitdruck stehe und nicht alles ganz gründlich nachschauen kann. Sonst wären meine viele einsen noch mehr und keine zweien mehr. Dies ist kein schwäzen. Ich will nur verdeutlichen das man wenn man gut ist und alles genaustens testet so gut wie keine Fehler macht.

Wenn ich fies bin, weise ich dich mal darauf hin, dass man schwätzen mit "t" in der Mitte schreibt... so viel zu Zeitdruck und Gründlichkeit. Aber das ist hier egal.

Du gehst grundsätzlich davon aus, dass der Programmierer "gut" ist. Aber das ist kein Argument. Ein "guter" Programmierer kann, nach deiner Definition, auch in Binärcode programmieren und dabei immernoch korrekte, hochoptimierte, funktionierende Programme schreiben. So ist das aber nicht.

Ich gebe dir recht das die meisten Progger heute unter Zeitdruck stehen und deswegen Fehler zu finden sind.

Zeitdruck würde ich persönlich noch als untertrieben bezeichnen. Was ich gelegentlich höre, ist da schon ein bisschen extremer. "Morgen muss das funktionieren, denn um 15oo wird das vorgeführt!" - "Aber da ist noch gar nichts vorhanden" - "Egal, du hast noch 10 Stunden, dann geht es. Punkt."
So in der Art etwa.

Aber ich stehe nicht unter Zeitdruck und lasse mich auch nicht vom wachsenden Markt unter diesen bringen.

Ich will diese Aussage sehen, wenn du damit Geld verdienen und durch Unpünktlichkeit potentielle Käufer (= Geld) abschrecken würdest.

Ich werde doch nicht Schnelligkeit auf Kosten von Stabilität setzen.

Wenn du anfängst, in deinem OS Features zu implementieren, dann wirst du wahrscheinlich auch ein bisschen anfangen zu schlampen. Vermute ich einfach mal. Denn z.B. TCP/IP ist eine Sammlung von rekursiven Abhängigkeiten. Ohne Hardwaretreiber kannst du kein IP testen, ohne IP wiederum kannst du keinen Hardwaretreiber testen. So geschieht es an vielen Stellen. Auch glaube ich nicht, dass du auf Anhieb eine komplett ausreichende API erschaffst. Wenn du z.B. einen Taschenrechner erzeugst, fehlt dir vielleicht in deiner Mathematik-Bibliothek ein bisschen was, dann passt du das dort an und möglicherweise brennt dir dann ein anderes Programm, was die alte Bibliothek brauchte, durch. Unter Umständen merkst du es nichtmal ... und released. Dann hast du deine Stabilität schon gebrochen.

Je komplexer dein Projekt wird, umso weniger kannst du alles testen. Vielleicht merkst du später, dass dein jetzt guter Ansatz irgendwann total fehl am Platze ist - oder du sogar jetzt schon Fehler einprogrammiert hast? Wer sagt dir, dass z.B. deine GDT auch beim allerletzten Eintrag korrekt bleibt und nicht mit verhunzten Grenzen abraucht?

Oftmals sind -das- die Fehler, mit denen man Probleme hat und nicht das Eintippen in die entsprechende Sprache. Denn dann fängt man notgedrungen an zu pfuschen, um nicht alles neu aufarbeiten zu müssen.

Bei konstantem Zeitaufwand und konstanter Intelligenz des Programmierers wird die Qualität von Software mit der zunehmenden Abstraktion der Programmiersprache steigen.

Der Spruch ist klasse! Den muss ich mir merken.

Svenska: Intelligentes (System)Design ist natuerlich die Voraussetzung fuer Portierbarkeit. Aber ich denke, das sollte dir bewusst sein.

Das ist wahr. Aber nachdem ich etwas in den Minix-Code reingeschaut habe, finde ich #ifdef und #define einfach grausam. So kann man nicht vernünftig für verschiedene Plattformen entwickeln... mich überrascht es dabei, dass es doch getan wird (siehe Linux, Minix).

Gruß,
Svenska

[bitmaster]

Um das Ganze mal abzukürzen. Das ich Schwätzen mit d geschrieben habe liegt ebend daran das ich beim schreiben hier nciht alles gründlich anschaue. Ich habe schon so viele verschiedene Mathe lehrer gehabt.

Zeitdruck würde ich persönlich noch als untertrieben bezeichnen. Was ich gelegentlich höre, ist da schon ein bisschen extremer. "Morgen muss das funktionieren, denn um 15oo wird das vorgeführt!" - "Aber da ist noch gar nichts vorhanden" - "Egal, du hast noch 10 Stunden, dann geht es. Punkt."
So in der Art etwa.

Meine Antwort: Dann machen Sie es bitte selber.

Ja, ich will in keiner zurzeit vorhandenen Softwarefirma arbeiten. Da fehlen mir die Hochsprachenkenntnisse bzw. den Firmen das Assembler (je nachdem wie man es sieht).

Ich werde Assembler irgendwann so gut wie meine Muttersprache können (nicht von der Rechtschreibung her ^^).

Bitte versteht mich nicht falsch. Ich sage nicht das man mit Hochsprachen keine saubere Sachen hinbekommt. Nur es liegt einmal am Compiler und einmal am Progger. Aber leider wird es nie so sauber wie es in ASM gemacht sein kann.

sehr sehr gut ASM = wesentlich besser als sehr sehr gut C

schlecht ASM = vielleicht sogar schlechter als sehr sehr gut C


bitmaster

[hannibal]

Ich werde Assembler irgendwann so gut wie meine Muttersprache können (nicht von der Rechtschreibung her ^^).

Bitte versteht mich nicht falsch. Ich sage nicht das man mit Hochsprachen keine saubere Sachen hinbekommt. Nur es liegt einmal am Compiler und einmal am Progger. Aber leider wird es nie so sauber wie es in ASM gemacht sein kann.

sehr sehr gut ASM = wesentlich besser als sehr sehr gut C

schlecht ASM = vielleicht sogar schlechter als sehr sehr gut C

Falsch. Der C Compiler erzeugt Assembler - optimierten Assembler -, und du baust per Hand Hochsprachenkonstrukte nach, die dein Assembler gar nicht mal optimieren kann. Ich hoffe du begreifst irgendwann mal, dass Compiler sehr sehr sehr viel besser optimieren koennen, als du. Aber hoechstwahrscheinlich wirst du dem wieder widersprechen und auf deine Genauigkeit hinweisen, die natuerlich jedes automatisierte, getestete und vor allem durch Erfahrung gepraegte Optimierungsprogramm uebertrifft - natuerlich!

Ich will wirklich nicht unhoeflich erscheinen, aber komm doch bitte mal auf den Boden der Tatsachen zurueck. Wie alt bist du? 40? 50? Hast du Computer Science studiert und schon mehrere Hochsprachencompiler gebaut und bist zu dem Schluss gekommen, dass sie einfach unsauber arbeiten? Ja? Sollte das der Fall sein, dann bitte ich um Verzeihung fuer meine ueberaus kurzsichtige Sichtweise und gebe mich geschlagen.... Halt! So wie du hier schreibst bist du keine 16 Jahre alt, insofern: Nein.

Zu guter Letzt, moechte ich noch hinzufuegen, dass C tatsaechlich sehr sonderbar sein kann unter Umstaenden, aber trotzdem in den letzten Jahren gute Dienste geleistet hat. Es gibt mittlerweile sogar einige maechtige Nachfolger, die teilweise in die gleiche Richtung zielen, teilweise eher in andere Bereiche, aber immer noch im Kern von C abstammen. C hat gute Pionierarbeit geleistet, die ich nicht missen will.

[bitmaster]

@hannibal: Also 40 bin ich nicht, aber auch nicht jünger als 16. Das was du sagst ist einfach falsch. Schau dir gcc compilierten Code an und frage dich warum da so viel Unsinn drin ist (jetzt bitte nicht nur was kleines, da könnte es sein das der compiler das noch hinbekommt.

Vergleich:

Fenster mit Button:

ASM ca. 8 KByte, C ca. 64 KByte (Borland sogar evt. noch mehr)

Ja, ich weiß ist ein schlechtes Beispiel wegen den zusatzsachen für die Fenster etc. (kenn jetzt nicht so die Ausdrücke). Aber ich habe noch keinen Compiler gesehen der kleineren und/oder schnelleren Code erzeugt als ein ASM. Beweis mir das Gegenteil. Ja, ich bin ASM-Freak!!! Bist du 40 oder 50 und hast Compiler gebaut um sagen zu können das diese so gut optimieren?

bitmaster

[Korona]

Der Fenster mit Button Code ist mit Assembler auch 64 KB groß, wenn du die gleichen statischen Libs einbindest.

Assembler ist gut, wenn du direkt auf Register etc. zugreifen musst. Das muss man nur sehr wenig und für diesen wenigen Teil kann man auch mit Inline-Assembler arbeiten. Ich behaupte auch, dass der GCC Code, wenn man ihn richtig optimiert (durch setzen von -O3 und diversen anderen Flags und normal strukturierten Code) schneller ist als dein handgeschriebener Assemblercode. Dein Assembler kann nicht Inlinen, zumindest solange du es nicht per Hand machst. Er reagiert nicht auf die speziellen Eigenschaften einer Maschine (Optimierung für eine bestimmte Pipeline (Instruction scheduling) und Caching etc.). Selbst die Ausrichtung von Loops auf Pages musst du selbst machen, wenn du an das Ergebniss von GCC rankommen willst. Ich glaube nicht, dass du in der Lage bist solchen Code zu erstellen, niemand ist in der Lage das zu tun. Hinzu kommt die Portierbarkeit. Assembler Code ist nicht portierbar und selbst wenn dein Code für eine CPU-Generation perfekt ist, sieht es bei der nächsten ganz anders aus, da durch unterschiedliche Caches, Instructions und Pipelines der Code wieder ineffektiver wird. C Code ist dagegen sehr gut portierbar.

[kevin]

Ich glaube nicht, dass du in der Lage bist solchen Code zu erstellen, niemand ist in der Lage das zu tun.

Um bitmaster den Wind aus den Segeln zu nehmen: Freilich geht das. Es geht nur nicht mit vernünftigem Aufwand.

Schau dir gcc compilierten Code an und frage dich warum da so viel Unsinn drin ist (jetzt bitte nicht nur was kleines, da könnte es sein das der compiler das noch hinbekommt.

Ich hätte ja gesagt, bei was kleinerem kommst _du_ vielleicht noch hin. Der Compiler spielt seine Stärke erst aus, wenn es mal ein bißchen ernsthafter wird. Dann blickst du von Hand nämlich nicht mehr durch.

[bitmaster]

Dann blickst du von Hand nämlich nicht mehr durch.

Und da sind wir wieder bei dem was ich meine. Aber ersetze das "du" durch "die meisten". GCC optimiert nicht perfekt. Sowie kein Compiler.

bitmaster

[bitmaster]

Um das Ganze hier mal zu beenden. Ich interessiere mich einzig und allein für die x86-64 Architektur und deswegen spielt für mich portierbarkeit keine Rolle. Und Hochsprachen passen nicht zu mir. Die klauen mir den ganzen nervenkitzel. Ich finde die x86-64 Architektur klasse, und die bekomme ich in vollen Zügen nur mit ASM. ^^

bitmaster

[kevin]

Dann blickst du von Hand nämlich nicht mehr durch.

Und da sind wir wieder bei dem was ich meine. Aber ersetze das "du" durch "die meisten". GCC optimiert nicht perfekt. Sowie kein Compiler.

Und du auch nicht. So what?

Und Hochsprachen passen nicht zu mir. Die klauen mir den ganzen nervenkitzel.

Na endlich. Das erste akzeptable Argument deinerseits in diesem Thread.

[bitmaster]

Und du auch nicht. So what?

na, also ob das so stimmt

Na endlich. Das erste akzeptable Argument deinerseits in diesem Thread.

Nee, also so kann man das nicht sehen.

bitmaster

[Svenska]

sehr sehr gut ASM = wesentlich besser als sehr sehr gut C
schlecht ASM = vielleicht sogar schlechter als sehr sehr gut C

Ich habe mal einen Vergleich in einer Zeitschrift gelesen, in dem (auf 16 Mhz 386SX) Assembler mit QuickBasic (kompiliert) verglichen wurde.

Am Ende kam raus, dass der nichtoptimierte Assemblercode genausoschnell war wie der hochoptimierte Basiccode. Es handelte sich um einen Vergleichsalgorithmus. Daraus lässt sich schließen, dass Assembler zwar schnell sein kann, aber nicht muss. Eine solche Optimierung erfordert einen entsprechend guten Programmierer. Solcher Code ist dazu meist nicht mehr vernünftig von anderen versteh- oder lesbar.

Dazu vergisst du in deiner Betrachtung den Prozentsatz an I/O. In der heutigen Zeit ist es meistens viel wahrscheinlicher, dass du auf die Festplatte wartest, als ständig was rechnest. D.h. die maximale CPU-Geschwindigkeit spielt eh keine große Rolle, da du ja auf Komponenten wartest, deren Geschwindigkeit per Definition um Größenordnungen geringer ist.

Gruß,
Svenska