Was ist die Sprache der Zukunft? (Perfekte Programmiersprache)

[Mastermind]

Ich spiele mit dem Gedanken mir eine Programmier-Sprache anzueignen. Ich bin nicht sicher, ob das Thema hier reinpasst. Wenn nicht, dann bitte verschieben. Aber ich hab es hier reingesetzt, weil es mir auf den Ausblick der zukünftigen Technologien geht. Mir ist es halt sehr wichtig, dass ich, wenn ich schon sehr viel Zeit in sowas investiere, keine Sprache lerne, die dann nach zwei Jahren veraltet ist.

Ich habe mal ein bisschen TurboPascal und etwas C++ gelernt. Aber nichts weltbewegendes. Jetzt wollte ich mir einen kleinen Überblick verschaffen, aber hab es nicht geschafft. C++, C#, Java, .NET und dergleichen bieten sich an und ich kann überhaupt nicht einschätzen, was in einigen Jahren noch aktuell sein wird.

Mich würde vor allem interessieren, was für eine Sprache sinnvoll ist, wenn man ein Spiel entwickeln möchte und ob es eine Rolle spielt, ob man DX oder OGL bevorzugt. Und kann man jetzt schon mit DX10 anfangen? Wenn nein, lohnt es sich zu warten? Spielt es desweiteren eine Rolle bei dieser Entscheidung, ob man nur für Win oder auch für Linux und Macs entwickeln will?

Außerdem weiß ich auch nicht sicher, ob man mit einer universellen Sprache auskommt, oder beispielsweise für die KI eine extra Sprache lernen sollte. Auch Physik-Engine-Programmierung interessiert mich und auch da weiß ich nicht, ob es eine extra Sprache sein sollte. Und sollte man gleich mit der PhysX-API loslegen? Und nebenbei, braucht man heutzutage noch Wissen über ASSEMBLER?

Ich weiß, das sind viele Fragen, ich hoffe aber ihr könnt mir einen Ausblick auf die Zukunft geben und einen Rat geben womit ich anfangen sollte. Was ich noch erwähnen kann ist, dass ich nicht erstmal eine leichte und dann eine kompexe Sprache lernen will. Die erste ist nachher überflüssig und komplexe Konzepte sind kein Problem für mich, sondern eher eine Herausforderung. :smile:

[huha]

Eine perfekte Sprache gibt's nicht, da jede Sprache ihre Vor- und Nachteile hat. Wenn man mal eine kann, ist das Erlernen weiterer Sprachen allerdings nicht unbedingt schwer, insofern lohnt es sich, mit einer Sprache anzufangen, die leicht verständlich ist.

-huha

[Gast]

Wenn ich sagen könnte, was in einigen Jahren sein wird, dann würde ich nicht hier antworten, sondern in Nepal auf einem Berg sitzen und "ohmmm" singen! ;)

Aber im Ernst, zukunfssichere Sprachen sind schon C++,C# und Java (während .Net keine Programmiersprache ist, sondern ein Framework). Aber man muss auch bedenken, dass die allermeisten Codezeilen heutzutage immer noch in Cobol geschrieben sind. Guten Code schmiesst man halt nicht einfach weg und schreibt ihn in einer neuen Programmiersprache noch einmal.

Als Softwareentwickler kann ich dir nur aus meiner eigenen Erfahrung berichten. Wer einmal eine Programmiersprache beherrscht, der kann auch leicht jede andere Programmierprache erlernen. Gerade bei objektorientierten Sprachen ist der Ansatz ja immer der gleiche. Nur die Syntax unterscheidet sich zwischen den Dialekten. Oft entwickelt man diese Art von Programmen sowieso nicht in der eigentlichen Programmiersprache, sondern in Tools, wie z.B. UML.

Ich persönlich würde dir für deine genannten Zwecke C++ oder C# empfehlen. Assemblerkenntnisse können, wie alle Blicke über den Tellerrand, nie schaden. Und welche Engine oder API du letztendlich benutzt ist egal. Das wirst vermutlich eh nicht du entscheiden, sondern dein Arbeitgeber.

[Mastermind]

huha[/POST]']Eine perfekte Sprache gibt's nicht, da jede Sprache ihre Vor- und Nachteile hat. Wenn man mal eine kann, ist das Erlernen weiterer Sprachen allerdings nicht unbedingt schwer, insofern lohnt es sich, mit einer Sprache anzufangen, die leicht verständlich ist.

-huha
Naja, da ich wie gesagt schon ein bissel Erfahrung hab, wäre es in Meinen Augen nicht nötig.

Aber ich frag mal ganz frei heraus: Es wurden und werden fast alle Programme, wo es auf Performanz ankommt in C++ geschrieben. Warum wurde C# entwickelt? Wird C++ in Zukunft nicht mehr aktuell sein? In meinen Augen wäre es sinnvoll mit C++ anzufangen da man damit nahezu alles machen kann und es sehr schnell ist, allerdings würde ich mich dagegen entscheiden, wenn in Zukunft C# besser unterstützt werden wird und irgendwelche sonstigen Vorteile bietet.

[Mastermind]

Gast[/POST]']Wenn ich sagen könnte, was in einigen Jahren sein wird, dann würde ich nicht hier antworten, sondern in Nepal auf einem Berg sitzen und "ohmmm" singen! ;)

Aber im Ernst, zukunfssichere Sprachen sind schon C++,C# und Java (während .Net keine Programmiersprache ist, sondern ein Framework). Aber man muss auch bedenken, dass die allermeisten Codezeilen heutzutage immer noch in Cobol geschrieben sind. Guten Code schmiesst man halt nicht einfach weg und schreibt ihn in einer neuen Programmiersprache noch einmal.

Als Softwareentwickler kann ich dir nur aus meiner eigenen Erfahrung berichten. Wer einmal eine Programmiersprache beherrscht, der kann auch leicht jede andere Programmierprache erlernen. Gerade bei objektorientierten Sprachen ist der Ansatz ja immer der gleiche. Nur die Syntax unterscheidet sich zwischen den Dialekten. Oft entwickelt man diese Art von Programmen sowieso nicht in der eigentlichen Programmiersprache, sondern in Tools, wie z.B. UML.

Ich persönlich würde dir für deine genannten Zwecke C++ oder C# empfehlen. Assemblerkenntnisse können, wie alle Blicke über den Tellerrand, nie schaden. Und welche Engine oder API du letztendlich benutzt ist egal. Das wirst vermutlich eh nicht du entscheiden, sondern dein Arbeitgeber.
Vielen Dank für die Tipps. :smile:

Könntest du vielleicht noch kurz darauf eingehen (aus meiner Antwort auf huha):
"Es wurden und werden fast alle Programme, wo es auf Performanz ankommt in C++ geschrieben. Warum wurde C# entwickelt? Wird C++ in Zukunft nicht mehr aktuell sein? In meinen Augen wäre es sinnvoll mit C++ anzufangen da man damit nahezu alles machen kann und es sehr schnell ist, allerdings würde ich mich dagegen entscheiden, wenn in Zukunft C# besser unterstützt werden wird und irgendwelche sonstigen Vorteile bietet."

[Gast]

Mastermind[/POST]']"Es wurden und werden fast alle Programme, wo es auf Performanz ankommt in C++ geschrieben. Warum wurde C# entwickelt? Wird C++ in Zukunft nicht mehr aktuell sein? In meinen Augen wäre es sinnvoll mit C++ anzufangen da man damit nahezu alles machen kann und es sehr schnell ist, allerdings würde ich mich dagegen entscheiden, wenn in Zukunft C# besser unterstützt werden wird und irgendwelche sonstigen Vorteile bietet."Alle .Net-Sprachen, mananged C++, C# und Visual Basic erzeugen die sogenannte IL (Intermediate Language). Das Ergebnis ist also in allen drei Sprachen das gleiche. Welche du davon benutzt ist also priniziell völlig egal.

C# ist sicher eine Sprache der Zukunft. Sie ist objektorientiert, ISO-Standard, es sind viele Fallstricke aus C++ entfernt, offen und durch das Monoprojekt auch auf Linux lauffähig. Dennoch würde ich heute jemandem, der ernsthaft in die Programmierung einsteigen will empfehlen, mit C++ anzufangen. Die Gründe sind einfach die riesige Codebasis, die sicher noch viele Jahre (vermutlich Jahrzehnte) erhalten bleiben wird, die hervorragende Dokumentation, und die Tatsache, dass wenn man C++ beherrscht, leicht auf andere Sprachen wie C# umsteigen kann.

[Trap]

Lisp ist seit 50 Jahren die Sprache von der die meisten Features von neuen Sprachen kopiert werden und Nachahmung ist bekanntlich die höchste Form der Anerkennung.

http://www.paulgraham.com/quotes.html ist nett.

[Expandable]

Trap, Du scheinst ja großer Lisp-Fan zu sein?! ;)

Ansonsten ist meine persönliche (!!) Einschätzung: C++ ist sicherlich ein guter Anfang. Wenn Du C++ kannst, ist C# einfach. Wenn Du C# kannst könntest Du eventuell noch ein paar Probleme mit C++ kriegen (Pointer, es ist aber kein Problem, wenn Du Referenzen richtig verstehst). Aber da so gut wie alle Spiele in C++ geschrieben sind, lern C++.

Ob OpenGL oder D3D ist prinzipiell egal - beide können das gleiche (featuremäßig). Wenn Du plattformunabhängig sein willst, ist OpenGL die einzige Wahl (D3D ist Win-only). Heutige Spiele verwenden zumeinst D3D, also wenn Du irgendwo als Spieleprogrammierer arbeiten willst, wäre D3D die bessere Wahl. Ich persönlich würde einem Anfänger allerdings OpenGL ans Herz legen, da es IMO leichter zu erlernen ist (zumindest kam es mir so vor).

Ansonsten denke ich, dass C# Java den Rang ablaufen wird, wenn MS C# und .NET weiterhin so aggressiv pusht.

[Trap]

Ich halte es da mit Alan Kay:
Don't worry about what anybody else is going to do. The best way to predict the future is to invent it.
Wenn du hervorragende Programme entwickelst wird das anerkannt, egal welche Sprache du benutzt. Auch im Bereich Spiele, wie Jak and Dexter gezeigt hat.

[Gast]

Empfehle den Einstieg über Visual Basic (VB) (nur im MS-Umfeld) und dann überleiten auf C++. Versuche mit dem was VB bietet objektorientiert (OO) zu programmieren. Es sind Einschränkungen, weil VB nicht den vollen Funktionsumfang bietet. Gerade bei diesen Limitierungen lernst Du den OO-Ansatz am besten kennen. Diese Limitierungen sind in C++ natürlich nicht vorhanden. Es empfielt sich auch C allein zu üben. Wenn Du C drauf hast, dann ist der Einstieg in C++ deutlich einfacher.

[tokugawa]

Lern nicht eine Programmiersprache, lerne Programmieren.

Dann kommst du mit jeder Programmiersprache in kürzester Zeit zurecht.

Das ist übrigens auch das, warum man im Informatikstudium jetzt nicht wirklich "Sprachen" lernt, sondern Grundprinzipien (prozedurale, objektorientierte, logikorientiert, funktionale Programmierung), die man auf viele Sprachen umlegen kann.

Also, nur eine Sprache zu lernen, und nur die dann zu können, ist ineffizient.


Natürlich mußt du wo anfangen, und hier sind die "Lernsprachen" Java oder Pascal eh nicht so schlecht.

Trotzdem immer im Hinterkopf behalten dass man idealerweise sich nicht nur auf diese eine Programmiersprache festbeißt.

Expandable[/POST]']
Ob OpenGL oder D3D ist prinzipiell egal - beide können das gleiche (featuremäßig). Wenn Du plattformunabhängig sein willst, ist OpenGL die einzige Wahl (D3D ist Win-only).


Das hört man zwar immer wieder, aber hier muß ich entschieden dagegensprechen: in der Theorie ist OpenGL plattformunabhängig, in der Praxis nicht.

Wenn man diverse neue Features nutzen will (ich sag nur Framebuffer Objects), dann muß man unglaublich kämpfen mit Unterschieden zwischen den OpenGL-Implementationen verschiedener Plattformen, verschiedener GPU-Hersteller, usw., dass es im Prinzip wieder darauf hinausläuft, jede Plattform einzeln zu entwickeln und vor allem zu testen.

Also, zumindest die Idee "ich schreibs auf Plattform X und brauchs nur mehr für Plattform Y zu kompilieren und es läuft" ist auf jeden Fall falsch.


Mastermind[/POST]']Aber ich frag mal ganz frei heraus: Es wurden und werden fast alle Programme, wo es auf Performanz ankommt in C++ geschrieben. Warum wurde C# entwickelt? Wird C++ in Zukunft nicht mehr aktuell sein? In meinen Augen wäre es sinnvoll mit C++ anzufangen da man damit nahezu alles machen kann und es sehr schnell ist, allerdings würde ich mich dagegen entscheiden, wenn in Zukunft C# besser unterstützt werden wird und irgendwelche sonstigen Vorteile bietet.

Unperformant ist C# sicher nicht, wie einige Grafikengines in C# beweisen. Kombiniert mit einer vor allem schnellen und robusten Entwicklung, wo man auch sehr leicht zu gut wartbarem Code kommt, hat C# mit Managed DirectX zusammen einige Vorteile.

Bei allen Diskussionen darum, welche Sprache irgendwas besser kann als C++ bleibt bei C++ vor allem eines übrig: dass alle Libraries die es gibt (etwa Physikengines usw.) primär erst mal für C++ gedacht sind. Die Codebasis ist riesig. Performance von C++ ist eigentlich eher nur ein Nebenfaktor, denn Performance bieten andere Sprachen genauso.

C++ lernen ist sicher niemals verkehrt. Und da Java, C#, und Objective C sehr ähnlich sind, lernt man idealerweise eh gleich die "Familie der C-artigen Sprachen".

Aber wie gesagt: nicht Programmiersprachen lernt man, sondern Programmieren.

[HellHorse]

huha[/POST]']Wenn man mal eine kann, ist das Erlernen weiterer Sprachen allerdings nicht unbedingt schwer,
Solange es das gleiche Paradigma ist schon. Wenn du dein ganzes Leben lang imperativ programmiert hast, dann kann dich eine pur funktionale Sprache ganz schön hart ficken.

Wenn du es mir nicht glaubst, dann schreib einfach mal ein grössers Programm in Haskell.
Mastermind[/POST]']Es wurden und werden fast alle Programme, wo es auf Performanz ankommt in C++ geschrieben.
C++ dieser langsame Bloat? Schlimmstenfalls C, im besten Fall gleich Assembler.
Mastermind[/POST]']In meinen Augen wäre es sinnvoll mit C++ anzufangen da man damit nahezu alles machen kann
Sicher, dauert bloss so 10 Jahre. Standardfrage, was ist ein protected abstract virtual base pure virtual private destructor?
Wenn ich mir allerdings anschaue, wie viele C oder C++ Programme ich kenne, die noch nie anfällig für einen Pufferüberlauf waren, ist die Chance recht gross, dass du nie C oder C++ beherrschen wirst.

Und zu VB:
BASIC has become the leading cause of brain-damage in proto-hackers. This is another case (like Pascal) of the cascading lossage that happens when a language deliberately designed as an educational toy gets taken too seriously. A novice can write short BASIC programs (on the order of 10-20 lines) very easily; writing anything longer is (a) very painful, and (b) encourages bad habits that will make it harder to use more powerful languages well. This wouldn't be so bad if historical accidents hadn't made BASIC so common on low-end micros. As it is, it ruins thousands of potential wizards a year.

[tokugawa]

@HellHorse: ich hoffe das mit Assembler meintest du ironisch :)

Bei heutigen multiskalaren Prozessorarchitekturen sind die heuristischen Optimierungsalgorithmen in Compilern besser in der Lage als ein Mensch, eine optimierte Befehlsfolge für eine bestimmte CPU auszugeben.

Natürlich wird's noch Supermenschen geben, der bei handoptimiertem Assembler-Code noch ein paar Zyklen raushacken kann. Ich glaub gerade in der Demoszene hocken einige dieser mir nicht ganz geheuren Roboter-Mensch-Kreuzung.

Aber da ist der Aufwand und die dadurch gewonnene Performance meiner Meinung nach nicht mehr balanciert. Mal abgesehen vom Wartungsaufwand von purem C oder Assembler-Code.



Mist bauen kann man in jeder Sprache (siehe http://thedailywtf.com), und man kann C++ vieles ankreiden, was in anderen Sprachen besser ist. Aber C++ ist in den meisten Disziplinen zumindest nicht grottenschlecht (Prinzip "Jack of all Trades, Master of none" - frei übersetzt "kann alles, aber nichts meisterhaft"), und die immense vorhandene Codebasis bzw. die Third-Party-Library-Unterstützung machen C++ immer noch zu einer guten Wahl.

Sicher gibt es schnellere (wobei, das ist ja compiler-abhängig und nicht sprachen-abhängig, besser wartbarere, (in Hinblick auf OOP) vollständigere (Smalltalk z.B.) Sprachen, aber kaum eine andere Sprache steht im Querschnitt gesehen "recht gut bis sehr gut" in allen Aspekten da.

Funktionale, stackorientierte (Forth z.B.) oder logikorientierte Sprachen haben hingegen ihre eigene Problemdomäne und sind damit genauso "zukunftssicher".

Also, wenn man auf die Frage des Originalposters zurückkommt, muß man zurückfragen: worin stellt sich die Frage der "Zukunftssicherheit"? In Bezug darauf, wie gut der Code den man einmal erstellt hat, in Zukunft noch passende Compiler findet? Da steht C++ sicher nicht schlecht da.

[del_4901]

HellHorse[/POST]'] protected abstract virtual base pure virtual private destructor?


sowas kann es nicht geben!

[tokugawa]

AlphaTier[/POST]']sowas kann es nicht geben!

Such erst mal in Google bevor du sowas behauptest!

[HellHorse]

Trap[/POST]']Ich halte es da mit Alan Kay:
Und ich dachte jetzt kommt
the greatest single programming language ever designed
;)

[Trap]

Ne, solche Kommentare mach ich erst, wenn ich etwas erfolgreiches in Lisp entwickelt und dann für einige Millionen verkauft habe ;)

[del_4901]

tokugawa[/POST]']Such erst mal in Google bevor du sowas behauptest!
du denkst wohl ich bin total bekloppt? nenn mir doch mal ein Beispiel ... du wirst keins finden ... (zumindestens keins was sich kompellieren lässt)

[tokugawa]

AlphaTier[/POST]']du denkst wohl ich bin total bekloppt? nenn mir doch mal ein Beispiel ... du wirst keins finden ... (zumindestens keins was sich kompellieren lässt)


class x
{
// hier irgendeine abstrakte (pure virtual) Methode
};

class y : virtual protected x
{

private:
virtual ~y() = 0;

};

class z : protected y { };


(wirft in Visual Studio 2005 natürlich eine Warning aus, dass ~y() in z unzugreifbar ist, aber kompilieren lässt sich's)

[del_4901]

tokugawa[/POST]']
class x
{
};

class y : virtual protected x
{

private:
virtual ~y() = 0;

};

class z : protected y { };


(wirft in Visual Studio 2005 natürlich eine Warning aus, dass ~y() in z unzugreifbar ist, aber kompilieren lässt sich's)
vergiss es einfach, "abstract" ist in dem Zusammenhang einfach nicht zulässig

mal abgesehen von base und pure ...

[Trap]

Doch, das ist schon richtig so, man muss es nur richtig lesen:
protected abstract virtual base class, pure virtual private destructor

[tokugawa]

AlphaTier[/POST]']vergiss es einfach, "abstract" ist in dem Zusammenhang einfach nicht zulässig

mal abgesehen von base und pure ...

Glaub mir, das stimmt so :)

Bloß weil deine Aussage widerlegt wird, heißt das nicht dass plötzlich alles "nicht zulässig" ist. Gib doch einfach mal d

Im Übrigen bist du jetzt mit der Argumentation dran. Was passt an "abstract" nicht? Und an "base" und "pure"?

Erklär das mal genau, was dir nicht passt. Einfach plötzlich zu sagen "Vergiss es einfach, das ist alles eh nicht zulässig", wenn man eine Argumentation verliert, ist keine besonders gute Qualität eines Alpha-Tiers :)


Hier mal meine Erklärung:

protected abstract virtual base pure virtual private destructor


protected abstract virtual base ist mal x:

Zugegebenermaßen hab ich in meinem Codestück x nicht als abstrakte Klasse angelegt, aber das ist mal egal (man denke sich eine abstrakte Klasse x), da ich sie beim vererben in x sowieso als "virtual" deklariere. x ist also als abstract class zu sehen

Was ist eine abstrakte Klasse? Eine abstrakte Klasse ist eine Klasse mit mindestens einer abstrakten Methode. In C++ wird das auch "pure virtual class" bzw. "pure virtual method" genannt. Typischerweise bezeichnet mit "= 0" nach der Methodendeklaration.

x ist die base class von y. base trifft also auch zu. protected virtual sowieso, ist ja so notiert.

pure virtual private destructor:

Die Destruktormethode ~y() ist pure virtual, da sie mit "= 0" denotiert ist. Sie ist private, und sie ist ein Destruktor.

q.e.d. würd ich sagen :)

[del_4901]

Du willst nicht aufgeben, wa?

das abstract gehört hinter den Bezeichner und vor den Rumpf. ... ja da ist c++ Eigen ^^

Googel erstmal in der MSDN, bevor du hier sonen Fladen hinlegst.

und das schon am frühen Morgen ...

[Trap]

class x{
virtual void t()=0;
};
class y : virtual protected x {
virtual ~y() = 0;
friend class z;
};
y::~y(){};
class z : y{
virtual void t(){};};
z z;
y ist in dem Fall die Klasse mit
protected abstract virtual base class, pure virtual private destructor

[tokugawa]

AlphaTier[/POST]']Du willst nicht aufgeben, wa?

das abstract gehört hinter den Bezeichner und vor den Rumpf. ... ja da ist c++ Eigen ^^


Schauen wir uns das nochmal an:
protected abstract virtual base pure virtual private destructor

Welcher Bezeichner? Welcher Rumpf? Da kommt kein Bezeichner und kein "Rumpf" vor!

Dieses protected abstract virtual base pure virtual private destructor ist der Name für so ein Konstrukt in menschlicher Sprache, nicht C++.

"abstract" ist sowieso kein Standard-C++ Keyword. Ja, C++/CLI verwendet das Keyword, das ist aber Microsoft .NET-spezifisch und nicht Teil von ISO-C++.

In Standard C++ bedeutet "abstract" dasselbe wie "pure virtual", und zwar auf Meta-Ebene, also wenn man von abstrakten Klassen spricht, meint man Klassen die "pure virtual" sind.


Googel erstmal in der MSDN, bevor du hier sonen Fladen hinlegst.


Scheinbar bist du der, der das nicht gemacht hat. "abstract" ist kein Standard-C++-Keyword.

Du hast also immer noch nicht bewiesen warum das alles "nicht zulässig" sein soll.

Meine Güte, gib doch einfach mal zu dass du falsch liegst (das wäre ein persönliches Qualitätsmerkmal einer echten Führungspersönlichkeit, die du ja scheinbar sein willst als "Alpha-Tier").

[(del)]

tokugawa[/POST]']Bei heutigen multiskalaren Prozessorarchitekturen sind die heuristischen Optimierungsalgorithmen in Compilern besser in der Lage als ein Mensch, eine optimierte Befehlsfolge für eine bestimmte CPU auszugeben.

Natürlich wird's noch Supermenschen geben, der bei handoptimiertem Assembler-Code noch ein paar Zyklen raushacken kann. Ich glaub gerade in der Demoszene hocken einige dieser mir nicht ganz geheuren Roboter-Mensch-Kreuzung.

Aber da ist der Aufwand und die dadurch gewonnene Performance meiner Meinung nach nicht mehr balanciert. Mal abgesehen vom Wartungsaufwand von purem C oder Assembler-Code
Auch Compiler werden nur von Menschen hergestellt. Wenn man wirklich Ahnung hat und sich ein 'Assemblat' zum Durchgucken ausgeben läßt, dann kann das gelegentlich schon für ein "WTF?!" sorgen ;)

Im Großen&Ganzen hast Du aber natürlich Recht. Auch wenn es sich gelegentlich extrem lohnt bzw. lohnen würde paar 'leistungsrelevante' Schleifen in 10-100KB handoptimiertem Assembler hinzuklatschen.

An sich müßte man meinen, mit der weit fortgeschrittenen Komputerunterstützung der Entwicklung der Compiler wäre man seit einiger Zeit auf der sicheren Seite, aber Patzer passieren nach wie vor immer und überall. Nur ein kleines Beispiel von vielen http://www.codeproject.com/cpp/improved2005crt.asp

[tokugawa]

BessereHälfte[/POST]']Auch Compiler werden nur von Menschen hergestellt.


Die Herstellungsverfahren, bzw. Algorithmen sind aber gut bekannt (Recursive Descent Parser, Attributierte Grammtiken, LL(1) bzw. LR(1)-Parser, tabellengestützte Top-Down-Analyse, oder Bottom-Up-Analyse, List-Scheduling-Befehlsreihenfolgen-Selektion, usw.), und die Güte der Optimierten Befehlsauswahl-Algorithmen ist auch bekannt. Basiert ja alles auf Theoretischer Informatik.

Außerdem gibt's ja Compiler-Generatoren.

BessereHälfte[/POST]']
Wenn man wirklich Ahnung hat und sich ein 'Assemblat' zum Durchgucken ausgeben läßt, dann kann das gelegentlich schon für ein "WTF?!" sorgen ;)
[/url]

Klar, eine optimierte Befehlsfolge muß (dank Pipelining/Multiskalarer Architektur) nicht mehr dem logischen Ablauf entsprechen. Das kann schon sehr verwirrend sein, deswegen mein ich ja, dass ein Compiler sich nicht beirren lässt durch die semantische Ebene - wenn man Befehle anders anordnen kann, tut er's auch.

BessereHälfte[/POST]']
Im Großen&Ganzen hast Du aber natürlich Recht. Auch wenn es sich gelegentlich extrem lohnt bzw. lohnen würde paar 'leistungsrelevante' Schleifen in 10-100KB handoptimiertem Assembler hinzuklatschen.
[/url]

Klar, klassischer Profiling-Fall: Optimiere den häufigsten Fall.

BessereHälfte[/POST]']
An sich müßte man meinen, mit der weit fortgeschrittenen Komputerunterstützung der Entwicklung der Compiler wäre man seit einiger Zeit auf der sicheren Seite, aber Patzer passieren nach wie vor immer und überall. Nur ein kleines Beispiel von vielen http://www.codeproject.com/cpp/improved2005crt.asp

Ja, klar. Nur muß man hier sagen, hier wurde halt eine einzelne Funktion gebencht. In einer Applikation würde so ein Unterschied in der Gesamtperformance dann gar nicht so groß ausfallen, wenn diese Funktion nur wenige % Ausführungswahrscheinlichkeit besitzt, oder vielleicht durch andere Dinge "versteckt" wird.

Ein Beispiel dafür wären ja C#-Grafikengines. C# mag vielleicht in Einzelfunktionen gemessen langsamer sein (auch nicht unbedingt, aber möglich), aber im Zusammenspiel in einer Grafik-Engine werden die Performance-Nachteile sicher oft versteckt durch das parallele Zusammenspiel mit der GPU. Dasselbe kann eben bei C++ auch passieren - dass ein handoptimierter Assembler-Teil vielleicht an sich 10-mal schneller ist, aber letztendlich in der echten Applikation überhaupt keine Zusatzperformance bringt.

Es ging mir in meinem Posting auch nicht nur um Performance an sich, sondern auch um Wartbarkeit. Der relativ geringe Performance-Vorteil in der Praxis, plus die schwerere Wartbarkeit (Wiederverwendbarkeit, Portabilität, usw.) sprechen eigentlich dagegen, zu früh Teile eines Programms handzuoptimieren. Zumindest sollte man diese Teile eines Programms nicht nur in Assembler vorliegen haben, sondern etwa über ein #ifdef zuschaltbar, sodass man über den Buildprozeß bestimmen kann ob diese Hand-Optimierung greift oder nicht.

[(del)]

tokugawa[/POST]']
Klar, eine optimierte Befehlsfolge muß (dank Pipelining/Multiskalarer Architektur) nicht mehr dem logischen Ablauf entsprechen. Das kann schon sehr verwirrend sein, deswegen mein ich ja, dass ein Compiler sich nicht beirren lässt durch die semantische Ebene - wenn man Befehle anders anordnen kann, tut er's auch
Ja sicher. WENN man aber Kenne hat, kann man das nach eigener Meinung mal umschmeißen und gucken wer Recht hat. Mensch oder Compiler. Daher halte ich Demo-Coder nicht gleich für Roboter-Menschen ;) Auch zB. die 3rd part builder die in einem sehr überschaubarem Masse mit Asm am Firefox drehen. Im Vergleich zum originalen Firefox erlebt man hier oft einen deutlichen Leistungszuwachs.

Ja, klar. Nur muß man hier sagen, hier wurde halt eine einzelne Funktion gebencht. In einer Applikation würde so ein Unterschied in der Gesamtperformance dann gar nicht so groß ausfallen, wenn diese Funktion nur wenige % Ausführungswahrscheinlichkeit besitzt, oder vielleicht durch andere Dinge "versteckt" wird
Dann würde sich die Frage stellen, ob man den richtigen Teil des Kodes optimierte ;) Der Artikel ergab sich aus dieser Diskussion klick (http://groups.google.de/group/microsoft.public.de.vc/tree/browse_frm/thread/0b839b6cf81a8dc1/bdacd7e0f2bf6698)
Ich finde es halt sehr lobenswert, wenn man in der Lage ist die Ergebnise wenigstens brauchbar zu verifizieren. Asm hin oder her. Letztendlich ergibt sich die allgemeine Steigerung der Compiler aus der Menge der Detailverbesserungen. Imho sollte man keine einzige Funktion opfern wollen, nur weil das Gesamtergebnis besser ist. Ich halte das für einen der Grundsätze. Für Leute die Anwendungen programmieren wie auch für die, welche die Werkzeuge dazu liefern. Daher find ich CCPUticker&Co genauso stark wie Solaris samt DTrace.

Es ging mir in meinem Posting auch nicht nur um Performance an sich, sondern auch um Wartbarkeit
Ich glaub die oft erwähnte Müh mit der Wartbarkeit hängt direkt damit zusammen wieviel man handoptimiert. Und ob eine handoptimierte Schleife dauernd gewartet werden muß oder in anderen Projekten Verwendung findet.

Ich find aber das wird hier alles insgesamt langsam extrem OT. Bis dann mal :D

[Trap]

tokugawa[/POST]']Die Herstellungsverfahren, bzw. Algorithmen sind aber gut bekannt (Recursive Descent Parser, Attributierte Grammtiken, LL(1) bzw. LR(1)-Parser, tabellengestützte Top-Down-Analyse, oder Bottom-Up-Analyse, List-Scheduling-Befehlsreihenfolgen-Selektion, usw.), und die Güte der Optimierten Befehlsauswahl-Algorithmen ist auch bekannt. Basiert ja alles auf Theoretischer Informatik.
Wie so vieles was mit Optimierung zu tun hat ist auch die Optimierung im Compilerbau in vielen Teilproblemen NP-schwer oder sogar nicht entscheidbar.

Daher gibt es für (Performance-)Optimierung keine optimalen Algorithmen (kann man mit Satz von Rice einfach beweisen) sondern nur immer bessere, zumindest solange Leute daran arbeiten bessere Algorithmen zu finden.

[tokugawa]

Trap[/POST]']Wie so vieles was mit Optimierung zu tun hat ist auch die Optimierung im Compilerbau in vielen Teilproblemen NP-schwer oder sogar nicht entscheidbar.

Daher gibt es für (Performance-)Optimierung keine optimalen Algorithmen (kann man mit Satz von Rice einfach beweisen) sondern nur immer bessere, zumindest solange Leute daran arbeiten bessere Algorithmen zu finden.

Deswegen schrieb ich ja nicht "bekannte optimale Algorithmen", sondern "Güte". Die Güte einer Heuristik lässt sich nämlich durchaus bestimmen in der Algorithmik, bzw. ist die "Gütegarantie" quasi ein Vergleichsmerkmal von Heuristiken.

Dass es immer bessere geben wird, ist klar und gut so.

Wir werden aber echt immer mehr OT.

@BessereHälfte: stimme dir absolut zu - man muß halt im Prinzip die richtigen Stellen optimieren, und auch nicht nur reine Zyklenschinderei, sondern auch algorithmisch.