ZeroZerp schrieb:
4. Es ist im Softwarebereich aufgrund von unwägbaren Supportgegebenheiten Usus, den Einsatzbereich einzuschränken bzw. zu zertifizieren.
Ich hab auch bis jetzt einige Zeit darüber nachgedacht, mit welcher Sichtweise man auch an das Thema herangehen kann und am Ende kam mir dann auch immer der Support und die manchmal damit verbundenen Garantien in den Sinn.
Intel steht für ihre Bibliothek am Ende gerade und besonders in den USA macht man sich recht schnell angreifbar, wenn etwas nicht so funktioniert, wie es funktionieren soll. Ich kann Intel hier bedingt auch verstehen, wenn sie AVX, AVX2 und AVX512-Code in ihrer Bibliothek nur für eigene Prozessoren freigeben. Denn wenn es zu einem Problem kommt, weil AVX von AMD oder Via nicht ganz so implementiert wurden, wie von Intel vorgesehen, kann es zu Problemen kommen.
Aus Sicht des Supports als auch der Gewährleistung ist die Entscheidung also durchaus verständlich und nachzuvollziehen.
Aber ich musste da auch erst mal in Ruhe darüber nachdenken und mir überlegen: Welchen Grund könnte es abseits dafür geben und welche Gründe kennst du aus deinem Alltag dafür.
ZeroZerp schrieb:
Alles in allem sehe ich keinen Grund, warum Intel einen optimierten Codepfad in eine für die eigenen Prozessoren geschriebene Software, für ein Konkurrenzprodukt integrieren sollte, um diese zu beschleunigen oder allumfassend zu unterstützen.
Hier ist halt die Frage, und ich glaube daran scheitert auch ein Konsens hier in der Diskussion, was man nun als Optimierung auf die eigene Architektur verstehen kann und will und was allgemeingültige Optimierungen sind.
Gerade bei so komplexen Themen wie der Vektorisierung sind da die Grenzen doch recht fließend, vor allem wenn ich mir die MKL mal genauer ansehe und mir die verschiedenen Implementierungen zwischen den einzelnen SSE-Pfaden und dann später AVX, AVX2 und AVX512. Die Unterschiede der einzelnen Pfade ergibt sich oft eher durch die Breite der möglichen Vektoren, der Nutzung von FMA und eben den damit verbundenen Befehle in den Erweiterungen. Nimmt man diese eher deklarativen Unterschiede aus den einzelnen Funktionen heraus, dann sind die Unterschiede zwischen den einzelnen Pfaden eher mit der Lupe zu suchen.
Es ist halt all zu oft, dass man statt zwei SSE-Befehle für Mul und ADD den FMA-Befehl nutzt also - fiktiver Beispiel Code - aus einem vec_add(vec_mul(vector_a, vector_b),vecotrc) wird ein vec_fma(vector_a, vector_b, vector_c) und ebenso wird halt dann oft statt ein Vektor mit 128Bit eben 256Bit oder 512Bit gebildet und dann eben der entsprechende Befehl für die Extensions. (Noch mal, das ist jetzt stark vereinfacht. Wenn ihr Fehler findet, ruhig sagen und ergänzen.
)
Die eigentliche Arbeit, nämlich die Berechnungen für eine Vektorisierung aufzubereiten wird in jedem Datenpfad vorgenommen und so findet man in jedem Datenpfad auch oft dieselben grundlegenden Optimierungen.
Es fällt in dem Fall echt schwer zusagen, ob es sich um spezielle Optimierungen für Intel-CPUs handelt, oder ob man hier einfach gewisse Funktionspfade den Mitbewerbern vorenthält. Nehme ich mir die meisten Unterschiede zwischen den Pfaden vor, dann würde ich eher sagen, dass man hier einfach gewisse Pfade der Konkurrenz vorenthält, denn es geht am Ende oft nur darum, welcher x86-Befehl genutzt wird, alles bis zu dieser Auswahl ist oft gleich und dann wird im SSE-Pfad der einfachere Weg des AVX-Befehls durch ganze Befehlsketten ersetzt.
Ned Flanders schrieb:
Optimierung verlangt doch wirklich keiner. Pessimierung aber eben auch nicht.
Sieht man sich den Code der MKL genau an, dann muss man in dem Fall den meisten "Krtikern" von Intel in dem Fall zu stimmen. Zu oft sind sich die Code-Pfade zwischen SSE, AVX, AVX2 und AVX512 ähnlich und nur an ganz wenigen Stellen wird wirklich mal was Interessantes für AVX getan und in der Regel bildet man die einfachen AVX-Befehle mit SSE nach, was teilweise sogar komplizierter ist als der eigentliche AVX-Pfad.
ZeroZerp schrieb:
Intel wird oftmals mit allen Mitteln in die Bad Boy-Ecke gezwungen. Bei AMD drückt man bei ähnlichen Sachverhalten das Auge zu. Emotional zu verstehen. Rational unfair.
Na, das lese ich immer wieder von einigen, die hier Intel verteidigen, aber irgendwie fehlt es mir da immer an passenden Beispielen, bei denen AMD entsprechend agierte.
Ansonsten muss ich dir aber zu stimmen. Diese Anfeindungen der User hier unter einander ist das ganze sicher nicht wert. Im Endeffekte ist es auch an AMD, dass sie mal ihren Arsch bewegen. Es nutzt nichts, wenn man gute Hardware hat, aber an der Softwareseite regelmäßig hinten ansteht.
Im Endeffekt kann sowohl Intel als auch nVidia immer wieder AMD nicht durch die bessere Hardware ausstechen, sondern weil sie neben der Hardware auch passende Software-Infrastruktur zur Verfügung stellen und Entwickler auch mit entsprechendem Support versorgen.
Intel ist weniger ein Bad-Boy, als dass sie eben genau das machen, was man in der Wirtschaft macht. Man unterstützt seine eigenen Produkte.
