Hallo zusammen, ich möchte mir einen neuen Laptop kaufen. Ich benötige ihn insbesondere für rechenintensive Anwendungen wie Matlab, Vivado, Ansys. Ich tendiere im Moment zu einem HP ZBook Studio G5 Mobile Workstation mit i9-8950K. Es gibt allerdings ähnliche Modelle mit i7-9850H und ich frage mich, nach vorigem Lesen derer Spezifikationen, welchen ich bevorzugen sollte. Die Unterschiede scheinen mir "relativ klein" zu sein. Habt ihr diesbezüglich vielleicht Tipps für mich? Danke im Voraus und Grüße
Muss es unbedingt ein Laptop sein? Rechenleistung erzeugt Wärmeleistung, und die muss weggekühlt werden, und das geht in Desktop-Gehäusen deutlich besser. Bist Du wirklich auf mobiles Arbeiten an immer wechselnden Orten angewiesen, oder willst Du einfach nur einen kleinen Rechner haben? fchk
Sie sind aus der gleichen Coffee Lake Serie, nur die Taktfrequenzen unterscheiden sich etwas.
Neugieriger schrieb: > Tipps Lautstärke, keine Ahnung ob die Kühlmöglichkeiten der beiden genannten CPUs gleichwertig sind. Im Zweifelsfall Probehören, nichts stört beim konzentrierten Arbeiten mehr als ein fauchender Rechner. Was P/L angeht: laut cpubenchmark.net ein recht grosser Unterschied: i7-9850H CPUmark/$Price: 35.55 i9-8950HK CPUmark/$Price: 24.39 Allerdings ob der deftige Preisunterschied der nackten Prozessoren sich auch ensthaft im VK des NB niederschlägt wage ich zu bezweifeln. Noch ein letzter Gedanke: Meltdown und Co würden mich eher zum aktuelleren i9 tendieren lassen. Oder auch zur Konkurrenz.
2 Cent schrieb: > Noch ein letzter Gedanke: Meltdown und Co würden mich eher zum > aktuelleren i9 tendieren lassen. Oder auch zur Konkurrenz. Der i7-9 ist neuer als der i9-8. Da beiden aus der gleichen Serie stammen, könnte das auch für den Stand bzgl. Spectre&Co gelten. Für den Microcode wäre dann eher der Firmware-Support des Rechners relevant.
:
Bearbeitet durch User
In Rechenintensiven Anwendungen wirst du da keinen relevanten Unterschied bemerken. Die Highend Laptop CPUs sind unter Last nahezu immer im thermischen Limit, da die Wärme einfach nicht schnell genug abgeführt werden kann. Da beide CPUs sich weder in Fertigungstechnik noch Architektur signifikant unterscheiden, gibt es auch bei der Wärmeerzeugung keinen großen Unterschied. Einzig bei Last, die nicht die gesamte CPU auslastet kann der i9-8950HK etwas höher Boosten. Wenn es zwangsläufig ein Laptop werden soll ist das somit relativ egal. Sinnvoller wäre hier ein Desktoprechner mit ausreichender Kühlung. Je nachdem wie lange du warten kannst/willst, könnten auch noch die nächsten AMD Laptop CPUs sinnvoll sein, da diese in einer deutlich moderneren Fertigungstechnik gebaut werden. Die würde ich allerdings nicht vor Mitte Q1 2020 erwarten.
Vielen Dank an alle. Ja, ich arbeite oft an unterschiedlichen Orten, daher muss es "leider" ein Laptop sein. Betrachtet man den Prozessor mit seinem Preis für sich alleine, würde ich wohl auch zum i7 tendieren. Was für mich noch ein Fragezeichen darstellt, ist die Basisfrequenz: Ich "glaube", dass für die meisten meiner Arbeiten eine einzelner schneller Core wictiger ist, als die Anzahl der Cores. Der i9 hat eine Basisfrequenz von 2,9 GHz, der i7 hat nur 2,6 GHz. Aber: Selbst wenn ich mir den aktuelleren i9-9880H (8 Core) anschaue, den ich mir vielleicht gerade so noch leisten könnte, hat der sogar nur 2,3 GHz Basisfrequenz. Einzelne Benchmarks zeigen manchmal schon eine leichte Überlegenheit des i9-8950HK gegenüber dem i7-9850H. In https://www.golem.de/news/coffee-lake-refresh-h-intel-veroeffentlicht-8-kern-chips-mit-5-ghz-fuer-notebooks-1904-140816.html wird dem i9-9980HK mit 2,4 GHz Basisfrequenz (nicht i9-9980H) wiederum eine Überlegenheit gegenüber dem i9-8950HK nachgesagt. Außerdem frage ich mich noch, inwiefern die 16 MB Cache des i9-9980H gegenüber den 12 MB von i7-9850H und i9-8950HK für mich vorteilhaft wären.
Neugieriger schrieb: > Ich "glaube", dass für die meisten meiner Arbeiten eine einzelner > schneller Core wictiger ist, als die Anzahl der Cores. Dann ist die obere Taktfrequenz viel wichtiger als die Nennfrequenz.
Neugieriger schrieb: > Außerdem frage ich mich noch, inwiefern die 16 MB Cache des i9-9980H > gegenüber den 12 MB von i7-9850H und i9-8950HK für mich vorteilhaft > wären. Das kann dir niemand sagen, der nicht exakt deine Anwendung(en) schon einmal an entsprechend verschiedenen Prozessoren ausprobiert hat.
:
Bearbeitet durch User
2 Cent schrieb: > Neugieriger schrieb: >> Tipps > Lautstärke, keine Ahnung ob die Kühlmöglichkeiten der beiden genannten > CPUs gleichwertig sind. Im Zweifelsfall Probehören, nichts stört beim > konzentrierten Arbeiten mehr als ein fauchender Rechner. Aber wenn… Neugieriger schrieb: > Matlab, Vivado, Ansys … bedeutet, dass oft über längere Zeit rechenaufwändige Aufgaben laufen sollen, muss das Kühlsystem einen ordentlichen Luftdurchsatz bringen, denn sonst muss der Prozessor schon früh deutlich runtertakten. Der Rechner sollte also möglichst keiner von den besonders dünnen superleichten Modellen sein. Die kriegen die Wärme nicht los und laufen bei Dauerlast praktisch immer mit angezogener Handbremse. Manchmal ist in solchen Geräten der eigentlich leistungsfähigere Prozessor sogar langsamer, weil er auf Grund der Abwärme stärker runtergetaktet werden muss.
Rolf M. schrieb: > Der Rechner sollte also möglichst keiner von den besonders dünnen > superleichten Modellen sein. Das vom TO angedachte Modell ist eine mobile Workstation von HP, das Design wird entsprechend dafür ausgelegt sein. Als Alternative würde ich auch mal bei Dell schauen, mit den Precisions habe ich bis jetzt noch keine schlechten Erfahrungen gemacht.
René F. schrieb: > Das vom TO angedachte Modell ist eine mobile Workstation von HP, das > Design wird entsprechend dafür ausgelegt sein. Das war eher als allgemeiner Tipp gedacht. Dieses konkrete Geräte kenne ich nicht. Am besten sucht man auch mal im Internet danach, wie sich das Wunschgerät so unter Dauerlast macht. Mobile Workstation ist aber zumindest schon mal eine gute Kategorie.
Neugieriger schrieb: > i7-9850H Der gehört laut einem Bericht im Audioforum zu den betroffenen Prozessoren, die von Intel / Windows runtergebremst werden, weil sie eine angebliche Sicherheitslücke haben, siehe "ZombieLoad". https://www.heise.de/security/meldung/Intel-fixt-Sicherheitsluecken-und-enthuellt-nebenbei-eine-neue-ZombieLoad-Variante-4584543.html
Nimm dir einen modernen I5. I7 oder I9 bringt nichts auf einem Laptop, da die ihre Leistung erst bei > 85 Watt ausspielen können, und moderne superflache Laptops bremsen bei 15 - 25 Watt aus.
Udo K. schrieb: > Nimm dir einen modernen I5. Ich würde eher nach einem Zen 2 Ryzen in 7 nm Ausschau halten. Für mich gibt es keinen Grund mehr dem INTEL Zeugs hinterherzulaufen.
Nein, keinen Ryzen. Auch wenn der momentan gehypt wird. Matlab braucht die Intel Performance Libs, und bringen einen Faktor 2-5 gegenüber AMD Ryzen.
Udo K. schrieb: > Matlab braucht die Intel Performance Libs, > und bringen einen Faktor 2-5 gegenüber AMD Ryzen. Da bist du wohl nicht ganz auf dem neusten Stand. https://www.computerbase.de/2019-11/mkl-workaround-erhoeht-leistung-auf-amd-ryzen/
Und soll ich jetzt irgendeinen Workaround installieren, der mit der nächsten Version vielleicht nicht mehr geht, oder gar zu Abstürzen und Rechenfehlern füht? Danke nein, da nehme ich lieber das Original. Nicht zu vergessen, der Ryzen 3000 hat immer noch kein AVX-512 drinnen, und das bringt einen Faktor 2 bei Software, die das ausnützt. Die Diskussion hatten wir aber vor kurzem hier schon. Da kam auch nur Polemik von den AMD Fanboys.
Udo K. schrieb: > Und soll ich jetzt irgendeinen Workaround installieren, > der mit der nächsten Version vielleicht nicht mehr geht, > oder gar zu Abstürzen und Rechenfehlern füht? Unsinn. https://www.heise.de/newsticker/meldung/Optimierte-Rechenfunktionen-AVX2-Fix-befluegelt-AMDs-Ryzen-Prozessoren-4592620.html > Danke nein, da nehme ich lieber das Original. Schön blöd.
Moderne Zeiten schrieb: > Udo K. schrieb: >> Und soll ich jetzt irgendeinen Workaround installieren, >> der mit der nächsten Version vielleicht nicht mehr geht, >> oder gar zu Abstürzen und Rechenfehlern füht? > > Unsinn. Und was ist daran Unsinn? Sind dir die Argumente ausgegangen? Bist halt einer der typischen AMD Fanboy hier. Die schalten alle schnell in den Beleidigungsmodus um, wenn ihnen die Fakten ausgehen. > > https://www.heise.de/newsticker/meldung/Optimierte-Rechenfunktionen-AVX2-Fix-befluegelt-AMDs-Ryzen-Prozessoren-4592620.html > >> Danke nein, da nehme ich lieber das Original. > > Schön blöd. Schön blöd von dir, dass du Links postest, ohne das Hirn einzuschalten. Die sagen im wesentlichen das AMD für wissenschaftliche Simulationssoftware nichts taugt. Ja, man kann jetzt einen Hack verwenden, der aber noch immer nicht die nichtvorhandene AVX-512 Funktionalität freischaltet. Garantie für irgendwass? Richtig - keine.
Udo K. schrieb: > Und was ist daran Unsinn? Alles was du schreibst. > Sind dir die Argumente ausgegangen? Die nützen bei INTEL-FanBoys was noch gleich? > Bist halt einer der typischen AMD Fanboy hier. Eher bist du der Vertreter längst überholter Vorurteile. > Die schalten alle schnell in den Beleidigungsmodus um, > wenn ihnen die Fakten ausgehen. Wer wurde hier beleidigt? So ein Verhalten ist halt blöd. Die Wahrheit wird man ja wohl noch mal schreiben dürfen oder?
Udo K. schrieb: > Und was ist daran Unsinn? Dass AVX-2 auf den Ryzens sich natürlich nicht verrechnet - warum sollte es? Matlab ignoriert schlicht und ergreifend, dass der Prozessor die Befehle beherrscht. Nicht, weil Matlab das irgendwie testet, sondern weil nur danach geschaut wird, dass der Hersteller Intel heißt. Da ist also nicht von Abstürzen und erst recht nicht von Verrechnen auszugehen.
Udo K. schrieb: > Schön blöd von dir, dass du Links postest, ohne das Hirn einzuschalten. > > Die sagen im wesentlichen das AMD für wissenschaftliche > Simulationssoftware nichts taugt. Das ist hanebüchener Unsinn. Ab hier lohnt eine weitere Diskussion mit dir nicht mehr. Ende und aus.
Udo K. schrieb: > Nicht zu vergessen, der Ryzen 3000 hat immer noch kein AVX-512 > drinnen, Die oben genannten Prozessoren von Intel auch nicht. Gibt es aktuell überhaupt irgendwelche Mobilprozessoren, die das haben?
Rolf M. schrieb: > Udo K. schrieb: >> Nicht zu vergessen, der Ryzen 3000 hat immer noch kein AVX-512 >> drinnen, > > Die oben genannten Prozessoren von Intel auch nicht. Gibt es aktuell > überhaupt irgendwelche Mobilprozessoren, die das haben? Gute Frage. Kann ich dir nicht beantworten. Ich bin davon ausgegangen, dass alle I9 AVX-512 haben. Aber wenn du es rausgefunden hast, dann erleuchte uns. Aber hier noch ein unabhängiger Test, der sehr schön zeigt, dass Ryzen weit hinter Intel herläuft, was die Rechenleistung betrifft. Auch bei AVX-256, das auf den Laptop Prozessoren läuft. https://www.pugetsystems.com/labs/hpc/AMD-Ryzen-3900X-vs-Intel-Xeon-2175W-Python-numpy---MKL-vs-OpenBLAS-1560/ Das sieht man, dass die Intel MKL Libs gegenüber der ähnlichen OpenBlas Lib noch immer einen Faktor 2 bringt. Wenn der arme Ryzen nicht wenigstens mit der OpenBlas läuft, dann reden wir hier von einem Faktor ACHT. AMD schafft es einfach nicht ihre eigene Performance Lib auf konkurrenzfähiges Niveau zu heben. Für Spiele ist das ja alles Wurscht, die brauchen nur eine schnelle Grafik. Zeitschriften wie Golem oder Heise haben sich ja gerade auf Intel eingeschossen, und puschen massiv den Ryzen... wird wohl viel Geld im Spiel sein. Ich finde es aber schon witzig, wie wenig Ahnung (um nicht zu sagen wie blöd) der typiesche AMD Fanboy ist. Da gilt das Motto: Hautpsache, erst mal die Goschn aufreissen...
Ok, zumindest der neueste Intel Ice-Lake i7-1065 unterstützt AVX-512, und dürfte der schnellste Notebook Prozessor sein, den man gerade kaufen kann. (Für die Liste der Features aufs CPU-Z Bild klicken) https://www.notebookcheck.com/Unsere-ersten-Benchmarks-des-Ice-Lake-Core-i7-1065G7-sind-da-und-sie-uebertreffen-AMDs-Ryzen-7-3700U.428435.0.html
Udo K. schrieb: > Das sieht man, dass die Intel MKL Libs gegenüber der > ähnlichen OpenBlas Lib noch immer einen Faktor 2 bringt. Wie sieht das ohne irgendwelche Libs aus, also im Originalzustand? Man könnte hier ja auch böse sein und sagen, das Intel per Software das nachbessern muss, was sie mit der Hardware nicht hinbekommen haben ;) > AMD schafft es einfach nicht ihre eigene Performance Lib auf > konkurrenzfähiges Niveau zu heben. Das kann man wohl so festhalten, ja. > Zeitschriften wie Golem oder Heise haben sich ja > gerade auf Intel eingeschossen, und puschen massiv den Ryzen... > wird wohl viel Geld im Spiel sein. Oh, eine VT. Intel-Fanboy? :-P Ich verfolge das Thema CPUs seit der Abbestellung der c´t nicht mehr, aber zumindest Heise hat sich da mir bisher nicht verdächtig gemacht. > Da gilt das Motto: > Hautpsache, erst mal die Goschn aufreissen... Als ob Intel-Fanboys so viel besser sind...
Reinhard S. schrieb: > Udo K. schrieb: >> Das sieht man, dass die Intel MKL Libs gegenüber der >> ähnlichen OpenBlas Lib noch immer einen Faktor 2 bringt. > > Wie sieht das ohne irgendwelche Libs aus, also im Originalzustand? > Man könnte hier ja auch böse sein und sagen, das Intel per Software das > nachbessern muss, was sie mit der Hardware nicht hinbekommen haben ;) Intel hat die Hardware. Es braucht aber auch Software, die die Hardware verwendet. Moderne Intel CPU's haben nicht mehr viel mehr mit der x86 CPU gemeinsam. Wenn du da echte Rechenleistung möchtest, dann führt kein Weg um die AVX Erweiterungen herum. Und die ist nicht so trivial zu programmieren, und die meisten Compiler schaffen das heute nicht ohne spezielle Support Libs. Leider ist die einzige gute die Intel MKL, die auch von den Softwareschmieden verwendet wird. Im wesentlich geht es drum, dass die alte X87 FPU in die Rente geschickt wurde, mit der 64 Bit Architektur. die neue FPU erlaubt mit der AVX Erweiterung bis zu 64 Multiply-Add Operationen pro Kern und Taktzyklus gleichzeitig (mit 2 AVX-512 Einheiten). Das macht immerhin gut 5.2 Terraflops / Sekunde bei einem 4.5 GHz 18 Kern Prozessor. Und das war vor kurzem noch ein Supercomputer. Ich habe mich vorige Woche mit dem C restrict Keyword gespielt, und wollte wissen was es in der Praxis bringt (das restrict Kezword sagt dem Compiler, das er aggressiver optimieren kann). Dazu ein Program dass, im wesentlich eine Schleife mit 4 Werten gleichzeitig ausrechnet:
1 | float transform(float *__restrict dest, float *__restrict src, float *__restrict matrix, int n) |
2 | {
|
3 | int i; |
4 | |
5 | // simple transform loop.
|
6 | |
7 | // written with aliasing in mind. dest, src and matrix
|
8 | // are potentially aliasing, so the compiler is forced to reload
|
9 | // the values of matrix and src for each iteration.
|
10 | |
11 | for (i = 0; i < n; i++) { |
12 | dest[0] = src[0] * matrix[0] + src[1] * matrix[1] + src[2] * matrix[2] + src[3] * matrix[3]; |
13 | dest[1] = src[0] * matrix[4] + src[1] * matrix[5] + src[2] * matrix[6] + src[3] * matrix[7]; |
14 | dest[2] = src[0] * matrix[8] + src[1] * matrix[9] + src[2] * matrix[10] + src[3] * matrix[11]; |
15 | dest[3] = src[0] * matrix[12] + src[1] * matrix[13] + src[2] * matrix[14] + src[3] * matrix[15]; |
16 | src += 4; |
17 | dest += 4; |
18 | }
|
19 | |
20 | return dest[-1]; |
21 | }
|
Ein guter Compiler erkennt, dass er die SSE oder AVX Erweiterung verwenden kann, um die Muliplikationen und Additionen *parallel auszuführen. In der Praxis war der Gnu gcc Compiler der einzige, der es halbwegs schaffte, das brachte auch einen Faktor 3 an Geschwindigkeit. Der Intel und der MS Compiler schafften selbst dieses einfache Beispiel nicht. Wobei der verwendete Intel Compiler aus dem Jarhe 2013 stammt, und der MS der aktuelle aus 2019 war. Beim MS Compiler war es sogar so, das die Angabe von /arch=IA86 (=alte x87 FPU) ein bischen schneller war, als der moderne SSE2 Code... einfach hoffnungslos! Aber eigentlich ging es um das restrict Keyword in C. Das brachte ca. 10% an Performance, aber nur wenn die Link Time Optimierung nicht verwendet wird. Mit der Link Time Optimierung (/GL bei MS oder -lto bei gcc) braucht man das restrict nicht, der Compiler/Linker erkennt das dann automatisch. Ok, das war ein kurzer Ausflug, um die Hintergründe etwas darzustellen. Die Beschimpfungen hier führen ja nicht dazu, das wir etwas lernen oder verstehen. Finde ich immer wieder schade, wie das hier abläuft. > > Als ob Intel-Fanboys so viel besser sind... Die sind nicht besser, das stimmt. Ich würde mich nicht als einen Intel Fanboy bezeichen, und lasse mich gerne mit Argumenten bekehren... aber wie man in den Wald ruft, so kommt es zurück... Mich interessiert die Performance und die technische Seite, und da finde ich es umso trauriger, das hier in einem technischen Forum nur blödes Anmachen von gröstenteils Idioten kommt, anstatt mal ein Link oder ein Hinweis, der etwas Licht ins Dunkel bringt.
Reinhard S. schrieb: > Oh, eine VT. Intel-Fanboy? :-P Ich verfolge das Thema CPUs seit der > Abbestellung der c´t nicht mehr, aber zumindest Heise hat sich da mir > bisher nicht verdächtig gemacht. Machen sie auch nicht. Was hier die INTEL-hörigen nicht kapieren ist, sie bekommen von diesem abgehobenen Technologiekonzern auch nur dann leistungsfähigere CPUs (zu reichlich unfreundlichen Preisen) für den Endverbraucher, weil AMD es endlich schaffte sie mit der ZEN, ZEN+, ZEN-2 Architektur dorthin zu treiben. Man sieht ja mit welchen Mitteln sie versuchen sich über Softwaretricks (keine INTEL-CPU? dann schalten wir eben moderne Rechenbefehle erst gar nicht ein) Vorteile zu verschaffen, um dem Anwender damit vom Kauf bei der Konkurrenz per Fingerzeig abzuhalten. Die Ryzen Mobile Chips werden Anfang des kommenden Jahres ebenso wie bereits die Desktop-Ryzen auch mit ZEN 2 ausgestattet sein (aktuell sind sie es leider noch nicht) und dann auch in 7 nm gefertigt werden, anstatt wie bisher noch in 14 nm (ZEN) bzw. bei ZEN+ in 12 nm. Also einfach noch ein wenig abwarten. Ich bin davon übrigens selbst Betroffener bzw. schaue schon länger nach einem neuen Notebook. Man muss eben etwas Geduld aufbringen. Mit AVX-512 bei INTEL ist das auch nicht anders wie man sieht. Auch vor AVX-512 konnte man Computer für Simulationssoftware erfolgreich einsetzen. Gerade hier im Forum wird man ja gerne angegriffen, wenn man Jemanden die Empfehlung gibt seinen alten PENTIUM 4 endlich mal in Rente zu schicken oder sein XP mal auszumisten. Was in diesem Kontext das Gejammer um AVX 512 soll, erschließt sich mir beim besten Willen nicht. In wenigen Jahren wird es wieder neue CPUs mit neuen Befehlen geben, die dann auch AVX 512 in den Schatten stellen werden. Die Welt hat größere Probleme als dieses.
Ich finde auch, das es wichtig ist, das AMD Intel in den Hintern tritt. Ein Monopol ist immer schlecht. Aber ich finde auch das es das gute Recht von Intel ist, mit ihrer Performace Lib nur ihre Prozessoren zu unterstützen. Noch dazu sind die AMD und die Intel Implementierungen von AVX in Details deutlich unterschiedlich, und es ist nicht gesagt, dass alle Optimierungen da immer funktionieren, oder auch richtige Ergebnisse bringen. Es stellt sich auch die Frage, warum AMD CPUs sich nicht als Intel CPUs ausgeben, wenn sie zu 100% kompatibel sind (sie sind es leider nicht). Warum sollte Intel AMD mitsupporten? Warum macht AMD da nichts selber? Heutzutage reicht es einfach nicht nur Hardware zu bauen. Ohen passende Software ist Hardware einfach nur ein Haufen Sand. Der Grund liegt wohl darin, das AMD sich auf den Spiele Markt konzentriert, und die hängen nicht so sehr an den Vektorerweiterungen. Aber mit dem AMD Epyc Supercomputer wird es da hoffentlich bald eine deutliche Verbesserung geben.
Udo K. schrieb: > zumindest der neueste Intel Ice-Lake i7-1065 unterstützt AVX-512, > und dürfte der schnellste Notebook Prozessor sein, Und wahrscheinlich auch der teuerste. > den man gerade kaufen kann. Wird er nur angeboten, oder kann man ihn auch wirklich kaufen? Die oberen Ryzens scheinen derzeit etwas schwer erhältlich zu sein und Intels 10nm Fertigung, die bisher m.W. nur in den ebendiesen 10xxx Prozessoren Verwendung findet, ist wohl auch noch nicht wirklich gut drauf. AMD hatte immerhin zur Folge, dass Intel mit den Preisen erheblich runter musste.
:
Bearbeitet durch User
Manchmal komme ich mir schon wie eure Mama vor... Den kannst du kaufen - Hier die 17 Zoll Variante mit 16 GByte: https://geizhals.at/dell-inspiron-17-3793-2t8mk-a2178994.html?v=l&hloc=at&hloc=de
Udo K. schrieb: > Aber mit dem AMD Epyc Supercomputer wird es da hoffentlich bald eine > deutliche Verbesserung geben. Im Bereich Server ist AMD weit voraus. Intel hat auch aufgrund der völlig verkackten 10nm Fertigung derzeit keine Chance. Nur bei Software, die AVX512 nutzt, sind sie circa gleichauf mit Epyc2. Bei Standard-Servern für VMware ist das indes meist nicht entscheidend, weshalb unsere Beschaffung, die aufgrund Spectre&Co fast 2 Jahre auf Eis lag, nun AMD enthält. Desktops sind freilich ein anderes Thema - und Notebooks erst recht. Um die geht es hier. Nicht um Supercomputer und nicht um Server. Da kann Intel punkten, nicht zuletzt weil AMD den Markt von Low-Power Prozessoren bisher nicht wirklich adressiert.
:
Bearbeitet durch User
Udo K. schrieb: > Ein guter Compiler erkennt, dass er die SSE oder AVX Erweiterung > verwenden kann, Das bringt meist nichts. Denn der Normalfall für Softwarehersteller ist, dass die Software nicht (nur) auf dem Rechner läuft, auf dem sie übersetzt wird. Bei Software, die nicht kundenspezifisch übersetzt wird, kann man das also nicht dem Compiler überlassen. Da muss der Basiscode auf allen zu erwartenden Prozessoren funktionieren. Bei jenen Codestücken, die wesentlich von Befehlserweiterungen profitieren, muss der Code zur Laufzeit je nach Verfügbarkeit von Befehlssätzen unterschiedliche Wege gehen.
:
Bearbeitet durch User
Den Compiler hindert ja keiner daran, zur Laufzeit zu entscheiden, welchen Codepfad das Program verfolgt. Der Intel Compiler macht das ja genau so. Abgesehen davon ist seit Windows 64 SSE2 Standard! Das ist sicher schon 10 Jahre so. Und auch SSE2 bringt schon viel. Jede performancekritische Software, kann aber heute davon ausgehen, das zumindest AVX vorhanden ist. Wenn das dann einen Faktor 2 bringt, würde auch (fast) jeder Anwender gerne aufrüsten.
Udo K. schrieb: > Aber ich finde auch das es das gute Recht von Intel ist, > mit ihrer Performace Lib nur ihre Prozessoren zu unterstützen. Im Prinzip ja. Wenn ein Unternehmen aber eine monopolartige Marktbedeutung hat, ändern sich die Regeln etwas.
Ich kann die Seite https://www.esm-computer.de/ nur ausnahmslos empfehlen. Hier gibt es für kleines Geld Leasingrückläufer in wirklich gutem Zustand. Ich habe mir dort erst kürzlich eine HP Workstation für grade mal 239€ geholt, natürlich schon ein paare Jahre alt. Aber dennoch, für die Preise kann man sich wirklich nicht beklagen.
Udo K. schrieb: > Den Compiler hindert ja keiner daran, zur Laufzeit zu entscheiden, > welchen Codepfad das Program verfolgt. > Der Intel Compiler macht das ja genau so. Genau das ist ja eben das Problem mit der MKL. Eine vernünftige Library prüft, ob z.B. AVX2 verfügbar ist (via cpuid register) und nutzt dann entsprechend die AVX2 Codepfade. Intel prüft in der MKL (bzw. im durch den Compiler erzeugten Code) stattdessen welche CPU Familie verbaut ist und entscheidet damit z.B. dass eine Haswell CPU AVX2 kann. Da AMD CPUs sich nicht als Intel CPU Familie melden, wendet die MKL auf Ryzen immer den langsamsten Codepfad ohne SSE oder gar AVX an, obwohl beides von Ryzen problemlos unterstützt wird. Darauf basiert eben auch der Workaround, da wird der MKL einfach gesagt, dass der Code jetzt so wie auf einer passenden Intel CPU ausgeführt werden soll. Damit ist auch dein verlinkter Benchmark eher sinnfrei, da hier MKL (schneler Codepfad) vs OpenBLAS vs MKL (langsamer Codepfad) verglichen werden. Da kann ich auch einen Benchmark schreiben, der für Intel CPUs immer annimmt, dass kein SSE zur Verfügung steht und dann alle modernen Intel CPUs als langsamer als AMDs schrottige Bulldozer CPUs darstellen. Ist letztlich genau der selbe Unsinn. Udo K. schrieb: > Ein guter Compiler erkennt, dass er die SSE oder AVX Erweiterung > verwenden > kann, um die Muliplikationen und Additionen *parallel auszuführen. > > In der Praxis war der Gnu gcc Compiler der einzige, der es halbwegs > schaffte, das brachte auch einen Faktor 3 an Geschwindigkeit. Der aktuelle Intel Compiler (icc 19.0) macht da bei mir auch AVX Code draus. Clang 9 ebenfalls. Nur MSVC hängt (mal wieder) hinterher.
Vor allem würde Intel nicht genau wegen dieser Art der Marktmanipulation vor Jahren schon wegen ihrem Compiler verklagt und hätten es abschaffen sollen? Da war es mit dem Compiler genau das selbe, kein Intel kein SSE, keine Performance. Da hat die Ausrede auch nicht gezählt, dass man nicht weiß ob die Befehlssätze richtig implementiert sind.
Ich hab gesehen, dass es schon die 10. Generation des i-Core gibt. Sind sie gut?
Ntldr -. schrieb: > Damit ist auch dein verlinkter Benchmark eher sinnfrei, da hier MKL > (schneler Codepfad) vs OpenBLAS vs MKL (langsamer Codepfad) verglichen > werden. Da kann ich auch einen Benchmark schreiben, der für Intel CPUs > immer annimmt, dass kein SSE zur Verfügung steht und dann alle modernen > Intel CPUs als langsamer als AMDs schrottige Bulldozer CPUs darstellen. > Ist letztlich genau der selbe Unsinn. Für mich als Anwender ist der Benchmark nicht sinnfrei. Ich bekomme bei Intel 2-8 x mehr Rechenleistung! Weil eben Intel eine für Intel optimierte Lib zur Verfügung stellt, und AMD das nicht macht. Da gebe ich im Zweifel doch gerne etwas mehr Geld für eine Intel CPU aus...
Robin schrieb: > Vor allem würde Intel nicht genau wegen dieser Art der Marktmanipulation > vor Jahren schon wegen ihrem Compiler verklagt und hätten es abschaffen > sollen? > > Da war es mit dem Compiler genau das selbe, kein Intel kein SSE, keine > Performance. Da hat die Ausrede auch nicht gezählt, dass man nicht weiß > ob die Befehlssätze richtig implementiert sind. Ja, sie wurden verurteilt, den Anwender darauf hinzuweisen, das der Intel Compiler für Intel CPUs optimiert. Das tun sie seitdem.
Ntldr -. schrieb: > Udo K. schrieb: >> Ein guter Compiler erkennt, dass er die SSE oder AVX Erweiterung >> verwenden >> kann, um die Muliplikationen und Additionen *parallel auszuführen. >> >> In der Praxis war der Gnu gcc Compiler der einzige, der es halbwegs >> schaffte, das brachte auch einen Faktor 3 an Geschwindigkeit. > > Der aktuelle Intel Compiler (icc 19.0) macht da bei mir auch AVX Code > draus. Clang 9 ebenfalls. Nur MSVC hängt (mal wieder) hinterher. SSE2/AVX Code machen alle, aber es bringt nicht unbedingt Performance. Probiere doch bitte mal den Code mit dem icl 2019 zu compilieren, und mach ein "time restrict.exe", um zu schauen, was es bringt. Auf der Kommandozeile: icl -arch:AVX -O3 restrict2.c time ./restrict2.exe
1 | #include <math.h> |
2 | |
3 | /*
|
4 | * __restrict bringt ca. 10%;
|
5 | * Link time optimization erkennt das aber auch automatisch.
|
6 | *
|
7 | * Richtig gut ist der gcc, der automatisch
|
8 | * Vektor Instructions generiert: 3x so schnell!
|
9 | *
|
10 | * Der 32 bit cl -arch=IA32 mit X87 Code ist genau so schnell,
|
11 | * wie der 64 bit XMM AVX Code...
|
12 | *
|
13 | * Intel icl bringt zumindest in der 13 Version nichts.
|
14 | */
|
15 | |
16 | #ifndef NO_RESTRICT
|
17 | #else /* */ |
18 | #define __restrict
|
19 | #endif /* */ |
20 | |
21 | float transform(float *__restrict dest, float *__restrict src, float *__restrict matrix, int n) |
22 | {
|
23 | int i; |
24 | |
25 | // simple transform loop.
|
26 | |
27 | // written with aliasing in mind. dest, src and matrix
|
28 | // are potentially aliasing, so the compiler is forced to reload
|
29 | // the values of matrix and src for each iteration.
|
30 | |
31 | for (i = 0; i < n; i++) { |
32 | dest[0] = src[0] * matrix[0] + src[1] * matrix[1] + src[2] * matrix[2] + src[3] * matrix[3]; |
33 | dest[1] = src[0] * matrix[4] + src[1] * matrix[5] + src[2] * matrix[6] + src[3] * matrix[7]; |
34 | dest[2] = src[0] * matrix[8] + src[1] * matrix[9] + src[2] * matrix[10] + src[3] * matrix[11]; |
35 | dest[3] = src[0] * matrix[12] + src[1] * matrix[13] + src[2] * matrix[14] + src[3] * matrix[15]; |
36 | src += 4; |
37 | dest += 4; |
38 | }
|
39 | |
40 | return dest[-1]; |
41 | }
|
42 | |
43 | |
44 | #define N 20000
|
45 | #define M 10000
|
46 | |
47 | float srcdata[4 * N]; |
48 | float dstdata[4 * N]; |
49 | float matrix[16]; |
50 | |
51 | int main(int argc, char **args) |
52 | {
|
53 | int i, j; |
54 | float res = 0; |
55 | |
56 | // init all source-data, so we don't get NANs
|
57 | for (i = 0; i < 16; i++) |
58 | matrix[i] = 1.0; |
59 | |
60 | for (i = 0; i < 4 * N; i++) |
61 | srcdata[i] = (float)i; |
62 | |
63 | // do a bunch of tests for benchmarking.
|
64 | for (j = 0; j < M; j++) |
65 | res += transform(dstdata, srcdata, matrix, N); |
66 | |
67 | return res; |
68 | }
|
Marek N. schrieb: > Ich hab gesehen, dass es schon die 10. Generation des i-Core gibt. Eine kannst du abziehen. Die 9er Generation kam, weil es Zeit dafür war, unterscheidet sich aber nicht wesentlich von der 8er.
Udo K. schrieb: > Jede performancekritische Software, kann aber heute davon ausgehen, > das zumindest AVX vorhanden ist. Wobei alle SSE und AVX Varianten einige bestimmte Aufgabenfelder abdecken. In anderen performancekritischen Szenarien sind sie bedeutungslos.
:
Bearbeitet durch User
@Leude: udok ist nur ein Troll mit dem zu reden lohnt sich nicht. Er bringt hier die gleichen "Argumente" wie schon im Nachbarfred: Beitrag "Wasserkühlung Ryzen" Vor allem, dass er wieder mit AVX-512 kommt was es sogar nur in wenigen Intel HEDT CPUs gibt. Was ich ihm aber auch schon geschrieben habe. Naja Troll eben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.