News Quartalszahlen: Intel sprengt bei Umsatz und Gewinn alle Erwartungen

[Unnu]

@Benji18 : Hier ist noch der Link
http://www.saponwin.com/vendor.asp?fi=&saps=&vi=9&fu=&pf=w&la=
Immerhin sind sie nicht sooo weit hintendran. Das wird schon.

 

[p.b.s.]

@xexex , wenn ich Ned Flanders richtig verstehe, ist nicht die Code-Optimierung das Problem, sondern wohl eine eingebaute Abfrage zur CPU-Identifikation, das dann AMD stark benachteiligt, was ohne diese nicht der Fall wäre. Das ist in meinen Augen Vorsatz und dürfte auch gegen das Patent- und Lizenzabkommen zwischen beider Hersteller verstoßen:

Advanced Vector Extensions (AVX) ist eine Erweiterung des x86-Befehlssatzes für Mikroprozessoren von Intel und AMD

 

[fdsonne]

@xexex , wenn ich Ned Flanders richtig verstehe, ist nicht die Code-Optimierung das Problem, sondern wohl eine eingebaute Abfrage zur CPU-Identifikation, das dann AMD stark benachteiligt, was ohne diese nicht der Fall wäre. Das ist in meinen Augen Vorsatz und dürfte auch gegen das Patent- und Lizenzabkommen zwischen beider Hersteller verstoßen:
https://de.wikipedia.org/wiki/Advanced_Vector_Extensions

Der Knackpunkt ist viel eher, wie wurde diese Code Optimierung "abgefragt" - es geht logisch nur nach dem Motto, wenn dann sonst.

Rein aus Programmierer Sicht ist es quasi fast gar kein Unterschied ob du die Abfrage:
- Wenn AMD, dann legacy, sonst optimized code
oder
- Wenn Intel, dann optimized code, sonst legacy
gestalten würdest - letzteres wäre nicht selten sogar schneller, weil es eben Sprungvorhersagen sei Dank höchst wahrscheinlich spekulativ schon weiter geht, während erstes ne Abbruchbedingung auf Intel CPUs wäre.
Aber moralisch ist erstere Abfrage schlicht ein NoGo während letztere einfach nur ein simpler Abwurf aller nicht explizit bevorteilter Themen wäre. Letzteres wäre sozusagen die "Optimierung" für spezielle Modelle/Produkte, ersteres der seitens Ned genannte Killswitch.

Weißt du wie MKL hier geschrieben wurde?

Aus meiner Sicht gibt es schlicht und ergreifend weder eine Regel noch irgend ein Gesetz was einen Softwareentwickler dazu zwingt, eine Featureabfrage zu erschaffen um vollvariabel bzw. volldynamisch auf jegliche CPUs reagieren zu können. Das KANN man machen, muss man aber eben nicht.
Solange Intel hier nicht AMD durch explizite Abfrage von der AMD Vendor ID ausschließt, sondern eben alles, was nicht Intel ist, auf den Legacy Pfad schickt, ist das moralisch sauber, wenn auch praktisch für den Anwender nicht schön. Ohne Zwang des Herstellers aber eben auch nicht zu erwarten. Theoretisch müsste es im Interesse der Entwickler hinter Mathlab sein, AMD mit optimierten Code zu versoren - im Zweifel müssen sie halt ne andere Lib für AMD einbauen, wenn MKL das nicht sicher stellen kann. ABER am Ende will das wohl wahrscheinlich einfach nur keiner bezahlen und allen real beteiligten Unternehmen ist es sogar völlig Bumms egal, was bei rum kommt - nur dass sich die Foristen drüber aufregen


Btw. was mich an dem Thema generell verwundert, warum regt man sich immer dann auf, wenn Intel im Spiel ist? Was ist denn mit all der ganzen Wald und Wiesen Software, die bspw. aus Supportgründen auf AVX verzichtet oder sogar auf neuere SSE Modi, nur damit die ewig hinterherlaufenden (bspw. K10 AMDler) überhaupt noch die Software verwenden können? In Games ist das nicht selten mal der Fall - kein K10 Support = Aufschrei in den Foren. Im Resultat baut man dann nen Legacypfad ein oder geht komplett auf alte Befehlserweiterungen zurück...

 

[Ned Flanders]

Weißt du wie MKL hier geschrieben wurde?

Die Abfrage läuft:

CPU vendor ID Abfrage

• Wenn "GenuineIntel", dann Feature Set Abfrage (SSE2,3,4,AVX,AVX2,AVX512)
• Wenn nicht "GenuineIntel", dann SSE2 (ohne Feature Set Abfrage).

Details dazu kann Dir @DocWindows erklären, der hat sich das sehr genau angeschaut.

Hier (ff) gings darum

warum regt man sich immer dann auf, wenn Intel im Spiel ist?

Das kann ich dir nicht erklären. Ich rege mich konkret über dieses Problem auf, auch weil ich und sehr viele andere eben davon direkt betroffen bin (war). Und das hat nunmal Intel programmiert. Das Intel dick Gewinne fährt finde ich super. Warum auch nicht.

 

[fdsonne]

Die Abfrage läuft:

CPU vendor ID Abfrage

• Wenn "GenuineIntel", dann Feature Set Abfrage (SSE2,3,4,AVX,AVX2,AVX512)
• Wenn nicht "GenuineIntel", dann SSE2 (ohne Feature Set Abfrage).

Das ergibt nur keinen wirklichen Sinn zwei Abfragen zu bauen... Denn wie erwähnt, wenn du nach Intel abfragst wird im "else" Zweig eh alles andere landen was die Bedingung nicht erfüllt - und exakt das ist eben moralisch absolut kein Problem. Denn es ist eine explizite Bevorteilung der eigenen Produkte (was logisch immer erlaubt ist) - dein zweiter Punkt hingegen ist moralisch schlicht ein NoGo, weil es explizit auf nicht Intel filtert.
Eine Featureset Abfrage ist kein Muss, wie erwähnt gibt es dazu schlicht kein Gesetz, keine Regel oder sonstwas. Wer das machen will, tut es, wer nicht, lässt es...

Man würde es also eher real so bauen:

• Wenn "GenuineIntel", dann Feature Set Abfrage (SSE2,3,4,AVX,AVX2,AVX512)
• sonst SSE2

In deinem Link erkenne ich btw. nix über die Abfrage. Auch ist eine Hexview der dll jetzt nicht wirklich etwas, was Details verrät? Wie wäre es mit nem Disassabler?
Vllt schau ich mir das am WE mal an... Verspreche pauschal aber nix.

Btw. Wenn mich nicht alles täuscht nutzt MKL auf nicht Intel andersweitig bevorzugten Produkten SSE3. Rein aus Interesse, woher hast du SSE2? Hast du was zum Lesen dazu?

Ergänzung (24. Januar 2020)

Das kann ich dir nicht erklären. Ich rege mich konkret über dieses Problem auf, auch weil ich und sehr viele andere eben davon direkt betroffen bin (war). Und das hat nunmal Intel programmiert. Das Intel dick Gewinne fährt finde ich super. Warum auch nicht.

Dann hast du zumindest erstmal nen validen und nachvollziehbaren Grund - was absolut kein Problem darstellt - aber die anderen knapp 250 Posts? Das macht hier so dein Eindruck als gibts nur MKL auf der Welt und ohne geht gar nix. Dabei ist das ne recht spezielle Lib. Mich wundert halt, dass sich bei den weit verbreiteten anderen Themen absolut keiner drauf aufhängt... Und wenn dann doch mal ein Entwickler alten Code raus lässt und vergleichsweise neue CPUs damit zur Vorraussetzung macht, schreien eher die Anderen. Die Nutzung von optimierten Befehlspfaden ist jetzt eben leider in 2020 nicht wirklich Praxis.

 

[Ned Flanders]

Wie gesagt, das ist nicht mein Metier. Du kannst mir da alles erzählen. ;-)

Verschwende dein WE nicht an der mkl.dll. Das Problem ist erstmal gelöst.

 

[xexex]

wenn ich Ned Flanders richtig verstehe, ist nicht die Code-Optimierung das Problem, sondern wohl eine eingebaute Abfrage zur CPU-Identifikation

Da ist korrekt, wie Intel selbst auf der eigenen Seite schreibt. (Ich nehme diesmal besser die deutsche Version)

Ob man das jetzt richtig findet sei mal dahin gestellt. Intel hat die Software für eigene Produkte programmiert und die Entwicklung aus der eigenen Tasche bezahlt, also dürfen sie damit auch machen was sie wollen.

Intel spricht auch eindeutig von Befehlssatzerweiterungen als Optimierungen für diese Software und unterstützt genau diese auf der AMD Plattform nicht.

Das ist in meinen Augen Vorsatz und dürfte auch gegen das Patent- und Lizenzabkommen zwischen beider Hersteller verstoßen:

Damit verstößt man gegen gar nichts, Intel hat sich nie verpflichtet jegliche Software so zu entwickeln, dass sie auf allen Plattformen gleich läuft. Das Patentabkommen, hat doch damit aber auch gar nichts zu tun.

Natürlich hat man hier vorsätzlich gehandelt, wieso sollte man für teuer Geld etwas programmieren und es dann der Konkurrenz in voller Leistung für Lau überlassen? Glaubst du das wird bei der OneAPI anders aussehen? Man programmiert sowas genau aus diesem Grund, damit man einerseits den Entwicklern Werkzeuge zur einfacheren Nutzung der eigenen Technik an die Hand geben kann und andererseits sie an die eigene Plattform bindet.
https://software.intel.com/en-us/oneapi

Es steht jedem frei es genauso zu handhaben und sich nicht auf die Arbeit anderer zu verlassen, AMD macht es letztlich nicht anders und proklamiert zum Beispiel GPUOpen, womit dann jeder Hersteller in Zukunft "seine" API hat.

 

[Ned Flanders]

Enthält GPUOpen auch eine Vendor String Abfrage, welche die Software einbremst wenn die Vendor ID nicht AMD ist oder worauf bezieht sich dein "macht es nicht anders"?

 

[blackiwid]

Das stellt doch die Vergangenheit in ein anderes Licht, man hörte hier ja immer das AMD so schlecht ist wegen Bulldozer, nun verkauft Intel die Bulldozer CPUs und die Leute können nicht genug von kriegen.

Es hatte also andere Gründe als Bulldozer warum AMD so schlechte Jahre hatte, ich mein der Bulldozer hat sicher nicht geholfen keine Frage aber der echte Grund für den Misserfolg war das vermutlich Intel gute Beziehungen zu Firmen hat, wie hier schon genannt wurden SAP, aber auch anderen die dann künstlich per Software bestenfalls nur für Intel optimieren vielleicht (will mich rechtlich hier nicht zu weit raus lehnen aus dem Fenster, daher das vielleicht) sogar mit Absicht AMD ausbremsen.

Stichwort Sheduler und Multithreading support. Gerade für Server war Bulldozer gar nicht sooo schlecht. Da da die grotige Singlecore Leistung ja irrelevant ist, sofern der Hersteller auf auch mal 5 Cent in Multicore Optimierung investiert hat oder nicht alle Software nur spezifisch auf Intel Hardware hin optimiert wird.

Ja es gibt Gründe warum Intel mit ihren Bulldozern massive gewinne machen, die Frage ist sind diese Gründe legitim oder nicht, wenn ein Markt so kaputt ist das ein Hersteller mit einem grottenschlechten Produkt Rekordumsaetze nach dem anderen fahren kann muss man von Monopol oder ner Marktverzerrungen reden so das der Markt nicht funktioniert das bessere Produkt setzt sich nicht mehr durch, was natürlich negativ für die Endkunden ist, selbst wenn es Firmen sind die das kaufen sie zahlen überteuerte Preise pro Leistung die sie dann natürlich in irgend ner Form auch an die Kunden weiter reichen.

Intel müsste wohl zerschlagen werden oder zumindest deutlich härter reguliert, wenn sie so den Markt verzerren und beherrschen können, das sie jegliche Konkurrenz ausschalten können.

 

[Ardadamarda]

Intel Aktie steigt heute zeitweise um +8% und erreicht neues 20 jahreshoch!
Man könnte fast meinen es geht ihnen besser den je!?

 

[Scrush]

Ach so läuft das ganze. Also wie gerade das Impeachment Verfahren gegen Trump? "Mich interessieren keine Fakten.".

bewährte systeme sind fakten.

und zwar für die, die die verantwortung der systeme tragen die inhouse oder beim kunden laufen werden. einfach so umsteigen auf einen anderen hersteller nur weil sie gerade ein kleines hoch haben, wäre viel zu riskant

 

[poi]

"Nobody ever got fired for buying IBM."
Das selbe gilt für intel.

Wenn der Sys-Admin die Wahl hat:
Geld das ihm zur Verfügung gestellt wird in intel stecken und in jedem Fall ne gute Figur machen (intel ist bei den alten Herren ja unfehlbar)
ODER
Der Firma Geld einsparen (was dich als Arbeitnehmer nicht juckt) aber wenn etwas schief läuft steht man als Idiot da weil der Boss nur intel kennt und man gegebenenfalls entlassen wird 'weil man keine Ahnung hat'

Da würde ich auch zu intel greifen

 

[parats]

Intel Aktie steigt heute zeitweise um +8% und erreicht neues 20 jahreshoch!
Man könnte fast meinen es geht ihnen besser den je!?

Der Aktienkurs ist das schlechteste Bewertungsmittel um die wirtschaftliche Lage eines Unternehmens festzustellen. IdR. Läuft die Börse voraus und spiegelt Erwartungen der Zukunft im aktuellen Kurs. Dazu gibt es diverse Kräfte am Kapitalmarkt, die einen Aktienkurs treiben können, also bspw. sentiment, momentum oder allgemeine Börsenstimmung um nur wenige zu nennen.

Abgesehen davon war vor 20 Jahren das Hoch der new economy wozu auch Intel irgendwie zählte. Da hätte man deiner Ansicht nach dann auch sagen können, dass es ihnen besser geht denn je. War aber nicht so.

 

[p.b.s.]

Da ist korrekt, wie Intel selbst auf der eigenen Seite schreibt.
Anhang anzeigen 869408

Das Intel-Zitat bezieht sich wohl auf die Code-Optimierung. Ich meinte jedoch eine wissentlich programmierte Abfrage zur CPU-Erkennung.

Intel hat die Software für eigene Produkte programmiert und die Entwicklung aus der eigenen Tasche bezahlt, also dürfen sie damit auch machen was sie wollen.

Das ist m.A.n. nicht so einfach. Deswegen mein Verweis auf Abkommen und Vereinbarungen zu Patenten und Lizenzen. Würde es sich so verhalten, wie Du es ausdrückst, ergäben solche Verträge wenig Sinn. Denn wenn ich eine Technik vom Konkurrenten verwenden darf, um z.B. bei Anwendungen oder Software keinen Nachteil zu erleiden, darf dieser Konkurrent wie in unserem Fall die CPU über eine versteckte Abfrage nicht ausbremsen oder gar blockieren. Allein daß jemand sowas macht beweist, daß die CPU mit dem Code umgehen könnte, weil die lizenzierte Technik verbaut wurde. Wenn jetzt Intels Software einen so hohen Stellenwert einnimmt, muß sogar darauf geachtet werden, in diesem Punkt nicht negativ aufzufallen. Ansonsten steht dann wieder das Kartellamt vor der Tür und die Strafe dürfte dieses mal heftiger ausfallen. Das ist deswegen so geregelt, weil eine solche Marktmacht neue Entwicklungen und den Fortschritt ausbremst oder gar negiert, und das sogar wissentlich. Wie man aktuell bei AMD neuen CPU's beobachten kann, hat Intel dahingehend tatsächlich geschlafen, besser gesagt, kaum investiert und ist wohl nun versucht, um Ecken seinen Konkurrenten durch derart unlautere Methoden den Absatz zu erschweren. Das geht aber nur, wenn man ein Monopol inne hat, sei es bei der Hardware oder wie in unserem Fall bei der Software. Das ist ganz klar wettbewerbswidrig und kann auch nicht mehr so einfach relativiert werden.

 

[Hayda Ministral]

@xexex , wenn ich Ned Flanders richtig verstehe, ist nicht die Code-Optimierung das Problem, sondern wohl eine eingebaute Abfrage zur CPU-Identifikation

Korrekt.

das dann AMD stark benachteiligt

Nicht korrekt. Bitte lesen, verinnerlichen und dann erst kommentieren: "Entgangener Vorteil ist kein Nachteil".

Intel nutzt Optimierungen die Intel für ihre CPUs getestet hat und von denen Intel weiß (na ja, zu wissen glaubt, Laurin FDIV läßt grüßen) dass sie auf ihren CPUs fehlerfrei laufen.

Ist die Begründung hinterfurzig? Ja, ist sie. Aber leider trotzdem im Kern nicht zu entkräften. Wer sich auf den Compiler eines CPU-Herstellers einläßt muss damit leben dass dieser Compiler nur für die CPUs des Herstellers optimale Compilate liefert. Die nicht-Optimierung betrifft im übrigen ja nicht nur AMDs sondern auch VIA/Zhaoxin. Es düfte also keine Abfrage "wenn AMD dann" geben sondern nur eine Abfrage "wenn nicht Intel [+Modell]" dann".

 

[olligo]

Alles nur weil wir den 9900k gekauft haben ...... heute stand jetzt, würde ich den AMD bevorzugen!

 

[p.b.s.]

Es düfte also keine Abfrage "wenn AMD dann" geben sondern nur eine Abfrage "wenn nicht Intel [+Modell]" dann".

Welche Prozessoren arbeiten denn noch mit dem Intel-Compiler? Cyrix? IBM? Wenn eine solche Abfrage implementiert wurde, nutzt es nicht der Optimierung. Denn wenn ein Prozessor den Code verarbeiten kann, kann es das auch bei einer Optimierung oder nicht. Nur daß eine Optimierung tatsächlich die Intel-CPU beschleunigt, was auch legitim ist. Eine Abfrage in der genannten Form ist demzufolge überflüssig und dient einzig nur der Benachteiligung von Konkurrenten, was wettbewerbswidrig ist und wie schon gesagt gegen Lizenzverträge verstößt.

 

[halbtuer2]

Ich bin zwar ziemlich spät in dieser Diskussion, aber:
Ist doch schön für Intel, wenn sie ihre Gewinnmarge erhöhen konnten, auch wenn es teilsweise zu Lasten von entlassenen Mitarbeitern geht. Aber so funktioniert der Kapitalismus. Und auch im Marxismus ist eben nicht jede Person gleich, gibt genügend Beispiele dafür.
Und das geneigter Kunder eher einem Intel als einem AMD greift: naja, Werbung halt.
Wer kauft denn einen WMB? Dann doch lieber einen BMW, oder?

Ich persönlich habe auch zu AMD der 3. Generation gewechselt, nachdem mein alter Xeon im Desktop ein bißchen an seine Grenzen gestoßen ist. Muss aber letzten Endes sagen, dieser Xeon hat 8 Jahre seinen Dienst verrichtet,
keine Murren oder Ähnliches.
Kein manuelles Hand anlegen von meiner Seite aus.
Hingegen war es bei dem Ryzen schon nötig, ein bißchen im Internet zu stöbern, daß Cool and Quit anständig funktionierte und der Prozessor nicht immer ständig am Limit lief.
Und ich hatte mich vorher ein wenig über den neuen Prozessor belesen, nur leider wurde diese Thematik in keinem Test erwähnt, hingegen das Internet voll von Fragen und Hilferufen ist.
Schmällerte meine Freude über diese schöne CPU natürlich ein bißchen, aber wenn auch dieser Ryzen 8 Jahre werkelt, wie sein Vorgänger, war es eine gute Wahl.

Aber wie auch schon früher erwähnt: Desktopmarkt ist wohl nur ein kleiner Teil bei Intel.
Die Krone der Leistung zu besitzen mag schön sein, scheinbar hat sie AMD zur Zeit, aber Leistung allein reicht nicht.
Genau wie im wahrem Leben.

 

[xexex]

Welche Prozessoren arbeiten denn noch mit dem Intel-Compiler?

Kein Prozessor nutzt einen bestimmten Compiler, es bleibt dir immer frei überlassen ob du den direkt von Microsoft nimmst, den freien GCC benutzt oder auf andere zugreifst.

Den Intel Compiler gibt es seit über zwanzig Jahren und entwickelt wurde er, um die eigenen CPUs besser und zeitnaher zu unterstützen.
https://en.wikipedia.org/wiki/Intel_C++_Compiler

Selbst auf der Wikipedia steht auch nicht erst seit heute:

The compilers generate optimized code for IA-32 and Intel 64 architectures, and non-optimized code for non-Intel but compatible processors, such as certain AMD processors. A specific release of the compiler (11.1) is available for development of Linux-based applications for IA-64 (Itanium 2) processors.

und wie schon gesagt gegen Lizenzverträge verstößt.

Gegen welche Lizenzverträge? Was hat ein Compiler mit CPU Patenten zu tun? Ziehe dir bitte keine Sachen aus der Nase die es so nicht gibt und stelle sie als gegeben dar.

 

[Banned]

Man möge sich mal vorstellen, die hätten auch noch vernünftige CPUs in 10nm auf die Reihe gekriegt für Server und Desktop.

Was wäre dann erst los?


Zeigt mir auf jeden Fall, dass viele Leute hier von Aktien nicht wirklich Ahnung haben, so wie ich auch.