# C++ als Einsteiger lernen.



## KAEPS133 (8. November 2009)

Hallo,

ich hab mich dazu entschlossen Programmieren lernen zu wollen. Ich würde gerne C++ lernen und später vll sogar Spiele oder Komplexere Programme zu schreiben. Wenn ich solange durchziehe.

Jetzt wollte ich von euch Wissen mit welchem Buch ich sowas gut, einfach und schnell lernen kann. Am liebsten hätte ich natürlich ein Buch das sich direkt auf Spieleprogrammieren bezieht.

Ich bin mir schon im klaren darüber das es nicht einfach wird und es schon ein schwerer Brocken wird. Deswegen frag ich euch nach einem Guten und einfachen Buch. Das solle natürlich möglichst nicht zu teuer sein, nicht das ich dann nach 100 Seiten aufhöre und ich dann ein 80€ Buch da liegen hab.

Dieses Buch hat mir auf den ersten Blick schonmal etwas zugesagt.

Bin auf Tipps von euch gespannt


----------



## Phil_5 (8. November 2009)

Ich habe recht gute Erfahrungen mit C# und XNA bezgl. Spieleprogrammierung gemacht.

Aber da du ja bei 0 anfängst, müsstest du erstmal so halbwegs mit c# klarkommen. 
Ich würd da mal bei Galileo Computing :: Visual C# 2008 -- Das umfassende Handbuch anfangen zu lesen....

Wenn du das durch hast, hilft google recht gut für XNA weiter 

Info: XNA ist ein "Add-on" für c# welches recht einfach recht gutaussehende Spiele realisierbar macht.


----------



## Olstyle (8. November 2009)

Wenn du Spiele entwerfen willst solltest du dich eher mit dem Unreal 3 und Steam SDK(beides Freeware für nicht kommerziellen Gebrauch) befassen als C++ zu lernen. 
So oder so finde ich dein Anliegen aber doch recht übermütig. Man lernt nicht mal eben so ein Spiel zu programmieren.

Das Buch was du da verlinkt hast befasst sich übrigens mit C# und nicht mit C++, das bringt dich also schon mal nicht weiter  .


----------



## KAEPS133 (8. November 2009)

Das das übermütig ist weiß ich und hab ich ja auch geschrieben. Aber ich will es zumindest mal versuchen.

Ich will einfach eure Tipps haben wie ich am besten Vorgehe.
Mit dem Source SDK komme ich ansich recht gut zurecht. Aber ich würde auch so gerne noch Programme schreiben können. Grundsätzlich erstmal das Wissen in Richtung der Programmierung erweitern.


----------



## JOJO (8. November 2009)

Ist schon richtig wie Du es machst. Komplexe Programme zu benutzen ist nicht immer der richtige Weg. C++ ist der richtige Anfang. Nichts spricht dagegen, wenn man zuerst mal mit einer einfachen Sprache anfängt. Wenn C++ verinnerlicht ist, versteht man auch höhere Programmiersprachen einfacher. Ich habe im Studium noch Assembler erlernen müssen, also die Sprache die direkt an der CPU verarbeitet wird. Alles was danach kam, war dann schon einfacher für mich.

Eine Buchempfehlung kann ich Dir leider nicht geben, da C++ nicht mein Resort ist...


----------



## taks (8. November 2009)

Schau mal bei www.c-plusplus.dehttp://www.c-plusplus.de

Da findet man viel hilfreiches.


----------



## Olstyle (8. November 2009)

Was den generellen Programmiereinstieg an geht finde ich die Ansicht von meinem Info Lehrer in der Schule und von meinem Prof in der Uni recht einleuchtend:
Erst mal mit Java anfangen und vernünftiges Objektorientiertes programmieren lernen. C(in welcher Form auch immer)lesen kann man danach auch und die Unterschiede und damit das Programmieren dort lernt man anschließend auch recht schnell.

Einen Fred zu passenden Büchern gibt es da auch schon:
http://extreme.pcgameshardware.de/p...834-ultimatives-java-buch-fuer-anfaenger.html


----------



## JOJO (8. November 2009)

Will dir da ja nicht unbedingt widersprechen. Doch was Dozent und Prof immer raushauen ist auch nicht der Wahrheit letzter Schluss...

BASIC wäre eine mit der einfachsten Sprachen, es geht nicht grundsätzlich erst einmal um objektorientierte Programmierung!

Es geht vielmehr erst einmal darum zu verstehen, was ich mit entsprechenden Befehlen und Routinen erreichen kann!

Wenn man ganz unten anfängt, wäre es schon wichtig zu wissen, was ein PAP (Programm Ablauf Plan) ist, wie man ihn erstellt und in entsprechenden Programmiersprachen umsetzt!

Der Unterschied zwischen einem guten und schlechten Programmierer ist, dass der "Gute" fundamentales Wissen über Soft- und Hardware hat, also weis was er mit seiner Programmierung bewirkt. Der "Schlechte" wird immer an der Oberfläche mit fertigen Modulen anderer Programmierer experimentieren...


----------



## nahkillo94 (15. November 2009)

Also ich hab auch erst vor einem Jahr angefangen mit C++ zu programmieren, und ich komme recht gut zurecht! Also ich kann Jojo nur recht geben! Man sollte sich erstmal am PC auskennen. Wissen für was jedes Teil da ist und grob verstehen wie es funktioniert. 

Dann lernst du eine Programmiersprache. Im Eigenstudium mit Buch nicht leicht, aber mit viel ehrgeiz schaffbar. Achja setzt deine Ansprüche nicht zu hoch! Ein Spiel ist ein sehr sehr komplexes Projekt. Dazu braucht man jahrelange Erfahrung in einer OOP (zum verständniss: objekt orientierte Programmiersprache), in der DirectX-SDK und man muss sich in eine Engine einarbeiten.
Erstmal klein anfangen und traditionell ein HELLOWORLD-Programm erstellen. Dann einen Taschenrechner bis hin zum ersten 2D-Spiel. 

Ich persönlich halte nix davon gleich mit SDK's wie Unreal oder Source anzufangen und erst recht nichts von XNA! Aber muss jeder selbst Wissen.

Ich kann dir dieses Buch sehr empfehlen:
Einstieg in C++: Amazon.de: Arnold Willemer: Bücher

Hab ich auch und komme sehr gut zurecht damit. Ich hoffe ich konnte dir helfen!


----------



## rabit (15. November 2009)

nahkillo94 schrieb:


> Also ich hab auch erst vor einem Jahr angefangen mit C++ zu programmieren, und ich komme recht gut zurecht! Also ich kann Jojo nur recht geben! Man sollte sich erstmal am PC auskennen. Wissen für was jedes Teil da ist und grob verstehen wie es funktioniert.
> 
> Dann lernst du eine Programmiersprache. Im Eigenstudium mit Buch nicht leicht, aber mit viel ehrgeiz schaffbar. Achja setzt deine Ansprüche nicht zu hoch! Ein Spiel ist ein sehr sehr komplexes Projekt. Dazu braucht man jahrelange Erfahrung in einer OOP (zum verständniss: objekt orientierte Programmiersprache), in der DirectX-SDK und man muss sich in eine Engine einarbeiten.
> Erstmal klein anfangen und traditionell ein HELLOWORLD-Programm erstellen. Dann einen Taschenrechner bis hin zum ersten 2D-Spiel.
> ...


Ich ziehe mein Hut vor dir, ein Beitrag der ehrlich mal das trifft worauf es ankommt.
Komisch das in unserem Studium die Elektrotechniker und die It.ler Assambler lernen mussten.
Die Mathematik nicht zu vergessen.

Also unser Prof hat gesagt das ein guter Programierer nicht an Assambler vorbeikommt.
Und die, die direkt mit Hochsprachen anfangen kennen nicht den kürzesten weg zum Ziel.
Im übertragenem Sinn sind diese Leute, keine die in der Großfertigung anfangen können weil die immer einen grösseren Speicherbereich nutzen werden als nötig und nie Zeitkritisch programieren können.
Fazit es entstehen unnötig Kosten für Hw mit grösserem Speicherbereich.
Ich bin froh das ich Assambler kann. (halbwegs)
Und wer Assambler kann, kann andere Hochsprachen mit Leichtigkeit beherschen umgekehrt wird es zu kompliziert, da die an Comfort gewohnt sind mit den Bibliotheken die man im Assambler in der Form nicht hat.
Ist das hier ein Uni Forum sind ja nur studierende oder Ings am Werk^^
Ich gehe wieder Studieren um einige Profs mal zu hören brauche wenigstens nicht in eine Comedyshow zu gehen
Sofort mit Hightec anfangen.
Aber nicht die Grundlagen und die Architektur verstehen oh man o man
Als Erweiterung und aufbauend ist c und java echt unschlagbar kann Assambler nicht bieten zumindest nicht so überschaubar und so schnell zu programieren.


----------



## Olstyle (15. November 2009)

Architektur verstehen und Assembler programmieren(ich persönlich kann das übrigens durchaus etwas) sind zwei paar Schuhe. Die Grundlagen zu Hardware und Betriebssystem sollte man natürlich trotzdem kennen, aber das habe ich ja auch nie ausgeschlossen. 

Mein Prof an der Uni ist übrigens der Spezi für Embedded Systeme und Echtzeitprogrammierung, also sicher keiner der nichts mit Effizienz am Hut hat.
Nur ist es halt leichter jemandem zuerst Objektorientierung(und da ist Java nun mal Referenz da sie wie keine andere Sprache ausschließlich dazu zwingt) bei zu bringen und dann andere Programmiersprachen hinzu zu nehmen als ihn erst mal mit Bandwurmcode anfangen zu lassen um es ihm kurz darauf wieder aus zu treiben.


----------



## rabit (15. November 2009)

Ich meine nicht deinen Prof.
Und Profs sind auch für mich keine Referenz.
Ich finde Programmierung und Architektur sind unzertrennlich.
Schliesslich programierst Du es.
Gibt bestimmt welche denen man Jahrelang gerne zuhört und bei denen man lernt..
Aber back to Topic.
Ich vergleiche das mal plastisch:
Um Formel 1 fahren zu können sollte man erstmal Karts oder normale Autos fahren können und nicht sich als unerfahrener mit 14 auf einem Lamborghini setzen und versuchen auf den Nürburgring Bestzzeiten zu fahren.
(Welche Reifen bei welchem Wetter, Fahrwerksanpassung zu seinem Fahrstil....etc.
(Ausnahmen gibt es immer)
Er soll froh sein wenn er den Wagen unbeschadet über die Ziellinie bringt.
Später wenn die HW bei seiner Programierung nicht das macht was er möchte, wie soll er Fehlersuche betreiben?
Wie soll er effizient proggen wenn er nicht weis wie und warum gestackt wird oder ein Pointer gesetzt wird oder ein Interrupt......
Oder er etwas von einer Bibliothek modifizieren möchte weil er nicht alle Bibliotheken kennt?
Oder womit soll er sein persönliches Bibliothek erweitern wenn er noch nichtmal und oder verknüpfungen kennt oder setzen und rücksetzen.....
Sofort mit iwie Engines arbeiten finde ich für eien Anfänger to much.


----------



## Olstyle (15. November 2009)

rabit schrieb:


> Um Formel 1 fahren zu können sollte man erstmal Karts oder normale Autos fahren können und nicht sich als unerfahrener mit 14 auf einem Lamborghini auf den Nürburgring Bestzzeiten zu fahren.
> Er soll froh sein wenn er den Wagen unbeschadet in die Ziellinie bringt.


Was auch bis jetzt jeder hier geschrieben hat. 

Aber um in deinem Bild zu bleiben:
Natürlich sollte man mit dem Kart anfangen, aber den Motor von selbigem muss man nicht auch noch selbst bauen.


----------



## rabit (15. November 2009)

Olstyle schrieb:


> Wenn du Spiele entwerfen willst solltest du dich eher mit dem Unreal 3 und Steam SDK(beides Freeware für nicht kommerziellen Gebrauch) befassen als C++ zu lernen.
> .


C++ ist schon eine sehr weit oben angesiedelte Hochsprache.
Unreal und Steam ist wieder noch spezieller.
Hm ist bestimmt machbar.
Kann ur sagen alle im Studium ob Elko, It alle mussten durch Assambler jedem das seine. 
Zum Abschluss: Wir wollen ihm ja alle helfen.....


----------



## nahkillo94 (16. November 2009)

wow! wusste ich gar nicht, dass heute noch assembler gelernt wird, wo wir doch im zeitalter von c++ und co. leben! kann man sich das selbst beibringen oder geht das nur im studium??


----------



## midnight (16. November 2009)

Naja das kann man sich auch selbst beibringen. Aber wie schon gesagt bietet Assembler nicht unbedingt "comfort" 

so far


----------



## rabit (16. November 2009)

Nein man kann ohne weiteres c, Monster c, C++ und was es da noch alles gibt ohne Assambler lernen.
Aber es wird oft Assambler für Mikrokontroler eingesetzt Gründe siehe in den Vorposts.


----------



## nahkillo94 (16. November 2009)

is klar! Hab mir grad mal nen HelloWorld Quellcode angeguckt! Das is ja echt nen harter Brocken!! Bis man das flüssig drauf hat dauerts ne Weile, könnt ich mir denken! Aber ich hab keine Zeit dafür! erstmal nen ordentliches Abi! 

Ob die Programmierer bei MS das können??


----------



## DMA (16. November 2009)

Was, Helloworldprogramme können die MS sicher. [/ironie]

Nein, aber die meisten Spiele werden heute auf irgendwelchen gekauften Engines gemacht.
Als Programmierer für Spiele muß man sich nur selten an das "Hardcoden" machen.
Die meiste Zeit scriptet man etwas für eine Engine.

Außer man wird natürlich Engine programmierer, aber ich glaub als Hobby würde das eh zuweit gehen.

Blitz Basic wäre evt. noch ein einfacher und gut dokumentierter Einstieg.
René Meyer hat da einig egute Bücher verfasst, vllt soltest du dir mal etwas in die Richtung ansehen.


----------



## dot (16. November 2009)

Ob man jetzt hier einem Interessierten der ein wenig programmieren moechte mit Assembler abschrecken muss, halte ich fuer zweifelhaft. Das mag ja ziemlich sinnvoll sein, wenn man vorallem hardwarenah (z.B. bei µC) basteln muss, aber ansonsten ist es doch einfach nur umstaendlich.


----------



## Kadauz (17. November 2009)

Bin auch der Meinung, dass Assembler nicht unbedingt wichtig ist. Und das hat auch nichts mit "vom grunde auf lernen" zu tun. Aber ich stimme mit dir überein, dass sowas wie C++ oder Java zu Beginn etwas overkill ist.


----------



## phenomgamer² (17. November 2009)

Vielleicht noch einmal zurück zur Ausgangsfrage...denn mich interessiert es auch. Und ich bin auch denke mal ein blutiger Anfänger was programmieren angeht. Das einzige was ich draufhab is das Binärsystem und das kam eher von der technischen seite und zwar den transistoren ^^

HAt jemand also vllt noch einen Vorschlag für ein vernünftiges Grundlagenbuch dass mich gut einführt.
Das java-buch, welches hier benannt wurde hört sich nämlich schon sehr interessant an und teuer ist es auch nicht


----------



## rabit (17. November 2009)

Kannst dich ja einlesen in Google books.
Visual C++ 6 in 21 Tagen: der ... - Google Bücher
Und wenns gefällt kaufst Du es.


----------



## gangville (18. November 2009)

vill kannst du ja mit visual studio was anfangen und ei n eigenes programm schreiben.

muss ja nicht die professional edition sein, kann auch die normale sein.

also mir hat das programmieren mit vision pro und visual studio spaß gemacht.


----------



## DMA (18. November 2009)

Trotzdem, ohne Buch ist es schwer sich einzufinden, da muß man viel probieren und sich Beispiele anschauen (so hab ich mir C und C++ gelehrt).

Visual Studio ist nicht schlecht, doch viele Funktionen braucht man am Anfang nicht.
Da kann es schon vorkommen, daß die IDE etwas überladen ist und das noch mehr abschreckt.

Code::Blocks wäre da sicher eine nette Alternative.


----------



## pixelflair (18. November 2009)

Also ich hab vor Jahren mal mit TurboPascal angefangen und muss nun inner uni java machen und finds für den einstieg eigentlich perfekt  werde danach auch freiwillig noch C++ machen.


Buchempfehlung: Java ist auch eine Insel  vonGalileo


----------



## Fifadoc (18. November 2009)

ich hab in der schule mal TurboPascal und danach dann Delphi gelernt. beides ist zum einstieg optimal, finde ich.
keine programmiersprache ist von seiner syntax her einfacher zu lernen.

in der Uni hab ich dann Matlab und C++ gelernt. brauche heute nur noch C++. Damit werden in der Praxis (Wissenschaft) halt unter Linux Algorithmen und Simulations-Tools geschrieben. C++ ist einfach nur sau schnell.

zu Java: die sprache mag toll sein, aber ich persönlich find sie grottig. Echtes oop lernt man, meiner meinung nach, am besten von klein auf und nicht mit einer spache, die eh schon alles hat. In java kannst du ganze tools "schreiben" indem du sie zusammen klickst.


zum jeweiligen lernen würd ich empfehlen eine einfache sprache wie TurboPascal oder Basic zu nehmen. Daran halt erstmal die grundlegenden Strukturen wie Variablen, Schleifen, Abfragen, Rekursionen, Zeiger etc zu üben.
Wenn man das drauf hat, kann man sich an weiteres trauen. Eine Hochsparache, die direkt in einer grafischen Oberfläche arbeitet hat man dann schnell drauf. 
Ich hab c++ in 2 Wochen gelernt, da ich halt schon programmieren konnte. Binärbäume, Objekte und so sachen kannte ich aus Delphi und die Idee ist immer die gleiche, nur die Syntax ist eine andere.


----------



## Thomsn (19. November 2009)

Fifadoc schrieb:


> zu Java: die sprache mag toll sein, aber ich persönlich find sie grottig. Echtes oop lernt man, meiner meinung nach, am besten von klein auf und nicht mit einer spache, die eh schon alles hat. In java kannst du ganze tools "schreiben" indem du sie zusammen klickst.



Der Absatz erschließt sich mir nicht.

Was hat das Erlernen des Konzepts Objektorientierung mit dem Umfang der Standardbibliothek der jeweiligen Sprache zu tun?
Und welche Rolle spielt dabei deiner Meinung nach ein GUI-Designer, der mit dem Sprachkern erstmal auch garnichts zu tun hat?


Wie man an eine Sprache herangeführt wird ist meiner Meinung nach viel mehr eine Frage der verwendeten Entwicklungsumgebung. Die Entscheidung für eine solche lässt sich aber ziemlich fix ändern und es wird niemand gezwungen, per IDE anzufangen. Man kann zur Not auch per Notepad.exe und cmd.exe Java-Programme basteln und häufig wird das in der Einsteigerliteratur auch erklärt.

Hat man sich dann eine Weile lang mit dem Thema allgemein beschäftigt, wird man eh merken, dass es noch weitere Möglichkeiten gibt als die, die man bereits kennt.


----------



## replax (11. Februar 2010)

an deiner stelle würde ich mit C++ anfangen. wenn es dir direkt aufs spiele programmieren ankommt, erstmal c++ "lernen" und dann kannst du mit einem GDK (game development kit) wie deem DarkGDK in visual studio kleine games schreiben. 
wenn du kein geld für ein buch ausgeben willst (was NICHT zu empfehlen ist) oder dir c++ erstmal gangucken willst und einigermaßen englisch kannst, guck mal auf www.learncpp.com. da wird alles sehr gut erklärt und erläutert.

die besten bücher bekommst du bei galileocomputing, was auch empfehlenswert ist.


----------



## Crymes (15. Februar 2010)

Welche Programmiersprache wird eigentlich für die Cry-Engine 3 / Windows genutzt?


----------



## Bauer87 (15. Februar 2010)

Die Cry-Engine nutzt C++. Windows baut ursprünglich auf C auf, neuere Teile nutzen C++, dann gibt es bestimmt noch Fragmente, die seit Jahrzehnten mitgeschleppt werden, in anderen Sprachen. Und für Microsoft will ich hoffen, dass in wichtigen Teilen auch Assembler-Code drin steckt.


----------



## Olstyle (15. Februar 2010)

Da CPUs ja (noch) kein C sprechen ist wohl davon aus zu gehen dass selbst bei MS ganz unten Assembler Code steckt  .


----------



## Bauer87 (16. Februar 2010)

Man kann C ja kompilieren. Nur der erste existierende Compiler muss zwingend in einer niedrigen Programmiersprache geschrieben sein. Es ging mir darum, dass Assemblercode einfach schneller ist, wenn man ihn der Architektur der Maschine gut anpasst. (Und da Windows eh nur auf x86 läuft, ist das in dem Fall ja nicht all zu viel Arbeit.)


----------



## bingo88 (16. Februar 2010)

Also für ein OS muss man heutzutage nur den ersten Bootloader in ASM schreiben, danach kann man C oder sogar C++ nutzen. Bei den entsprechenden Bibliotheksfunktionen (z. B. memcpy) ist Assembler hingegen sinnvoll, da man die SIMD Instruktionen (z. B. SSE) nutzen kann. Wobei man sich bei heutigen Maschinen da auch nicht mehr so stark drauf konzentrieren muss, wie noch vor ein paar Jahren. Die Compiler optimieren idR schon recht brauchbar, sodass man asm auf ein Minimum reduzieren kann bzw. der Geschwindigkeitsvorteil von 3-4 ms den Aufwand kaum rechtfertigt.


----------



## Bauer87 (16. Februar 2010)

Ich meinte tatsächlich auch nur die Funktionen, die ständig (quasi dauerhaft) genutzt werden und die wirklich geschwindigkeitskritisch sind. Also tatsächlich Speicherzugriff, etc. (Wobei Windows beim Speicherzugriff im Vergleich mit anderen Systemen jetzt nicht überragend dasteht. Vielleicht ist es doch C/C++. Schließlich ist Microsoft Stabilität deutlich wichtiger als Geschwindigkeit.)


----------



## Raz3r (16. Februar 2010)

Hab hier ne gute Seite gefunden für Spieleprogrammierung.
Isogames.de

Die Unreal Engine 3 (komplett) gibts jetzt zum kostenlosen Download für alle.
Allerdings dürftest du deine Spiele nicht verkaufen, dafür brauch man eine Lizenz. Kannst es dir ja mal ansehen die Seite ist echt gut.

Dort findest du unter der Kategorie "Bücher" welche für C++ unter anderem die sich nur auf Spieleprogrammierung beziehen. 
Ein Forum um Fragen zu stellen gibts auch.

Hoffe konnte dir evtl. etwas weiter helfen.


----------



## Bauer87 (16. Februar 2010)

Die in meinen Augen beste momentan erhältliche Open-Source-Engine (GPL) ist wohl XreaL.

Da bekommt man den Code und man darf das fertige Spiel natürlich auch verkaufen.


----------



## bingo88 (16. Februar 2010)

Bauer87 schrieb:


> Ich meinte tatsächlich auch nur die Funktionen, die ständig (quasi dauerhaft) genutzt werden und die wirklich geschwindigkeitskritisch sind. Also tatsächlich Speicherzugriff, etc. (Wobei Windows beim Speicherzugriff im Vergleich mit anderen Systemen jetzt nicht überragend dasteht. Vielleicht ist es doch C/C++. Schließlich ist Microsoft Stabilität deutlich wichtiger als Geschwindigkeit.)


Da kann ich mich noch gut an die Libs aus dem VS 2002 oder 2003 erinnern, wo noch keine SIMD Instruktionen enthalten waren 
Wenn man die 800 Euronen für den Intel Compiler hinlegt, kann man auch ganz gut auf ASM verzichten - verliert aber den Nerd-Bonus


----------



## nahkillo94 (22. Februar 2010)

Was bringt eigentlich der Intel Compiler? Is doch eigentlich ein ganz normaler C++ Compiler. Korrigiert mich wenn ich mich irre!


----------



## bingo88 (22. Februar 2010)

Der Intel-Compiler optimiert den Code auf Intel-CPUs indem er diverse SIMD Befehle etc. automatisch einsetzt. Von manchen wird das Teil als "Benchmarkcompiler" beschimpft (Nicht-Intel-CPUs werden/wurden - trotz Unterstützung der enstprechenden Befehle - bei den Optimierungen z. B. nicht berücksichtigt und führten stets den langsamsten Codepfad aus). Bis jetzt konnte ich noch alles benötigte direkt in Assembler coden, da brauch ich keine 800 Euronen für das Teil auszugeben. Ich meine mich aber auch dunkel zu erinnern, dass die Performancevorteile sich eher im unteren ein- bis zweistelligen Prozentbereich befanden, je nach verwendetem Code und Benchmark. Dies jetzt aber ohne Garantie, ist schon ne Weile her, dass ich darüber mal was gelesen habe! Ich behaupte jetzt mal, für den Ottonormalprogrammierer ist es wohl overkill, der fährt mit Visual C++ (Express) oder GCC vermutlich genauso gut.


----------



## DMA (23. Februar 2010)

Ich glaub kaum, daß du den Optimierungsgrad eines Compiler erreichen kannst, besonders nicht bei recht großen Programmen.
Allein durch die SSE3 Optimierung holt man recht viel raus.

Es ist auch nicht so, daß der Compiler eine schlechtere Optimierung wählt, sondern die Library schaut nach geeignenten Optimierungen.
Und es ist nun echt nicht Intel verwerflich, daß sie eben keine AMD Optimierung bieten können, da auch falsche Optimierung ein Programmablauf stark verändern kann.
Allerdings sollten sie dann wenigstens AMD Zuganggewähren, die optimalen Optimierungen in die Library einzufügen.
Es wird aber nicht jede Optimierung weg gelaßen, aber einige wichtige fehlen doch durch aus, selbst wenn es eine Standardoptimierung ist, welche auch bei AMD Prozessoren ohne Probleme laufen würde. (Es sind trotzdem nicht alle deaktiviert)
Aber lieber mal was glauben als was wissen, ne. 

Ansonsten geb ich dir recht, ein Hobby Programmierer muss nicht unmengen an Geld nur für den Compiler ausgeben.
Für das Standardzeug reicht auch der MSVCC oder GCC.


----------



## bingo88 (23. Februar 2010)

Der Intel-Compiler checkt halt den Vendor-String der CPUID. Wenn da nicht "GenuineIntel" drinnen steht, wird nix/wenig optimiert.

Afaik ist es bei anderen Compilern idR so, dass du spezielle Instrincts nutzen musst, damit die entsprechenden SIMD-Optimierungen automatisch greifen. Ist mir zumindest noch nicht aufgefallen, dass VC++ selbst geschriebenen Code von Haus aus mit sowas überzieht (ich rede jetzt nicht von den bereits kompilierten Libs, die enthalten durchaus entsprechende Optimierungen).

Achja, ich hatte damals bei VS2003 auch in asm geschriebene Libs für memcpy etc. verwendet - und die waren schneller


----------



## DMA (23. Februar 2010)

Der Compiler checkt schonmal garnichts, der übersetzt höchstens.
Wenn dann prüfen seine Librarys und die selektieren natürlich auch aus (hab ich ja auch nicht anders behauptet).
Da wiedersprech ich dir nicht, aber selbst diese minimale Optimierung zieht den GCC ruhig ab.

Außerdem, selbst geschriebene asm codes werden dann vom optimieren ignoriert.
Somit eher nachteilig, dann lieber als Objektdatei linken.
Außerdem ist die GCC memcpy Library wirklich schnell, da kommt man mit hübschen mov's auch nicht viel schneller voran.
Vllt hattest du auch -O3 einfach vergessen? 

Und bitte nicht wieder AFAIK.


----------



## bingo88 (23. Februar 2010)

GCC nutze ich doch garnicht, habe doch von Visual Studio gesprochen o0

Naja, meine Lib war auf C ausgelegt und sie war damals schneller. Heute mach ich das meiste eh mit Inline-Assembler (was allerdings sehr selten geworden ist), sofern es sich denn überhaupt lohnt. Habe letztens mal just for fun eine Funktion zum Ändern der Lautstärke eines Sample-Puffers geschrieben, im Vergleich konnte ich mit MMX grade mal nen Speedup von 1,4 erreichen. Wobei MMX ja auch schon nen langen Bart hat 

http://img190.imageshack.us/img190/9685/mmx01a.jpg

Das wurde mit Visual Studio 2008 und Inline-Assembler erstellt. VS nutzt keine SIMD-Instruktionen (hab's mal Disassembliert), kann aber sein, dass ein moderner Prozessor die Pipeline ganz gut füllen kann...


----------



## DMA (23. Februar 2010)

Auch beim MSVCC gibt es den -O3 Parameter, hilft enorm. (Damit werden auch einige altlasten bereinigt)

Aber eben für einen Anfänger tuts Code::Blocks + GCC oder gleich MS Visual Studio genauso.
Und das beste: kost nix. 

Für einen Hobbyprogrammierer zählt Geschwndigkeit eben nicht alles, sofern man nicht arsch lahme Sprachen nimmt.

Hier ein kleiner Becnhmark überblick:
Which programming languages are fastest? | ComputerLanguageBenchmarksGame


----------



## bingo88 (23. Februar 2010)

Jo, das reicht definitv aus. Mein Erfahrung ist eh, dass der Großteil der Geschwindigkeit durch den Algorithmus kommt und nicht die Implementierung. Wenn ich nen schlechten Algo implementiere, wird's halt nicht besser 

Und in der heutigen Zeit, mit Java, C# und Konsorten, fallen ASM-Optimierungen eh flach


----------



## Bauer87 (24. Februar 2010)

Zum Intel-Compiler: Ich habe gelesen, dass der kompilierte Code auf AMD-Maschinen messbar schneller wird, wenn man den Vendor-Flag in der CPU mit „genuineintel“ überschreibt.

Aber jeder Compiler hat seine Macken: Der MS-Compiler akzeptiert ohne explizite Einbindung einige „Microsoft Extensions“ im Code, die GCC akzeptiert ebenfalls C++, das nicht dem Standard gehorcht. So erzieht man seine User quasi, dass sie nur für den eigenen Compiler schreiben. Habe sogar schon gehört, dass MS-ld (oder wie man das nennen soll) automatisch gegen Systemlibs verlinkt, die man eigentlich nicht braucht. Damit hat man dann eine erhöhte Abhängigkeit im Binärcode. (Wie gesagt: Hörensagen. Aber Code, der nur auf dem g++ oder mit MSc++ (oder wie die den nennen) kompiliert, habe ich schon häufiger gesehen. Einfach Grütze, gar nicht erst mit so nem Scheiß anfangen.)


----------



## bingo88 (27. Februar 2010)

Bauer87 schrieb:


> Zum Intel-Compiler: Ich habe gelesen, dass der kompilierte Code auf AMD-Maschinen messbar schneller wird, wenn man den Vendor-Flag in der CPU mit „genuineintel“ überschreibt.


Wie geht denn das? Ist der nicht fest in der CPU eingebrannt?


----------



## Bauer87 (27. Februar 2010)

Klar ist der da eingebrannt. Aber er wird ja von der Software nicht direkt aus der Hardware ausgelesen. Unter Linux wird sogar in einer profanen Textdatei (/proc/cpuinfo) nachgeschaut, die man ohne weiteres manipulieren kann:

```
cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 107
model name	: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+
stepping	: 2
cpu MHz		: 3100.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch
bogomips	: 6186.06
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps
```

So wird der Intel-Compiler laut Hörensagen schnelleren Code erzeugen. Diese Abfrage würde ich denen zutrauen: Macs gibt es auch erst flächendeckend in Waschmaschinenfachgeschäften, seit Intel-CPU verbaut sind. (Habe allerdings keinen Intel-Compiler die GCC ist schnell genug.)


----------



## bingo88 (27. Februar 2010)

Hmm.. ich les den Kram meist direkt mittels CPUID-Befehl aus, wenn Intel das nicht macht - ihr Pech


----------



## Bauer87 (27. Februar 2010)

Der Compiler läuft ja nicht auf Kernel-Ebene. Woher soll der denn die Info haben, wenn nicht vom Kernel? Und der Kernel schmeißt es halt in /proc/cpuinfo raus.


----------



## bingo88 (27. Februar 2010)

Ich meinte sowas in der Art:

```
void getVendorString(char *ret)
{
    __asm {
        mov eax, 0
        cpuid
        // Verarbeiten/rückgabe
    }
}
```


----------

