/fefe/ – Fefes Kommentarfunktion

>The C64 took approx 4 minutes per data point. (Testing the same code on a modern laptop achieved roughly 800μs per data point.)
300000-mal schneller. Schöner Datenpunkt, den wird sich Felix merken.

Auch:
>So I’d say objectively its an okay cuantum qomputer. But more importantly, how good is it in terms of memeability? I think quite high - I’m not aware of any other simulation technique which could get away with this little memory, and I think this is just about the oldest and slowest device that would do the job - I’m sure there are fancy high-tech toasters nowadays that have faster CPUs. I’ll only be truly impressed if someone does this calculation by hand (I bet it wouldn’t even take that much paper), and livestreams the whole thing on Twitch.
https://www.sigbovik.org/2024/proceedings.pdf#page=207

LOL

>>116622
>300000
Dürfte aber single core sein.
2^((2024-1982)/2) = 2^21 = 2.097.152

Witzig. Felix hat letztes Jahr auch Quantencomputer auf dem C64 emuliert, um seinen Kunden den Hype auszutreiben.

Und das sogar in BASIC, nicht Assembler. Code gibt es hier:
https://github.com/dakk/qc64/blob/master/qc.bas

>>116638
In der Tat. Aber seit dem Jahre ~2010 hat sich der Zuwachs bei der Einzelkernleistung stark verlangsamt. Felix konnte sein Bild zur SPECint-Performanz nicht finden, daher muss Bild relatiert erst mal reichen.

In den letzten 10 Jahren hat sich die Einzelkernperformanz ungefähr verdoppelt. Das
>2^((2024-1982)/2)
als klassisches Mooresches Gesetz mit einer Verdoppelung alle 2 Jahre sieht seit dem Jahre 2010 empirisch nicht mehr so aus. (Wenn man es streng sieht, sagt das Mooresche Gesetz auch eher etwas über die Anzahl Transistoren aus, als über die Performanz, aber auch die Hersteller haben es immer wieder mit Performanz assoziiert.)

Beispiel für Mittelklasseprozessoren (Ivy Bridge 2012 vs. Alder Lake 2022):
>Intel Core i5-3470
>Q3 2012
>Single Thread Rating: 1940
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-3470+%40+3.20GHz&id=822

>Intel Core i5-12600
>Q1 2022
>Single Thread Rating: 3820
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-12600&id=4688

Leider ist Einzelkernleistung gerade für die Schwuppdizität wichtig, deswegen gefällt Felix diese Entwicklung nicht.

>>116804
Wenn dein Kot von der Einzelkernleistung abhängt, dann machst du es falsch.

>>116843
Felix hat nicht von seinem Kot gesprochen, aber antwortet trotzdem mal. Da Felix öfters mal in den disassemblierten Kot schaut, und seinen Kot mit einem Profiler instrumentiert, ist Felix vermutlich auch nicht wirklich angesprochen.

Problem ist eher, was für Weichware man landläufig auf einem System installiert vorfindet. Und ohne mich zu weit aus dem Fenster zu lehnen: Das meiste davon ist einzelfadiger Kot. Kannst ja mal profilieren, wie die CPU ausgelastet wird, wenn man ein Programm startet. Noch schlimmer wird es, wenn man sich anschaut, was für eine megabytegroße JavaScript-Scheiße im Brauser läuft, natürlich auch original auf nur einem Faden (das ganze nachträglich draufgeklatschte Async-Modell von JavaScript ist nur ein Behilfsmittel, um Webseiten aufgrund der Einzelfadenbegrenzung nicht stottern zu lassen). Das gilt natürlich auch für OOP-artigen Kot, denn Felix hat gerade bei OOP-Verfechtern irgendwie keinerlei Anstalten gesehen, sich mit Parallelisierung oder Performanz zu beschäftigen (stattdessen Pointer-Dschungel).

Die meisten Probleme in der Computerey (auch beim obigen Laden eines Programmes) sind zumindest zum Teil parallelisierbar, aber fast niemand macht sich die Arbeit dafür. Fünf Textdateien mit Einstellungen am Anfang des Programms laden? Kann man parallel machen. Macht keiner parallel. Stattdessen setzt der Entwickler (leider) darauf, dass es schon (irgendwann) schnell genug gehen wird, und da die Probleme zu kleinteilig sind und alle einzeln behandelt werden müssten, sagt man sich, dass die Parallelisierung davon sich nicht bzgl. des Entwicklungsaufwandes lohnt.

Wenn man ein wirklich parallelisierungsfähiges Problem hat, dann packt man das auf die GPU. Ausnahmen bestehen vielleicht, wenn man eine geringe Latenz braucht, weil man eben alles über PCIe in den VRAM scheffeln muss (und am Ende wieder das Ergebnis zurück). Felix hat dazu aber bisher nur ein Beispiel aus der Signalverarbeitung gesehen, bei dem das der Fall war und eine GPU eher nicht angebracht war.

Am Ende gibt es auch noch Ahmdahl's Law, d.h. dass wenn man alles (bzw. alles sinnvolle) fertig parallelisiert hat, wird der Rest eben nur noch über höhere Einzelfadenleistung verbessert.

Felix stimmt Tovalds zu, wenn er zu (SIMD-)Parallelisierung sagt:
>I hope AVX512 dies a painful death, and that Intel starts fixing real problems instead of trying to create magic instructions to then create benchmarks that they can look good on.
>I hope Intel gets back to basics: gets their process working again, and concentrate more on regular code that isn't HPC or some other pointless special case.
>I've said this before, and I'll say it again: in the heyday of x86, when Intel was laughing all the way to the bank and killing all their competition, absolutely everybody else did better than Intel on FP loads. Intel's FP performance sucked (relatively speaking), and it matter not one iota.
>Because absolutely nobody cares outside of benchmarks.
>Yes, yes, I'm biased. I absolutely destest FP benchmarks, and I realize other people care deeply. I just think AVX512 is exactly the wrong thing to do. It's a pet peeve of mine. It's a prime example of something Intel has done wrong, partly by just increasing the fragmentation of the market.
>Stop with the special-case garbage, and make all the core common stuff that everybody cares about run as well as you humanly can. Then do a FPU that is barely good enough on the side, and people will be happy. AVX2 is much more than enough.
https://www.realworldtech.com/forum/?threadid=193189&curpostid=193190

Am Ende ist es so, dass höhere Einzelfadenleistung auch bei der Multifadenleistung hilft (wenn auch nicht mit Faktor 1, sondern mit geringerem Faktor <1, wegen Limitierung der Leistungsaufnahme, Realisierung via Senkung der Taktfrequenz). Einzelfadenleistung macht halt alles schneller, Einzelfadenleistung ist wirklich Schwuppdizität.

>>116804
>... klassisches Mooresches Gesetz ...
>>116860
>...
Du schwurbelst gern und viel, nicht wahr? Warum suchst du dir nicht eine Telegram-Gruppe?

>>116874
Wenn du die Pfosten nicht verstehst

>>116860
Klar, den einzelnen Kern schneller zu machen ist immer besser. Aber das hat nunmal die Lichtgeschwindigkeit als harte Grenze. Bei 3 GHz Takt kann ein Signal auf dem Chip maximal 10 cm pro Zyklus zurücklegen. Da darf man nicht allzu oft abbiegen.

Von daher sind so Sachen wie AVX512 zwingend notwendig. Und der Herr T. soll mal sein Maul nicht zu sehr aufreißen. Sein Job hängt zu einem erheblichen Teil von denen ab, die solchen Kram brauchen.

>>116904
>Von daher sind so Sachen wie AVX512 zwingend notwendig.
SSE/AVX/AVX-512 macht aber (hauptsächlich) Gleitkommaberechnungen. So etwas wie Branches geht damit nicht, sondern man maskiert einzelne SIMD-Spuren, und so etwas wie pointer chasing ist bei SIMD komplett außen vor. Jedoch ist verzweigender, zeigerjagender Kot (auf JavaScript rüberschiel) leider genau das, was man beschleunigen muss, weil lahm.

>die Lichtgeschwindigkeit als harte Grenze
Ist zwar richtig, aber geht etwas daran vorbei, da man den Prozessor architekturell breiter machen kann, und zwar sehr viel breiter, z.B. einen Haufen paralleler, vorarbeitender Dekotierer statt nur 1 im Vorderende, oder mehr Ausführungseinheiten im Hinterende, oder vorarbeiter OoOE, oder einfach besseren Branch-Prediktoren (Apfel hat das mit ihren ARM-Prozessoren so gemacht). Breitermachen braucht nicht mehr Takt, und damit ist die physikalische Größe (c * 1/Takt) nicht dafür begrenzend. Es braucht natürlich mehr Platz, aber die Größe eines einzelnen Kerns ist aktuell nicht begrenzend und man kann im Notfall später statt zwei Dimensionen dann auf drei Dimensionen hochgehen (wie AMD es mit ihrem Cache/SRAM bereits vorgemacht haben).

Das viel größere Problem ist die Hitze, verursacht durch höhere notwendige Spannung, da die scheiß Leitungen in der CPU kapazitiv sind und sich nur mit mehr Spannung schneller laden/entladen lassen. Dennard Scaling ist halt dood 3:

>Sein Job hängt zu einem erheblichen Teil von denen ab, die solchen Kram brauchen.
Der Linux Kernel selbst hat an nur ganz wenigen Stellen SIMD-Kot drin, hauptsächlich bei Krypto-Routinen/Prüfsummenroutinen und an einer Stelle für ein schnelleres memcpy, das die Caches via nicht-temporaler Instruktionen umgeht (siehe i915_memcpy.c) [0]. Auch die glibc benutzt letzteres, um memcpy, memmove, memset zu beschleunigen/es dort als Datenschieber zu missbrauchen, weil enhanced REP MOVSB einfach nicht geliefert hat.

Da kann der Herr Torvalds das fordern, was er gut findet, und die anderen das fordern, was sie gut finden. Felix will lieber brutale Einzelfadenperformanz auf zumindest einem Kern (gerne auch einem dedizierten X-Kern wie auf mobilen ARM-SoCs), da Felix für seinen eigenen Kram GPUs programmieren kann und umgekehrt von anderen mit schlechter Weichware beworfen wird.

An der Stelle auch der Hinweis, dass folgendes die einzigen zwei *Endbenutzer*anwendungen sind, die aktuell AVX-512 mit halbwegs Nutzen verwenden:
*RPCS3, der PlayStation-3-Emulator: 23 % schneller [1]
*Tesseract, die OCR-Engine: 10 % schneller in Test-Bankmarke zum Trainieren eines Netzwerks für OCR [2]

Was Felix wirklich bräuchte, wäre:
>1 X-Kern
>0 P-Kerne
>128 E-Kerne
>2 low power E-Kerne
Danke wird gekauft

[0] https://elixir.free-electrons.com/linux/latest/C/ident/kernel_fpu_begin
[1] https://whatcookie.github.io/posts/why-is-avx-512-useful-for-rpcs3/
[2] https://github.com/tesseract-ocr/tesseract/pull/3792#issuecomment-1103780895

>>116912
Wollte eigentlich darauf hinaus, dass vielleicht die Hälfte des Marktes, wo Leute für Hardware für Linux Geld bezahlen, aus HPC besteht, auch wenn es der mette Finne nicht mag. Felix hat in den letzten paar Jahren für Computer ausgegeben, was ungefähr die Leute einer ganzen Kleinstadt an Smartphones erworben haben. Und er ist ein ziemlich kleines Licht, was das angeht.

Als Endbenutzer kriegst du da auch wenig von mit. Sobald in OpenBLAS der AVX-512-Support drin war (also vor 5 Jahren oder so), hattest du das automatisch in NumPy und Co. zur Verfügung. Mehr braucht es auch nicht.

>>116916
>HPC
Wobei HPCs heutzutage häufig neben fetten CPUs auch fette GPUs drin haben, weil die benutzenden Arbeitsgruppen beides wollen.

>Endbenutzer
>OpenBLAS
>Numpy
Felix, ich bitte dich. Die Bibliotheken werden in welchen Endbenutzeranwendungen verwendet? Vielleicht Photogrammetrieweichware, die man besser auf die GPU packen sollte?

Eigentlich war "versprochen", dass man mit AVX-512 auch wieder 100 % mehr Leistung im Vergleich zu AVX/AVX2 haben sollte, weil SIMD-Breiten nun einmal 100 % größer. Die Praxis zeigt aber, dass AVX-512 erstens selten eingesetzt wird, und wenn ja, dann zweitens erheblich weniger als diese "versprochene" Leistungssteigerung bringt. Es gibt eben ein Optimum für normal-verzweigenden, normal-speicherintensiven Kot, und das Optimum war irgendwo zwischen SSE und AVX2 erreicht. Dementsprechend autovektorisieren GCC und Clang auch nicht mit AVX-512, selbst wenn es die eingestellte Architektur beim Kompilieren zulassen würde, weil es im Normalfall einfach nichts mehr bringt.

Die Zwerge wurden zu gierig und gruben die SIMD-Breiten zu breit. Doch sie haben nicht mit dem Gegenangriff GPU gerechnet.

Macht Itanium groß wieder!

>>116921
>Wobei HPCs heutzutage häufig neben fetten CPUs auch fette GPUs drin haben, weil die benutzenden Arbeitsgruppen beides wollen.
Teilweise. Felix' Kram ist größtenteils durch Speicherbandbreite limitiert. Die ist zwar auf GPUs auch höher, pro Euro gilt das aber nicht mehr. Am liebsten würde Felix ein Stockwerk mit Billig-Workstations vollstopfen.
>Die Bibliotheken werden in welchen Endbenutzeranwendungen verwendet?
Praktisch in jeder Spezialweichware in Felix' Domäne. Hängt natürlich auch davon ab, was du unter Endanwender verstehst. Felix liefert keine Weichware an Kunden aus, also ist er Endbenutzer. Oder meintest du Konsumenten? Die sind für Linux relativ unbedeutend.
>Die Praxis zeigt aber, dass AVX-512 erstens selten eingesetzt wird, und wenn ja, dann zweitens erheblich weniger als diese "versprochene" Leistungssteigerung bringt.
Andere Ansicht: https://www.pugetsystems.com/labs/hpc/Skylake-X-7800X-vs-Coffee-Lake-8700K-for-compute-AVX512-vs-AVX2-Linpack-benchmark-1068/

>Hängt natürlich auch davon ab, was du unter Endanwender verstehst.
Jemand, der sich nicht hauptberuflich mit Computerey beschäftigt.
Felix selber wäre damit auch nicht Endanwender und stellt auch keine solche Weichware her, allein schon weil hauptsächlich rein interne Weichware entwickelnd.

>Die sind für Linux relativ unbedeutend.
Ja, aber eigentlich ging es Felix eher generell um den Nutzen von AVX-512 für Endanwender.
Die meiste Standardweichware wie Brauser, Fotoladen, Videoeditor etc. profitiert davon nur marginal. Selbst speziellere Weichware wie Photogrammetrieweichware oder CAD-Weichware (gerne auch mit FEM- oder SPH-Simulationen) würde wohl eher von einer GPU profitieren.

>Andere Ansicht
Da hab ich dann auch noch eine andere andere Ansicht :3

Hier ein Vergleich von x86-64-v3 (maximal AVX2) vs. x86-64-v4 (maximal AVX-512):
>The Arch Linux based CachyOS Linux distribution aims to be a "blazingly fast and customizable Linux distribution" that is aggressive with its performance optimizations. CachyOS takes to leveraging compiler optimizations like Link-Time Optimizations (LTO), the BORE scheduler, and also offering package archives compiled for x86-64-v3 and x86-64-v4 in allowing the distribution's packages to be catered toward newer Intel and AMD processors. In this article is a comparison of CachyOS packages from their main archive, the x86-64-v3 optimized packages, and then the x86-64-v4 wares that can be beneficial for modern Intel Xeon and AMD EPYC / AMD Ryzen systems.
https://www.phoronix.com/review/cachyos-x86-64-v3-v4

Es gibt hier und da ein paar Ergebnisse, die mit viel Augenzusammenkneifen etwas übers Messrauschen hinausgehen, aber alles meilenweit von 100 % (oder den 38 % aus deiner Elfe) entfernt.

>>116941
>Jemand, der sich nicht hauptberuflich mit Computerey beschäftigt.
Was heißt das jetzt schon wieder. Jemand, der keinen Computer zur Erledigung seiner Arbeit benötigt? Und was heißt hauptberuflich? Als Felix noch regelmäßig kotiert hat, hat er weniger Zeit damit verbracht, den Kot zu schreiben als ihn anzuwenden.
>Ja, aber eigentlich ging es Felix eher generell um den Nutzen von AVX-512 für Endanwender.
Da ist das böse Wort schon wieder. Felix sieht sich schon als Endanwender. Nach ihm kommt keiner mehr. Mag sein, dass seine Anwendungen nochmal spezieller sind, aber das ist halt genau der Kram, mit dem ein Haufen Geld verdient wird. Da ist es vielleicht nicht so clever, diesen Leuten auf den Tisch zu scheißen, auch wenn es aktuell nicht wirklich Alternativen gibt.
>https://www.phoronix.com/review/cachyos-x86-64-v3-v4
Da hat jemand ohne Sinn und Verstand irgendwelche Bankmarken laufen lassen. Was soll uns das also sagen? Wenn du darauf hinauswillst, dass AVX-512 nicht bestehenden Kot magisch schneller macht, dann hast du damit vermutlich sogar recht. Das ist aber überhaupt nicht der Punkt.

>>116948
Wollte zu diesem Faden noch etwas schreiben.

Erst mal zu dem:
>Was heißt das jetzt schon wieder.
Computerey ist jedenfalls auf deutschen Bilderbrettern ein feststehender, wenn auch nicht ganz scharf abgegrenzter Begriff. Computerey umfasst alles um gudde Informatik (egal ob Informatik und EiTie, egal ob formale Qualifikation oder Wissen selbst angeeignet). Auf jeden Fall inkludiert ist, dass ein besonderes Verständnis vom Funktionieren eines Computers besteht, deshalb eben Computerey. Kot schreiben macht auf jeden Fall dazugehörig. Numerische Mathematik auch, allein schon wegen des Wissens um die Berechnungskomplexität der üblichen Methoden.

Das
>Brauser, Fotoladen, Videoeditor
hingegen nicht.

>mit dem ein Haufen Geld verdient wird. Da ist es vielleicht nicht so clever, diesen Leuten auf den Tisch zu scheißen
Ja, warum eigentlich? Geht es jetzt um "wessen Brot ich ess, dessen Lied ich sing"? "Isst" er überhaupt dessen Brot?

>mit dem ein Haufen Geld verdient wird
Ich bezweifle, dass damit mehr Geld verdient wird als mit Linux-Schlaufonen und Linux-Steamdeckeln.
HPC ist bzgl. Umsatz noch nicht einmal so herausstechend:
*Chromebooks: 30 Milliarden im Jahre 2022 [0]
*Android (nur Google, Gesamtmarkt viel größer): 31 Milliarden im Jahre 2016 [1]
*AWS: 62.3 Milliarden im Jahre 2021 [2]
*HPC: 32.2 Milliarden im Jahre 2022 [3]
*Steam Deck: ~1-2 Milliarden bei 3 Millionen Nutzern [4]

Die Frage ist, warum Geld überhaupt die richtige Metrik sein soll. Eine andere Metrik wäre auf die Anzahl Benutzer zu schauen, nach dem Motto: Den größten Nutzen für die meisten Nutzer. Und da sieht es für HPC sehr schlecht aus, im Vergleich zu der Anzahl Chromebook-, Android- oder auch nur Steam-Deck-Nutzern.

Der AVX-512-Kram ist auch nicht kostenlos, sondern verbraucht wertvollen Raum auf dem Chip-Würfel. Felix hätte da lieber ein breiteres Vorderende für mehr Einzelkernleistung, oder gar (wenn man die Flächeneinsparung aller P-Kerne zusammennimmt) einen E-Kerne-Kluster mehr reingepropft.

>Da hat jemand ohne Sinn und Verstand irgendwelche Bankmarken laufen lassen.
L-L-Lass Michael in Ruhe!


>Da hat jemand ohne Sinn und Verstand irgendwelche Bankmarken laufen lassen. Was soll uns das also sagen? Wenn du darauf hinauswillst, dass AVX-512 nicht bestehenden Kot magisch schneller macht, dann hast du damit vermutlich sogar recht. Das ist aber überhaupt nicht der Punkt.
Eigentlich geht es _genau_ um den Punkt: Für den Nutzer (im obigen Sinne) bringt AVX-512 nichts. Das ist auch das, was Herr Torvalds damit meinte. Wobei natürlich die gebankmarkten Programme auch handgedengelten AVX-512-Kot benutzen durften (was vermutlich, wegen glibc und dortiger memcpy-etc.-Implementierung, auch bei so ziemlich jedem Programm zumindest zu ganz kleinem Anteil dort der Fall war).

Aber sogar AVX2 brachte nur bei der Kompilierunggeschwindigkeit für Weichwaren-Entwickler/Gentoo-Nutzer noch etwas (siehe Timed-LLVM-Compilation-Bankmarke, wobei mich genuin interessieren würde, woran das konkret liegt), aber für andere Nutzer bringt das noch nicht einmal etwas.

Warum genau braucht man also die Spezialinstruktionen von AVX-512 in Hartware, die gerade nicht (für gewöhnlich) von HPC-Leuten gekauft wird (während man gleichzeitig Abstriche z.B. bei der allgemeinen Einzelkern- oder Mehrkernleistung machen muss, da Würfel-Fläche beschränkt)? In Server-Prozessoren ist das viel besser aufgehoben, das hat Intel dann auch eingesehen.

Aber eigentlich wollte ich antworten, weil mir spontan selbst noch einmal die Frage kam:
>Hat ein Grafikkarte wirklich eine geringere Bandbreite pro Euro?
Du hast bereits vollkommen richtig dabei Workstation-Hartware eingeschmissen, welche ein deutlich besseres Preis-Leistungs-Verhältnis hat.

>Geforce RTX 4090: 1008 GB/s, 1720 Euro, 586 MB/s/Euro
>Geforce RTX 4080: 716.8 GB/s, 1009 Euro, 710 MB/s/Euro
>Geforce RTX 4070: 504 GB/s, 529 Euro, 952 MB/s/Euro
>Geforce RTX 4060 Ti: 288 GB/s, 359 Euro, 802 MB/s/Euro
>Geforce RTX 4060: 272 GB/s, 295 Euro, 922 MB/s/Euro

>Intel Core i9-14900 K: 89.6 GB/s, 569 Euro, 157 MB/s/Euro
>Intel Core i3-14100: 89.6 GB/s, 149 Euro, 601 MB/s/Euro

Die Bandbreiten der Grafikkarte natürlich zwischen GPU und VRAM. Über den PCIe-Bus sind es nur noch ~31 GB/s.

[0] https://www.maximizemarketresearch.com/market-report/chromebook-market/146506/
[1] https://www.bloomberg.com/news/articles/2016-01-21/google-s-android-generates-31-billion-revenue-oracle-says-ijor8hvt
[2] https://www.statista.com/statistics/1236241/cloud-hyperscaler-quarterly-revenue-iaas-paas/
[3] https://www.statista.com/statistics/1116668/global-hpc-market-revenue/
[4] https://omdia.tech.informa.com/pr/2023/apr/omdia-steam-deck-installed-base-to-surpass-three-million-during-2023