News Beta-Chipsatztreiber: Destiny 2 startet erstmals auf AMD Ryzen 3000

[DocWindows]

Damit statistische Teste eine ausreichende Aussagequalität haben müsstest du mehr Werte liefern

Auflösung zu meinen Zahlen: Sie stammen aus einem simplen Algorithmus der als einzigen Seed-Input die aktuelle Uhrzeit (Stunden und Minuten) bekommen hat. Jeden Tag zur gleichen Stunde und Minute werden die gleichen Zahlen "ausgewürfelt". Somit sind die Zahlen nicht zufällig, weil vorhersagbar.

Du müsstest also einfach nur 2x innerhalb der selben Minute Zufallszahlen erzeugen und dann 1x zu einer beliebigen anderen Zeit um dies zu durchschauen. Aber die reinen Zahlen kannst du eben ohne Kontext nicht analysieren.

ich sehe es nun mal so, da man als Entwickler ja sicherstellen will dass das Programm auch läuft.
Zu Deiner Frage : ja, war ich mal, aber zur Zeit von Turbo Pascal 5 / 6.

Bis zu einem gewissen Grad will und kann man das als Entwickler auch. Irgendwo hörts aber auf. Wenn ein Funktionsaufruf mit der Rückgabe "Erfolgreich durchgeführt" beendet wird, muss ich mich als Entwickler darauf verlassen können, dass das auch stimmt. Man kann nicht bis ins kleinste Detail alles nachprüfen was Framework, Runtime, System und CPU machen. Wer würde denn z.B. so misstrauisch sein und z.B. diesen Code verwenden?

int i=1;
if (i != 1)
   return "Error";

Ich kann mich hier darauf verlassen dass i=1 ist, weil ich 1 als Wert zugewiesen habe. Da muss ich nicht prüfen ob wirklich ne 1 drin steht, oder vielleicht 0 oder -1.
Genausowenig muss ich prüfen ob nach dem Random-Funktionsaufruf den die CPU mit "Erfolgreich druchgeführt" beendet, ob im entsprechenden CPU-Register wirklich eine Zufallszahl steht. Ich kann davon ausgehen, denn die CPU hat mir ja zurückgemeldet dass sie eine Zufallszahl ermittelt hat.

Und das AMD Intel für die nächsten 20+ Monate überholt hat, dürfte man auch nicht gerade unter Profit verbuchen.

Unter was verbucht man denn, dass von der "panischen Preisreduktion" der Intel CPUs nichts mehr übrig geblieben ist, und der 9700K sogar noch 4 Euro teuerer geworden ist?
Der 9900k hat vor dem 07.07.2019 rund 485 Euro gekostet. Dann hat Intel nach dem Release der Matisse CPUs eine Preisreduktion angekündigt. Heute kostet der 9900k 486 Euro.

Da hat die Schockstarre sehr schnell nachgelassen.

 

[VelleX]

Für das asrock B450M Steel Legend und x570 taichi gibt es mittlerweile ein neues BIOS für destiny 2

Irgendwie ist das B450M steel Legend mit 2.62B verschwunden und stattdessen das B450 steel Legend mit 2.63b drin 🤔

 

[ZeroStrat]

Bis zu einem gewissen Grad will und kann man das als Entwickler auch. Irgendwo hörts aber auf. Wenn ein Funktionsaufruf mit der Rückgabe "Erfolgreich durchgeführt" beendet wird, muss ich mich als Entwickler darauf verlassen können, dass das auch stimmt. Man kann nicht bis ins kleinste Detail alles nachprüfen was Framework, Runtime, System und CPU machen.

Innerhalb des Produktiv-Codes ist das kritisch, ja. Aber dafür sind Unit Tests da, was einem bei neuen CPUs auch nicht immer direkt hilft.

Was man auch noch machen könnte: beim Initialisieren der Anwendung Überprüfungen durchführen. So ein Startvorgang dauert doch gefühlt eh schon ewig.

 

[DocWindows]

Was man auch noch machen könnte: beim Initialisieren der Anwendung Überprüfungen durchführen.

Fragt sich halt was du da überprüfen willst und vor allem wie. Ich habe ja schon in #134 gefragt wie meine Beispielzahlen überprüft werden sollten um zu ermitteln ob es sich um valide Zufallszahlen handelt oder um ganz schlechte Fake-Zufallszahlen wie in meinem Beispiel.

So ein Startvorgang dauert doch gefühlt eh schon ewig.

Wenn du alle CPU-Instruktionen oder API-Calls vernünftig auf Plausibilität in der Endanwendung prüfen willst, dann möchte ich nicht wissen wie viele Cores und wie viel Zeit es braucht bis dann die Anwendung gestartet wird, wenn es jetzt schon ohne Überprüfungen gefühlt ewig dauert.

Bei vielen Frameworks hast du auch gar nicht die Möglichkeit jedes Pups zu untersuchen, weil sie nur 3 Dinge nach außen führen. Eingabewerte, Ausgbewerte und Rückgabewerte. Das müsste schon der Frameworkentwickler machen und du müsstest dich dann wieder darauf verlassen dass es eben so funktioniert wie es dokumentiert ist.
Destiny nutzt ne Engine, die Engine nutzt ein Framework, das Framework nutzt die System-API. Was kann Destirny jetzt dafür wenn der Framework-Entwickler einen API-Call nicht korrekt auswertet oder dass die System-API sich falsch verhält?

Da stellt sich einfach die Frage der Verhältnismäßigkeit. Muss ich z.B. ein Filehandle das ich mit fopen erhalte nochmal überprüfen ob es zu der Datei gehört die ich an die Funktion übergeben habe, oder kann ich davon ausgehen dass es schon stimmen wird, wenn ich das Handle erhalte und der Errorcode 0 ist?

Das ist alles ziemlich absurd.

Du machst doch bei diesem CapFrameX Projekt mit. Da müsstest du doch genau wissen wovon ich spreche. Bist du schuld wenn das .NET Framework sich anders verhält als dokumentiert, weil du es ja hättest überprüfen können? Oder ist Microsoft schuld, weil sich das Framework anders verhält als dokumentiert?

 

[ZeroStrat]

@DocWindows Das ist ja Schwarz-weiß-Denken. Wenn man dieser oder jene Funktion mit Tests abdeckt, die man, warum auch immer, als grundlegend betrachtet, dann muss man auch die absoluten Basics wie add abdecken. Warum? Was mir oft begegnet, ist ein gewisses Schubladendenken, dass Ansätze und Patterns allgemeingültig seien wie ein Naturgesetz. Man adaptiert jedoch die Ansätze auf die Probleme, nicht umgekehrt.

Und ja, ich habe schon Basics wie round mit Unit Tests abgedeckt und dabei Unterschiede bei Definition rechtzeitig entdeckt. Bei der Berechnung der Quantile das gleiche.

Ich bin kein Freund davon, dass man Dinge strikt so und so machen muss. Es kommt auf den Kontext an. Wenn mir eine Zufallsfunktion Indizes liefern soll, dann prüfe ich, ob das >=0 ist, ja.

 

[Piktogramm]

Was man auch noch machen könnte: beim Initialisieren der Anwendung Überprüfungen durchführen. So ein Startvorgang dauert doch gefühlt eh schon ewig.

Wie willst du eine CPU auf das korrekte Verhalten von Befehlen testen, wenn der Code für diese Tests auf eben jener CPU läuft wo du nicht auf die korrekte Ausführung der Befehle vertrauen kannst?

Allein aktuelle X86 CPUs mittels Fuzzing abzuklopfen dauert Tage und da gehen die Tests mindestens davon aus, dass elementare Befehle der CPU funktionieren.

Ergänzung (31. Juli 2019)

@DocWindows Das ist ja Schwarz-weiß-Denken. Wenn man dieser oder jene Funktion mit Tests abdeckt, die man, warum auch immer, als grundlegend betrachtet, dann muss man auch die absoluten Basics wie add abdecken. Warum? Was mir oft begegnet, ist ein gewisses Schubladendenken, dass Ansätze und Patterns allgemeingültig seien wie ein Naturgesetz. Man adaptiert jedoch die Ansätze auf die Probleme, nicht umgekehrt.

Und woher willst du zu einem Zeitpunkt wissen, welche CPU-Befehle einer beliebigen Architektur unter welchen Bedingungen in Zukunft Fehler verursachen? Das ist schlicht unmöglich. Wenn du also forderst, dass Software gegen Fehlverhalten von CPUs robust sein soll, dann geht das nur in dieser Totalen.

Oder man nutzt den etablierten Weg, bei dem sich eine CPU an ihr definiertes Verhalten zu halten hat.

Und ja, ich habe schon Basics wie round mit Unit Tests abgedeckt und dabei Unterschiede bei Definition rechtzeitig entdeckt. Bei der Berechnung der Quantile das gleiche.

Und deine Tests führst du wie du es für das Testen der CPU forderst bei jedem Programmstart neu aus, so wie du es für CPUs gern hättest?

Ich bin kein Freund davon, dass man Dinge strikt so und so machen muss. Es kommt auf den Kontext an. Wenn mir eine Zufallsfunktion Indizes liefern soll, dann prüfe ich, ob das >=0 ist, ja.

Anmerkung: Die Forensoftware setzt mit hier ein Quote und lässt sich nicht davon abbringen :/

=0 wäre ein bescheidener Tests für eine Zufallsfunktion die ein signed Integer ausspucken soll. Einfach mal so die Entropie halbieren, super! Aber immerhin hättest du den AMD Bug damit erwischt

Die Frage ist dann nur noch, wie wir zukünftig Fehler abfangen, falls mal irgend eine CPU der Meinung ist sich an die normierte Zufallszahl 4 zu halten? Sieht das bei dir dann so aus:

if rdrand = 0
    fail()
else if rdrand < 0
    praise_amd()
else if rdrand > 0
    install_win10update()
else
    return(rdrand)

Deutlich besser als einfach wie definiert das C-Flag zu prüfen -.-

 

[DaBo87]

BTW: Fürs Gigabyte x570 Aorus Elite ist das neue BIOS F4i released worden, hat schon AGESA 1003ABB unter der Haube. Also dürften andere Boars auch schon was bekommen haben, wenn es Gigabyte betrifft, nehme ich an

 

[Ned Flanders]

Laut www.Planet3Dnow.de sprießen die AGESA 1.0.0.3abb BIOSE jetzt wie Pilze aus dem Boden.

@Jan sind die Beta Chipsatz Treiber damit für Destiny auf den entsprechenden Boards obsolete? Könnt ihr das Testen/Bestätigen?

 

[VelleX]

Also beim Taichi hab ich gestern die 1.70A installiert. Von AGESA 1.0.0.3ABB steht da allerdings nichts.
Vielleicht hat Planet3Dnow das einfach falsch interpretiert.

 

[Ned Flanders]

Also beim Taichi hab ich gestern die 1.70A installiert. Von AGESA 1.0.0.3ABB steht da allerdings nichts.
Vielleicht hat Planet3Dnow das einfach falsch interpretiert.

Kannst Du die AGESA Version mit Aida64 auslesen?

-->Motherboard-->Bios

 

[VelleX]

Wie bei CPU-Z steht da auch nur "Combo-AM4 1.0.0.3"
Auch wenn man das Firmware File mit dem Editor öffnet und nach "Combo" sucht findet man das gleiche

 

[Ned Flanders]

Wie bei CPU-Z steht da auch nur "Combo-AM4 1.0.0.3"

Strange, oder? Warum sollte es dann den Destiny2 Bug beheben können? Alternative Lösung?

Strange ist auch, das GigaByte unter den wörtlich gleichen Release Notes abb erwähnt.

Edit

@VelleX

Gigabyte sagt aber ausdrücklich 1.0.0.3abb und per editor steht da auch nur 1.0.0.3 drinn.

Ich würde sagen du hast das 1.0.0.3abb auf Deinem Board. Das ergibt sonst keinen Sinn.