PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: News des 16. Februar 2024


Leonidas
2024-02-17, 09:14:37
Link zur News:
https://www.3dcenter.org/news/news-des-16-februar-2024

hardtech
2024-02-17, 13:56:49
wieso kommt der betrug bei intel so spät raus?
finde das eher schändlich für intel und zeugt von mangelnder kompetenz bei eigenen produkten.

Leonidas
2024-02-17, 14:07:54
Denkbarerweise dauert es etwas, ehe man auf dem Level so was entdeckt - gerade wenn die Performance-Vorteile keine Welten sind. Wahrscheinlich hat man es erst entdeckt, weil die neuen Compiler es nicht mehr haben (seit Dez '23) und es erst damit einen Anreiz gab, dem nachzugehen.

Gast
2024-02-17, 18:52:53
wieso kommt der betrug bei intel so spät raus?
finde das eher schändlich für intel und zeugt von mangelnder kompetenz bei eigenen produkten.

Ich finde es eher schändlich da von Betrug zu sprechen.

Anscheinend wurde zwar gegen die Hausregeln von SPEC verstoßen, aber da sind eher die Regeln fragwürdig als der Verstoß.

Offensichtlich hat der optimierte Code immer noch die selben Berechnungen und das selbe Ergebnis gebracht, und nicht wie die Behauptung "Cheat" impliziert, irgendwas einfach weggelassen.

SPEC wirft der Optimierung "narrow applicability" vor. Wenn dem so ist, dann werfe ich dem Benchmark "narrow applicability" vor, und stelle den an sich in Frage.

Leonidas
2024-02-18, 03:38:44
Kann man so sehen. Aber andererseits kann man auch sagen: Der Code beschleunigt nur den Benchmark. Wo ist der Vorteil für den Nutzer? Wo ist das Äquivalent bei realen Anwendungen?

Gast
2024-02-18, 07:29:16
Kann man so sehen. Aber andererseits kann man auch sagen: Der Code beschleunigt nur den Benchmark. Wo ist der Vorteil für den Nutzer? Wo ist das Äquivalent bei realen Anwendungen?

Der Code beschleunigt alle Anwendungen mit der gleichen narrow applicability.
Und wie der andere Gast sagt, mit der Aussage behaupten spec selber indirekt, dass ihr benchmark für die performanceeinordnung nur begrenzt was taugt.

Leonidas
2024-02-18, 09:23:20
Der Code beschleunigt alle Anwendungen mit der gleichen narrow applicability.

Das hat die SPEC was anderes hierzu geschrieben. Wer hier mehr Recht hat, kann ich allerdings leider nicht ergründen, dass können nur entsprechende Techniker.

Denniss
2024-02-18, 13:47:16
Der Code hat rein auf den Bechmark optimiert und nichts weiter. Dies ist laut Spec nicht erlaubt weil dadurch das Ergebnis verfälscht wird. Das ist quasi so als ob der Code da einen Spickzettel mit der Teillösung eingebaut hat und dort kaum was berechnet werden musste

Gast
2024-02-18, 18:57:58
Wo ist der Vorteil für den Nutzer? Wo ist das Äquivalent bei realen Anwendungen?

Die Optimierung würde das Äquivalent in realen Anwendungen genauso beschleunigen. Wenn es dieses nicht gibt ist der Benchmark an sich zu hinterfragen, nicht die Optimierung darauf.

Gast
2024-02-18, 18:59:40
Das ist quasi so als ob der Code da einen Spickzettel mit der Teillösung eingebaut hat und dort kaum was berechnet werden musste

Eben nicht, der Code hat genau das selbe berechnet, nur Datenstrukturen effizienter angeordnet.

Wenn man das als "Cheating" bezeichnet muss man OOOE generell als "Cheating" bezeichnen.

OpenVMSwartoll
2024-02-18, 21:39:32
Eben nicht, der Code hat genau das selbe berechnet, nur Datenstrukturen effizienter angeordnet.

Wenn man das als "Cheating" bezeichnet muss man OOOE generell als "Cheating" bezeichnen.

Ich habe gerade nachgelesen. Der Code hat exakt zwei Benchmarks beschleunigt und wurde dann wieder entfernt.

Nicht, dass Intel erstmalig mit dem Finger in der Keksdose erwischt worden wäre...

Exxtreme
2024-02-18, 21:49:15
Eben nicht, der Code hat genau das selbe berechnet, nur Datenstrukturen effizienter angeordnet.

Wenn man das als "Cheating" bezeichnet muss man OOOE generell als "Cheating" bezeichnen.

Wenn der Compiler das ausschließlich in diesem Benchmark macht und nirgendwo sonst dann wäre das sehr wohl Cheating.

Leonidas
2024-02-19, 03:05:37
Muss ich auch so sagen. Wenn, dann kann die Darstellung der SPEC falsch sein. Ist jene hingegen korrekt, dann ist die Sachlage eindeutig: Beschleunigung allein von Benchmarks = Cheating. RealWorld sollte beschleunigt werden, nicht ausschließlich Benchmarks.

Gast
2024-02-19, 10:21:21
Wenn der Compiler das ausschließlich in diesem Benchmark macht und nirgendwo sonst dann wäre das sehr wohl Cheating.

Der würde das genauso bei jeder anderen Software machen, die den selben Code verwendet.

Wenn keine andere Software den selben Code verwendet ist das nicht der Fehler vom Compiler.

Denniss
2024-02-20, 00:05:52
Der würde das genauso bei jeder anderen Software machen, die den selben Code verwendet.

Wenn keine andere Software den selben Code verwendet ist das nicht der Fehler vom Compiler.Whitewashing

Exxtreme
2024-02-20, 00:10:52
Der würde das genauso bei jeder anderen Software machen, die den selben Code verwendet.

Wenn keine andere Software den selben Code verwendet ist das nicht der Fehler vom Compiler.

Also hat VW beim Abgasskandal auch nicht beschissen, richtig? Denn wenn die Fahrer das gleiche Fahrprofil hätten wie ein hängendes Auto auf einem Prüfstand dann würde das Auto ja auch weniger Stickstoffdioxid in die Luft blasen, richtig?

Wirklich zu blöd, dass die Gerichte diese Genialität von VW nicht erkannt haben ...

Gast
2024-02-20, 10:46:30
Also hat VW beim Abgasskandal auch nicht beschissen, richtig? Denn wenn die Fahrer das gleiche Fahrprofil hätten wie ein hängendes Auto auf einem Prüfstand dann würde das Auto ja auch weniger Stickstoffdioxid in die Luft blasen, richtig?

Hätte VW nur das gemacht hätten sie auch nicht betrogen. Dass der damals verwendete NEFZ nichts mit dem realen Betrieb zu tun hat ist und war nicht die Schuld der Hersteller, und war auch schon lange vorher bekannt.

VW hat allerdings betrogen, da man erkannt hat, ob ein Messgerät am CANBUS hängt und dann den Motor in einem anderen Betriebszustand betrieben hat, selbst wenn der Kunde exakt nach NEFZ gefahren wäre, hätte er nicht die Abgaswerte erreichen können, die auf dem Papier standen.