CPU Fehler: AMD & Intel Compileroptimierung
- Ersteller ansley
- Erstellt am
Ach Leute….
Egal was man heute kauft, es ist nie 100%ig fertig. Selbst ein Auto nicht! Wie viele Kunden bekommen nichts mit, wenn mal schnell hier und da eine neue Firmware auf das eine oder andere Steuergerät programmiert wird, wenn es mal wieder Service ansteht. Erst letzte Woche wurde in meinem Auto VW Golf 5 das Tachoinstrument komplett ausgetauscht, da das Gerät ein Softwarefehler enthielt und es nicht umprogrammiert werden konnte. Man bemerke „deutsche Qualität“! Alles super toll getestet!!! Aber ich sage nicht „Müll“ dazu, denn nur wer nichts tut macht auch keine Fehler.
Es wird einfach vieles zu kompliziert und Fehleranfälliger, da nicht alles bei der Auslieferung getestet werden kann. Wenn zu es zu lange dauert, dann wird man von Konkurrenz überrumpelt. Daher wird in Kauf genommen, Patches nachzuliefern, denn Kaufpreis ist bei vielen Käufern entscheidend, weniger die Qualität, bzw. wenige sind bereit mehr auszugeben. Ich denke jeder sieht es genauso, dass es so ist. Natürlich würde ich gerne Qualität haben, würde auch mal 5Euronen oder mehr auszugeben, aber dann geht’s wirklich ins Geld, dann muss ich schon 1000mal überlegen.
@thunderbird
Stalker ist nicht mein Lieblingsspiel!
Stell dir nur vor, da du ja ein Maschinenbauer bist, du hast an einem Motor gearbeitet und zur Serienreife gebracht. Jetzt kommt einer Daher und sagt „Müll“ dazu. Nur weil der Motor nicht mit Normal-Benzin läuft, obwohl der für Super konzipiert wurde. Wie würdest du darauf reagieren?!
Selbst solche Firmen wie Adobe lassen ihre alten Produkte fallen und bringen extra Software für VISTA raus, obwohl Adobe ein kleines Vermögen verlangen. Dann frag ich dich „Was erwartest du bitteschön von einem Spiel für 45€?“
Nun zu Intel…
Dann fange ich mal mit Compilern an. Für das erstellen einer Sofware existieren unterschiedliche Compiler, die immer auf Intel-Architektur (PC-Basis) ausgelegt sind. Das soll heißen, dass einige Codeabfolgen so optimiert werden können, dass diese eben schnell auf Intel ablaufen. AMD kann dagegen diese nicht richtig ausführen, mal angenommen zum Verdeutlichen, weil Prozessor bei dieser Abfolge falsche Berechnungen ausführt und z.B. zum Abstürzen bringen (wers nicht glaubt, bitte Prozessorarchitekturen und Codetraps genau beachten). Zu der Entwicklungszeit wird alles auf Intel getestet und auf den Markt gebracht. Nun, der beschriebene Fehler kann vielleicht garnie auf einer AMD-Maschine auftreten, weil bestimmte Konfiguration nicth gegeben ist, dagegen bei einer anderen Maschine tritt es immer wieder auf. An dieser Stelle muss also der Fehler analysiert und behoben werden, das wird dann auf BIOS-Ebene gelöst oder Softwareupdate und muss dann noch an den Kunden gebracht werden. Während dessen toben einige Kunden und verlauten „Müll“.
Ein weiterer Faktor ist, der verbaute Chipsatz, dieser ist in gewissermaßen ein Prozessor selbst und führt Anweisungen von Haupt-CPU aus. Hat der einen Fehler bei bestimmten Instruktionen, führt das unweigerlich auch auf Fehlfunktionen in der Software. Deswegen für die beste Kompatibilität ist INTEL das Nonplusultra. Wenn man INTEL hat, schließt das Denkfehler in der Software nie aus, aber die Gefahr, dass aufgrund eines Hardwarefehlers Software nicht richtig funktioniert ist minimal.
Viele haben wohl vergessen, wie schwer AMD am Anfang hatte, als Chipsätze Fehler enthielten, CPU einige Instruktionen falsch ausführte, und somit Software nicht richtig funktionierte usw. Jetzt ist es natürlich besser geworden, aber die Wahrscheinlichkeit ist immer noch da
Ich denke somit alle Fragen bezüglich INTEL geklärt zu haben.
Und bin ich immer noch disqualifiziert?
Egal was man heute kauft, es ist nie 100%ig fertig. Selbst ein Auto nicht! Wie viele Kunden bekommen nichts mit, wenn mal schnell hier und da eine neue Firmware auf das eine oder andere Steuergerät programmiert wird, wenn es mal wieder Service ansteht. Erst letzte Woche wurde in meinem Auto VW Golf 5 das Tachoinstrument komplett ausgetauscht, da das Gerät ein Softwarefehler enthielt und es nicht umprogrammiert werden konnte. Man bemerke „deutsche Qualität“! Alles super toll getestet!!! Aber ich sage nicht „Müll“ dazu, denn nur wer nichts tut macht auch keine Fehler.
Es wird einfach vieles zu kompliziert und Fehleranfälliger, da nicht alles bei der Auslieferung getestet werden kann. Wenn zu es zu lange dauert, dann wird man von Konkurrenz überrumpelt. Daher wird in Kauf genommen, Patches nachzuliefern, denn Kaufpreis ist bei vielen Käufern entscheidend, weniger die Qualität, bzw. wenige sind bereit mehr auszugeben. Ich denke jeder sieht es genauso, dass es so ist. Natürlich würde ich gerne Qualität haben, würde auch mal 5Euronen oder mehr auszugeben, aber dann geht’s wirklich ins Geld, dann muss ich schon 1000mal überlegen.
@thunderbird
Stalker ist nicht mein Lieblingsspiel!
Stell dir nur vor, da du ja ein Maschinenbauer bist, du hast an einem Motor gearbeitet und zur Serienreife gebracht. Jetzt kommt einer Daher und sagt „Müll“ dazu. Nur weil der Motor nicht mit Normal-Benzin läuft, obwohl der für Super konzipiert wurde. Wie würdest du darauf reagieren?!
Selbst solche Firmen wie Adobe lassen ihre alten Produkte fallen und bringen extra Software für VISTA raus, obwohl Adobe ein kleines Vermögen verlangen. Dann frag ich dich „Was erwartest du bitteschön von einem Spiel für 45€?“
Nun zu Intel…
Dann fange ich mal mit Compilern an. Für das erstellen einer Sofware existieren unterschiedliche Compiler, die immer auf Intel-Architektur (PC-Basis) ausgelegt sind. Das soll heißen, dass einige Codeabfolgen so optimiert werden können, dass diese eben schnell auf Intel ablaufen. AMD kann dagegen diese nicht richtig ausführen, mal angenommen zum Verdeutlichen, weil Prozessor bei dieser Abfolge falsche Berechnungen ausführt und z.B. zum Abstürzen bringen (wers nicht glaubt, bitte Prozessorarchitekturen und Codetraps genau beachten). Zu der Entwicklungszeit wird alles auf Intel getestet und auf den Markt gebracht. Nun, der beschriebene Fehler kann vielleicht garnie auf einer AMD-Maschine auftreten, weil bestimmte Konfiguration nicth gegeben ist, dagegen bei einer anderen Maschine tritt es immer wieder auf. An dieser Stelle muss also der Fehler analysiert und behoben werden, das wird dann auf BIOS-Ebene gelöst oder Softwareupdate und muss dann noch an den Kunden gebracht werden. Während dessen toben einige Kunden und verlauten „Müll“.
Ein weiterer Faktor ist, der verbaute Chipsatz, dieser ist in gewissermaßen ein Prozessor selbst und führt Anweisungen von Haupt-CPU aus. Hat der einen Fehler bei bestimmten Instruktionen, führt das unweigerlich auch auf Fehlfunktionen in der Software. Deswegen für die beste Kompatibilität ist INTEL das Nonplusultra. Wenn man INTEL hat, schließt das Denkfehler in der Software nie aus, aber die Gefahr, dass aufgrund eines Hardwarefehlers Software nicht richtig funktioniert ist minimal.
Viele haben wohl vergessen, wie schwer AMD am Anfang hatte, als Chipsätze Fehler enthielten, CPU einige Instruktionen falsch ausführte, und somit Software nicht richtig funktionierte usw. Jetzt ist es natürlich besser geworden, aber die Wahrscheinlichkeit ist immer noch da
Ich denke somit alle Fragen bezüglich INTEL geklärt zu haben.
Und bin ich immer noch disqualifiziert?
Ähh wie soll eine auf Intel optimierte Software einen "Hardwarefehler" z.b beim Mobo Chip umgehen?
Gut OK das mit der auf INTEL optmierten Software lasse ich mal bedingt gelten. Da gib es immer wieder, aber auch immer seltener Ausrutscher.
Oder aber, umgekehrt, wie soll eine auf INTEL optmierte Software eine Hardwarefehler ausgleichen.
Software funzt oder sie funzt nicht. Hardware ist voll funktionstüchtig oder kaputt! BASTA!
Aber da von Intel auf AMD zu schliessen und umgekehrt halte ich schon für etwas abenteuerlich!
![[P3D] Crazy_Chris](/data/avatars/m/0/429.jpg?1596828194){kind=avatar}
[P3D] Crazy_Chris
Grand Admiral Special
"auf Intel optimiert" bedeutet aber nicht das dieser Code nur fehlerfrei auf Intel CPUs läuft. Die Compiler setzen eine Hochsprache in x86 konformen Maschinencode um der auf allen 100% x86 + Erweiterungen wie SSE usw. ausgeführt werden kann.
Das dieser Code einer AMD CPU Architekturbedingt nicht schmeckt kann schon sein aber trotzdem läuft dieser Code fehlerfrei darauf! Alles andere wäre auch purer Wahnsinn und würde in einer "Windows XP Intel Core 2 Edition" usw. enden die dann auch nur auf diesem Prozessortyp läuft.
Entweder ist die Software 100% x86 kompatibel oder sie ist es nicht.
Außerdem einigt man sich immer auf den kleinsten Nenner um bestimmte CPU Typen nicht außen vor zu lassen. Inzwischen ist es ja noch so das bei fast allen Programmen SSE2 immernoch optional ist. Pentium III, Athlon XP sind zwar schon seit Jahren veraltet aber diese bieten eben nur SSE1.
Das dieser Code einer AMD CPU Architekturbedingt nicht schmeckt kann schon sein aber trotzdem läuft dieser Code fehlerfrei darauf! Alles andere wäre auch purer Wahnsinn und würde in einer "Windows XP Intel Core 2 Edition" usw. enden die dann auch nur auf diesem Prozessortyp läuft.
Entweder ist die Software 100% x86 kompatibel oder sie ist es nicht.
Außerdem einigt man sich immer auf den kleinsten Nenner um bestimmte CPU Typen nicht außen vor zu lassen. Inzwischen ist es ja noch so das bei fast allen Programmen SSE2 immernoch optional ist. Pentium III, Athlon XP sind zwar schon seit Jahren veraltet aber diese bieten eben nur SSE1.
Zuletzt bearbeitet:
@Michl
Nein.. Hardwarefehler ist nicht gleich Rauchzeichen
Mit Hardwarefehler meinte ich… Fehlfunktion(en) unter bestimmten Voraussetzungen.
So als Beispiel… also sehr sehr grob
CPU von einer Firma IMuio:
2+2=4 -> Berechnung richtig
CPU von einer Firma AMuio:
2+2=3 -> Berechung falsch
-> Hardwarefehler, da Berechnung falsch.
Da die modernen Prozessoren codetraps können, d.h. es tritt ein Interrupt auf, wenn bestimmte Codebefehle erkannt werden, durch bestimmte Codesequenzen wird dieser Rechenfehler wieder behoben.
CPU von einer Firma AMuio:
Interne Prüfung der Mnemonics (Assemblerbefehle)
2+2 -> Interrupt, ins BIOS umgeleitet
1+3 = 4 Berechung richtig, da anderer Code, verlasse BIOS und wieder mit der Ausführung weiter
Ich hoffe das war jetzt gut verständlich
Nach dem gleichen Prinzip arbeitet auch Intel ... Intel CPUs haben auch "Fehler" Nur eben weil alles auf Intel zugeschnitten wird (entwickelt), werden Fehler von AMD nicht immer bedacht/berücksichtigt.
Nein.. Hardwarefehler ist nicht gleich Rauchzeichen
Mit Hardwarefehler meinte ich… Fehlfunktion(en) unter bestimmten Voraussetzungen.
So als Beispiel… also sehr sehr grob
CPU von einer Firma IMuio:
2+2=4 -> Berechnung richtig
CPU von einer Firma AMuio:
2+2=3 -> Berechung falsch
-> Hardwarefehler, da Berechnung falsch.
Da die modernen Prozessoren codetraps können, d.h. es tritt ein Interrupt auf, wenn bestimmte Codebefehle erkannt werden, durch bestimmte Codesequenzen wird dieser Rechenfehler wieder behoben.
CPU von einer Firma AMuio:
Interne Prüfung der Mnemonics (Assemblerbefehle)
2+2 -> Interrupt, ins BIOS umgeleitet
1+3 = 4 Berechung richtig, da anderer Code, verlasse BIOS und wieder mit der Ausführung weiter
Ich hoffe das war jetzt gut verständlich
Nach dem gleichen Prinzip arbeitet auch Intel ... Intel CPUs haben auch "Fehler" Nur eben weil alles auf Intel zugeschnitten wird (entwickelt), werden Fehler von AMD nicht immer bedacht/berücksichtigt.
Zuletzt bearbeitet:
Thunderbird 1400
Grand Admiral Special
Also ich habe mit Informatik ja nichts am Hut, aber ich denke mal diese Zeiten, in denen AMD-Systeme als weniger stabil als Intel-Systeme galten, sind lange vorbei. Darüber gibt es keine aussagekräftigen Statistiken, dass Spiele oder andere Anwendungen auf AMD-Systemen häufiger zu Instabilitäten führen, als auf Intel-Systemen.
Trotzdem ist es ein Unterschied, ob in einem Auto aus Kostengründen bewusst Teile niedriger Qualität verbaut werden, die bei normaler Beanspruchung die Sicherheit nicht gefährden (die Motoren zum Verstellen der Seitenspiegel haben z. B. eine Nutzungsdauer von irgendwas um die 30 Minuten oder so), oder ob ein Spiel mit offensichtlichen, schwerwiegenden Bugs auf den Markt gelassen wird, um schnell Kohle zu kassieren, "der dumme Kunde kauft's ja auch unfertig und macht uns den Betatester". Denn in letzterem Fall wird die Leistung des Herstellers, ein funktionierendes Produkt zu liefern, nicht erbracht. Manche Spiele kommen derart unfertig auf den Markt...das wäre wie ein Auto, dass nur bei Temperaturen zwischen 20 und 25°C fährt.
Gut, das Urteil "Müll" mag bei Stalker etwas übertrieben sein, aber auch nur, weil es vom Hersteller nicht offiziell für Vista freigegeben ist (wahrscheinlich arbeiten die unter Hochdruck daran, die ganzen Bugs auszubessern, damit das Teil auch unter Vista zufriedenstellend läuft, denn ein neues Spiel, dass unter dem neuen MS OS nicht läuft, lebt nicht lange). Da frage ich mich nur, warum die meisten alten Spiele, und erst recht der Großteil der neuen, problemlos unter Vista laufen.
Wir hatten mal einen neuen Polo auf dem Prüfstand, bei dem haben wir in 5(!) Minuten die Batterie komplett leergelutscht (mit allen Verbrauchern an). Aus Kostengründen wird halt immer wieder "Müll" eingebaut (die Batterie), aber natürlich ist deswegen nicht das ganze Auto Müll.
Trotzdem ist es ein Unterschied, ob in einem Auto aus Kostengründen bewusst Teile niedriger Qualität verbaut werden, die bei normaler Beanspruchung die Sicherheit nicht gefährden (die Motoren zum Verstellen der Seitenspiegel haben z. B. eine Nutzungsdauer von irgendwas um die 30 Minuten oder so), oder ob ein Spiel mit offensichtlichen, schwerwiegenden Bugs auf den Markt gelassen wird, um schnell Kohle zu kassieren, "der dumme Kunde kauft's ja auch unfertig und macht uns den Betatester". Denn in letzterem Fall wird die Leistung des Herstellers, ein funktionierendes Produkt zu liefern, nicht erbracht. Manche Spiele kommen derart unfertig auf den Markt...das wäre wie ein Auto, dass nur bei Temperaturen zwischen 20 und 25°C fährt.
Gut, das Urteil "Müll" mag bei Stalker etwas übertrieben sein, aber auch nur, weil es vom Hersteller nicht offiziell für Vista freigegeben ist (wahrscheinlich arbeiten die unter Hochdruck daran, die ganzen Bugs auszubessern, damit das Teil auch unter Vista zufriedenstellend läuft, denn ein neues Spiel, dass unter dem neuen MS OS nicht läuft, lebt nicht lange). Da frage ich mich nur, warum die meisten alten Spiele, und erst recht der Großteil der neuen, problemlos unter Vista laufen.
Zuletzt bearbeitet:
Devastators
Grand Admiral Special
ach, das erwähnst Du jetzt?
btw. ich kann mir nur mehr schlecht als Recht vorstellen, dass AMD und INtel im x86 Design nicht zueinander 100% Kompatibel sind.
Performance-Unterschiede sind natürlich Design-Mässig entstanden, aber so wie ich Dich verstehe kann man unter einem normalen "x86" Kompiler ein Programm schreiben, dass nur und ausschliesslich auf Intel läuft
Deine Motorentwicklung und vor allem die anschliessende Serienproduktion ist in keiner Weise mit einer Software zu vergleichen.
bei Software gibt es keine Serienstreuung, alles ist exakt vorgegeben. Wenn es ausgiebig getestet wurde können keine Flächendeckenden Fehler mehr auftreten.
Beim Auto wird vom Anfang an der Rotstift angesetzt und schwankungen in der Produktion können ebenfalls noch deutlich auftauchen.
Was also dort an Fehlern auftaucht ist in Kauf genommen.
Zuletzt bearbeitet:
@Devastators
Du hast mich missverstanden
AMD und INTEL haben denselben Befehlssatz x86, sie haben bloß bei diesen 3Dnow und SSE Unterschiede und sie haben unterschiedliche Architektur, also internen Aufbau von Schaltkreisen.
Stell dir ein Auto vor. Der Motor ist in diesem Fall der Prozessor. Karosserie ist Eben ein PC mit RAM,Graka,Platten usw.
So.. wie bekommt man aus einem Motor mehr Leistung? Z.B. Motoröl, Zündkerzen, Chiptuning, das sind diese Faktoren die von Compilern vorgenommen werden.
Jetzt wurde der Intelmotor voll getunt, um einige Prozent rauszuholen, d.h. es wurden Tests gefahren um Schwachstellen und Stärken zu finden. Soweit es möglich ist, werden Schwachstellen möglichst behoben.
Jetzt kommt einer drauf… hmm.. es gibt ja auch noch AMD-Motoren.. den bau ich gleich ein. Da der Motor ja dieselbe Funktion ausübt, aber der Rest, Motoröl, Zündkerzen und Chiptunig eigentlich für ihn nicht vorgesehen sind. So kann es zu Ausfällen führen.
Z.B. Optimierungen werden sehr oft bei Treibern verwendet, aber auch beim Betriebssystem selber, da hier jede Stärke ausgenutzt werden muss, um nicht zu viel Perfomance zu verlieren.
Mal angenommen..
Intel führt diese Berechnung sehr schnell aus.
1+3 = 4
Aber diese sehr langsam
2+2 = 4
Und bei dieser rechnet er falsch
3+1 = 3
Jetzt AMD
Diese führt er schnell aus
3+1 = 4
Diese sehr langsam
2 + 2 = 4
Und diese rechnet er falsch aus
1 + 3 = 3
So dann nun eine Optimierung für Intel vorgenommen wurde, lautet der Befehl nach kompilieren so aus
1+3 = 4 da sehr schnell bei Intel…
Jetzt die Frage aller Fragen, was macht dann AMD, wenn dieser Befehl kommt?
Viele Programme, vor paar Jahren hatten spezielle DLLs für 386 / 486 / P3 / P4 Prozessoren.
Daher kommt auch die bessere Kompatibilität zu Intel bei diesen Programmen…. Heute ist es natürlich etwas anders, da CPUs bereits im GHz-Bereich arbeiten und müssen dann somit langsame Berechnungen durchführen. Gegenbenfalls sind ja auch noch SSE –Befehle für die Beschleunigung da.
Ich hoffe damit das Kapitel für immer zu schließen.
Du hast mich missverstanden
AMD und INTEL haben denselben Befehlssatz x86, sie haben bloß bei diesen 3Dnow und SSE Unterschiede und sie haben unterschiedliche Architektur, also internen Aufbau von Schaltkreisen.
Stell dir ein Auto vor. Der Motor ist in diesem Fall der Prozessor. Karosserie ist Eben ein PC mit RAM,Graka,Platten usw.
So.. wie bekommt man aus einem Motor mehr Leistung? Z.B. Motoröl, Zündkerzen, Chiptuning, das sind diese Faktoren die von Compilern vorgenommen werden.
Jetzt wurde der Intelmotor voll getunt, um einige Prozent rauszuholen, d.h. es wurden Tests gefahren um Schwachstellen und Stärken zu finden. Soweit es möglich ist, werden Schwachstellen möglichst behoben.
Jetzt kommt einer drauf… hmm.. es gibt ja auch noch AMD-Motoren.. den bau ich gleich ein. Da der Motor ja dieselbe Funktion ausübt, aber der Rest, Motoröl, Zündkerzen und Chiptunig eigentlich für ihn nicht vorgesehen sind. So kann es zu Ausfällen führen.
Z.B. Optimierungen werden sehr oft bei Treibern verwendet, aber auch beim Betriebssystem selber, da hier jede Stärke ausgenutzt werden muss, um nicht zu viel Perfomance zu verlieren.
Mal angenommen..
Intel führt diese Berechnung sehr schnell aus.
1+3 = 4
Aber diese sehr langsam
2+2 = 4
Und bei dieser rechnet er falsch
3+1 = 3
Jetzt AMD
Diese führt er schnell aus
3+1 = 4
Diese sehr langsam
2 + 2 = 4
Und diese rechnet er falsch aus
1 + 3 = 3
So dann nun eine Optimierung für Intel vorgenommen wurde, lautet der Befehl nach kompilieren so aus
1+3 = 4 da sehr schnell bei Intel…
Jetzt die Frage aller Fragen, was macht dann AMD, wenn dieser Befehl kommt?
Viele Programme, vor paar Jahren hatten spezielle DLLs für 386 / 486 / P3 / P4 Prozessoren.
Daher kommt auch die bessere Kompatibilität zu Intel bei diesen Programmen…. Heute ist es natürlich etwas anders, da CPUs bereits im GHz-Bereich arbeiten und müssen dann somit langsame Berechnungen durchführen. Gegenbenfalls sind ja auch noch SSE –Befehle für die Beschleunigung da.
Ich hoffe damit das Kapitel für immer zu schließen.
Devastators
Grand Admiral Special
ne, noch nicht ganz
Das SSE, 3dnow oder auch MMX Befehlserweiterungen zum normalen x86 Befehlssatz sind ist mir auch klar. SSE3 Befehle auf einem Thunderbird würde dieser nicht ausführen können. Diese Kombination wäre aber ein eklatanter Programmierfehler (vom Programmierer oder schon vom Compiler-Entwickler. k.A. wie die Erweiterungschecks abgefragt werden)
Das man ein Programm auf eine spezielle CPU (mit deren stärken und vor allem Schwächen) optimieren kann ist mir auch klar.
Nur verstehe ich an Deinem Beispiel nicht, wie die Kombination entstehen soll, dass ein Befehl (normaler x86) auf einem Intel korrekt verarbeitet werden kann aber auf dem AMD nicht.
Verstehe ich es richtig, dass Du von generellen bekannten CPU Fehlern sprichst? (wie damals beim P1 mit AFAIK den Wurzel-Funktionen oder was da nachweislich falsch berechnet wurde
Wenn ich also nur die Fehler von Intel berücksichtige jedoch nicht die hauseigenen bekannten Fehler von AMD?
Das wäre mich immernoch eine Designschwäche des Compilers
m.E. beruhen nahezu sämtlichen Inkompatibilitäten aus der Tatsache, dass AMD sich mit Mainboard-Chips von Fremdanbietern vertragen muss, wärend Intel alles sauber zueinander entwickeln kann.
Ein Intel "damals" auf einem ALI Chipsatz war doch mind. genauso katastrophal.
Heutige Probleme mit AMD sind doch i.d.R. Probleme mit dem Chipsatz (egal ob NVidia oder Via).
[P3D] Crazy_Chris
Grand Admiral Special
Hey ansley, was du hier von "der ein rechnet falsch und der andere richtig" erzählts hab ich so noch nirgends gelesen. Von außen gesehen sind die CPUs entweder kompatibel oder nicht. Ein auf Pentium4 optimierter Code läuft auch auf einen Athlon 64 (der hatte ja erst SSE2) absolut fehlerfrei und stabil. Der Compiler macht nicht mehr als das er den Code so optimiert das dieser besser (schneller) auf der Netburst Architektur läuft. Trotzdem läuft dieser absolut fehlerfrei auf einer Athlon 64 CPU da diese 100% kompatibel zu x86 +SSE ..usw. ist.
Nenn uns doch mal endlich reale Beispiele mit Quellenangabe. Gerne auch mit Assemblercode.
Das es Bugs im Design einer CPU geben kann ist ja ganz normal nur werden diese vom Compiler umschifft wenn sie denn bekannt sind. Meistens sind es eh nur Bugs die die Performance etwas drücken.
Den letzten wirklichen Fehler hatte wohl der Pentium (P5) mit seinem FDIV-Bug.
Nenn uns doch mal endlich reale Beispiele mit Quellenangabe. Gerne auch mit Assemblercode.
Das es Bugs im Design einer CPU geben kann ist ja ganz normal nur werden diese vom Compiler umschifft wenn sie denn bekannt sind. Meistens sind es eh nur Bugs die die Performance etwas drücken.Den letzten wirklichen Fehler hatte wohl der Pentium (P5) mit seinem FDIV-Bug.
Zuletzt bearbeitet:
@Devastators & @[P3D] Crazy_Chris
Das Rechenbeispiel ist nur ein BEISPIEL!!!! weiter nichts, es soll nur Kompatibilitätsprobleme verdeutlichen, dass nichts Perfektes gibt, nicht mal in der Natur.
Die gefunden Fehler werden mit jeder neuen Version ausgebessert. Aber generell hat sowohl Intel wie auch AMD Dokumente mit den bekannten Fehlern, die von Compilern wie auch im BIOS berücksichtigen werden sollen/müssen.
Rechenfehler ist eine Sache, aber es sind noch viele miese Sachen vorhanden.
Ich komme aus embedded Bereich und da gibt’s Fälle die unbedingt eingehalten werden müssen. Interruptssperren wenn bestimmte Zugriffe erfolgen, dann Workarrounds für verschiedene Fehler in der Peripherie. Da in diesem Bereich die CPUs weniger komplex sind als bei INTEL und AMD so ist die Peripherie die manchmal ziemlich Krankt. Wie eben auch bei den Chipsätzen im PC-Bereich.
@Devastators
Die meisten Fragen hast du bereits selber beantwortet
Es ist nicht ein Problem eines Compilers, wenn er was für AMD nicth beachtet. Intel besitzt schließlich über ca. 80% Marktanteil (weiss nicht genau, denke so um die zahl rum), früher noch mehr. Wer würde also mehr beachtet?!
@[P3D] Crazy_Chris
Ich habe keine Beispiele und keine Assemblercodes, ich komme aber aus dem selben Sektor nur eben mit etwas langsamen uC von Microchip, Freescale, Toshiba und Renesas. Alle haben ihre stärken und schwächen. Für jeden uC müssen Optimierungen gemacht werden, da nicht alle „gleich“ arbeiten, und man hat nicht ewig Zeit. Je nach Familie vom gleichen Hersteller müssen ganz bestimmte Codesequenzen eingehalten werden, sonst sind Daten korrupt. Und bei AMD und Intel wird es nicht anders sein.
Das Rechenbeispiel ist nur ein BEISPIEL!!!! weiter nichts, es soll nur Kompatibilitätsprobleme verdeutlichen, dass nichts Perfektes gibt, nicht mal in der Natur.
Die gefunden Fehler werden mit jeder neuen Version ausgebessert. Aber generell hat sowohl Intel wie auch AMD Dokumente mit den bekannten Fehlern, die von Compilern wie auch im BIOS berücksichtigen werden sollen/müssen.
Rechenfehler ist eine Sache, aber es sind noch viele miese Sachen vorhanden.
Ich komme aus embedded Bereich und da gibt’s Fälle die unbedingt eingehalten werden müssen. Interruptssperren wenn bestimmte Zugriffe erfolgen, dann Workarrounds für verschiedene Fehler in der Peripherie. Da in diesem Bereich die CPUs weniger komplex sind als bei INTEL und AMD so ist die Peripherie die manchmal ziemlich Krankt. Wie eben auch bei den Chipsätzen im PC-Bereich.
@Devastators
Die meisten Fragen hast du bereits selber beantwortet
Es ist nicht ein Problem eines Compilers, wenn er was für AMD nicth beachtet. Intel besitzt schließlich über ca. 80% Marktanteil (weiss nicht genau, denke so um die zahl rum), früher noch mehr. Wer würde also mehr beachtet?!
@[P3D] Crazy_Chris
Ich habe keine Beispiele und keine Assemblercodes, ich komme aber aus dem selben Sektor nur eben mit etwas langsamen uC von Microchip, Freescale, Toshiba und Renesas. Alle haben ihre stärken und schwächen. Für jeden uC müssen Optimierungen gemacht werden, da nicht alle „gleich“ arbeiten, und man hat nicht ewig Zeit. Je nach Familie vom gleichen Hersteller müssen ganz bestimmte Codesequenzen eingehalten werden, sonst sind Daten korrupt. Und bei AMD und Intel wird es nicht anders sein.
Devastators
Grand Admiral Special
Solange es aber keine konkreten nachweislichen Beweise gibt ist das dennoch alles pure Theorie und Wahrscheinlichkeitsrechnung.
Chipsatzprobleme werden sicherlich die allermeissten sofort zugeben (wer mal den KT7 SouthbridgeBug hatte oder ein NForce2 mit einigen Zicken, aber auch ein Intel mit nicht Intel Chipsatz kann zicken wie ... egal
.
Bei diesen Inkompatibilitäten (wie auch bei vielen Problemem mit Creative Karten) werden aber auch sehr oft Grenzwerte nicht eingehalten und man läuft z.T. ausserhalb definierter Spezifikationen. Da wundert es niemanden wenn das irgendwo mal schief geht.
Wenn sich ein Compiler nicht exakt am x86 Befehlssatz hält und AMD somit garnicht korrekt damit arbeiten kann ist es sehr wohl und einzig und alleine Schuld des Compilers.
Mehr als 100% die Befehle umsetzen kann AMD mit seinen Prozessoren nicht tun
Soll AMD nun auch die Intel Fehler implementieren damit man genauso "Stabil" wird?
Chipsatzprobleme werden sicherlich die allermeissten sofort zugeben (wer mal den KT7 SouthbridgeBug hatte oder ein NForce2 mit einigen Zicken, aber auch ein Intel mit nicht Intel Chipsatz kann zicken wie ... egal
.Bei diesen Inkompatibilitäten (wie auch bei vielen Problemem mit Creative Karten) werden aber auch sehr oft Grenzwerte nicht eingehalten und man läuft z.T. ausserhalb definierter Spezifikationen. Da wundert es niemanden wenn das irgendwo mal schief geht.
Wenn sich ein Compiler nicht exakt am x86 Befehlssatz hält und AMD somit garnicht korrekt damit arbeiten kann ist es sehr wohl und einzig und alleine Schuld des Compilers.
Mehr als 100% die Befehle umsetzen kann AMD mit seinen Prozessoren nicht tun
Soll AMD nun auch die Intel Fehler implementieren damit man genauso "Stabil" wird?
[P3D] Crazy_Chris
Grand Admiral Special
Schon klar das man selbst Code in Hochsprache (C z.B.) nicht von einer Architektur zur anderen portieren kann wenn man auf der Hardwareebene programmiert. Bei nahezu allen Programmen für PCs programmiert man auf der Betriebssystemebene. Daher spielt die Architektur keine Rolle und solange die CPUs 100% kompatibel zum im Compiler erzeugten Maschinecode sind. (und das sind sie ja!)
Der Vergleich zum µController passt daher nicht da dort kein Betriebssystem im Hintergrund steht. Selbst in C geschriebener Code für sagen wir den Atmel AVR kann nicht einfach so für die ARM oder 8051 Architektur compiliert werden da dieser Code sehr hardwarenah ist. Ohne größere Anpassungen würde rein garnichts funktionieren.
Na jedenfalls ist dein "AMD CPUs ist nicht kompatibel und erzeugt daher eher Abstürze" schlichtweg flasch.
So..gings hier nicht um Stalker?
@Devastators & @[P3D] Crazy_Chris
Ihr habt das Prinzip immer noch nicht verstanden…
Das letzte mal und dann ist Schluss
Moderne Prozessoren haben eine Pipeline und diese darf keinesfalls leer sein oder falsche Instruktionen enthalten, d.h. Pipeline muss dann wieder geleert und neu gefüllt werden, sonst geht Performance zunichte. Aus diesem Grund haben Prozessoren ausgeklügelte Sprungvorhersage. Das ist das eine. Auf der anderen Seite, darf die Bearbeitung des aktuellen Befehls die anderen Befehle in der Queue nicht ausgewertet lassen, dafür sind verschiedene Instanzen im Prozessor zuständig. Ihr müsst einen Prozessor bidirektional vorstellen, Input bedeutet zugleich (nicht gleich) Output, d.h. diese beiden Zustände verlaufen parallel. Das Thema ist zu komplex um es zu verstehen und hier darüber zu schreiben. Es wird verhindert dass Wartepausen entstehen. Stellt euch vor, ein Befehl geht zum Berechnen rein und gleichzeitig geht das Ergebnis des vorherigen Befehls raus. Es wird also nicht versucht erstmal einen Befehl abzuarbeiten, diesen sichern und erst dann wird der nächste geholt. Das würde sehr viel Performance kosten. Durch diese Parallelisierung gibt’s manche Abfolgen von Befehlen, also hintereinander, die zu einem Fehler führen können, von mir aus, Bitkipper, falscher Sprung, es gibt zu viele Möglichkeiten. Um diese speziellen Abfolgen zu verhindern werden z.B. NOP Befehle vom Compiler eingebaut oder es treten Codetraps auf (also Softwareinterrupts, d.h. Befehl falsch, haben auch viele uC).
Nun zu den Compilern. Die Compiler kennen den jeweiligen Prozessor und können somit speziell auf diesen Prozessor die Pipeline und Befehlabfolge so ablegen, dass der Prozessor nie warten muss bis seine Pipeline gefüllt wird. Außerdem wird Cachegröße dafür voll ausgenutzt. Diese Optimierungen sind nur für bestimmte Prozessoren und sind meistens in Compilern durch Optionen wie 386/486/Pentium/PPro/P3/P4 vorbelegt, das kann man aber auswählen. Es sind dann spezielle DLL die beim Starten des Programms geladen werden.
Es heißt nicht, dass Amd nicht in der Lage wäre den gleichen Code mit Bravur auszuführen, nur eben wenn Compiler die Sequenzfehler für Intel abgefangen hat (assemblercode ist ja schon erzeugt), kann aber bei Amd auf der anderen Seite an einer anderen Position im Code zu Fehlern führen, was aber bei Intel funktioniert.
Wenn das immer noch nicht ausreicht... huch.. ich gebs auf
@Devastators
Für Codeportierung wird HAL (Hardware Abstraction Layer) verwendet, oder wie es ebenfalls genannt wird -> Hardware-Modul. Siehe generellen Betriebssystemaufbau.
Für praktisch jeden uC gibt’s Betriebssysteme, wie komplexe wie auch primitive, aber es gibt sie in jeder Firmware, sonst würde Chaos herrschen.
Ach ja … Stalker läuft noch ohne abstürze … vielleicht kommt’s noch, wer weiß.
Ihr habt das Prinzip immer noch nicht verstanden…
Das letzte mal und dann ist Schluss
Moderne Prozessoren haben eine Pipeline und diese darf keinesfalls leer sein oder falsche Instruktionen enthalten, d.h. Pipeline muss dann wieder geleert und neu gefüllt werden, sonst geht Performance zunichte. Aus diesem Grund haben Prozessoren ausgeklügelte Sprungvorhersage. Das ist das eine. Auf der anderen Seite, darf die Bearbeitung des aktuellen Befehls die anderen Befehle in der Queue nicht ausgewertet lassen, dafür sind verschiedene Instanzen im Prozessor zuständig. Ihr müsst einen Prozessor bidirektional vorstellen, Input bedeutet zugleich (nicht gleich) Output, d.h. diese beiden Zustände verlaufen parallel. Das Thema ist zu komplex um es zu verstehen und hier darüber zu schreiben. Es wird verhindert dass Wartepausen entstehen. Stellt euch vor, ein Befehl geht zum Berechnen rein und gleichzeitig geht das Ergebnis des vorherigen Befehls raus. Es wird also nicht versucht erstmal einen Befehl abzuarbeiten, diesen sichern und erst dann wird der nächste geholt. Das würde sehr viel Performance kosten. Durch diese Parallelisierung gibt’s manche Abfolgen von Befehlen, also hintereinander, die zu einem Fehler führen können, von mir aus, Bitkipper, falscher Sprung, es gibt zu viele Möglichkeiten. Um diese speziellen Abfolgen zu verhindern werden z.B. NOP Befehle vom Compiler eingebaut oder es treten Codetraps auf (also Softwareinterrupts, d.h. Befehl falsch, haben auch viele uC).
Nun zu den Compilern. Die Compiler kennen den jeweiligen Prozessor und können somit speziell auf diesen Prozessor die Pipeline und Befehlabfolge so ablegen, dass der Prozessor nie warten muss bis seine Pipeline gefüllt wird. Außerdem wird Cachegröße dafür voll ausgenutzt. Diese Optimierungen sind nur für bestimmte Prozessoren und sind meistens in Compilern durch Optionen wie 386/486/Pentium/PPro/P3/P4 vorbelegt, das kann man aber auswählen. Es sind dann spezielle DLL die beim Starten des Programms geladen werden.
Es heißt nicht, dass Amd nicht in der Lage wäre den gleichen Code mit Bravur auszuführen, nur eben wenn Compiler die Sequenzfehler für Intel abgefangen hat (assemblercode ist ja schon erzeugt), kann aber bei Amd auf der anderen Seite an einer anderen Position im Code zu Fehlern führen, was aber bei Intel funktioniert.
Wenn das immer noch nicht ausreicht... huch.. ich gebs auf
@Devastators
Für Codeportierung wird HAL (Hardware Abstraction Layer) verwendet, oder wie es ebenfalls genannt wird -> Hardware-Modul. Siehe generellen Betriebssystemaufbau.
Für praktisch jeden uC gibt’s Betriebssysteme, wie komplexe wie auch primitive, aber es gibt sie in jeder Firmware, sonst würde Chaos herrschen.
Ach ja … Stalker läuft noch ohne abstürze … vielleicht kommt’s noch, wer weiß.
Devastators
Grand Admiral Special
so schnell geb ich nicht auf
Du gehst also ganz generell davon aus, dass CPUs immer wieder mal Fehler machen. (Ich habe mich schon immer gefragt ob eine CPU immer exakt richtig rechnet und bei den unglaublichen Mengen an Bits nicht mal eins falsch steht weil irgendwo elektrisch zu nahe am Grenzwert "gearbeitet" wurde)
Der Compiler kann das also weitgehend abfangen, glaub ich so einfach mal.
Was ich mich jetzt Frage:
Was ist mit Programmen die 1-2 Jahre alt sind, die kennen meinen neuen C2D überhaubt nicht.
Die verwendeten Compiler hängen doch i.d.R. Jahre hinter der aktuellsten CPU-Generation zurück (wow, wir rüsten momentan auf VStudio 2005 auf )
Irgendwie passen Deine Aussagen (die logisch klingen) noch nicht alle zusammen.
Der P4 hat doch mit dem P3 kaum noch etwas gemeinsam.
Der C2D ist nochmals stark geändert worden u.s.W. und Teile von W2k sind doch locker 10 Jahre alt.
Wo ist da der Vorteil eines C2D gegenüber AMD?
Damals waren beide CPU-Typen und deren Macken noch Wunschtraum.
Aktuell fehlt mir auch vollkommen ein praktischer Zusammenhang, denn die mögliche grössere Fehleranfälligkeit von AMDs (im Vergleich zu Intel) ist mittlerweile keine Entscheidungshilfe mehr Wert. Auch im Serverbetrieb wird zunehmend AMD eingesetzt.
Ausser einigen (vielleicht früher berechtigten) Vorurteilen scheint sich alles sehr relativiert zu haben.
Und eine unbesiegbare Stabilität scheint kein Kaufgrund mehr für Intel zu sein, sonst hätten wir aktuell keinen Preiskampf im CPU-Markt.
@Mods:
Sorry für das OT, kann man das vielleicht mal extrahieren?
Ich finde das Thema allein gesehen mind, genauso spannend wie Stalker
Du gehst also ganz generell davon aus, dass CPUs immer wieder mal Fehler machen. (Ich habe mich schon immer gefragt ob eine CPU immer exakt richtig rechnet und bei den unglaublichen Mengen an Bits nicht mal eins falsch steht weil irgendwo elektrisch zu nahe am Grenzwert "gearbeitet" wurde)
Der Compiler kann das also weitgehend abfangen, glaub ich so einfach mal.
Was ich mich jetzt Frage:
Was ist mit Programmen die 1-2 Jahre alt sind, die kennen meinen neuen C2D überhaubt nicht.
Die verwendeten Compiler hängen doch i.d.R. Jahre hinter der aktuellsten CPU-Generation zurück (wow, wir rüsten momentan auf VStudio 2005 auf
)Irgendwie passen Deine Aussagen (die logisch klingen) noch nicht alle zusammen.
Der P4 hat doch mit dem P3 kaum noch etwas gemeinsam.
Der C2D ist nochmals stark geändert worden u.s.W. und Teile von W2k sind doch locker 10 Jahre alt.
Wo ist da der Vorteil eines C2D gegenüber AMD?
Damals waren beide CPU-Typen und deren Macken noch Wunschtraum.
Aktuell fehlt mir auch vollkommen ein praktischer Zusammenhang, denn die mögliche grössere Fehleranfälligkeit von AMDs (im Vergleich zu Intel) ist mittlerweile keine Entscheidungshilfe mehr Wert. Auch im Serverbetrieb wird zunehmend AMD eingesetzt.
Ausser einigen (vielleicht früher berechtigten) Vorurteilen scheint sich alles sehr relativiert zu haben.
Und eine unbesiegbare Stabilität scheint kein Kaufgrund mehr für Intel zu sein, sonst hätten wir aktuell keinen Preiskampf im CPU-Markt.
@Mods:
Sorry für das OT, kann man das vielleicht mal extrahieren?
Ich finde das Thema allein gesehen mind, genauso spannend wie Stalker
Zuletzt bearbeitet:
[P3D] Crazy_Chris
Grand Admiral Special
@Devastators & @[P3D] Crazy_Chris
Ihr habt das Prinzip immer noch nicht verstanden…
Das letzte mal und dann ist Schluss
Ein ganz klein wenig Ahnung hab ich schon von der Materie.
Und das was du uns da erzählen willst stimmt so einfach nicht. Wie Devastators schon erklärt hat würde nach deiner "Theorie" kein Programm auf einen C2D fehlerfrei laufen das z.B. für einen 386er compiliert wurde.
Warum geht es trotzdem? Erklär uns das mal bitte. PS: Nenn mir ein Betriebssystem für einen Intel 8051 Microcontroller?
Schon ok, weiß was du meinst ^^Hast du nicht vor 2-3 Posts noch das Gegenteil behauptet? Kompatibel heißt für mich das der Code immer fehlerfrei ausgeführt werden kann. Das hat nichts mit der Performance zutun.
Von "außen" gesehen verhalten sich die Prozessoren (ob nun 386 oder C2D) gleich. Dass in Wirklichkeit der C2D oder welcher Prozessor auch immer den Code durch ausgeklügelte Sprungvorhersagen, Pipelines, Out of Order Execution, Caches oder was auch immer anders anordnet und damit sehr viel schneller als ein 386 ausführt spielt für das Endergebnis kein Rolle. Wäre es nicht so, so würde der C2D nicht 100% kompatibel sein und man könnte seine alten Programme in die Tonne kloppen da sie nicht mehr laufen.
Zuletzt bearbeitet:
[P3D] Crazy_Chris;3138680 schrieb:
In der Regel ist es nicht Aufgabe des Compilers irgendwelche Fehler auszubügeln - dafür gibts halt die Code-Traps -> Bios-Aufgabe. Der von Dir schon angesprochene FDIV-Bug ist eine typische Ausnahme - viele Compiler bieten die Option hierfür sicheren Code zu verwenden (auf Kosten der Performance). Wie weiter untem im Thread erwähnt kann der Compiler aber nicht die passende Instanz für die Korrektur sein, da dieser keinerlei Entwicklungen nach der Compiletime berücksichtigen kann. Dafür gibts halt Bios-Updates.
Der FDIV-Bug war halt eine Besonderheit weil er im Gegensatz zu vielen anderen Problemen statistisch deutlich häufiger auftreten konnte als viele andere Fehler. Die Errata-Liste beider Hersteller ist aber recht umfangreich. Allerdings sind die Umstände unter denen diese auftreten oft so selten, daß man in der Realität davon nichts spürt.
Mnemonics sind das was Du als Entwickler verwendest, weil für den Menschen deutlich lesbarer ist als der Maschinencode. Die CPU weiß natürlich von den Mnemonics nix - die kennt nur die Bytefolgen des Maschinencodes. Aber das Grundprinzip bleibt selbstredend so wie Du es erklärt hast.
so schnell geb ich nicht auf
Du gehst also ganz generell davon aus, dass CPUs immer wieder mal Fehler machen. (Ich habe mich schon immer gefragt ob eine CPU immer exakt richtig rechnet und bei den unglaublichen Mengen an Bits nicht mal eins falsch steht weil irgendwo elektrisch zu nahe am Grenzwert "gearbeitet" wurde)
Der Compiler kann das also weitgehend abfangen, glaub ich so einfach mal.
Was ich mich jetzt Frage:
Was ist mit Programmen die 1-2 Jahre alt sind, die kennen meinen neuen C2D überhaubt nicht.
Fehler gibt es in der Tat - siehe Errata-Liste. Und dann kommen noch mögliche externe Quellen hinzu wie z.B. durch höhere Sonnenaktivität verursacht. Von vielen CPUs gibts es deswegen z.B. solche die besonders für den Einsatz in kritischen Bereichen wie Raumfahrt oder Medizin ausgelegt sind. Gerade die Verkleinerung der Strukturen erhöht die Gefahrenlage, weil z.B. immer weniger Elektronen für eine Signalübertragung/Speicherung verwendet werden.
Pentium in Bereichen erhöhter Strahlung. Diese hardended CPUs hinken den aktuellen Top-Modellen in der Regel um viele Jahre hinterher. Im Space Shuttle fliegen heute noch Derivate des i8086 - man hat vor zwei, drei Jahren versucht weitere CPUs am Markt zu erwerben, was viele Leute hat glauben machen, daß der alte XT-Rechner auf einmal doch irre viel Geld wert wäre (gesucht wurden aber eher medizinische Geräte in denen diese Spezial-Varianten auch verbaut wurden).
Der Compiler ist in der Geschichte außen vor - der muß sich darauf verlassen, daß der Prozessor den erzeugten Code korrekt umsetzt. Da der Compiler von kommenden Entwicklungen auch noch nichts weiß wäre hier - wie von Dir beschrieben - auch kein Eingreifen möglich.
Leider fehlt mir etwas der Thread-Start - wurde ja offensichtlich hier hin verschoben. Was ich aus den Zeilen lese ist, daß Ihr hier mächtig an einander vorbeiredet !
A) Vermutlich von keinem bestritten wird, daß es seit ewigen Zeiten keine CPU mehr gegeben hat, die vollkommen fehlerfrei arbeitet. In der Praxis lassen sich die kleinen Mängel halt mit Korrekturen im Bios im Griff halten.
B) Die Wahl der Testplattform bestimmt selbstverständlich die Fehleranfälligkeit des Endproduktes. Das sagt letztlich über die Qualität der Plattformen aber nichts aus.
Kleines Beispiel: Plattformen A und B. Mein Prototyp enthält noch 500 Fehler, davon treten 490 auf beiden Plattformen auf, 5 nur auf A und 5 nur auf B (beide quasi gleichwertig). Die Qualitätskontrolle findet primär auf Plattform B statt. Hierbei werden von den gemeinsamen Fehlern 350 gefunden ( fehlerfreie Software ist ein Gerücht - über fehlerarm können wir gerne reden ), und von denen die nur auf B auftreten 3. Bei einem kurzen Test auf A wird nur einer gefunden ( weil schlichtweg hier weniger Aufwand getrieben wird !). Endresultat:
4 nur auf A
2 nur auf B
140 auf beiden
Ist B nun besser ? Nein - bei umgekehrter Testplattform wäre das Ergebnis umgekehrt. In der freien Wildbahn kann nicht jeder Entwickler auf allen Plattformen in gleichem Umfang testen. Je größer das Projekt um so breiter selbstverständlich die Breite der Tests - und umso weniger Plattformabhängigkeiten treten auf. Von großen Projekten wie Apache, Mozilla, OpenOffice ist nicht bekannt, daß diese auf AMD oder Intel stabiler laufen würden.
(Obige Zahlen sind selbstverständlich aus der Luft gegriffen - aber in der Regel sind die meisten Fehler softwareseitig und betreffen alle Plattformen. Und selbst die beste Qualitätskontrolle läßt oft ne Menge durchschlüpfen - obwohl Entwickler das nur ungern zugeben).
Intel hat diesen Umstand sehr früh erkannt und entsprechend reagiert. Die Compiler - vor allem aber die vielen weiteren Tools - haben einen hervorragenden Ruf. VTune z.B. ist ein sehr sehr nützliches Tool um der Performance der eigenen Programme auf die Spur zu kommen. Ich persönlich finde da Codeanalyst von AMD (noch) nicht gleichwertig ( dies ist selbstverständlich subjektiv - aber ich höre das halt auch aus meinem Umfeld so ). Selbstverständlich hat Intel kein Interesse daran AMD-CPUs als Entwicklerplattformen zu unterstützen, so daß VTune z.B. nur auf Intel-Plattformen läuft. Wem das wichtig ist wird möglicherweise eher zu Intel greifen und somit weniger auf AMD testen.
ABER:
Die Inkompatibilitäten sind dermaßen gering, daß diese in der Praxis für den Normalverbraucher völlig irrelevant sind. Die Stabilitätsprobleme der Software übersteigen die der CPUs in der Regel um mehrere Größenordnungen.
Für kritische Bereiche muß man da selbstverständlich andere Maßstäbe ansetzen - beim Airbus A320 werden z.B. für die Steuerung sowohl Intel als auch Motorola (jetzt wohl Freescale) CPUs verwendet, um solche systematischen Fehler weiter zu begrenzen.
Die Unterschiede der Entwicklerplattform wirken sich in der Regel halt viel mehr auf die Performance als auf die Stabilität aus.
Leider wird die Qualitätskontrolle vielfach von den Kunden maßlos überschätzt. Die meisten Entwickler stehen unter erheblichem Zeitdruck - und Qualitätskontrolle trägt nicht unmittelbar zur Wertschöpfung bei. Außerdem respektiert der Markt sowas leider auch nicht hinreichend - ich brauche mir dazu nur all die vielen Threads anschauen in denen Firma A schon auf dem Markt ist und B noch nicht.
Mein (subjektives!) Fazit. Es gibt prinzipiell Unterschiede durch unterschiedliche Unterstützung auf Entwicklerseite - aber im Vergleich zu den von der Software selber verursachten Fehlern sind diese in der allgemeinen Praxis unerheblicher als viele meinen.
Just my 2 cents dazu,
Tom
Devastators
Grand Admiral Special
vielen Dank, war sehr gut und verständlich geschrieben.
So wie ich das nun verstanden habe, ist es reine Hardware (Mainboard und Bios-) Sache den PC stabil laufen zu lassen.
Die Tests von denen Du sprichst laufen ja alle auf sehr niedrigem Hardware-Nahem Niveau ab.
Somit bleibt die Kernaussage jedoch weitgehend erstmal bestehen, ein Software-Entwickler hat keine stalibilitäts-Einfluss mehr auf das eingesetzte System. So nah kommt dieser nicht mehr an die Hardware heran.
Die Kernaussage hat ursprünglich gelautet, dass Intel stabiler ist, eben weil es die verbreitetere Platform ist und Software i.d.R: auf dieser direkt entwickelt wurde.
Diese Aussage alleine stehen gelassen halte ich immernoch für falsch.
Deiner Aussage nach wäre die Kombination Intel CPU und Intel Mainboard mit enger Zusammenarbeit der Bios Hersteller die stabilste Lösung.
Erst dann kommt die Software.
Es ist aber durchaus Möglich, andere Hersteller mit anderen Kombinationen eine gleichweritige Stabilität zu erreichen.
Diese Stabilität ist also vollkommen losgelöst von der eingesetzten Software die später unter einem Betriebssystem laufen soll.
Läuft das Betriebssystem, läuft auch die Software gleichgut wie auf anderen Systemen.
So wie ich das nun verstanden habe, ist es reine Hardware (Mainboard und Bios-) Sache den PC stabil laufen zu lassen.
Die Tests von denen Du sprichst laufen ja alle auf sehr niedrigem Hardware-Nahem Niveau ab.
Somit bleibt die Kernaussage jedoch weitgehend erstmal bestehen, ein Software-Entwickler hat keine stalibilitäts-Einfluss mehr auf das eingesetzte System. So nah kommt dieser nicht mehr an die Hardware heran.
Die Kernaussage hat ursprünglich gelautet, dass Intel stabiler ist, eben weil es die verbreitetere Platform ist und Software i.d.R: auf dieser direkt entwickelt wurde.
Diese Aussage alleine stehen gelassen halte ich immernoch für falsch.
Deiner Aussage nach wäre die Kombination Intel CPU und Intel Mainboard mit enger Zusammenarbeit der Bios Hersteller die stabilste Lösung.
Erst dann kommt die Software.
Es ist aber durchaus Möglich, andere Hersteller mit anderen Kombinationen eine gleichweritige Stabilität zu erreichen.
Diese Stabilität ist also vollkommen losgelöst von der eingesetzten Software die später unter einem Betriebssystem laufen soll.
Läuft das Betriebssystem, läuft auch die Software gleichgut wie auf anderen Systemen.
Danke für die Blumen
Wenn Du das aus meinen Zeilen gelesen hast, hab ich mich vermutlich unglücklich ausgedrückt. Aufgabe des Bios ist es auch sich den Errata zu widmen. Nur in Ausnahmefällen werden sich Softwareentwickler der allgemeineren Art damit rumschlagen (können). Stabilität ist aber natürlich eine Kette - wenn ein Glied davon patzt ists vorbei mit der Stabilität. Eine buggy Software wird natürlich durch eine gute Plattform nicht plötzlich stabil. Ich würde Deinen Satz daher gerne wie folgt umformulieren:
Aufgabe von Mainboard/Bios ist es der Software eine stabile vorhersehbare Plattform zu bieten.
Es bleiben ihm viele Möglichkeiten die Stabilität negativ zu beeinflussen - und wenn ich mich so umschaue wird dies auch nach Kräften genutzt
Umgekehrt ist das schon deutlich schwieriger.
Ich würde mich dem Thema mal aus folgendem Blickwinkel nähern. Man behebt nur die Bugs, die man findet. Man findet die, die einem über den Weg laufen. Und es laufen einem nur die übern Weg, die entlang des eigenen Pfades liegen. ABER ! Bei herkömmlicher Software ist die Anzahl der hardwarespezifischen Bugs bedeutend geringer als allgemeine Fehler in der Ablauflogik. Der Bug befindet sich auch in der Entwicklung in der Regel 30-50cm vor dem Display. Und bei größeren Projekten wird selten nur auf einer Plattform alleine getestet. Somit nivellieren sich die Unterschiede auch hier.
Hm, ich hab mit meinem AMD-System Software zum Auswerten von Kernspin und CT-Aufnahmen im Bereich der Strahlentherapie entwickelt und war mit der Stabilität höchst zufrieden - würde mich also durchaus nicht pauschal dem Intel-Lager zugehörig sehen. Derzeit steht für mich ein Wechsel auf Dual Core an, um unter anderem die Performance-Aspekte von Multithreading besser optimieren zu können - und für mich ist durchaus noch nicht klar auf welches Pferd ich setze. Für Intel spricht in meinem Fall halt die Verfügbarkeit sehr guter Entwicklungstools, die teilweise auf AMD-Systemen nicht nutzbar sind. Was die Stabilität angeht, habe ich nicht die geringsten Zweifel, daß ich in BEIDEN Lagern Hardwarekombinationen finden werde, die meinen Ansprüchen gerecht werden. Und ich neige grundsätzlich dazu mir keine Exoten zuzulegen, sondern mir was aus dem Mainstream rauszupicken. Zum einen spiegelt sich das in den Preisen wieder und die Marktmacht drängt dann zu längerer/besserer Unterstützung seitens der Hersteller. Aber da hat halt jeder seine eigenen Heuristiken. Ich glaube nicht an DEN goldenen Weg.
Bis auf wenige Spezialfälle sehe ich das genau so.
Ich hab inzwischen über 15 verschiedene Boards hinter mir - und es war nicht ein einziges dabei, daß nicht nach einer kurzen Eingewöhnung stabil zu betreiben war. Und seit den Tagen, in denen sich der anfangs K86 genannte Chip in Form des K5 materialisierte, gab es nie eine Zeit in der ich nicht sowohl im Intel- als auch im AMD-Lager eine in meinen Augen brauchbare Kombination gefunden hätte. In beiden Lagern gabs stets brauchbare Lösungen und auch genauso Schrott.
Gruß,
Tom
@ Ansley Ich verstehe zwar mit so viel von Prozessoren weiß aber das man X86 kompatible Prozessoren nicht mit Prozessoren vergleichen kann die völlig anders arbeiten.
Das wäre als würdest du den Prozessor einer PS 3 mit dem einer Xbox 360 vergleichen.
Das wäre als würdest du den Prozessor einer PS 3 mit dem einer Xbox 360 vergleichen.
Devastators
Grand Admiral Special
Nein, ich habe mich nicht präzise ausgedrückt.
Es ging mir darum, wenn Board/CPU und Bios gut zusammen harmonieren (also dort keine Fehler zu erwarten sind) meint ansley, dass eine Software dennoch stabiler auf Intel laufen kann als auf AMD-Systemen.
Ich (und andere auch) sind jedoch der Überzeugung, dass ein sauber laufendes AMD System (also ohne Hardware-Konflikte, Bios Probleme) sich 100% identisch zum intel System verhält.
In meinen Augen sind Vergleiche über die Architekturgrenzen durchaus legitim. Man sollte sich halt nur davor hüten daraus Pauschalurteile abzuleiten. Ich wähl mal ein noch deutlich krasseres Beispiel: GPU und x86-CPU. Eine moderne GPU hat eine gigantische Rechenleistung, die in Teilbereichen jede CPU blass aussehen läßt. Fehlt die Parallelisierbarkeit der Anwendung und treten vor allem viele Conditional Branches auf kehren sich die Verhältnisse wieder fatal. Wenn ich mir im Anschluß Ergebnisse der Sorte "x1800 ist viel besser als Core Quad/Barcelona, weil Folding damit viel schneller geht" / "Core Quad/Barcelona sind viel besser, weil Schach darauf viel schneller läuft" verkneifen kann ist alles im grünen Bereich. Aber ein "für Folding ist die CPU (derzeit) recht wurscht, wenn ich dafür eine x1800 einsetze" macht in meinen Augen durchaus Sinn.
Die grundsätzliche Problematik, die Ansley beschreibt, daß mit der zunehmenden Komplexität immer mehr Designfehler die Testphase unerkannt überstehen, trifft auf ALLE Architekturen zu. Errata gibts auch für PowerPC, Itanium, Sparc, und und und. Ansley´s Anliegen ist halt der Hinweis auf unterschiedlichen Umgang mit diesen Errata.
Was die Praxis in der freien Wildbahn angeht, sind wir da ziemlich gleicher Meinung. 100% gibt es bei verschiedenen Dingen eigentlich nie - das trifft auch für zwei verschiedene CPUs aus dem Hause Intel zu! Niemand würde z.B. eine Steuerungssoftware für ein Kernkraftwerk auf CPU X entwickeln und vor allem evaluieren und später auf einer ganz anderen Plattform laufen lassen. Aber wir sind in der glücklichen Lage, daß die wenigsten von uns kritische Nuklearanlagen im Keller betreiben. Und vor dem Hintergrund der unglaublichen Zahl von Logikfehlern in gängigen Programmen nimmt sich das Restrisiko dieser Differenzierungen einfach so verschwindend gering aus.
Ein altes Beispiel für solch verschiedenen Verhaltensweisen findet man hier. Boshaft kann man sowas immer nutzen - und anschließend lässig die Schultern zucken, weil man ja anständigen Assembler ausgerollt hat - aber das gilt natürlich für beide Seiten - und ist auch nicht das was Ansley meint. Ich erinner mich dumpf, daß im Linux-Bereich vor einiger Zeit Codesequenzen angepaßt worden sind, weil die auf einer CPU-Schiene unter bestimmten Konstellationen Fehler verursachen konnten. Und natürlich findet man sowas eher, wenn man auch das gleiche System einsetzt. Sogesehen unterschreibe ich die Aussage von Ansley durchaus. Ich bewerte die Praxisrelevanz halt nur deutlich geringer.
Gruß,
Tom
PS:
Stehen zwei Bergsteiger auf zwei verschiedenen Bergen. Wessen Augen sind in größerer Höhe ? Der eine hat saubere Schuhsohlen - der andere Staub darunter. Statistisch hat selbstverständlich der dem mit dem Staub einen höheren Sichtpunkt - oder sollte die Höhe der Berge auch eine Rolle spielen ?. Mag nun jeder für sich selbst entscheiden wie wichtig das ist.
Devastators
Grand Admiral Special
Das trifft ja die Aussage, die ich selber schon beschrieben habe.
Aktuell verwendete Software wurde i.d.R. NICHT auf den Plattformen entwickelt die beim Release zur verfügung steht.
Stalker (worum es ursprünglich mal ging) ist über einige Jahre entwickelt worden. Zu Beginn gab es noch kein X2 oder C2D.
Beta-tests und dergleichen haben i.d.R. auch die selbe Hardware-Vielfalt wie die reale Welt.
Dahingegen wäre es mal interessant zu wissen, ob es signifikante Unterschiede bei den gemeldeten Fehlern gibt zwischen AMD und Intel-Systemen.
Ähnliche Themen
