Futuremark bevorzugt Intel-Prozessoren?

@gruffi, (erledigt)

Ließt du Neros Postings nicht, er hat selbst geschrieben das Intel es den Herstellern sehr leicht macht, ihren Compiler zu verwenden, während bei AMD mehr Handarbeit gefragt ist. Also wenn du mir was falsches unterstellt, muß das auch Hand und Fuß haben, und dazu gehört es nummal alle Postings zu lesen, und nicht nur Wortfetzen.

Nochmal zu Intel, deren Microcode ist Updatebar ! , AMD bietet sowas nicht an. Es gab letztes nen Microsoft-Update das ab Pentium 3 oder noch früher bis zur aktuellsten Intel-CPU ein Microcodeupdate beinhaltet hatte. Aber es ist auch nicht auzuschließen, das Intel im Gegensatz zu VIA, eine Art Sperre drin hat die diese CPU-ID Umgehung nicht ermöglicht.

@Nero24,

Gut wenn AMD, bisher auch ohne eigenen Compiler gut gefahren ist und diese Situation nicht änderbar ist, wie es @Obrien beschrieben hat, und sich die Hersteller dahingehend nicht bemühen AMD zu optimieren, sind wir nun in einer Sackgasse gelandet für die es scheinbar keine Lösung gibt. Damit sehe ich dann das Thema als erledigt an. Den es sieht ja wohl nicht so aus das sich das in Zukunft ändern wird, oder was soll man bitte machen ?

@bbot,

ich habe doch geschrieben das das Programm Ur-Alt ist und man daher nicht nachtragen kann, wenn es auf aktuellen Intel CPUs nunmal besser läuft, auch wenn es ja wie schon beschrieben für den Pentium 1 optimiert worden ist, da es von AMD quasi nichts gab. Aber das wurde ja bereits erwähnt, unter anderem auch das das Programm neu compiliert worden ist, scheinbar wird das alles überlesen.

@SPINA, (erledigt)

hmm habe da andere Infos, in den letzten großen Bugs von AMD, wurde dieses Thema aufgegriffen. Und da wurde auch erwähnt das hier Intel im Vorteil ist, und man bei AMD nicht so ohne weiteres was updaten könnte. Würde jetzt aber das betreffende Zitat auf die schnelle nicht finden.

@brabe, da stimme ich dir zu der Antwort im Grafikkartenbeispiel !
 
Zuletzt bearbeitet:
Und da wurde auch erwähnt das hier Intel im Vorteil ist, und man bei AMD nicht so ohne weiteres was updaten könnte.
Also Microcode Updates gibt es definitiv auch bei AMD. Allerdings kommen diese bisher wohl nur über Updates für das System BIOS des Mainboardherstellers. Intel ist da wesentlich flexibler. So koopieriert man mit Microsoft und Microcode Updates wurden schon über Windows Update ausgeliefert. Beispielsweise als einige schwere Bugs im B2 Stepping des Core 2 Duo gefunden wurden und kürzlich bei weiteren schweren Bugs im G0 Stepping des Core 2 Duo und Core 2 Quad.

Siehe auch: http://support.microsoft.com/kb/936357
 
Also Microcode Updates gibt es definitiv auch bei AMD. Allerdings kommen diese bisher wohl nur über Updates für das System BIOS des Mainboardherstellers. Intel ist da wesentlich flexibler. So koopieriert man mit Microsoft und Microcode Updates wurden schon über Windows Update ausgeliefert. Beispielsweise als einige schwere Bugs im B2 Stepping des Core 2 Duo gefunden wurden und kürzlich bei weiteren schweren Bugs im G0 Stepping des Core 2 Duo und Core 2 Quad.

Gut, dann wäre dieser Punkt erledigt. :)
 
Kann AMD nicht selbst einen Compiler rausbringen?
Vielleicht sogar einen AMD64 basierenden.
Könnten sie sicherlich. Die Frage ist nur, inwiefern sich das lohnt. Hier argumentieren einige Leute zwar mit fehlenden finanziellen Mitteln, das ist aber recht kurzsichtig. Das Problem an einem eigenen Compiler ist vielmehr ein zeitliches bzw das des Know-How. Es würde Jahre dauern, um etwas konkurrenzfähiges auf die Beine zu stellen. Da fährt man kurzfristig besser, wenn man sich auf bestehende Projekte konzentriert, wie GCC.

Vor einigen Jahren hat unser EDV-Lehrer in der Schule gemeint, dass es bald 128bit CPUs geben wird. Ist nun schon lange her... ist das Überhaupt notwendig? Wäre diese Technikentwicklung nicht schon überfällig und sogar schon 256 od 512 ausständig?? Würde das überhaupt was bringen??
Grundsätzlich haben aktuelle x86 CPUs eine 64 Bit Architektur, und das wird auch noch länger so bleiben. Eine 256 Bit SIMD Pipeline wird mit AVX kommen. Und 256 Bit lohnen sich definitiv, gerade was FP Berechnungen betrifft. Normalerweise wird bezüglich FP einfache (32 Bit) oder doppelte Genauigkeit (64 Bit) entsprechend IEEE verwendet. Die aktuelle SSE Pipeline (128 Bit) kann aber nur einfache Genauigkeit bei zB 4-fach Vektoren mit einer Instruktion verarbeiten. Benötigt man doppelte Genauigkeit, sind hierfür zwei Instruktionen notwendig. Mit einer 256 Bit Pipeline kann man dann auch 4-fach Vektoren mit doppelter Genauigkeit in einem Rutsch verarbeiten.
Und je breiter die Pipeline, desto höher die nutzbare Genauigkeit. IEEE hat afaik momentan bis 128 Bit Genauigkeit spezifiziert. Wobei sich die Frage stellt, wie sinnvoll das im Consumer Bereich ist. Eine 256 Bit SIMD Pipeline sollte hier auf lange Sicht für CPUs jedenfalls erstmal reichen. Wobei Intel beim Larrabee ja bereits auf eine 512 Bit SIMD Pipeline und x86 setzen soll. Allerdings ist das auch wieder eine etwas andere Baustelle.

Aber wie hat das Zidane so schön gesagt "Intel Bashing ist In".
Ach, "AMD Bashing" nicht, oder wie? Leute, die mit solchen Aussagen argumentieren, sind oftmals die unsachlichsten überhaupt. Tragt etwas Konstruktives bei oder haltet einfach die Füsse still. Damit wäre allen am besten geholfen.

Den CPU Name String kann man auch beim AMD ändern
Und wie? (es ist zudem der Hersteller String ausschlaggebend, nicht der CPU String)

Die Diskussion hat irgenwie wenig mit der Meldung zu tun. Es geht hier um einen Benchmark, der bei Intels bessere Ergebnisse Zaubert, und nicht um compiler, und wie diese auf die achsotollen intels optimiert sind, oder auch nicht.
Dir ist aber schon bewusst, dass Compiler dafür verantwortlich sind, aus Quellcode ausführbare Anwendungen zu erzeugen? Und dass Compiler auch unterschiedliche Codepfade erzeugen, was wiederum das Thema ist? Wie hier schon mehrfach erwähnt wurde, ich würde Futuremark auch erstmal keine Absicht unterstellen.

Ich verstehe nur nicht, warum die NANO als INTEL Version schneller ist als eine NANO als AMD Version. Anscheinend hat sie doch alles, was ein Intel auch zu bieten hätte. Aber warum wird nicht nach den Erweiterungen gefragt, sondern nach dem CPU Typ? Kann man nur abfragen, ob eine CPU SSE3 hat, wenn man weiss welche CPU es ist?
Grundsätzlich ist cpuid nicht standardisiert. Es kann also von Hersteller zu Hersteller Unterschiede geben. Wobei die Basis Feature Flags zumindest bei AMD und Intel weitestgehend gleich sind. SSE3 findet man zB unter der cpuid Funktion 1, ecx, Bit 0. Es gibt aber auch Hersteller spezifische Feature Flags, wo man natürlich erstmal wissen muss, um welche CPU es sich handelt.

Ließt du Neros Postings nicht, er hat selbst geschrieben das Intel es den Herstellern sehr leicht macht, ihren Compiler zu verwenden, während bei AMD mehr Handarbeit gefragt ist.
Und was genau stellst du dir unter diesem "sehr leicht machen" vor? :] Die Verwendung des Intel Compilers ist auch nicht anders als das bei anderen Compilerherstellern der Fall ist. Was genau willst du also aussagen?
 
den 64-Bit Compiler (für K-8.) von microsoft verwenden?
"The 64-bit build environment in the release of the Microsoft® Windows® Server 2003 DDK includes a 64-bit compiler you can use to build and test 64-bit driver code that runs on AMD64 processors. The following sections describe the AMD64-specific aspects of this compiler."
Quelle: http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_11467_11511,00.html

Auch bringt der neuere Microsoft Compiler "Orcas" sehr gute Leistung und kann für AMD K-10 optimiert compilieren.
http://developer.amd.com/cpu/partners/pages/WindowsZone.aspx
http://developer.amd.com/documentation/articles/Pages/972007174_2.aspx
 
Zuletzt bearbeitet:
@gruffi,

die Antwort von Nero, wenn dir das nicht paßt nerv ihn und nicht mich, da er davon mehr versteht als ich, das sollte du ja wohl noch hinbekommen. :]


Den gibt es! AMD hat keinen eigenen Compiler! Wenn ein Software-Hersteller für AMD optimieren will, muss er den entsprechend optimierten Codeteil manuell per Assembler schreiben :o oder zumindest die AMD Math Libraries verwenden (was ebenfalls ein Umschreiben des Codes per Hand erfordert) was sich natürlich kaum ein kommerziell arbeitendes Unternehmen antut (Zeit ist Geld). Die meisten Software-Häuser verwenden im Windows-Bereich ja sowieso den Microsoft-Compiler. Wer aber unbedingt auf die Architektur eines Intel-Prozessors optimieren möchte, dem macht es Intel leicht, denn Intel hat einen eigenen Compiler. Einfach einbinden in die Microsoft Visual Studio Entwicklungsumgebung und statt der zaghaften Microsoft-Optimierungen (i386, i586 oder i686, MMX/SSE ja/nein) die heftigen Optimierungen des Intel-Compilers auf ganz spezielle CPUs auswählen vor dem bauen der Binaries. Da muss nichts zeitaufwändig per Hand umprogrammiert werden. Einfach Haken setzen und fertig. Das ist der Unterschied bei der Optimierung auf AMD und/oder Intel CPUs. Ich denke das beantwortet, wieso die Software-Häuser es sich kaum antun auf AMD-CPUs zu optimieren. ;)

Aber beim Fall SuperPI hat das gar nichts damit zu tun, ob der Programmierer auf eine Intel-CPU optimieren wollte oder nicht. Im Jahr 1995 gab es schlichtweg keine anderen
Architekturen als die von Intel. Der K5, AMDs erste eigene CPU-Architektur, war noch gar nicht auf dem Markt und die AMD-CPUs davor waren Clones von Intel-Prozessoren. Damals stellte sich die Frage also noch gar nicht, auf welchen CPU-Hersteller man optimieren soll. Dass heute, 13 Jahre nachdem SuperPI compiliert wurde, die ein oder andere aktuelle CPU aufgrund ihrer Architektur besser mit dem Uralt-Compilat zurecht kommt, konnte damals gewiss noch niemand beabsichtigt oder gar beeinflusst haben. Das ist heute eben aus verschiedenen Gründen so, aber man kann zumindest anhand des internen Aufbaus der CPUs erklären wieso das so ist (siehe mein letztes Posting).

Aber darum geht's in dem Artikel ja eigentlich gar nicht, oder? ;) Hier geht's um den Futuremark PCMark2005 und dessen merkwürdigem Verhalten beim Ändern der Hersteller-ID auf einem VIA-System.

Damit wäre auch diese Frage für mich erledigt, weitere Fragen dazu werden ignoriert, der Rest den ich oben zitiert habe kann noch Stellung nehmen.
 
Zuletzt bearbeitet:
Ja, da hat Nero24 scheinbar ein paar falsche Vorstellungen. Es gibt genauso Compiler, die auch Optimierungen für AMD anbieten. Zudem werden spezielle Hersteller Optimierungen sowieso nur selten genutzt. IdR wird allgemein optimiert (inlinig, loop unrolling, fast fp, simd, etc). Deswegen braucht AMD noch lange keinen eigenen Compiler.
Die AMD Math Library ist zudem noch eine etwas andere Geschichte und hat mit dem Compiler selbst erstmal nichts zu tun.
Bevor du also irgendwas nachplapperst, solltest du in Zukunft besser erstmal wissen, wovon du sprichst. ;)
 
@Zidane

Was willst du eigentlich hier (im Thema), außer "Stimmung" zu machen? *noahnung*

Was wirklich Konstruktives kam von dir nicht wirklich herum... ;)
 
Nero Braucht einen grösseren Ansehen-Balken *chatt*

Könnt ihr mal aufhören Erbsen zu zählen.
Die Diskussion hat irgenwie wenig mit der Meldung zu tun. Es geht hier um einen Benchmark, der bei Intels bessere Ergebnisse Zaubert, und nicht um compiler, und wie diese auf die achsotollen intels optimiert sind, oder auch nicht.
Vielleicht ist Sysmark ja mit dem Intel Compiler kompiliert? ;D

Kann AMD nicht selbst einen Compiler rausbringen?
Vielleicht sogar einen AMD64 basierenden.
Viel zu viel Arbeit. AMD unterstützt jedoch GCC. GCC ist halt nur um Längen langsamer als Intels eigener.

Und wie? (es ist zudem der Hersteller String ausschlaggebend, nicht der CPU String)
Man kann ihn nicht ändern. Du kannst aber den Call abfangen und dem Programm dann vorgaukeln was du willst
 
Im Fall von SuperPi bin ich wohl der einzigste der es nicht so sieht, weil ein K8 einen Pentium 4 hier schlägt ! , sollte ja nicht so sein, wenn der Code rein auf Intel optimiert wäre, zumal ein AMD Prozessor ja ebenfalls zu den IBM kompatiblen CPUs gehört.

Es ist ein ungeeigneter Benchmark [Die Eignung beschränkt sich auf Performancevergleiche unter CPUs der gleichen Familie].

Und warum regt man sich darüber auf, verstehe ich nicht. Weil dies bei z.b Spielen nicht bemängelt wird, das manches Spiel auf ATI/AMD Karten schneller läuft als bei Nvidia und umgekehrt. Irgendwie scheint das hier ne verkehrte Welt zu sein. Wenn man sich darüber aufregt, dann bitte auf alles schimpfen, was Hersteller A zu B oder umgekehrt bevorteilt oder sich besser und gut ist.

Warum? Der Sinn des Benchmarks: Man möchte ein möglichst einfaches Programm, mit dem man eine möglichst zuverlässige Aussage über die Performance eines Systems machen kann.

Wird ein System wie in hier gezeigter Weise bevorteilt geht das eben genau gegen den Sinn eines Benchmarks. Es ist Betrug an allen Nutzern und hat per se überhaupt gar nix mit AMDs Fähigkeit zu tun. Wenn, dann hat es was mit Moral zu tun, und die findet man bei Intel ja reichlich...

Ich habe keine Ahnung, warum das zu ner Intel / AMD Bashing Diskussion führen musste...
 
Zuletzt bearbeitet:
Hallo
ich würde mich mal als ambitionierten Laien bezeichnen, und versteh vieles von dem was hier geschrieben wird nicht.
könntet Ihr mir sagen welche der beiden Aussage richtig ist?

1. Futuremark erkennt anhand der Vendor-ID um welchen Prozessor es sich handelt, testet das Feature-Set und legt so fest, was dieser abzuarbeiten hat. je nach Prozessor mit einem anderen Compiler. Dies muss nicht immer etwas mit dem tatsächlichen Fähigkeiten des Prozessors zu tun haben,denn sonst würde der VIA Nano unter der Vendor-ID Intel nicht besser abschneiden als mit AMD Vendor-ID.
2. Futuremark erkennt anhand der Vendor-ID um welchen Prozessor es sich handelt, testet das Feature-Set und legt so fest, was dieser abzuarbeiten hat, dann wird bei allen derselbe Compiler verwendet.Da der VIA Nano je nach Vendor-ID unterschiedliche Ergebnisse bringt, muss es an der Bewertung liegen.

Falls beide Aussagen falsch sind würde ich mich freuen wenn jemand versuchen könnte eine allgemein verständliche, richtige Zusammenfassung zu geben.
 
Hallo
ich würde mich mal als ambitionierten Laien bezeichnen, und versteh vieles von dem was hier geschrieben wird nicht.
könntet Ihr mir sagen welche der beiden Aussage richtig ist?

1. Futuremark erkennt anhand der Vendor-ID um welchen Prozessor es sich handelt, testet das Feature-Set und legt so fest, was dieser abzuarbeiten hat. je nach Prozessor mit einem anderen Compiler. Dies muss nicht immer etwas mit dem tatsächlichen Fähigkeiten des Prozessors zu tun haben,denn sonst würde der VIA Nano unter der Vendor-ID Intel nicht besser abschneiden als mit AMD Vendor-ID.
2. Futuremark erkennt anhand der Vendor-ID um welchen Prozessor es sich handelt, testet das Feature-Set und legt so fest, was dieser abzuarbeiten hat, dann wird bei allen derselbe Compiler verwendet.Da der VIA Nano je nach Vendor-ID unterschiedliche Ergebnisse bringt, muss es an der Bewertung liegen.

Falls beide Aussagen falsch sind würde ich mich freuen wenn jemand versuchen könnte eine allgemein verständliche, richtige Zusammenfassung zu geben.

Wenns Dein Englisch zuläßt, dann les gleich den Orginallink bei aceshardware, den ich im von Nero verlinkten Thread gepostet hab, hier nochmal der Link:
http://www.planet3dnow.de/vbulletin/showthread.php?t=336249

Kurz:
Bin zu 99,9% sicher, dass das an nem verwendeten Intel Compiler lag. Gibt/Gab schon genügend andre Beispiele in der Vergangenheit, bei denen der Intel Compiler der Schuldige war, glaub kaum, dass das Zufall ist.

ciao

Alex
 
@Zidane

Was willst du eigentlich hier (im Thema), außer "Stimmung" zu machen? *noahnung*

Was wirklich Konstruktives kam von dir nicht wirklich herum... ;)

Naja, wenn man bedenkt das dies dein einzigster Beitrag ist, von den ganzen 3 Seiten, solltest du dir selbst die Frage stellen, was du mit deinem sinnfreien Posting hier eigentlich bezwecken willst. Themenbezogen ist er jedenfalls nicht :]

@BLJ,

du solltest die Beiträge schon mit Namen zitieren, da man schnell überlesen kann von wem sie stammen. Was Benchmarks allgemein angeht, können die lediglich theoretisch zeigen, was die CPUs leisten können, da die Praxis dann meist anders aussieht ist ja nicht ungewöhnlich. Man kauft sich ja nicht nur ein PC weil man diesen dann benchen will. Und wenn im Fall von Featuremark zu Intel hin optimiert ist, wäre das auch noch legitim solange man nicht Offiziell ankündigt beide CPUs voll zu unterstützen, das wäre dann Betrug. Ansonsten muß man sich damit abfinden, ich habe da kein Problem mit, blöd für die anderen halt,. Da nutzt auch das rumgeheule nicht, dadurch wird und kann man nichts erreichen. Also bleibt nur die Frage offen ob Featuremark betrogen hat oder nicht !
 
Zuletzt bearbeitet:
Was Benchmarks allgemein angeht, können die lediglich theoretisch zeigen, was die CPUs leisten können, da die Praxis dann meist anders aussieht ist ja nicht ungewöhnlich. Man kauft sich ja nicht nur ein PC weil man diesen dann benchen will. Und wenn im Fall von Featuremark zu Intel hin optimiert ist, wäre das auch noch legitim solange man nicht Offiziell ankündigt beide CPUs voll zu unterstützen, das wäre dann Betrug. Ansonsten muß man sich damit abfinden, ich habe da kein Problem mit, blöd für die anderen halt,. Da nutzt auch das rumgeheule nicht, dadurch wird und kann man nichts erreichen. Also bleibt nur die Frage offen ob Featuremark betrogen hat oder nicht !

Hm, welchen Sinn hat dann ein Benchmark noch?
 
Was Benchmarks allgemein angeht, können die lediglich theoretisch zeigen, was die CPUs leisten können, da die Praxis dann meist anders aussieht ist ja nicht ungewöhnlich. Man kauft sich ja nicht nur ein PC weil man diesen dann benchen will.


Ach ja, stimmt, hab ich ganz vergessen.
Weils keine perfekte Staatsform gibt leben wir am besten in Anarchie, nicht wahr?

Nur weil man keinen perfekten Benchmark machen kann, heisst das noch lange nicht, dass man sie extra schlechter machen soll.

Und sich dabei noch Neutralität auf die Fahnen schreiben... pha..


was heisst überhaupt 'voll unterstützen' ?
Und wenn im Fall von Featuremark zu Intel hin optimiert ist, wäre das auch noch legitim solange man nicht Offiziell ankündigt beide CPUs voll zu unterstützen, das wäre dann Betrug.

Wie soll man denn den Begriff interpretieren? Du meinst wohl, dass der Bench alle Funktionseinheiten / Befehle einer CPU benutzt? Ist das realistisch und nützlich?
Oder meinst du, dass der Bench maximal-möglich für jede CPU optimiert sein soll? Ist das realistisch und nützlich?

Ne. Aber: wir müssen gar nicht über Praxisnah diskutieren. Wenn ein Bench in direkter Abhängigkeit der VendorID [d.h. nicht durch die Leistung der CPU] die Ergebnisse ändert, so ist das (keine rechtliche Wertung) ganz einfach eine Verarschung.

Dann verdienen Sie auch jegliches Gebashe.



ich würde Futuremark auch erstmal keine Absicht unterstellen.
Das nicht, aber seeeeeehr schlechte QA... ;-)
 
Zuletzt bearbeitet:
............

Kurz:
Bin zu 99,9% sicher, dass das an nem verwendeten Intel Compiler lag. Gibt/Gab schon genügend andre Beispiele in der Vergangenheit, bei denen der Intel Compiler der Schuldige war, glaub kaum, dass das Zufall ist.

ciao

Alex

Das würde ja bedeuten ,dass der Compiler, unabhänig vom Feature-Set, einer AMD CPU unnötiger Weise einen aufwändigeren Rechenweg vorgibt um seine Leistung zu bremsen.
Hat Microsoft, die ja in einer ähnlichen Monopolstellung sind, nicht genau für solche Benachteiligungen anderer Anbieter schon ein paar hundert Millionen Strafe zahlen müssen?
 
Das würde ja bedeuten ,dass der Compiler, unabhänig vom Feature-Set, einer AMD CPU unnötiger Weise einen aufwändigeren Rechenweg vorgibt um seine Leistung zu bremsen.
Jupp ... der Sachverhalt steht auch mit in der AMD Klageschrift gegen Intel, ist wie besagt schon länger / lange genug bekannt.

ciao

Alex
 
Intressant finde ich das viele hier davon ausgehen das es sich nur um 1 Benchmark handelt wo dieses zutrifft.

ich zweifel das an, bin der meinung viele Benchmarks machen es ähnlich, dazu kommen dann noch autoren die Werte nicht "deuten".
Da fällt mir spontan ein Phenom Usertest ein in dem dieser zwar weniger max. Frames in Farcry produzierte als ein Core2 aber mehr minimale Frames.
Was hier "wichtig" für ruckelfreies Spielen ist sollte klar sein.


Das problem mit der Optimierung ist in meinen augen viel ehr eingetreten als hier bisher genannt wurde! Das erste große Opfer der fehlende Optimierung war der K6-2 der dan 3DNOW in der Lage war den Intel P1 -P2 das fürchten zu lehren! Leider war Quake2 eine der wenigen wirklich drauf Optimierten Anwendungen! (hatte AMD das nicht sogar selbst übernommen?)

Potenzial steckt noch gewaltig in AMD CPUs und ich denke mit optimiertem Code würde Intel kein Licht am ende des Tunnels sehen!
 
Das würde ja bedeuten ,dass der Compiler, unabhänig vom Feature-Set, einer AMD CPU unnötiger Weise einen aufwändigeren Rechenweg vorgibt um seine Leistung zu bremsen.

Der Intel-Compiler schaltet bei nicht Intel CPUs gleich ganze Instruction Sets ab, vornehmlich SSE. Und gerade die Befehle können viele Operationen sehr deutlich beschleunigen.
 
Der Intel-Compiler schaltet bei nicht Intel CPUs gleich ganze Instruction Sets ab, vornehmlich SSE. Und gerade die Befehle können viele Operationen sehr deutlich beschleunigen.

Wenn du SSE durch SSE2/SSE3/SSE4 ersetzt, kann man das so stehen lassen ;) [wobei ich mir bei SSE2 nicht so sicher bin]
 
Hm, welchen Sinn hat dann ein Benchmark noch?

Im Prinzip keinen, wenn geschummelt wird, wie in diesem Beispiel. oder im Fall von 3D Marks und Co wo Nvidia mehr negativ aufgefallen als ATI durch Optimierungen um mehr Punkte zu erreichen auf Kosten der Bildqualität. Wie du siehst, kann man sich ruhig diese Fragen stellen, da durch die Manipulation ein theoretischer vgl. nicht möglich ist.

@BLJ,

also wärst du dafür weiterhin, benches zu verwenden die andere nicht Intel CPUs ausbremsen, den gar keinen zu verwenden ist auch nicht die optimale Lösung. Ich denke die meisten fertig PC Käufer, benchen ihren Rechner noch nichtmal, und stellen sich somit die Frage erst gar nicht, wie man sie sich hier stellt.

Wer hat das gebashe verdient ?

Featuremark ja - sofern man den eine Absicht beweisen kann, wobei es ja offensichtlich ist, wie man es im VIA@Intel Beispiel sieht. Intel dagegen nicht, die liefern nur einen mögl. Compiler, wie MS auch.

Mit voll unterstützen meinte ich ehr, ohne Nachteile für kompatible CPUs, wie in der News beschrieben.

Wobei es mir trotzdem schwer fällt zu glauben, das eine einfache Änderung einer CPU ID wie bei VIA die Bremse lößt, da ja VIA und Intel hier sicher nicht die gleichen Instruktionen für die Abarbeitung verwenden, obwohl der Intel Compiler ja nicht auf VIA optimiert ist. Verstehe jedenfalls zuwenig davon, um das nachvollziehen zu können. Da es genug amdere Beispiele gibt, wo sowas möglich ist wenn gewisse Grundvorrausetzungen gleich sind, und bei anderen wiederum es nicht reicht quasi einfach eine Kennung zu ändern und schon läuft das. Den das andere CPUs mit einem Compiler für eine bestimmte CPU nicht optimal laufen, ist ja erstmal nichts ungewöhnliches, den dafür hätte man die Möglichkeit andere CPUs ebenfalls zu optimieren. Im VIA-Beispiel deute ich es so, das der Intel Compiler sehr wohl für VIA als geeignet erscheint sonst würde er durch die andere Kennung trotzdem nicht optimal laufen, wenn dem nicht so wäre.
 
Zuletzt bearbeitet:
Das nicht, aber seeeeeehr schlechte QA... ;-)
Das kann gut möglich sein. :)

Wenn du SSE durch SSE2/SSE3/SSE4 ersetzt, kann man das so stehen lassen ;) [wobei ich mir bei SSE2 nicht so sicher bin]
SSE3 und SSE4 sind meiner Erfahrung nach nicht so ausschlaggebend und werden nur wenig bis gar nicht genutzt. SSE(1) und SSE2 sind wiederum von der Anwendung abhängig, einfache oder doppelte Genauigkeit. Insofern hat PuckPoltergeist schon nicht ganz unrecht. Wobei ich eher vermute, dass der ICC zT zwar schon SSE für Nicht-Intel CPUs benutzt, vornehmlich aber nur skalare Instruktionen und keine vektorisierten.

Featuremark ja - sofern man den eine Absicht beweisen kann, wobei es ja offensichtlich ist, wie man es im VIA@Intel Beispiel sieht. Intel dagegen nicht, die liefern nur einen mögl. Compiler, wie MS auch.
Du argumentierst von einem falschen Standpunkt aus. Ich hatte es doch auch schon mal erwähnt. Lies dir die Beiträge bitte sorgfältiger durch. Anwendungssoftware im x86 Bereich wird normalerweise nicht auf eine spezielle Hardware hin optimiert. Entwickler nehmen den Compiler ihrer Wahl und hoffen, dass dieser möglichst gut optimierten Code erzeugt. Man müsste Futuremark also erstmal nachweisen, dass sie für spezielle Hardware optimiert haben. Aber selbst wenn das zutreffen würde, was ich gar nicht mal für so abwegig halte, könnte man das ihnen noch nicht vorwerfen. Im zweiten Schritt müsste man nachweisen, dass all dies vorsätzlich geschah, um eine bestimmte Hardware zu bevorteilen. Und dann wäre immer noch nicht geklärt, ob hier lediglich eine Teilschuld vorliegt oder doch mehr. Recht viel Konjunktiv, wenn du mich fragst. Im Gegensatz dazu steht der ICC, welcher einen recht zweifelhaften Ruf geniesst. Und egal was Futuremark letztendlich gemacht hat, der ICC hat den Rest erledigt.
 
Zuletzt bearbeitet:
Im Prinzip keinen, wenn geschummelt wird, wie in diesem Beispiel. oder im Fall von 3D Marks und Co wo Nvidia mehr negativ aufgefallen als ATI durch Optimierungen um mehr Punkte zu erreichen auf Kosten der Bildqualität. Wie du siehst, kann man sich ruhig diese Fragen stellen, da durch die Manipulation ein theoretischer vgl. nicht möglich ist.
Ein theoretischer wie praktischer Benchmark ist möglich und machbar, wenn man wie bei seriösen Benchmarks (z.B. SPEC) arbeitet. Solche Spielerein wie von Futuremark sind Dummfug, haben aber auf den Consumermarkt einen enormen Einfluss. Das lässt sich leider auch nicht ändern, weil hier der gigantische Spagat zwischen Einfachheit und Informationsgehalt geschafft werden muss. Aber gerade deshalb sollten Anbieter wie Futuremark seriös arbeiten. Nur ist das da wohl das gleiche wie bei der Presse. Was am meisten gelesen wird, ist der größte Schund.

Ich denke die meisten fertig PC Käufer, benchen ihren Rechner noch nichtmal, und stellen sich somit die Frage erst gar nicht, wie man sie sich hier stellt.
Nein, aber sie richten sich danach, was in Zeitschriften wie Computer-Blöd steht. Und da werden häufig gerne solche Benchmarks herangezogen.
 
Ein theoretischer wie praktischer Benchmark ist möglich und machbar, wenn man wie bei seriösen Benchmarks (z.B. SPEC) arbeitet. Solche Spielerein wie von Futuremark sind Dummfug, haben aber auf den Consumermarkt einen enormen Einfluss. Das lässt sich leider auch nicht ändern, weil hier der gigantische Spagat zwischen Einfachheit und Informationsgehalt geschafft werden muss. Aber gerade deshalb sollten Anbieter wie Futuremark seriös arbeiten. Nur ist das da wohl das gleiche wie bei der Presse. Was am meisten gelesen wird, ist der größte Schund.


Nein, aber sie richten sich danach, was in Zeitschriften wie Computer-Blöd steht. Und da werden häufig gerne solche Benchmarks herangezogen.

Das ist das andere Problem, viele verlassen sich auf die Testzeitschriften. Und was dabei rauskommt, sieht man ja im extremen beim Chip Mainboardtest :] , oder auch jenen Benchmarktest mit zusammengewürfelten Werten, oder Schlüsseln die man als Laie nicht nachvollziehen kann. Irgendwie ist man da in einer Zwickmühle. Oder den letzten Fall wo sich Zeitschriften schmieren lassen, und ein wenig was erfinden oder ein Gerät besser darstellen lassen, son Beweis habe ich ja hier liegen. Nur sind das Bereiche die den Geldbetrag von Computer Teilen übersteigen, z.b in der HiFi Szene - wo dann dementsprechende Hersteller damals in den 90er dahinterstanden z.b Sony.
 
Zurück
Oben Unten