Projekte und Tools, Hammersoftware, Opteron, AMD64
- Ersteller Bokill
- Erstellt am
Frisch von http://www.amdzone.com/index.cfm#1
Jedenfalls scheint doch einen grössere Unterstützung da zu sein als für 3DNow!
Interne Links:
Software für 3DNow! im Vergleich!
http://www.planet3dnow.de/vbulletin/showthread.php3?threadid=94347
SSE2-Verbreitung
http://www.planet3dnow.de/vbulletin/showthread.php3?threadid=89839
Nachtrag
Spezielle P3D Opteronlinksammlung Dort sind weitere Links zum Hammer enthalten... auch zu Softwarefragen
in Englisch aber wirklich immer noch lesenswert:
SSE Technology in New Intel Prescott Processors
http://www.xbitlabs.com/articles/cp...escott-sse.html
und
Da kann man hoffen, dass noch mehr Schub für den Hammer erzeugt wird.
Jedenfalls scheint doch einen grössere Unterstützung da zu sein als für 3DNow!
Interne Links:
Software für 3DNow! im Vergleich!
http://www.planet3dnow.de/vbulletin/showthread.php3?threadid=94347
SSE2-Verbreitung
http://www.planet3dnow.de/vbulletin/showthread.php3?threadid=89839
Nachtrag
Spezielle P3D Opteronlinksammlung Dort sind weitere Links zum Hammer enthalten... auch zu Softwarefragen
in Englisch aber wirklich immer noch lesenswert:
SSE Technology in New Intel Prescott Processors
http://www.xbitlabs.com/articles/cp...escott-sse.html
Soll halt ein Teaser sein
Zuletzt bearbeitet:
solche Tuningmassnahmen sind, zeigt der folgende Heiseartikel:
Eigentlich dachte ich, dass mit der Aussage: XY läuft mit dem OS YZ. Bedeutet: "Es läuft ohne Probleme."
In der Realität bedeutet die erstmalige Aussage: "CPU läuft erstmals mit YZ OS wirklich."
[wahre Bedeutung]
Es wurde von hinten durch die Brust programmiert, und keiner weiss warum dies tatsächlich funktioniert, aber egal es läuft und wird deswegen erstmals veröffentlicht und angepriesen.
[/wahre Bedeutung]
http://www.heise.de/newsticker/data/ola-05.08.03-002/
Eigentlich dachte ich, dass mit der Aussage: XY läuft mit dem OS YZ. Bedeutet: "Es läuft ohne Probleme."
In der Realität bedeutet die erstmalige Aussage: "CPU läuft erstmals mit YZ OS wirklich."
[wahre Bedeutung]
Es wurde von hinten durch die Brust programmiert, und keiner weiss warum dies tatsächlich funktioniert, aber egal es läuft und wird deswegen erstmals veröffentlicht und angepriesen.
[/wahre Bedeutung]
Was den Intanium64-Befehlssatz angeht, so möchte ich den Kernel-Entwicklern zu Gute halten, dass es wohl eine Fülle von unübersichtlichen Befehlen handelt. Selbst Linus sagte in der Kernel-Mailingliste, dass er den Befehlssatz vom Opteron eindeutiger und leichter finde.
Ausserdem muss man sehen, dass nicht alle Entwickler über die entsprechende Hardware verfügen, so alles "auf blauen Dunst" programmieren (sie sind halt entsprechend gut
Ich denke es wird auch in einiger Zeit noch leichte Probleme mit den neuen Standards geben. Zum Beispiel IPv6 wird bereits seit Jahren entwickelt und ist immernochnicht produktiv im Einsatz. Trotzdem sieht man in den ChangeLogs häufig kleine Änderungen in dem Code.
Grüße,
Moritz
PS: Hat jemand "einfache" Tutorials oder Beschreibungen, zur Optimierung von Code an CPU-Features (z.B. 3dNow, 3dNow+, SSE, SSE2, etc.)
Ausserdem muss man sehen, dass nicht alle Entwickler über die entsprechende Hardware verfügen, so alles "auf blauen Dunst" programmieren (sie sind halt entsprechend gut
Ich denke es wird auch in einiger Zeit noch leichte Probleme mit den neuen Standards geben. Zum Beispiel IPv6 wird bereits seit Jahren entwickelt und ist immernochnicht produktiv im Einsatz. Trotzdem sieht man in den ChangeLogs häufig kleine Änderungen in dem Code.
Grüße,
Moritz
PS: Hat jemand "einfache" Tutorials oder Beschreibungen, zur Optimierung von Code an CPU-Features (z.B. 3dNow, 3dNow+, SSE, SSE2, etc.)
Zuletzt bearbeitet:
Dieser Thread hat mitlerweile schon 2000 Hits, jedoch liess ich diesen Thread verschimmeln, wie eigentlich alle anderen Forenteilnehmer auch.
Wie ist es möglich, dass dennoch der Thread so lange auf der Hauptseite ist?
Die besuchte Anzahl kann`s auch nicht sein, da habe ich wirklich noch andere Threads promotet (nicht nur eigene).
Wie gesagt ist mir irgendwie echt rätselhaft.
Wie ist es möglich, dass dennoch der Thread so lange auf der Hauptseite ist?
Die besuchte Anzahl kann`s auch nicht sein, da habe ich wirklich noch andere Threads promotet (nicht nur eigene).
Wie gesagt ist mir irgendwie echt rätselhaft.
redhat taroon beta http://planet64bit.de/modules.php?name=News&file=article&sid=132
gentoo x86-64 http://planet64bit.de/modules.php?name=News&file=article&sid=128
gentoo x86-64 http://planet64bit.de/modules.php?name=News&file=article&sid=128
Ich habe zwar 0 Ahnung von Software und erst recht keine vom Programmieren...
Eines des grössten Geheimnisse von P3D war auch, weswegen der Thread auch in den "Liste der Aktuellen Diskusionen" drin war...
Diskutiert wurde praktisch gar nicht...
auch wennn tatsächlich über 2000 Hits zu verzeichnen waren...egal,
P3D hat einen Hinweis auf Mathematische Bibliotheken zu AMD CPUs herausgebracht.
Man kann wirklich hoffen, dass durch Optimierten Code (Handgeschrieben gar?) wirklich viel aus AMD CPUs herausgequetscht wird.
Mit diesem Hilfsmittel für Programmierer, konnen verbesserte Programme geschrieben werden...
Also sind diese Tools keine "Pätsche" oder Upgrades wie die Flicken für den Windowsanwender...
Für Mausfellnutzer wie mich sind diese vollkommen ungeeignet...
Is eher was für den Programm- Spezis wie Seemann oder gar für intelhasser
Eine Sache ist mir jedoch unklar... Ist dies Hammeroptimiert- oder mögen die auch den Athlon/AthlonXP?
Neue AMD Core Math Library (ACML) 1.5
Eines des grössten Geheimnisse von P3D war auch, weswegen der Thread auch in den "Liste der Aktuellen Diskusionen" drin war...
Diskutiert wurde praktisch gar nicht...
auch wennn tatsächlich über 2000 Hits zu verzeichnen waren...egal,
P3D hat einen Hinweis auf Mathematische Bibliotheken zu AMD CPUs herausgebracht.
Man kann wirklich hoffen, dass durch Optimierten Code (Handgeschrieben gar?) wirklich viel aus AMD CPUs herausgequetscht wird.
Mit diesem Hilfsmittel für Programmierer, konnen verbesserte Programme geschrieben werden...
Also sind diese Tools keine "Pätsche" oder Upgrades wie die Flicken für den Windowsanwender...
Für Mausfellnutzer wie mich sind diese vollkommen ungeeignet...
Is eher was für den Programm- Spezis wie Seemann oder gar für intelhasser
Eine Sache ist mir jedoch unklar... Ist dies Hammeroptimiert- oder mögen die auch den Athlon/AthlonXP?
Neue AMD Core Math Library (ACML) 1.5
Dresdenboy
Redaktion
☆☆☆☆☆☆
Übrigens zieht das Code Optimization projekt um. Irgendwer hat den Namen "Optimizer" für ein JPG-Optimierungs-Tool beansprucht und bei mir hat es die SF-Mails ins Spam sortiert.. nix mitbekommen und nach 14 Tagen ohne Reaktion gehört das Projekt einem anderen. Die Leute bei SF versuchen, die Daten (war zum Glück nicht viel *g*) wiederherzustellen.
Der neue Name wird dann Optimizer64 sein.
Da können alle mitmachen, die sich dafür interessieren und Lust haben, vorhandene Open-Source-Projekte etwas zu optimieren (meist ist das nur für Kernalgorithmen notwendig).
Zur Zeit "kümmere" ich mich um eine neue FFT für Prime95. George Woltman optimiert die vorhandene für den Opteron, soweit machbar ist. Die Members von mersenneforum.org haben Geld gespendet, um einen Opteron für George und andere Entwickler zu kaufen. Das ist doch mal was!
Der neue Name wird dann Optimizer64 sein.
Da können alle mitmachen, die sich dafür interessieren und Lust haben, vorhandene Open-Source-Projekte etwas zu optimieren (meist ist das nur für Kernalgorithmen notwendig).
Zur Zeit "kümmere" ich mich um eine neue FFT für Prime95. George Woltman optimiert die vorhandene für den Opteron, soweit machbar ist. Die Members von mersenneforum.org haben Geld gespendet, um einen Opteron für George und andere Entwickler zu kaufen. Das ist doch mal was!
Zuletzt bearbeitet:
Dresdenboy
Redaktion
☆☆☆☆☆☆
Die ACML Bibliotheken wurden in der 32-bit-Version für Athlon-XP-Architektur compiliert. Das könnte also gehen. Auf Arbeit kann ich ja mal schauen (das sind über 20MB), ob da x87-Code drin ist.
Aber sie sind nicht die schnellsten (siehe http://www.fftw.org/speed/ - die Opteron-Tests, ACML wird in Schwarz mit Dreieck-Symbolen in den Diagrammen dargestellt). Das liegt aber auch daran, das FFTW neue Verfahren einsetzt. Es wird in einem längeren Durchlauf einfach viel Code getestet und variiert und dann der schnellste verwendet. Bei ACML sind die Funktionen einmal programmiert und optimiert worden und sind für verschiedene Parameter immer die gleichen. Manchmal ist das auch steuerbar - dazu habe ich aber zuwenig in ACML reingeschaut (da vor-aussortiert
).Merkwürdig
Der Thread verschimmelte auf höchstem Niveau...wochenlang...hab den selbst schmählich nicht "gegossen" und nun eine Infoexplosion sondergleichen?!
Die Benchmarks sehen aber nicht nur positiv für den Opteron aus...
habe allerdings auch keine Ahnung, wofür die diversen Kurven stehen...sehe den Wald vor Bäumen nicht...sind ja nicht zwei SANDRA Benchmarks *grins*
PS: Sehr bemerkenswerter Thread über Sinn und Unsinn von MS`s WOW64...
ich nenne solch eine Umsetzung HÄ?64
Athlon 64 16bit Codeunterstützung?
Sehr bemerkenswert, da die Linuxgemeinde wesentlich mehr Goodies aus dem Hammer herausquetscht als MS!
Der Thread verschimmelte auf höchstem Niveau...wochenlang...hab den selbst schmählich nicht "gegossen" und nun eine Infoexplosion sondergleichen?!
Die Benchmarks sehen aber nicht nur positiv für den Opteron aus...
habe allerdings auch keine Ahnung, wofür die diversen Kurven stehen...sehe den Wald vor Bäumen nicht...sind ja nicht zwei SANDRA Benchmarks *grins*
PS: Sehr bemerkenswerter Thread über Sinn und Unsinn von MS`s WOW64...
ich nenne solch eine Umsetzung HÄ?64
Athlon 64 16bit Codeunterstützung?
Sehr bemerkenswert, da die Linuxgemeinde wesentlich mehr Goodies aus dem Hammer herausquetscht als MS!
Zuletzt bearbeitet:
Dresdenboy
Redaktion
☆☆☆☆☆☆
Ich hatte einen Link parat und muß jetzt warten, bis das Sourceforge-Team die neue alte Projekt-Seite wiederhergestellt hat.
Als Einstiegspunkt (für die Art der Performance-Probleme beim Prime95-Code auf Opteron) empfehle ich: http://mersenneforum.org/showthread.php?s=&threadid=1072
MOVAPD ist ein ernster Flaschenhals. Den kann man nur mit Tricks umschiffen (mehr memory operands verwenden).
Zur Zeit arbeite ich mich von der anderen Seite heran - einen Algorithmus zu implementieren mit paralleler FFT und Integer-Transformation. Damit werden die meist brachliegenden Integer-Einheiten genutzt (meist ist die FPU mit Adds beschäftigt) und man kann die Transformationen kombinieren um die mit Doubles erreichbare Genauigkeit drastisch zu erhöhen.
Nach der Implementation kommt Assembler-Optimierung. George Woltman hat die Berechnungen von Prime95 zu 99% in Assembler. Das ist ein sehr großer Aufwand bei größeren Änderungen. Da habe ich schon angefangen, Scripte zu schreiben, um Optimierungen am Code vorzunehmen %)
Eine fertige neue FFT, die prima auf Opteron (und ähnlich gut ausgestatteten CPUs - im Prinzip die meisten 64bit CPUs) läuft, wäre bei Erfolg noch für viele andere Projekte nützlich.
Es gab schon Anfragen/Vorschläge an das Optimizer-Projekt, z.B. die Codecs von XVID zu optimieren oder gar die Code-Optimierung von GCC. Aber da muß man erst einmal schauen, ob nicht schon so eine Arbeit im Gange ist (bei GCC sowieso schon lange).
Interesse geweckt?
PS: Es gibt ja schon einige nutzbare Entwicklungs-Opteron-Systeme (Sourceforge (4x), AMD DevCenter usw.). Aber ein Athlon 64 daheim auf dem Tisch ist auch praktisch (wird bei mir bald sein).
Als Einstiegspunkt (für die Art der Performance-Probleme beim Prime95-Code auf Opteron) empfehle ich: http://mersenneforum.org/showthread.php?s=&threadid=1072
MOVAPD ist ein ernster Flaschenhals. Den kann man nur mit Tricks umschiffen (mehr memory operands verwenden).
Zur Zeit arbeite ich mich von der anderen Seite heran - einen Algorithmus zu implementieren mit paralleler FFT und Integer-Transformation. Damit werden die meist brachliegenden Integer-Einheiten genutzt (meist ist die FPU mit Adds beschäftigt) und man kann die Transformationen kombinieren um die mit Doubles erreichbare Genauigkeit drastisch zu erhöhen.
Nach der Implementation kommt Assembler-Optimierung. George Woltman hat die Berechnungen von Prime95 zu 99% in Assembler. Das ist ein sehr großer Aufwand bei größeren Änderungen. Da habe ich schon angefangen, Scripte zu schreiben, um Optimierungen am Code vorzunehmen %)
Eine fertige neue FFT, die prima auf Opteron (und ähnlich gut ausgestatteten CPUs - im Prinzip die meisten 64bit CPUs) läuft, wäre bei Erfolg noch für viele andere Projekte nützlich.
Es gab schon Anfragen/Vorschläge an das Optimizer-Projekt, z.B. die Codecs von XVID zu optimieren oder gar die Code-Optimierung von GCC. Aber da muß man erst einmal schauen, ob nicht schon so eine Arbeit im Gange ist (bei GCC sowieso schon lange).
Interesse geweckt?
PS: Es gibt ja schon einige nutzbare Entwicklungs-Opteron-Systeme (Sourceforge (4x), AMD DevCenter usw.). Aber ein Athlon 64 daheim auf dem Tisch ist auch praktisch (wird bei mir bald sein).
Die entsprechende Meldung bei P3D lautet Intel veröffentlicht x86-64 Compiler
Da warten wir auf die Eignung des aktuellen intel-Kompilers Intel 8.1/EM64T ... und da sind schon erste Ergebnisse raus.
1. Er funktioniert.
2. Auch mit dem K8.
Aber solch eine Statement ist doch erstmalig für einen Kompiler von intel:
-> Zeitnachteil, da der Infofluss nun nicht mehr intern ist.
-> Performancenachteil, da die Hardware nun mal nicht aus dem gleichen Hause stammt.
Die Testplattform war ein K8:
dabei ist auffällig, dass andere Kompiler nicht mehr so stark absacken, wenn sie von intel auf die Plätze verwiesen werden. Auffällig ist auch, dass auch eine intelplattform den Code annimmt, allerdings sind die Leistungsprofile von AMD und intel deutlich anders:
.
Alles und noch viel mehr (Leistungs-Vergleichs-Tabellen) bei SPEC CPU2000. Part 17.
AMD64/EM64T and 64-bit code.
The third attempt.
MFG Bokill
1. Er funktioniert.
2. Auch mit dem K8.
Aber solch eine Statement ist doch erstmalig für einen Kompiler von intel:
Ist die Linux-gemeinde mit dem gcc so gut geworden, oder hat intel wegen des Plattformnachteils (Referenzplattform ist nun mal AMD64) nun eindeutig Standortnachteile?
-> Zeitnachteil, da der Infofluss nun nicht mehr intern ist.
-> Performancenachteil, da die Hardware nun mal nicht aus dem gleichen Hause stammt.
Die Testplattform war ein K8:
dabei ist auffällig, dass andere Kompiler nicht mehr so stark absacken, wenn sie von intel auf die Plätze verwiesen werden. Auffällig ist auch, dass auch eine intelplattform den Code annimmt, allerdings sind die Leistungsprofile von AMD und intel deutlich anders:
Ein sehr lesenswerter Test von Kirill Kochetkov von Digit-Life... auch wenn ich nicht alles verstanden habe
.Alles und noch viel mehr (Leistungs-Vergleichs-Tabellen) bei SPEC CPU2000. Part 17.
AMD64/EM64T and 64-bit code.
The third attempt.
MFG Bokill
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Womit belegst du diese Aussage? Was du hier meinst, ist daß das System überhaupt erstmal bootet und in irgendeiner Form ansprechbar ist. Das wird aber auch meist so dargestellt. Ich kann mich jetzt nichtmal an Meldungen von MS erinnern, daß Windows angeblich irgendwo drauf läuft, und es im Endeffekt noch nicht so war.
edit: Ok, war diesmal echt zu blind, den "tieferen Sinn" hinter den Zeilen zu erkennen.
Satire ist aber manchmal auch was feines ![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
Zuletzt bearbeitet:
Dresdenboy
Redaktion
☆☆☆☆☆☆
Ich schätze Kirill Kochetkov als einer der besten Artikelautoren im Bereich Compiler+SPEC. Das AMD64 dabei öfters unter die Lupe genommen wird, ist ebenfalls sehr günstig.
Zum ICC 8.0 & 8.1:
Ich sehe da nur ein Problem für den Einsatz von ICC 8.1 als K8-Compiler: Während die Version 8.0 aufgrund der 32bit-Code-Erzeugung auch das Instruction-Scheduling für PPro-Architekturen (also auch P-M) beherrschen muß, ist das für den ICC 8.1 für 64bit-Code zur Zeit nicht notwendig, da es ja noch keinen 64bittigen P-M gibt. Resultierend daraus optimiert er für den Prescott/Nocona-Kern und verwendet entsprechend geeignete Befehle bei für diese CPUs optimierter Anordnung. Nur - wie schon von P4-Code bekannt - sind solche Befehlsfolgen u. auch Optimierungen auf die andere Cache-Architektur nicht optimal für den K8. Damit rücken auch bisher als weniger gut optimierend bekannte Compiler (GCC) immer weiter vor, da ICC auf dem K8 durch anders optimierten Code zurückfällt.
Die anderen kommerziellen Compiler haben natürlich auch viel Erfahrung und Können auf ihrer Seite. Pathscale sticht da geradezu heraus und dürfte allein durch seine guten Ergebnisse zusätzliche Verkäufe des Opteron initiieren. Ein 10% schnellerer Compiler bringt schließlich etwa soviel, wie ein Opteron mit höherem Speedgrade.
Und an GCC arbeiten auch sehr viele gute Entwickler. Diese müssen sich allerdings nicht alle mit dem K8 beschäftigen, damit der GCC guten Code erzeugt. Dafür reicht ein gutes K8-Backend, während schon vor der CPU-spezifischen Code-Generierung viel passiert, was schließlich zu schnellerem Code führt.
Bleibt als Fazit:
Da der K8 dank dem ICC 8.1 nur noch Nocona/Prescott-optimierte Befehlssuppe bekommt, mag er diese nicht ganz so schnell verspeisen, da zuviele kleine Bröckchen den Kauprozess aufhalten..
Zum ICC 8.0 & 8.1:
Ich sehe da nur ein Problem für den Einsatz von ICC 8.1 als K8-Compiler: Während die Version 8.0 aufgrund der 32bit-Code-Erzeugung auch das Instruction-Scheduling für PPro-Architekturen (also auch P-M) beherrschen muß, ist das für den ICC 8.1 für 64bit-Code zur Zeit nicht notwendig, da es ja noch keinen 64bittigen P-M gibt. Resultierend daraus optimiert er für den Prescott/Nocona-Kern und verwendet entsprechend geeignete Befehle bei für diese CPUs optimierter Anordnung. Nur - wie schon von P4-Code bekannt - sind solche Befehlsfolgen u. auch Optimierungen auf die andere Cache-Architektur nicht optimal für den K8. Damit rücken auch bisher als weniger gut optimierend bekannte Compiler (GCC) immer weiter vor, da ICC auf dem K8 durch anders optimierten Code zurückfällt.
Die anderen kommerziellen Compiler haben natürlich auch viel Erfahrung und Können auf ihrer Seite. Pathscale sticht da geradezu heraus und dürfte allein durch seine guten Ergebnisse zusätzliche Verkäufe des Opteron initiieren. Ein 10% schnellerer Compiler bringt schließlich etwa soviel, wie ein Opteron mit höherem Speedgrade.
Und an GCC arbeiten auch sehr viele gute Entwickler. Diese müssen sich allerdings nicht alle mit dem K8 beschäftigen, damit der GCC guten Code erzeugt. Dafür reicht ein gutes K8-Backend, während schon vor der CPU-spezifischen Code-Generierung viel passiert, was schließlich zu schnellerem Code führt.
Bleibt als Fazit:
Da der K8 dank dem ICC 8.1 nur noch Nocona/Prescott-optimierte Befehlssuppe bekommt, mag er diese nicht ganz so schnell verspeisen, da zuviele kleine Bröckchen den Kauprozess aufhalten..
PuckPoltergeist
Grand Admiral Special
Seit Version 3 der gcc ist der Unterschied zum icc so zusammen geschrumpft, daß es nicht mehr weit zur Meßungenauigkeit ist. Wenn ich nicht irre, dürfte im Moment auch der/die gcc der schnellst Compiler für den K8 sein.
@PuckPoltergeist
[satire][/satire] ... aber nett zu wissen, dass du gar MS in Schutz nimmst ... ist bei kompetenten Linux-Anwendern ja eine echte Seltenheit
*friedens-taube-überreich*
MsFG Bokill
@Dresdenboy
THX für die Info, sollte man wohl mal weitere Artikel von dem erforschen
MFG Bokill
Öhemm das war eine satirischer Beitrag ... sollte ich bei technischen Threads wirklich folgende Tags verwenden?
[satire][/satire] ... aber nett zu wissen, dass du gar MS in Schutz nimmst ... ist bei kompetenten Linux-Anwendern ja eine echte Seltenheit
*friedens-taube-überreich*
MsFG Bokill
@Dresdenboy
THX für die Info, sollte man wohl mal weitere Artikel von dem erforschen
MFG Bokill
Dresdenboy
Redaktion
☆☆☆☆☆☆
Bei SPEC-Messungen wird für die meisten Integer-Codes im 64bit-Modus mittlerweile GCC eingesetzt. Allerdings zeigen zumindest bei diversen SPEC-Result-Trackings GCC 4.0 (SSA) und ältere Versionen noch viele Bereiche, wo selbst ICC 7 besser ist. Aber die Arbeit an GCC steht ja nicht still.
![mtb][sledgehammer](/data/avatars/m/1/1883.jpg?1596828194){kind=avatar}
mtb][sledgehammer
Grand Admiral Special
Interessanter Test, verlangt noch ein wenig Leserbedarf bei mir
Zwischenfrage: Was macht der Test "179.art". Dieser Test profitiert sowohl mit dem icc als auch gcc deutlich. Dabei fällt aber besonders das Ergebnis des Nocona mit icc auf: über 200 % Vorteil gegenüber dem 32 Bit Compiler.
Zwischenfrage: Was macht der Test "179.art". Dieser Test profitiert sowohl mit dem icc als auch gcc deutlich. Dabei fällt aber besonders das Ergebnis des Nocona mit icc auf: über 200 % Vorteil gegenüber dem 32 Bit Compiler.
Dresdenboy
Redaktion
☆☆☆☆☆☆
Der Test arbeitet im Bereich der KI:Original geschrieben von mtb][sledgehammer
Interessanter Test, verlangt noch ein wenig Leserbedarf bei mir
Zwischenfrage: Was macht der Test "179.art". Dieser Test profitiert sowohl mit dem icc als auch gcc deutlich. Dabei fällt aber besonders das Ergebnis des Nocona mit icc auf: über 200 % Vorteil gegenüber dem 32 Bit Compiler.
http://www.specbench.org/cpu2000/CFP2000/179.art/docs/179.art.html
PuckPoltergeist
Grand Admiral Special
Ist eigentlich nicht notwendig. Ich haue ja auch selbst genug damit um mich.
Die Woche war wohl doch zu anstrengend, daß ich hier nicht mehr mit gekommen bin. ]
... aber nett zu wissen, dass du gar MS in Schutz nimmst ... ist bei kompetenten Linux-Anwendern ja eine echte Seltenheit
Naja, ich muß mich ja nicht auf deren Niveau runter begen, und pauschal alles von denen durch den Dreck ziehen.
Nehm ich.
http://planet64bit.de/modules/news/article.php?storyid=314
Mit Hinweis auf das AMD PDF 32035
THX Desti von planet64bit.de
MFG Bokill
Mit Hinweis auf das AMD PDF 32035
THX Desti von planet64bit.de
MFG Bokill
PuckPoltergeist
Grand Admiral Special
Das Paper halte ich durchaus für nicht ungefährlich. Der Schalter -ffast-math beim gcc erzeugt mitunter nicht korrekten Code, bzw. fehlerhafte Genauigkeit, was bei manchen Programmen fatal sein kann. Es wird darauf auch in dem Paper nochmal etwas eingegangen, nur finde ich, daß das gleich bei der ersten Erwähnung von -ffmast-math aufgezeigt werden sollte. Wenn man nicht aufpaßt, kann das ganz böse in die Hose gehen.
Außerdem wird funit-at-a-time anders als dort angegeben, schon bei -O2 angeschalten.
Alles in allem ist es aber trotzdem lobenswert, daß hier von AMD Optimierungsmöglichkeiten bei verschiedenen Compilern für Softwareentwickler zusammengetragen werden, insbesondere da AMD keine eigenen Entwicklungstools (Compiler) herstellt. Hoffentlich pflegen sie das auch ordentlich.
PS: zum -ffast-math
@Puck
Von Programmieren habe ich keinerlei Dunst ... das überlasse ich lieber intel_hasser, Seemann und anderen. Da ich aber in grauer Vorzeit diesen und auch noch einen weiteren Thread zu 3DNOW! gemacht hattem ist`s zumindest für einige Geeks und Mutanten erwähnenswert, die sich damit beschäftigen.
Man kann ja nicht alles wissen & finden. Gut möglich dass heutige Noobs, in ein zwei Jahren sich auf bestimmte Anlaufstellen besinnen.
An sich gehört dieser Thread eher in das Programmier-Forum ... zu seiner Entstehungszeit gabs das ja noch nicht.
MFG Bokill
Von Programmieren habe ich keinerlei Dunst ... das überlasse ich lieber intel_hasser, Seemann und anderen. Da ich aber in grauer Vorzeit diesen und auch noch einen weiteren Thread zu 3DNOW! gemacht hattem ist`s zumindest für einige Geeks und Mutanten erwähnenswert, die sich damit beschäftigen.
Man kann ja nicht alles wissen & finden. Gut möglich dass heutige Noobs, in ein zwei Jahren sich auf bestimmte Anlaufstellen besinnen.
An sich gehört dieser Thread eher in das Programmier-Forum ... zu seiner Entstehungszeit gabs das ja noch nicht.
MFG Bokill
Ähnliche Themen
