Interessant, dass auf Heise die Schnellere Compilierzeit hervorgehoben wurde, in diesem Bericht aber die Geschwindigkeit der erzeugten Programme. Fakt ist scheinbar, dass beides zutrifft, ich persönlich bevorzuge die Compilierzeit, denn Gentoo beschäftigt eben den Prozessor. ABer für die meisten Distris dürfte wohl eher der schnellere Programmcode wichtiger sein. Ob der GCC bald dem Intel Compiler sehr nahe kommt, der ja nun schon immer die Messlatte sehr hoch angesetzt hat?
Von Reiner Schischke am Di, 20. April 2004 um 23:24 #
Salut Sven, zumindest in der Überschrift hatte Heise ja beides erwähnt. Zitat: "GCC 3.4 erzeugt schneller schnelleren Code" Im Artikel hatten sie aber tatsächlich sich nur auf die Compiler-Laufzeit gestürzt. Aber für die Code-Effizienz ist halt das pro-linux Forum da. Das nenne ich gelungene Arbeitsteilung. Man liesst so besser beide. ;-) Man sollte aber bei der Code-Qualität nicht die verwandten Algorhitmen unterschätzen.
Hmm, also eigentlich ist die Geschwindigkeit des erzeugten Codes wichtiger.
Ausser Du bist von Beruf Programmierer und _NIE_ Anwender. Oder dein Hobby ist es, nicht mit Linux arbeiten, sondern deinen Rechner beim Gentoo-kompilieren zugucken... ;-)
Also ein paar alten Möhren ein Quentchen mehr Geschwindigkeit _durch schon kompilierte Programme_ rausholen, davon haben mehr Menschen etwas als ein paar Minuten beim kompilieren sparen. Kompilieren tu ich nur zwischendurch. Mit den kompilierten Programmen arbeiten schon _sehr viel_ länger.
Und wenn's schnell sein soll, gibts noch die 2.95er Serie.
Ich warte ungern auf Compiler, weswegen ich auch C/C++ nicht mag sondern Pascal vorziehe (als Entwickler). Ein C Compiler ist erst dann fix, wenn er mit dem Borland Delphi Compiler gleichziehen kann Alles andere ist und bleibt eine Qual
ich finde den Borland Delphi Compiler ätzend. Er ist zwar schnell, aber auch ziemlich doof. Ich sage "Optimierungen abschalten" und was bekomme ich im Debugger: "Variable ist wegen Optimierung nicht verfügbar" => Fazit: NERVT!!!! (Es sei den du hast eine Lösung für dieses Problem)
wenn ihr unbedingt schneller compilieren wollt, dann gibts doch sowas wie den distcc (Verteiltes compilieren) oder ihr stockt einfach eure hardware auf SO ca. 2 dual Athlon + 2GB Ram machen die sache recht angenehm Sowohl beim compilieren als auch zur laufzeit !!!
Wenn es richtig schnell sein soll dann nim den alten Turbopascal 3.0 Compiler auf einem Z80 CP/M mit 8 Mhz. Compilieren und starten war da so ziemlich das gleiche... Dagegen sehen die meisten heutigen Compiler aus wie lahme Enten
Mh, das größte das wir hier haben hat 130'000 und braucht auf einem lahmen PC um die 30 Sekunden, das denke ich ist ok. Wäre der PC fixer (und der speicher net so voll ) wäre er sicher auch noch schneller.
Ja Delphi kompiliert schon fix, aber beim C++ Builder musst du ja auch nicht lange warten. Was schon brutal ist sind KDE Programme mit KDevelop, da wünsche ichs mir auch manchmal dass es schneller gehen würde.
Ich hab frühers auch alles mit Delphi programmiert, mittlerweile fast alles mit C++ Builder wenns an Win Programme geht und KDevelop wenns an Linux Programme geht, ab und zu nehme ich sogar Kylix(Delphi IDE)unter Linux. Delphi ist okay aber C++Builder ist die Leichtigkeit von Delphi und die Power von C++, darüberhinaus auch noch mit Kylix einsetzbar. Schade das Kylix so schlecht angenommen wurde, denn die Kombination ansich ist ja ne feine Sache nur müsste die Unterstützung seitens der Entwickler und seitens Borland da sein.
Von Felix Schwarz am Mi, 21. April 2004 um 15:10 #
Ich warte ungern auf Compiler, weswegen ich auch C/C++ nicht mag sondern Pascal vorziehe (als Entwickler).
Bei Pascal hast du natürlich den Vorteil, dass Wirth einen Grundsatz bei seiner Sprachentwicklung konsequent verfolgt hat: Der Compiler sollte einfach sein. Und wenn der Compiler wenig "raten" muss, sondern sehr schnell sehen kann, mit welchen Konstrukten er es zu tun hat, wird das ganze Parsing etc. natürlich auch sehr viel einfacher => höhere Compiler-Geschwindigkeit.
Von Kai F. Lahmann am Mi, 21. April 2004 um 10:43 #
naja, die Zahl ist wohl bei der Kompilierzeit größer (verwundert ja auch nicht, die verbesserte Laufzeit fließt ja automatisch in diese ein, wenn ein Kompiler mal sich selbst kompiliert hat.)
Na, so ganz fehlerfrei ist die 3.4 wohl doch noch nicht, ich habe innerhalb von fünf Minuten zwei Crashs erzeugen können, die mit dem 3.3.1 nicht auftraten und auch nicht in den Betas. Mal schauen, woran es liegt, wahrscheinlich verliert wieder mal der Optimizer ein paar Zeiger, wie schon bei der 3.2.
================ Na, so ganz fehlerfrei ist die 3.4 wohl doch noch nicht, ich habe innerhalb von fünf Minuten zwei Crashs erzeugen können, die mit dem 3.3.1 nicht auftraten. ================
Es gibt halt Software die beim Kunden reift.
Gilt sowohl für kommerzielle, als auch für Open Source.
Gilt sowohl für kommerzielle, als auch für Open Source.
Sebastian.
Also entweder bist du wirklich hoffnungslos pessimistisch (immer alles möglichst schlecht sehen) oder halt doch ein Troll. Ist dir schonmal der Gedanke gekommen, dass ab einer bestimmten Projektgröße so ziemlich jede Software zur Bananesoftware wird? Ab einem gewissen Punkt wird das ganze so komplex, dass es nicht mehr überschaubar ist. Fehler lassen sich dann ganz einfach nicht mehr vermeiden.
Hab's gefunden und den Bug eingetragen. Es gibt Probleme, wenn die Quellen statt aus Pipes (also cpp) aus Sockets kommen. Einige Fälle werden nicht korrekt behandelt. Soweit ich es sehe, dürfte der Fix aber keine Kleinigkeit sein.
Das iss son Kurs den zufällig viele Leute auf einmal als Verkaufskurs angeben.. also so "Verkaufe meine Aktien wenn sie unter 6,50 fallen" und wenn das viele auf einmal machen.. kann es passieren das ne Aktie nur durch Zufall unter diese Marke fällt und plötzlich wird überall autoverkauft und die Aktie geht auf Tiefflug :o)
Ich fange gerade an mit dem gcc Atmel Controler (z.b. ATmega16, hat 16kB Flasch, 16 Mhz und bis zu 1Mega Instruktionen / MHz) zu programmieren. Wird die Ausführgeschwindigkeit des Codes durch die neue gcc version merklich schneller (also z.B. 5%) ?
Die Compilierzeiten sind bei Controllern eh zu vernachlässigen, ich denke die liegen im bereich von "Schwupp" bis 30 Sekunden.
Den gcc muss man für die Atmelprogrammierung eh selber compilieren.
Von Mark Hämmerling am Mi, 21. April 2004 um 14:42 #
Salut Mark :)
noch bin ich auch gespannt, ob 3.4.0 meinen AVR's einen Geschwindigkeitsvorteil bringt. Gerade bei zeitkritischen Interruptroutinen (20facher Phasenanschnitt, nebenher noch DMX512 mit 250kbaud decodieren, und noch RC5 etc.) wäre das praktisch. Daß die Compilierdauer so hervorgehoben wird, wundert mich als Controllerprogrammierer auch etwas. Natürlich ist es schön, wenn der Compiler nicht mehr so lange braucht. Aber wichtig ist doch das Endergebnis. Bei µC's ist das Verhältnis natürlich auch sehr extrem. 3 Sekunden für's make, und dann läuft der Controller monatelang Tag und Nacht mit diesem Programm. Da ist bestmögliche Optimierung natürlich erste Wahl. Das o.g. Projekt heißt übrigens Semitone - ein Open Source Dimmer.
Tip: Nimm debian (sid) - da gibt's avr-gcc, avr-libc und andere nützliche Tools für µC's fertig als Binärpakete.
ok hier noch die dämliche bemerkung eines gentooers;)
gentoo hat ebenfalls ebuilds für avr-binutils, avr-gcc, avr-libc, ponyprog und friends.
was die geschwindikeit angeht. weiss nicht ob da fur die muCs wirklich viel drinnliegt. vorallem beim interrupt handling würde ich nichtzuviel erwarten. aber cool wärs natürlich schon.
von den Optimierungen merkt man wohl nur was, wenn man eine "große" CPU (Desktop/Server), sprich MMU, FPU, MMX/SSE(2), HT, ... hat. Neue Optimierungen für die "kleinen" CPU wird man wohl nicht finden (schließlich arbeiten die seit x Jahren an den Optimierern).
zumindest in der Überschrift hatte Heise ja beides erwähnt. Zitat: "GCC 3.4 erzeugt schneller schnelleren Code"
Im Artikel hatten sie aber tatsächlich sich nur auf die Compiler-Laufzeit gestürzt. Aber für die Code-Effizienz ist halt das pro-linux Forum da. Das nenne ich gelungene Arbeitsteilung. Man liesst so besser beide. ;-)
Man sollte aber bei der Code-Qualität nicht die verwandten Algorhitmen unterschätzen.
A+
Reiner
Ausser Du bist von Beruf Programmierer und _NIE_ Anwender.
Oder dein Hobby ist es, nicht mit Linux arbeiten, sondern deinen Rechner beim Gentoo-kompilieren zugucken... ;-)
Also ein paar alten Möhren ein Quentchen mehr Geschwindigkeit _durch schon kompilierte Programme_ rausholen, davon haben mehr Menschen etwas als ein paar Minuten beim kompilieren sparen.
Kompilieren tu ich nur zwischendurch. Mit den kompilierten Programmen arbeiten schon _sehr viel_ länger.
Und wenn's schnell sein soll, gibts noch die 2.95er Serie.
Ich warte ungern auf Compiler, weswegen ich auch C/C++ nicht mag sondern Pascal vorziehe (als Entwickler). Ein C Compiler ist erst dann fix, wenn er mit dem Borland Delphi Compiler gleichziehen kann
Alles andere ist und bleibt eine Qual 
ich finde den Borland Delphi Compiler ätzend. Er ist zwar schnell, aber auch ziemlich doof. Ich sage "Optimierungen abschalten" und was bekomme ich im Debugger: "Variable ist wegen Optimierung nicht verfügbar" => Fazit: NERVT!!!!
(Es sei den du hast eine Lösung für dieses Problem)
BM
wenn ihr unbedingt schneller compilieren wollt, dann gibts doch sowas wie den distcc (Verteiltes compilieren) oder ihr stockt einfach eure hardware auf
SO ca. 2 dual Athlon + 2GB Ram machen die sache recht angenehm 
Sowohl beim compilieren als auch zur laufzeit !!! 
Ich hab frühers auch alles mit Delphi programmiert, mittlerweile fast alles mit C++ Builder wenns an Win Programme geht und KDevelop wenns an Linux Programme geht, ab und zu nehme ich sogar Kylix(Delphi IDE)unter Linux. Delphi ist okay aber C++Builder ist die Leichtigkeit von Delphi und die Power von C++, darüberhinaus auch noch mit Kylix einsetzbar. Schade das Kylix so schlecht angenommen wurde, denn die Kombination ansich ist ja ne feine Sache nur müsste die Unterstützung seitens der Entwickler und seitens Borland da sein.
Fast alle IDEs kompilieren bereits beim Tippen im Hintergrund
(sowieso, wenn Code-Completion an ist).
Viele Systeme haben praekompilierte Headerfiles (die binaeren
Interfaces der Pascal-Units machen da keinen Unterschied).
Bei Pascal hast du natürlich den Vorteil, dass Wirth einen Grundsatz bei seiner Sprachentwicklung konsequent verfolgt hat: Der Compiler sollte einfach sein. Und wenn der Compiler wenig "raten" muss, sondern sehr schnell sehen kann, mit welchen Konstrukten er es zu tun hat, wird das ganze Parsing etc. natürlich auch sehr viel einfacher => höhere Compiler-Geschwindigkeit.
fs
Na, so ganz fehlerfrei ist die 3.4 wohl doch noch nicht,
ich habe innerhalb von fünf Minuten zwei Crashs erzeugen können,
die mit dem 3.3.1 nicht auftraten.
================
Es gibt halt Software die beim Kunden reift.
Gilt sowohl für kommerzielle, als auch für Open Source.
Sebastian.
Gilt sowohl für kommerzielle, als auch für Open Source.
Sebastian.
Also entweder bist du wirklich hoffnungslos pessimistisch (immer alles möglichst schlecht sehen) oder halt doch ein Troll.
Ist dir schonmal der Gedanke gekommen, dass ab einer bestimmten Projektgröße so ziemlich jede Software zur Bananesoftware wird? Ab einem gewissen Punkt wird das ganze so komplex, dass es nicht mehr überschaubar ist. Fehler lassen sich dann ganz einfach nicht mehr vermeiden.
Also, some individual systems have been obsoleted:
SCO UnixWare with UDK, i?86-*-udk*
Im übrigens hat bei SCO anscheinend endlich der Countdown eingesetzt
10...
9...
9...
7...
http://de.finance.yahoo.com/q?s=SCOX&d=c&t=5d&l=on&z=b&q=l
Bei 6,50 sollen angeblich massiv stoploss losgehen...
Das iss son Kurs den zufällig viele Leute auf einmal als Verkaufskurs angeben.. also so "Verkaufe meine Aktien wenn sie unter 6,50 fallen" und wenn das viele auf einmal machen.. kann es passieren das ne Aktie nur durch Zufall unter diese Marke fällt und plötzlich wird überall autoverkauft und die Aktie geht auf Tiefflug :o)
Gruß
Waldgeist
Ich fange gerade an mit dem gcc Atmel Controler (z.b. ATmega16, hat 16kB Flasch, 16 Mhz und bis zu 1Mega Instruktionen / MHz) zu programmieren.
Wird die Ausführgeschwindigkeit des Codes durch die neue gcc version merklich schneller (also z.B. 5%) ?
Die Compilierzeiten sind bei Controllern eh zu vernachlässigen, ich denke die liegen im bereich von "Schwupp" bis 30 Sekunden.
Den gcc muss man für die Atmelprogrammierung eh selber compilieren.
Schon mal schönen Dank
Mark
noch bin ich auch gespannt, ob 3.4.0 meinen AVR's einen Geschwindigkeitsvorteil bringt. Gerade bei zeitkritischen Interruptroutinen (20facher Phasenanschnitt, nebenher noch DMX512 mit 250kbaud decodieren, und noch RC5 etc.) wäre das praktisch. Daß die Compilierdauer so hervorgehoben wird, wundert mich als Controllerprogrammierer auch etwas. Natürlich ist es schön, wenn der Compiler nicht mehr so lange braucht. Aber wichtig ist doch das Endergebnis. Bei µC's ist das Verhältnis natürlich auch sehr extrem. 3 Sekunden für's make, und dann läuft der Controller monatelang Tag und Nacht mit diesem Programm. Da ist bestmögliche Optimierung natürlich erste Wahl. Das o.g. Projekt heißt übrigens Semitone - ein Open Source Dimmer.
Tip: Nimm debian (sid) - da gibt's avr-gcc, avr-libc und andere nützliche Tools für µC's fertig als Binärpakete.
Grüße,
Mark
gentoo hat ebenfalls ebuilds für avr-binutils, avr-gcc, avr-libc, ponyprog und friends.
was die geschwindikeit angeht. weiss nicht ob da fur die muCs wirklich viel drinnliegt. vorallem beim interrupt handling würde ich nichtzuviel erwarten. aber cool wärs natürlich schon.
von den Optimierungen merkt man wohl nur was, wenn man eine "große" CPU (Desktop/Server), sprich MMU, FPU, MMX/SSE(2), HT, ... hat. Neue Optimierungen für die "kleinen" CPU wird man wohl nicht finden (schließlich arbeiten die seit x Jahren an den Optimierern).
Gruß
Jens
Wolf