Futuremark bevorzugt Intel-Prozessoren?

[Emploi]

....
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.

Genau, aber wie sieht die(eine) mögliche Lösung aus? Das wäre die Frage!

1. Sollte sich AMD mit MS synergieren und bessere (nicht Intel kompatible) Compiler entwickeln ? (Was verdammt viele Ressourcen verschlingen würde)...

2. Oder sollte eine richterliche Gewalt für die "Intel eigenen"(?) Verbesserungen vorgesehenen Compiler auch zwingend für die AMD CPUs nutzbar machen?

3. Dem frei-, monopol-kapitalistischen Intel Treibe(-r)n (gemeint sind die Compiler) freien Lauf gelassen werden?

4. ?? ?

 

[Gast29012019_2]

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.

Auf der einen Seite könnte man meinen, das der Intel-Compiler auf der einen Seite unabhängig von dem Programm wo er eingebunden wird, alleine bestimmt welche CPU diesen Compiler nutzen darf und welche nicht, und somit benachteiligt werden. Dann wiederum wird geschrieben, das das Thema zu komplex ist um das so einfach zu ermöglichen, da jede CPU anders ist, was wiederum dadurch ins absodum geführt wird, das eine einfach Änderung der CPU-ID die Bremse gelöst hat, was den Schluß zuläßt das jede CPU, selbst nen AMD mit Intel String (symbolisch) gesehen seine optimale Leistung erbringen kann. Irgendwie sind das für mich zuviele Möglichkeiten ?

 

[PuckPoltergeist]

Auf der einen Seite könnte man meinen, das der Intel-Compiler auf der einen Seite unabhängig von dem Programm wo er eingebunden wird, alleine bestimmt welche CPU diesen Compiler nutzen darf und welche nicht, und somit benachteiligt werden. Dann wiederum wird geschrieben, das das Thema zu komplex ist um das so einfach zu ermöglichen, da jede CPU anders ist, was wiederum dadurch ins absodum geführt wird, das eine einfach Änderung der CPU-ID die Bremse gelöst hat, was den Schluß zuläßt das jede CPU, selbst nen AMD mit Intel String (symbolisch) gesehen seine optimale Leistung erbringen kann. Irgendwie sind das für mich zuviele Möglichkeiten ?

Für einen Benchmark-Hersteller? Wohl kaum!

 

[tomturbo]

Der Intelcompiler soll gefälligst "neutralen" Code erzeugen wenn er verlangt wird. So einfach ist das.

Also wenn ich SSE2 setze sollen sie SSE2 Code bauen bei SSE3 dann SSE3 usw.
Darüber hinaus sollen von mir aus noch Spezialschalter für bestimmte prozessorspezifische Optimierungen sein, die dann aber eh kein Mensch unabsichtlich verwendet weil er sonst befürchten muss dass seine Kompilate wo anders nicht mehr lauffähig sind.

Es ist eine Sauerei wenn die Geschwindigkeit eines Binarys vom ausgelesenen Namen der CPU-ID abhängt.

lg
__tom

 

[gruffi]

Auf der einen Seite könnte man meinen, das der Intel-Compiler auf der einen Seite unabhängig von dem Programm wo er eingebunden wird, alleine bestimmt welche CPU diesen Compiler nutzen darf und welche nicht, und somit benachteiligt werden. Dann wiederum wird geschrieben, das das Thema zu komplex ist um das so einfach zu ermöglichen, da jede CPU anders ist, was wiederum dadurch ins absodum geführt wird, das eine einfach Änderung der CPU-ID die Bremse gelöst hat, was den Schluß zuläßt das jede CPU, selbst nen AMD mit Intel String (symbolisch) gesehen seine optimale Leistung erbringen kann. Irgendwie sind das für mich zuviele Möglichkeiten ?

Nein. Das Thema ist in der Tat ziemlich komplex. Ich habe eher das Gefühl, du weisst nicht wirklich, was ein Compiler ist. Dieser wird nirgendwo in ein "Programm eingebunden". Genauso wenig "nutzt eine CPU einen Compiler".
Ein Compiler ist im Grunde nichts anderes als ein stinknormales Programm. Stell dir das einfach als eine Art Übersetzer vor. Du hast zB einen Quellcode, welcher von Entwicklern in einer Hochsprache wie C++ geschrieben wurde. Für Menschen ist dieser Code noch recht verständlich. Ein Prozessor kann damit aber nichts anfangen. Damit sich dies ändert, wird der Quellcode in Maschinencode oder Zwischencode (Interpreter) übersetzt. Das passiert einmalig und auch nur an dieser Stelle kommt der Compiler zum Zuge. Anschliessend wird der übersetzte Code direkt vom Prozessor, oder im Falle von Zwischencode von einer VM, verarbeitet. Hier interessiert der Compiler selbst überhaupt nicht mehr. Wohl aber, WIE er übersetzt hat.

 

[Emploi]

Auf der einen Seite könnte man meinen, das der Intel-Compiler auf der einen Seite unabhängig von dem Programm wo er eingebunden wird, alleine bestimmt welche CPU diesen Compiler nutzen darf und welche nicht, und somit benachteiligt werden. Dann wiederum wird geschrieben, das das Thema zu komplex ist um das so einfach zu ermöglichen, da jede CPU anders ist, was wiederum dadurch ins absodum geführt wird, das eine einfach Änderung der CPU-ID die Bremse gelöst hat, was den Schluß zuläßt das jede CPU, selbst nen AMD mit Intel String (symbolisch) gesehen seine optimale Leistung erbringen kann. Irgendwie sind das für mich zuviele Möglichkeiten ?

Oh Mann, alleine bestimmt das Programm (nicht der Compiler) /was jetzt mehrere Maschinencodesseqenzen zur Auswahl hat/, die im übrigen durch Compiler zuvor erzeugt wurden (absolut unerheblich was dafür für eine CPU benutzt wurde, die illegalen Opscodes (gibt es die noch?) wurden doch nach dem 6501/Z80 abgeschafft ) , was ausgeführt wird oder nicht....

 

[Gast29012019_2]

Der Intelcompiler soll gefälligst "neutralen" Code erzeugen wenn er verlangt wird. So einfach ist das.

Also wenn ich SSE2 setze sollen sie SSE2 Code bauen bei SSE3 dann SSE3 usw.
Darüber hinaus sollen von mir aus noch Spezialschalter für bestimmte prozessorspezifische Optimierungen sein, die dann aber eh kein Mensch unabsichtlich verwendet weil er sonst befürchten muss dass seine Kompilate wo anders nicht mehr lauffähig sind.

Es ist eine Sauerei wenn die Geschwindigkeit eines Binarys vom ausgelesenen Namen der CPU-ID abhängt.

lg
__tom

Mag ja sein, das der Intel-Compiler das bereits tut. Er findet eine Intel CPU und schaltet alles verfügbare frei, wird nun eine andere CPU eingebaut wird dies auch erkannt und es kommt zum Einsatz eines "Kompatibilitätsmodus" der zwangsläufig nicht schneller sein muß. Sonst stimme ich dir zu, so sollte es nicht sein !

@gruffi, @Emploi -

wurde demnach nur den Schluß zulassen, das der sprich "Intel-Compiler" und somit quasi Intel alleine die Schuld trägt, das andere CPUs benachteiligt werden. Und Featuremark hier keine Schuld angelastet werden kann, da sie nur die Auswahl des MS o. Intel Übersetzers haben, und diesen Weg auch nutzen. Einen anderen Schluß läßt es für mich jedenfalls nicht zu.

 

[PuckPoltergeist]

Mag ja sein, das der Intel-Compiler das bereits tut.

Nein, das tut er eben nicht. Der Intel-Compiler kennt nur die Optimierungsstufen für verschiedene Intel-CPUs. Dazu baut er eine Abfrage in den Code ein, der einen separaten Kompatibilitätsmodus für nicht-Intel CPUs einschaltet. Und da sind dann sämtliche Optimierungen abgeschalten, egal ob die CPU irgend ein SSE kann oder nicht. Und ja, ich weiß das, ich hab mir den Code angesehen. Der Intel Compiler schaltet mehr Optimierungen ab, als notwendig wäre. Hier bevorzugt Intel ganz massiv die eigenen Produkte. Inwiefern das jetzt legitim ist, sei dahin gestellt. Für einen Benchmark-Bauer ist das jedoch inakzeptabel.

 

[Emploi]

...
das wäre zu prüfen ! - Inwieweit ist der Code für den Programmierer der zu schreibenden Software zugänglich, kann er den eingefügten Intel Compiler selbst anpassen, verändern, optimieren oder nicht. Oder kann er diesen nur integrieren und abwarten was passiert, denke aber nicht das man da selbst keinen Einfluss drauf hat, Oder ?

So gut wie gar nicht. Vor 15-20 Jahren war das noch möglich. Als die Assembler Programmier (jetzt Complierprogrammierer) noch wussten was sie da taten , jetzt werden solche "fähige" Leute mit Kusshand gesucht. 8) Der Großteil schreibt sowie nur noch in Hochsprachen... D.H. mittlerweile ist die prozessornahe Programmierung soweit von den Hochsprachen entfernt, wie die Antarktis von Europa... Einfach mal schnell etwas fixen (wie früher) ist nicht mehr möglich...

EDIT:

@PuckPoltergeist, bist du ein ASSIfähiger ?

 

[PuckPoltergeist]

wurde demnach nur den Schluß zulassen, das der sprich "Intel-Compiler" und somit quasi Intel alleine die Schuld trägt, das andere CPUs benachteiligt werden. Und Featuremark hier keine Schuld angelastet werden kann, da sie nur die Auswahl des MS o. Intel Übersetzers haben, und diesen Weg auch nutzen. Einen anderen Schluß läßt es für mich jedenfalls nicht zu.

Wie oben schon angedeutet, für einen Benchmark-Bauer ist das nicht akzeptabel. Wenn ich einen Benchmark herstelle, sollte ich auch wissen, was ich da messe, und wie ich das tue. Entweder ist Futuremark unfähig (was ich nicht glaube), oder sie bevorteilen einen Hersteller.
.
EDIT :
.

So gut wie gar nicht. Vor 15-20 Jahren war das noch möglich. Als die Assembler Programmier (jetzt Complierprogrammierer) noch wussten was sie da taten , jetzt werden solche "fähige" Leute mit Kusshand gesucht. 8) Der Großteil schreibt sowie nur noch in Hochsprachen... D.H. mittlerweile ist die prozessornahe Programmierung soweit von den Hochsprachen entfernt, wie die Antarktis von Europa... Einfach mal schnell etwas fixen (wie früher) ist nicht mehr möglich...

Ach Quark. Auch heute muss ein Entwickler noch wissen, was er da zusammen schreibt. Sonst bleibt er nicht allzu lange am Markt.

 

[Gast29012019_2]

Nein, das tut er eben nicht. Der Intel-Compiler kennt nur die Optimierungsstufen für verschiedene Intel-CPUs. Dazu baut er eine Abfrage in den Code ein, der einen separaten Kompatibilitätsmodus für nicht-Intel CPUs einschaltet. Und da sind dann sämtliche Optimierungen abgeschalten, egal ob die CPU irgend ein SSE kann oder nicht. Und ja, ich weiß das, ich hab mir den Code angesehen. Der Intel Compiler schaltet mehr Optimierungen ab, als notwendig wäre. Hier bevorzugt Intel ganz massiv die eigenen Produkte. Inwiefern das jetzt legitim ist, sei dahin gestellt. Für einen Benchmark-Bauer ist das jedoch inakzeptabel.

Wenn man wie du es sagst den Code sehen kann, kann man diesen für nicht Intel CPUs anpassen, oder hast Intel dafür gesorgt das dies nicht möglich ist, falls ja brauchte Featuremark nur den "Compiler" zu ändern, falls nicht was kann Featuremark dann tun um genau das in Zukunft zu verhindern, außer den Intel Compiler auszumotten und statt dessen den MS-Compiler zu verwenden, damit hätten die CPUs dann wohl gleiche Berechtigungen bei der Übersetzung.

 

[Emploi]

Ich gehe von kleinen bis mittelständischen Unternehmen aus, da wird jeder gleich frohlockend angekuckt. Wenn jemand meint, er kann das auch lesen (und verstehen!) was der Herr Compiler da rausgehauen hat.

 

[Gast29012019_2]

Für den Fall könnte AMD gegen Intel was ausrichten, sprich "Techologieaustausch" in Hardware vorhanden, jedoch in der Software nicht berücksichtigt. Umgekerht gehts auch, sollten 64-Bit Anwendungen bei AMD schneller laufen, als bei Intel. Ein Austausch sollte die Software berücksichtigen.

 

[PuckPoltergeist]

Wenn man wie du es sagst den Code sehen kann, kann man diesen für nicht Intel CPUs anpassen, oder hast Intel dafür gesorgt das dies nicht möglich ist, falls ja brauchte Featuremark nur den "Compiler" zu ändern, falls nicht was kann Featuremark dann tun um genau das in Zukunft zu verhindern, außer den Intel Compiler auszumotten und statt dessen den MS-Compiler zu verwenden, damit hätten die CPUs dann wohl gleiche Berechtigungen bei der Übersetzung.

Du weißt nicht wirklich, was ein Compiler ist und wie er funktioniert, oder? Ich habe mir den Programmcode genommen, und mit dem Intel-Compiler zum fertigen Programm übersetzt. Dieses Programm hab ich wiederum durch einen Disassembler gejagt, und mir den erzeugten Assemblercode angesehen. Und da waren Kniffe vom Intelcompiler zu sehen. Das lässt sich nicht so einfach ändern. Schon garnicht, weil man nicht weiß, ob man damit Sicherheitschecks abschaltet, die wirklich notwendig sind. Denn wie schon geschrieben, der Intelcompiler kennt nur Optimierungsstufen für Intel-CPUs. Es kann also sein, dass er nicht nur auf SSE(2,3,hastenichtgesehn) optimiert, sondern direkt auf Befehlssequenzen, die nur auf bestimmten Intel-CPUs zu korrekten Ergebnissen führen. Da nur Intel die kompletten Details kennt, wäre das ein absolutes Glücksspiel, darauf zu vertrauen, dass das überall korrekt funktioniert.
Ergo bleibt als Ergebnis nur, Compiler bzw. Compileroptionen zu verwenden, die auf allen Plattformen gleich bzw. ähnlich funktionieren. Alternativ kann man auch verschieden Versionen eines Benchmarks auf verschiedene Plattformen optimiert anbieten. Dass da manche Plattformen auf der Strecke bleiben, ist klar.

 

[Emploi]

...
Ergo bleibt als Ergebnis nur, Compiler bzw. Compileroptionen zu verwenden, die auf allen Plattformen gleich bzw. ähnlich funktionieren. Alternativ kann man auch verschieden Versionen eines Benchmarks auf verschiedene Plattformen optimiert anbieten. Dass da manche Plattformen auf der Strecke bleiben, ist klar.

+

Wenn man wie du es sagst den Code sehen kann, kann man diesen für nicht Intel CPUs anpassen, oder hast Intel dafür gesorgt das dies nicht möglich ist, falls ja brauchte Featuremark nur den "Compiler" zu ändern, falls nicht was kann Featuremark dann tun um genau das in Zukunft zu verhindern, außer den Intel Compiler auszumotten und statt dessen den MS-Compiler zu verwenden, damit hätten die CPUs dann wohl gleiche Berechtigungen bei der Übersetzung.

Eben, um es mit deinen Worten zu sagen: Hätten wir das auch geklärt!

Aber eben das wird nicht passieren... Wenn jemand GROSSES mit einem großen Geldsäckchen hinter Vielen steht.

 

[Scour]

Eben, sponsopred by Intel

Das sollte aber schon längst vor diesen Diskussionen bemerkt worden sein.

 

[Gast29012019_2]

Du weißt nicht wirklich, was ein Compiler ist und wie er funktioniert, oder? Ich habe mir den Programmcode genommen, und mit dem Intel-Compiler zum fertigen Programm übersetzt. Dieses Programm hab ich wiederum durch einen Disassembler gejagt, und mir den erzeugten Assemblercode angesehen. Und da waren Kniffe vom Intelcompiler zu sehen. Das lässt sich nicht so einfach ändern. Schon garnicht, weil man nicht weiß, ob man damit Sicherheitschecks abschaltet, die wirklich notwendig sind. Denn wie schon geschrieben, der Intelcompiler kennt nur Optimierungsstufen für Intel-CPUs. Es kann also sein, dass er nicht nur auf SSE(2,3,hastenichtgesehn) optimiert, sondern direkt auf Befehlssequenzen, die nur auf bestimmten Intel-CPUs zu korrekten Ergebnissen führen. Da nur Intel die kompletten Details kennt, wäre das ein absolutes Glücksspiel, darauf zu vertrauen, dass das überall korrekt funktioniert.
Ergo bleibt als Ergebnis nur, Compiler bzw. Compileroptionen zu verwenden, die auf allen Plattformen gleich bzw. ähnlich funktionieren. Alternativ kann man auch verschieden Versionen eines Benchmarks auf verschiedene Plattformen optimiert anbieten. Dass da manche Plattformen auf der Strecke bleiben, ist klar.

Da ich beruflich und im Hobby nicht programmiere kann ich das nicht wissen, es sei den man erklärt es mir, oder befragt das Wiki oder googelt danach. Ich beschränke mich lediglich auf das Auswechseln von defekter Hardware, PC Komplettbau, Einrichten von Mininetzwerken, DSL Anschlüsse, Warten und Konfigurieren von Telefonanlagen (Heimgebrauch) und Software nur Betriebsysteme und Problembehebung, alles das was von Bekannten, Kollegen und Freunden in Sachen PC-Probleme so auftritt und das nur zum Hobby. Beruflich mache ich was ganz anderes, und da kann ich mich nur auf das nötigste was bisher immer gereicht hat beschränken, um die Probleme zu lösen. Alles andere bleibt außen vor.
Betriebsysteme auch nur noch XP, alles ältere schon lange nicht mehr. Demnächst dann Vista, ..........

Auch wenn vermutlich mehr als 50% der P3dnow User hier, ihr PC Hobby zum Beruf gemacht haben, ich glaube wir brauchen eine neue offizielle Umfrage !

 

[Emploi]

Da ich beruflich und im Hobby nicht programmiere kann ich das nicht wissen, es sei den man erklärt es mir, oder befragt das Wiki oder googelt danach.

Eine ganz einfache Anfrage an Wiki hätte schon die gröbsten Missverständnisse (wenn auch für den Laien kompliziert) geklärtt: http://de.wikipedia.org/wiki/Compiler

Warum sollten wir uns nochmal die Finger fusselig schreiben, wenn es doch im mittlerweile größten Lexikon "DA" steht.

So wie durch dich in den letzten Seiten dieses Fadens dargestellt (verkaufst) hast (und das kannst du wirklich akzeptabel, ein paar Fremdwörter und schon klingt es professionell ), schienst du bis vor Kurzem der Experte schlecht hin zu sein? SRY...

Gruß
Emploi (der immer noch auf dem Knall wartet)

 

[gruffi]

Du weißt nicht wirklich, was ein Compiler ist und wie er funktioniert, oder? Ich habe mir den Programmcode genommen, und mit dem Intel-Compiler zum fertigen Programm übersetzt. Dieses Programm hab ich wiederum durch einen Disassembler gejagt, und mir den erzeugten Assemblercode angesehen.

Wieso so umständlich? Nahezu jeder bekanntere Compiler unterstützt Assembler Listings. Oder kann der ICC das nicht?

 

[Gast29012019_2]

Eine ganz einfache Anfrage an Wiki hätte schon die gröbsten Missverständnisse (wenn auch für den Laien kompliziert) geklärtt: http://de.wikipedia.org/wiki/Compiler

Warum sollten wir uns nochmal die Finger fusselig schreiben, wenn es doch im mittlerweile größten Lexikon "DA" steht.

So wie durch dich in den letzten Seiten dieses Fadens dargestellt (verkaufst) hast (und das kannst du wirklich akzeptabel, ein paar Fremdwörter und schon klingt es professionell ), schienst du bis vor Kurzem der Experte schlecht hin zu sein? SRY...

Gruß
Emploi (der immer noch auf dem Knall wartet)

Durch deinen ersten Beitrag auf Seite 3, hast du auch nicht grad danach den Eindruck gemacht, als wenn du davon irgendwas verstehen würdest, sondern lediglich einfach eine unpassende Bemerkung eingebracht. Aber ich späteren Verlauf nochmal die Kurve gekriegt.

Es gibt aber sicher Bereiche wo man ohne gutes (verkaufen) seiner Person, sehr schnell weg vom Fenster ist.

Zumindest habe ich von einigen Beiträgen die ich im laufe der Jahre gesehen habe, echt den Eindruck das die User ihren Beruf verfehlt haben, und im Marketing bestens aufgehoben wären.

Trotzdem wird mich das nicht daran hindern, auch in Zukunft in Themen zu posten für die ich mich interessiere, auch wenn diese außerhalb meines Fachbereiches liegen. Erweitern kann man sich immer, sofern es die Umgebung zuläßt. Es gibt auch sicher viele die weniger Ahnung als ich haben und hier posten, und trotzdem nicht auf den Gedanken kommen das ausnutzen. Habe auch kein Problem damit, zu sagen das ich halt nicht alles weiß oder wissen kann, und selbst wenn man alles erlesen kann und passend zusammentrickt, trotzdem Lücken vorhanden sind die man nicht ausfüllen kann.

PC ist in seinem Umfang der Themen zu Umfangreich als das man alles in max tiefe beherrschen könnte, sowohl Soft/Hardware. Entweder man weiß viel mit entsprechender Tiefe, oder fast alles mit weniger Tiefe. Ich habe mir zum Ziel gesetzt, das Wissen was ich immer brauche zu vertiefen, den Rest zu erweitern mit weniger Tiefe und das was mich nicht interessiert oder brauchbar ist zu vernachlässigen, und es beim Hobby zu belassen. Beruflich gesehen wäre mir das zu stressig, und ich wäre nicht in der Lage meine Arbeit in der Qualität abzuliefern, die angebracht wäre. Da gibts halt gewissen Vorgaben und Zeitdruck die mich einschränken würden und ich die Arbeit nur auf das nötigste beschänken könnte. Und weniger Geld gebe es auch, zu meinem jetzigen Beruf. Will zwar nicht damit behaupten, das der PC-Service den die Händler liefen, schlecht ist - es gab aber Fälle wo ich es dann gerichtet habe, und mal vermuten wurde das jemand der nur diesen Beruf erlernt um damit Geld zu verdienen, weniger Ahnung haben kann als jemand der sich aus Hobby mit eigenem Antrieb da reinsteigert und das intensiviert.

So, und nun mache ich Schluß, und sry für den ganzen Offtopic hier ............

 

[PuckPoltergeist]

Wieso so umständlich? Nahezu jeder bekanntere Compiler unterstützt Assembler Listings. Oder kann der ICC das nicht?

Ich weiß nicht, ob das hilft. Der ICC packt diesen Check erst sehr spät dazu. Ich habs jetzt nicht ausprobiert, aber der könnte schon als Objektcode vorliegen. Da hilft dann das Listing nicht mehr.

PS: Und das macht auch Sinn, dass der Teil schon als Objektcode vorliegt. Sonst ließe sich der Test sehr einfach deaktivieren.

 

[Emploi]

Durch deinen ersten Beitrag auf Seite 3, hast du auch nicht grad danach den Eindruck gemacht, als wenn du davon irgendwas verstehen würdest, sondern lediglich einfach eine unpassende Bemerkung eingebracht. Aber ich späteren Verlauf nochmal die Kurve gekriegt.

Es gibt aber sicher Bereiche wo man ohne gutes (verkaufen) seiner Person, sehr schnell weg vom Fenster ist.

Zumindest habe ich von einigen Beiträgen die ich im laufe der Jahre gesehen habe, echt den Eindruck das die User ihren Beruf verfehlt haben, und im Marketing bestens aufgehoben wären.

Trotzdem wird mich das nicht daran hindern, auch in Zukunft in Themen zu posten für die ich mich interessiere, auch wenn diese außerhalb meines Fachbereiches liegen. ....

Du musst dich doch nicht zu so später/früher Stunde Rechtfertigen. Man kann nicht Alles wissen, eben. Geht mir mehrfach genau so! Ich muss zum Beispiel noch das "mich verkaufen" lernen, was mir ziehmlich schwer fällt.

Zum Beitrag auf Seite 3-> ich lese halt gern mit ... und fand es nur zu amüsant ... So das ich dies kurz kommentieren "musste".

Den letzten zitierten Punkt halte ich eben so, ich denke wir werden uns noch öfters lesen.

 

[Opteron]

Das lässt sich nicht so einfach ändern. Schon garnicht, weil man nicht weiß, ob man damit Sicherheitschecks abschaltet, die wirklich notwendig sind. Denn wie schon geschrieben, der Intelcompiler kennt nur Optimierungsstufen für Intel-CPUs. Es kann also sein, dass er nicht nur auf SSE(2,3,hastenichtgesehn) optimiert, sondern direkt auf Befehlssequenzen, die nur auf bestimmten Intel-CPUs zu korrekten Ergebnissen führen. Da nur Intel die kompletten Details kennt, wäre das ein absolutes Glücksspiel, darauf zu vertrauen, dass das überall korrekt funktioniert.
Ergo bleibt als Ergebnis nur, Compiler bzw. Compileroptionen zu verwenden, die auf allen Plattformen gleich bzw. ähnlich funktionieren. Alternativ kann man auch verschieden Versionen eines Benchmarks auf verschiedene Plattformen optimiert anbieten. Dass da manche Plattformen auf der Strecke bleiben, ist klar.

Einfach sicher nicht, aber der Prof. Agner hat das schon rausgefunden, wie man vorgehen muss:
http://www.agner.org/optimize/optimizing_cpp.pdf
(Kapital 12.1 / S.118 (unten))

ciao

Alex

 

[NOFX]

Im Allgemeinen ist ja immer die Frage inwieweit ein Benchmarkprogramm unabhängiger sein sollte, als die Programme für den dieser die Geschwindigkeit mißt. Wenn nunmal (einfach in den Raum geworfen) 50% aller Programme, die üblicherweise zum Einsatz kommen mit eben jenem ICC compiliert wurden, bringt es ja nichts, wenn der Benchmark dieses in keiner Weise berücksichtigt.

Aus der Welt schaffen kann man dieses Problem erst, wenn Intel die Compiler-Entwicklung (evtl. gezwungenermaßen) ausgliedert. Wer weiß, vllt. traut sich die EU-Kommission bei einem Urteil zu Intels marktverzerrenden Absatzmethoden der letzten Jahre in der Richtung gewisse Auflagen zu machen.

 

[tomturbo]

Im Allgemeinen ist ja immer die Frage inwieweit ein Benchmarkprogramm unabhängiger sein sollte, als die Programme für den dieser die Geschwindigkeit mißt. Wenn nunmal (einfach in den Raum geworfen) 50% aller Programme, die üblicherweise zum Einsatz kommen mit eben jenem ICC compiliert wurden, bringt es ja nichts, wenn der Benchmark dieses in keiner Weise berücksichtigt.

Falsch!

Denn ein Benchmark soll ja nicht einen Absolutwert liefern, sondern einen Vergleichswert.
Und daher muss man darauf achten dass nicht irgend eine Komponente bevorzugt wird.

_tom