Thema: Ist C und Unix nur ein Joke?

[bitmaster]

@Svenska: Genau das meinte ich. Danke!!!!!!!

bitmaster

[hannibal]

Ok. Wir sind soeben auf ein sehr sonderbares Niveau... eh.. gesunken, wuerde ich mal sagen. Du kannst keinen QBasic Compiler mit GCC, ICC, oder sonstigen C Compilern vergleichen. Da steckt weitaus mehr dahinter bei einem C Compiler, vor allem bei den ganz Grossen.

*Kopf schuettel*

[Svenska]

Ich wollte damit nur zeigen, dass QB (welches per Definition um mind. Faktor 10 langsamer ist) durchaus die Geschwindigkeit von Assembler erreichen kann. Zudem muss man da auch weiterdenken - QB optimiert nicht von allein. Assembler auch nicht. C schon.

Ich gebe dir recht, dass Assembler die Möglichkeit zur optimalen Geschwindigkeit bietet. Aber: Ich bezweifle, dass du in der Lage bist, diese Möglichkeit zu nutzen. Eher schon ein C-Compiler wie gcc, der von Leuten programmiert wurde, die erheblich mehr von den Innereien der CPU verstehen als du. Die wissen dann auch, wie man das letzte Prozent aus der Hardware rauskitzelt.

Sofern du also nicht in der Lage bist, richtig guten / perfekten Assembler zu schreiben, bist du mit einer Hochsprache besser bedient. Denn da schaffst du es, in kürzerer Zeit (Zeit=Geld) mehr vom Programm fertigzustellen, als in Assembler. Zudem hast du mehr Zeit fürs Optimieren, die dir bei gegebener Zeit fehlt und die dann dafür sorgt, dass dein Assemblerprogramm langsamer läuft als das vergleichbare Hochsprachenprodukt.
In diesem Beispiel war die Entwicklungszeit für das Programm in QB+Optimierung genauso groß wie die Entwicklung in Assembler ohne Optimierung. Die Ausführungszeit war fast gleich. Überträgst du das Problem auf C, welches ja an sich schon bedeutend schneller ist als Assembler, hast du vielleicht eine Vorstellung, welchen Verlust die Entwicklung in Assembler eigentlich bedeutet.

Außerdem - und das ist viel wichtiger - hast du trotzdem deine I/O-Last. Der Geschwindigkeitsunterschied, den du mit deiner Sprache erreichst, spielt ohnehin keine Rolle, da ein moderner Prozessor >90% seiner Zeit eh im Leerlauf ruht. Da ist Optimierung nicht das große Thema, sondern eher die Programmierung in gegebener Zeit. Ich glaube nicht, dass du die Zeit (wie du schriebst) vernachlässigen kannst. Ein Treiber muss auf dem Markt sein, bevor die Konkurrenz entsprechende Produkte liefert. Da kommt es dann auf schnelle Entwicklung bei guter Funktionalität an.

Du kannst auf keinem Markt mit deiner Philosophie bestehen. Und ohne Markt wirst du nie etwas erreichen.

Gruß,
Svenska

[bitmaster]

@Svenska: Danke, aber erstens habe ich keine Lust mehr aus diese Schwachsinnige Diskussion. Und zweitens, wie blöd muss man ASM programmieren um nur die Geschindigkeit von QB zu erreichen. *kopfschüttel*

bitmaster

[Svenska]

Und zweitens, wie blöd muss man ASM programmieren um nur die Geschindigkeit von QB zu erreichen. *kopfschüttel*

Das hat nichts mit Blödheit zu tun, sondern mit elementarer Logik. Einerseits ist die Sprache an sich schon in der Lage, gewisse Sachen zu tun, andererseits ist sie nicht zwingend sehr gut dabei. Es ist ein Unterschied, ob ich den Bildschirm pixelweise oder blockweise beschreibe - schon allein dadurch komme ich auf einen Geschwindigkeitsunterschied, der bedeutend größer ist als der Unterschied, ob ich das nun mit C oder ASM mache. Zweitens darfst du auch Programmlogiken und Algorithmen nicht vergessen. Du brauchst nur einen nicht-optimalen Algorithmus benutzen und bist schon weit drunter. Gegen solche Entscheidungen hilft übrigens auch gcc nicht mehr. Mit Bubblesort haben wir in der Schule 2 Minuten auf unser Ergebnis gewartet, Quicksort erreichte das in unter 2 Sekunden. Trotzdem werde ich für kleine Datenmengen Bubblesort implementieren - einfach, weil der relativ schnell zu implementieren und zu verstehen ist und weil Geschwindigkeit nicht so wichtig ist, dass man sich da ewig mit Optimierungen beschäftigen muss.

Bin ich darum blöd?

Dafür habe ich in QB bedeutend mehr Entwicklungskomfort, ich kriege viele Fehler gleich mitgeteilt. Logische Fehler wie z.B. Indexüberschreitungen werden gleich festgestellt, während mir in Assembler u.U. der gesamte Adressraum um die Ohren fliegt. Diese Entscheidung ist oft wichtiger als die Implementation selbst.

[bitmaster]

Wenn ich mit QBasic natürlich Blockweise Pixel setzte und mit ASM

Code: [Auswählen]

mov rdi,dawopixelhinsoll

mov rcx,yanzahl*xanzahl
.1:
push rcx
mov eax,color
stosd
mov rcx,0FFFFFFFFFFFFFFFFh
loop $
pop rcx
loop .1
schreibe, dann ist der Basic code sicher schneller. Ich gebe dir da ja recht. Das einzige was ich bis jetzt sage ist:

Mit ASM kann man die volle schnelligkeit rausholen und mit anderen nicht. Ob das der Mensch kann, ist was anderes. Ich progge ASM ja nicht unbedingt wegen der Schnelligkeit sondern wegen dem spaß am x86 und x86-64 der mir bei den Hochsprachen verloren geht.


bitmaster

[Svenska]

Mit ASM kann man die volle schnelligkeit rausholen und mit anderen nicht.

Würde ich so allgemein nicht sagen, weil das Verhältnis Programm<->Wartezeit bei weitem nicht optimal ist.

Ich progge ASM ja nicht unbedingt wegen der Schnelligkeit sondern wegen dem spaß am x86 und x86-64 der mir bei den Hochsprachen verloren geht.

Damit sehe ich die Diskussion als beendet an.

Gruß,
Svenska

[bitmaster]

Damit sehe ich die Diskussion als beendet an.

Schön das zu hören.

bitmaster