Eine solche Optimierung wird erst dann wirklich interessant, wenn man die gelernten Daten beliebig tauschen kann, damit bspw. große Compilerfarmen wie SF.net ihre Ergebnisse der breiten Öffentlichkeit zugänglich machen können.
Auch wenn es nicht konkret dortsteht wird wohl Ziel sein, dass in diesem Projekt Daten gesammelt werden und diese dann in den offiziellen GCC einfließen. Dazu müssen die gewonnenen Benchmarkergebnisse aber auch erstmal verstanden werden (wo liegt die KI weswegen richtig, auf welche Fälle lässt sich das übertragen, auf welche eben auch nicht) - und da dürfte noch einige Arbeit anliegen, wenn das ganze aktuell zu im Schnitt langsameren Programmen führt - auch wenn einige deutlich schneller werden.
Ich denke nicht, daß es wichtig ist zu verstehen warum die KI an einer bestimmten Stelle richtig oder falsch liegt. Ich vermute, daß die Schnittstelle ähnlich wie ein neuronales Netz einige Lernzyklen absolviert und die sich ergebenden Gewichte lediglich in einer Matrix vorliegen. In dieser Matrix steckt dann sozusagen das Wissen, welches dem Kompiler dann zugeschaltet wird.
Was, denkst Du, ist die Aufgabe des neuronalen Netzes? Die Kreuzmenge über alle Optionskombinationen zu bilden und die Güte der Ergebnisse zu bestimmen ist keine Herausforderung.
Also zu wissen, wo die KI (ist ja nur eine Heuristik) Mist baut wäre schon praktisch (und da kommst du um das Warum nicht herum), um sie entweder anzupassen oder eben bei diesen Fällen nicht zum Zuge kommen zu lassen.
von Vorteil wäre solche Kenntnisse sicherlich, ist nur die Frage, ob man bei den kurzen Entwicklungszyklen in der Halbleiterindustrie die Zeit hat, sich diese Kenntnisse zu erarbeiten. Denn es wird ja nicht so sein, daß Probleme bei jeder Kompiler/Prozessor-Version an selber Stelle auftreten. Sicherlich gibt es solche konstanten Fehler, die wird man aber kaum mit einer KI suchen.
Die Chiphersteller führen uns an der Nase herum: Sie bauen Architekturen, von denen sie behaupten, sie seien auch ohne Taktsteigerung immer optimaler und parallelisierbarer - ganz einfach, weil sie die Takte in Folge von Technologieschwierigkeiten nicht beliebig nach oben jagen können.
In Wahrheit aber verlagern sie immer mehr Problemlösungen auf die Compilerbauer, weil Programmierer mit Parallelisierung - speziell architekturabhängiger - noch mehr überfordert sind als die Compilerbauer. Dass beide nicht das nötige Know-How und die Leistungsfähigkeit zur Anpassung auf alle parallelarchitekturen haben, ist man als Hardware-Lieferant aus dem Schneider, weil man so nicht den schwarzen Peter hat. Optimieren müssen ja die anderen.
Forschung...gutes Stichwort. Nicht Entwicklung, Forschung!
Eine generische Autoparallelisierungslösung ist ja zum einen technologisch hochkomplex, weil es so viele Konstrukte gibt.
Und zum Anderen kommen dann gerade bei C bei der Auto-Optimierung Feinheiten zum Tragen, die kaum ein Programmierer kennt. Du glaubst gar nicht, wieviele Verhalten undefiniert sind, wenn man mal ein paar Variablen falsch castet.
Normal macht das nix bis wenig (außer auf Legacy-Compilern), aber wenn dann Prozessoranweisungen über kreuz hin und her verschoben werden, unter der falschen Annahme, der Pointer xy sei const, fliegt einm alles um die Ohren.
Etwas plakativ, geb' ich zu. Konsequenz: Entweder man optimiert nur abstrakte Sprachen mit transparenter Speicherverwaltung, oder man macht neue Sprachstandards für C++ & co, die ein fehlerträchtige Konstrukte entfernen und durch andere ersetzen, oder aber man hat Genies als Programmierer. Die gibt es aber so selten.
Intel entwickelt auch passende Compiler. Im Übrigen ist es richtig, Komplexität auf die Compiler auszulagern. Fehler im Compiler lassen sich leichter beheben als Fehler in der CPU. Deshalb ist auch RISC zu bevorzugen.
Alpha war _technisch_ sehr erfolgreich. Die zur Verfügung stehenden Compiler konnten die voller Performance ausnutzen!
> Und was den 'deswegen RISC' Freund angeht:
korrekt: höhere Code-Dichte von x86
Bedenklich: x86 wäre komfortabler, weil man sich über nichts Gedanken machen müsse (das heißt nur "komfortabler für den Programmierer" - denn dieses Verhalten wird durch sehr komplexe Chips erkauft. Für den Programmierer ist das durchaus komfortabel, für den Chip an sich nicht (mehr Gatter benötigt, sehr viel komplexer => Chipentwicklung deutlich teurer, mehr Abwärme des Chips, Verkaufspreis bei gleicher Fertigungszahl höher). X86 wird nur dadurch so brauchbar, dass es in so hohen Stückzahlen verkauft wird, dass die hohen Entwicklungskosten wieder eingespielt werden ohne den Preis zu sehr zu erhöhen.
(Und BTW: Itanium ist _kein_ RISC im engeren Sinne, sondern VLIW)
Trotzdem - wie weit it Mips gekommen? Alpa? Parisc? Alles so in den GHz bereich und dann verreckt, nicht wahr? Sparc doch auch.
Es ist scheißegal wie 'teuer' die Chips sind, wenn sie derartig viel verkauft werden, daß sie wieder billig werden - und billig sind x86 und amd64. Dagegen sind alpha&co unbezahlbar teuer, obwohl sie doch 'viel einfacher' in der Entwicklung und Herstellung sind ... Und wenn man sieht wie weit man die x86 Architektur reißen konnte, kann die so schlecht nicht sein.
Es ist scheißegal wie 'teuer' die Chips sind, wenn sie derartig viel verkauft werden, daß sie wieder billig werden - und billig sind x86 und amd64. Dagegen sind alpha&co unbezahlbar teuer, obwohl sie doch 'viel einfacher' in der Entwicklung und Herstellung sind ... Und wenn man sieht wie weit man die x86 Architektur reißen konnte, kann die so schlecht nicht sein. Seit i686 (Pentium Pro) sind alle x86-Prozessoren im Kern RISC-CPUs. Zusätzliche Befehle werden vom Microcode (der übrigens von GNU-Zealots gehasst wird, weil er nicht unter GPL steht) in die eigentlichen RISC-Befehle zurückübersetzt.
"Echte" RISC-CPUs hast du in fast allen elektronischen Geräten, einschließlich Smartphones, Routern, Set-Top-Boxen, Spielekonsolen. Nur handelsübliche PCs fallen da raus.
Dass Alpha und Co. im PC-Bereich keine Chance hatten, liegt nun mal daran, dass Desktops grundsätzlich IBM-PC-kompatibel sein müssen, sonst kauft sie niemand. Genau deshalb hatte AMD bei der Entwicklung von AMD64 auf bedingungslose Kompatiblität zu IA32 geachtet. Wäre dies nicht passiert, hätten wir auch heute sicher noch keine 64-Bit-CPUs in Heimanwender-Rechnern.
Von Christian Reisinger am Sa, 5. Juli 2008 um 12:57 #
Man darf auch nicht den Beitrag von Microsoft unterschätzen. Da Windows auf >= 90 % aller Desktops läuft, und Windows nur auf x86 läuft haben alle Konkurenten keine Chance. Und über die rießigen Stückzahlen konnte Intel die Nachteile von x86 leicht auf die einzelnen CPUs aufschlagen. Die Konkurenten konnten "nur" noch den Server Bereich abdecken, und da sind die Stückzahlen zu klein um auf Dauer rentabel sein.
Erstaunlich dennoch, dass dann so etwas wie Vista überhaupt auf den Markt gebracht wird, dessen neue Konzepte (sinnvollerweise) so ziemlich jedem vor 2000 geschriebenen Programm die Zusammenarbeit verweigern dürften. Es geht also interessanterweise, Umbrüche vorzunehmen, wenn auch schleppend.
Windows NT lief übrigens auf Alpha, MIPS (NT 3.5) und PowerPC (kA, welche Version genau). Windows 2000 gabs bis zur letzen Beta für Alpha, aber nicht mehr final (wurde eingestellt, nachdem die Alpha-Leute die weitere Unterstützung von Linux angekündigt hatten). Auch einen Teil von Office gabs für dies Plattform. (Wobei x86-Anwendungen relativ langsam auf diesen CPUs waren => keine echte Alternative, noch dazu gab es ja vernünftige OS von Digital/IBM/SGI für diese Systeme).
was intern abläuft ist ziemlich egal. Wenn Gnome auf den Chips bits schaufeln - egal, solange es schnell ist UND nach AUSSEN hin alles schön beim alten bleibt.
x86er sind deswegen keine RISC, weil sie mehr 'können' als jene und auch nicht wie diese programmiert werden. Was dann intern abläuft ist schnurzpiepegal.
Und noch etwas: bei Alpha gab es großartige Zeiten, wo der compiler sogar wissen mußte auf welchen MOBO die CPU sitzt und einigermaßen schnellen code zu generieren.
Bei x86ern läuft selbst 386er Code auf aktuellen CPUs flott.
Also aktuell ist die schnellste CPU (GHz) der Power von IBM. Sparc gibts auch als 2+ GHz-Version.
MIPS ist technologisch am Ende (alle weißen Flecken in der ISA sind aufgebraucht => Befehlssatz nicht mehr erweiterbar).
> [x86 = RISC im Kern]
Ja, und die Logikschaltung, um CISC -> RISC zu überführen ist genauso groß wie das Rechenwerk. Wenn darauf verzichtet würde wäre könnte man die Zahl der Kerne pro Prozessor entsprechend ohne sonstige Veränderungen verdoppeln (gut, so warten wir ein Jahr länger).
Langfristig wäre es nett, wenn man x86 sowohl mit alten x86-Befehlen als auch direkt mit seinen RISC-Befehlen füttern könnte. Das ist allerdings dahingehend problematisch, dass ein AMD-Prozessor intern ganz anders aussieht als ein Intel-Teil => Kompatibilität ginge verloren.
und nochwas, diese 'risc' opcodes sind riesig groß. Das heißt, mehr Kram muß über den sowieso schon langsamen Bus aus dem sehr langsamen Hauptspeicher geschaufelt werden - und dann auch noch die caches, die weniger Befehle halten könnten.
Soll der Chip doch dekodieren! Darin sind sie GUT. Langsam ist der Speicher und wichtig ist der Platzverbrauch im cache und da hat x86 nunmal einige Vorteile.
Von Christian Reisinger am Sa, 5. Juli 2008 um 20:03 #
Ja, und die Logikschaltung, um CISC -> RISC zu überführen ist genauso groß wie das Rechenwerk. Wenn darauf verzichtet würde wäre könnte man die Zahl der Kerne pro Prozessor entsprechend ohne sonstige Veränderungen verdoppeln (gut, so warten wir ein Jahr länger).
Genau das ist auch der Grund warum der Intel Atom nie mit einer CPU von Arm beim Stromverbrauch konkurieren können wird. Der Atom Prozessor kann HT, dazu gab es ein Statement von ARM, dass es einfacher ist einen zusätzlichen Core hinzufügen, als Hyperthreading zu unterstützen (da die einzelnen Teile von Hyperthreading + Cache eine CPU ergeben).
und es wird gemacht. Mein mp3 Player hat 2 arm cores in einem chip. Sogar meine Festplatten haben eine 'dual arm based firmware' für extra-Performance.
Da wird sich Intel vielleicht (hoffentlich) noch wundern. Wozu ht, wenn man zwei, 4,8 ECHTE cores haben kann? Bei minimalen Stromverbrauch.
Das macht Intel (ebenso AMD) heute bereits. Auch wenn ihr Hauptaugenmerk auf ihrem eigenen Compiler liegt, den sie ja verkaufen wollen, ist es auch für Intel wichtig, dass Linux und MacOS (beide werden mit GCC gebaut) auf ihrer Hardware gut laufen.
Die CPU-Entwickler sollten lieber in den GCC als in einen eigenen Compiler investieren. Diese eigenen Compiler sind doch Nischenlösungen ohne nennenswerten Einsatz. Das Potenzial der CPUs kann nur durch einen Compiler sinnvoll ausgereizt werden, der auch in der breiten Anwendung ist. Die Leistungsfähigkeit irgendwelcher Nischencompiler bringt nichts.
Zu meiner Zeit hat man Übersetzer bzw. übersetzen gesagt. Compilieren tut wirklich weh. Kompilieren lasse ich mir ja im Rahmen der zunehmenden Internationalisierung der deutschen Sprache gerade noch eingehen, aber compilieren? Come on, guys!
Ich habe schon immer Compiler und compilieren gesagt. An das neudeutsche Kompiler und kompilieren kann ich mich noch weniger gewöhnen als an Filosofie. Eine weitere befremdliche deutsche Bezeichnung ist Keller(speicher) für Stack. Die Bezeichnung Keller(speicher) benutzte unser Prof schon mitte der 90er Jahre oder auch noch früher.
Das Kellerprinzip hat Prof. Fritz Bauer, ehemals TU Muenchen, eingefuehrt. Das ist also der urspruengliche Name fuer das was *spaeter* als "Stack" bezeichnet wurde.
Bei einem solchen Namen, ist diese Einschätzung auch nicht weiter verwunderlich.
Ein Vorschlag kann, nach dem "Wiki"-Prinzip, hier abgegeben werden: http://www.deutscheinformatik.de/index.php/E-Rechnernetz
Was soll man dann erst zum Namen der "ersten universellen Programmiersprache der Welt" von 1941 sagen? Der Name den der Erfinder Konrad Zuse gegeben hatte war: "Plankalkühl"
Weiteres in der deutschsprachigen freien Enzyklopädie Wikipedia:
> Zu meiner Zeit hat man Übersetzer bzw. übersetzen gesagt.
"Deine Zeit" ist entweder schon lange her oder erst neu. Neuerdings kommen die dämlich eingedeutschten Begriffe wie Übersetzer bzw. übersetzen wieder in Mode. Bei mir heißt es immer noch Compiler bzw compilieren. Damit weiß jeder, was gemeint ist. Ich sage ja auch mounten, klicken,... Wenn jeder für etablierte Begriffe eigene/andere "deutsche" Begriffe erfindet, ist das Chaos perfekt.
Meiner Meinung nach bildet ein neuronales Netz einen mangelhaften Ansatz.
Genau genommen geht es um Optimierungen und da existieren wunderbare Ansätze, wie genetische Algorithmen, Threshold Accepting, Simulated Annealing, Evolutionsstrategien. Mit diesen lassen sich nicht nur die Compiler optimieren, sondern auch die Algorithmen, die eingesetzt werden. Ich habe genetische Algorithmen schon 2000 eingesetzt, um die Leistung von Datenbanken (damals Informix) zu optimieren. Es waren zwar nur wenige Parameter ( Threads, Prozessoren, Cachegrößen), aber es ließen sich beeindruckende Verbesserungen erzielen.
Ein künstliches neuronales Netz (KNN) erfordert aber, je nach Komplexität des Lösungsraumes, eine mehr oder weniger große Zahl von Trainingseinheiten. KNNs sind hauptsächlich ideal zur Mustererkennung, weniger zur Optimierung. Wenn ich also in einer Zeitreihe, einer Matrix, o.ä. ein Muster erkennen will, dann würde ich ein KNN einsetzen.
Der beste Compiler bleibt bei seinem Optimierungspotential gnadenlos hinter einer virtuellen Maschine (VM) zurück. Viele Informationen fallen erst beim Linken oder sogar erst zur Laufzeit an. Welche Methode eines Objektes nun wirklich ausgeführt werden muss weiß erst der Linker oder aber aber die Laufzeitumgebung. Das Objekt kann ja N-mal abgeleitet sein und damit die Methode N-mal überschrieben. Was für ein Objekt da jetzt wirklich vorliegt kann der Compiler nicht wissen. Ich bin mal gespannt ob da noch wirklich optimierungspotential in den Compilern steckt.
Gruß, LX
lg
Erik
lg
Erik
Gruß, Lars
Und echte Fehler in CPUs werden durchaus mit KI-Techniken gesucht. Verifikation ist eines der großen Forschungsgebiete der KI.
In Wahrheit aber verlagern sie immer mehr Problemlösungen auf die Compilerbauer, weil Programmierer mit Parallelisierung - speziell architekturabhängiger - noch mehr überfordert sind als die Compilerbauer. Dass beide nicht das nötige Know-How und die Leistungsfähigkeit zur Anpassung auf alle parallelarchitekturen haben, ist man als Hardware-Lieferant aus dem Schneider, weil man so nicht den schwarzen Peter hat. Optimieren müssen ja die anderen.
Eine generische Autoparallelisierungslösung ist ja zum einen technologisch hochkomplex, weil es so viele Konstrukte gibt.
Und zum Anderen kommen dann gerade bei C bei der Auto-Optimierung Feinheiten zum Tragen, die kaum ein Programmierer kennt. Du glaubst gar nicht, wieviele Verhalten undefiniert sind, wenn man mal ein paar Variablen falsch castet.
Normal macht das nix bis wenig (außer auf Legacy-Compilern), aber wenn dann Prozessoranweisungen über kreuz hin und her verschoben werden, unter der falschen Annahme, der Pointer xy sei const, fliegt einm alles um die Ohren.
Etwas plakativ, geb' ich zu. Konsequenz: Entweder man optimiert nur abstrakte Sprachen mit transparenter Speicherverwaltung, oder man macht neue Sprachstandards für C++ & co, die ein fehlerträchtige Konstrukte entfernen und durch andere ersetzen, oder aber man hat Genies als Programmierer. Die gibt es aber so selten.
Im Übrigen ist es richtig, Komplexität auf die Compiler auszulagern. Fehler im Compiler lassen sich leichter beheben als Fehler in der CPU. Deshalb ist auch RISC zu bevorzugen.
nein. Alpha und CO haben das auch gemacht. Genauso wie IA64 (und sie sind bisher alle auf die Klappe gefallen)
Und was den 'deswegen RISC' Freund angeht:
http://www.ussg.iu.edu/hypermail/linux/kernel/0302.2/1909.html
und noch ein bißchen weiterlesen.
> Und was den 'deswegen RISC' Freund angeht:
korrekt: höhere Code-Dichte von x86
Bedenklich: x86 wäre komfortabler, weil man sich über nichts Gedanken machen müsse (das heißt nur "komfortabler für den Programmierer" - denn dieses Verhalten wird durch sehr komplexe Chips erkauft. Für den Programmierer ist das durchaus komfortabel, für den Chip an sich nicht (mehr Gatter benötigt, sehr viel komplexer => Chipentwicklung deutlich teurer, mehr Abwärme des Chips, Verkaufspreis bei gleicher Fertigungszahl höher). X86 wird nur dadurch so brauchbar, dass es in so hohen Stückzahlen verkauft wird, dass die hohen Entwicklungskosten wieder eingespielt werden ohne den Preis zu sehr zu erhöhen.
(Und BTW: Itanium ist _kein_ RISC im engeren Sinne, sondern VLIW)
Trotzdem - wie weit it Mips gekommen? Alpa? Parisc? Alles so in den GHz bereich und dann verreckt, nicht wahr? Sparc doch auch.
Es ist scheißegal wie 'teuer' die Chips sind, wenn sie derartig viel verkauft werden, daß sie wieder billig werden - und billig sind x86 und amd64. Dagegen sind alpha&co unbezahlbar teuer, obwohl sie doch 'viel einfacher' in der Entwicklung und Herstellung sind ... Und wenn man sieht wie weit man die x86 Architektur reißen konnte, kann die so schlecht nicht sein.
Seit i686 (Pentium Pro) sind alle x86-Prozessoren im Kern RISC-CPUs. Zusätzliche Befehle werden vom Microcode (der übrigens von GNU-Zealots gehasst wird, weil er nicht unter GPL steht) in die eigentlichen RISC-Befehle zurückübersetzt.
"Echte" RISC-CPUs hast du in fast allen elektronischen Geräten, einschließlich Smartphones, Routern, Set-Top-Boxen, Spielekonsolen. Nur handelsübliche PCs fallen da raus.
Dass Alpha und Co. im PC-Bereich keine Chance hatten, liegt nun mal daran, dass Desktops grundsätzlich IBM-PC-kompatibel sein müssen, sonst kauft sie niemand. Genau deshalb hatte AMD bei der Entwicklung von AMD64 auf bedingungslose Kompatiblität zu IA32 geachtet. Wäre dies nicht passiert, hätten wir auch heute sicher noch keine 64-Bit-CPUs in Heimanwender-Rechnern.
lg
Erik
x86er sind deswegen keine RISC, weil sie mehr 'können' als jene und auch nicht wie diese programmiert werden. Was dann intern abläuft ist schnurzpiepegal.
Und noch etwas: bei Alpha gab es großartige Zeiten, wo der compiler sogar wissen mußte auf welchen MOBO die CPU sitzt und einigermaßen schnellen code zu generieren.
Bei x86ern läuft selbst 386er Code auf aktuellen CPUs flott.
MIPS ist technologisch am Ende (alle weißen Flecken in der ISA sind aufgebraucht => Befehlssatz nicht mehr erweiterbar).
> [x86 = RISC im Kern]
Ja, und die Logikschaltung, um CISC -> RISC zu überführen ist genauso groß wie das Rechenwerk. Wenn darauf verzichtet würde wäre könnte man die Zahl der Kerne pro Prozessor entsprechend ohne sonstige Veränderungen verdoppeln (gut, so warten wir ein Jahr länger).
Langfristig wäre es nett, wenn man x86 sowohl mit alten x86-Befehlen als auch direkt mit seinen RISC-Befehlen füttern könnte. Das ist allerdings dahingehend problematisch, dass ein AMD-Prozessor intern ganz anders aussieht als ein Intel-Teil => Kompatibilität ginge verloren.
Soll der Chip doch dekodieren! Darin sind sie GUT. Langsam ist der Speicher und wichtig ist der Platzverbrauch im cache und da hat x86 nunmal einige Vorteile.
Ja, und die Logikschaltung, um CISC -> RISC zu überführen ist genauso groß wie das Rechenwerk. Wenn darauf verzichtet würde wäre könnte man die Zahl der Kerne pro Prozessor entsprechend ohne sonstige Veränderungen verdoppeln (gut, so warten wir ein Jahr länger).
Genau das ist auch der Grund warum der Intel Atom nie mit einer CPU von Arm beim Stromverbrauch konkurieren können wird. Der Atom Prozessor kann HT, dazu gab es ein Statement von ARM, dass es einfacher ist einen zusätzlichen Core hinzufügen, als Hyperthreading zu unterstützen (da die einzelnen Teile von Hyperthreading + Cache eine CPU ergeben).
Da wird sich Intel vielleicht (hoffentlich) noch wundern. Wozu ht, wenn man zwei, 4,8 ECHTE cores haben kann? Bei minimalen Stromverbrauch.
Eine weitere befremdliche deutsche Bezeichnung ist Keller(speicher) für Stack. Die Bezeichnung Keller(speicher) benutzte unser Prof schon mitte der 90er Jahre oder auch noch früher.
Verknüpfung:
http://www.deutscheinformatik.de
M.f.G.
Also da find' ich echt Krank. :-(
Ein Vorschlag kann, nach dem "Wiki"-Prinzip, hier abgegeben werden: http://www.deutscheinformatik.de/index.php/E-Rechnernetz
Was soll man dann erst zum Namen der "ersten universellen Programmiersprache der Welt" von 1941 sagen?
Der Name den der Erfinder Konrad Zuse gegeben hatte war: "Plankalkühl"
Weiteres in der deutschsprachigen freien Enzyklopädie Wikipedia:
http://de.wikipedia.org/wiki/Plankalkül
M.f.G.
"Deine Zeit" ist entweder schon lange her oder erst neu. Neuerdings kommen die dämlich eingedeutschten Begriffe wie Übersetzer bzw. übersetzen wieder in Mode. Bei mir heißt es immer noch Compiler bzw compilieren. Damit weiß jeder, was gemeint ist. Ich sage ja auch mounten, klicken,... Wenn jeder für etablierte Begriffe eigene/andere "deutsche" Begriffe erfindet, ist das Chaos perfekt.
Genau genommen geht es um Optimierungen und da existieren wunderbare Ansätze, wie genetische Algorithmen, Threshold Accepting, Simulated Annealing, Evolutionsstrategien. Mit diesen lassen sich nicht nur die Compiler optimieren, sondern auch die Algorithmen, die eingesetzt werden. Ich habe genetische Algorithmen schon 2000 eingesetzt, um die Leistung von Datenbanken (damals Informix) zu optimieren. Es waren zwar nur wenige Parameter ( Threads, Prozessoren, Cachegrößen), aber es ließen sich beeindruckende Verbesserungen erzielen.
Ein künstliches neuronales Netz (KNN) erfordert aber, je nach Komplexität des Lösungsraumes, eine mehr oder weniger große Zahl von Trainingseinheiten. KNNs sind hauptsächlich ideal zur Mustererkennung, weniger zur Optimierung. Wenn ich also in einer Zeitreihe, einer Matrix, o.ä. ein Muster erkennen will, dann würde ich ein KNN einsetzen.