Workstation: erste Tests

Wo weiterhin über die Singlethread-Performance schwadroniert wird. Ich weiß, für Deinen speziellen Anwendungsfall ist das natürlich kriegsentscheidend. Für den Rest der Welt halt nicht. Aber das hatte ich Dir ja bereits erklärt.

Was natürlich ein Beleg dafür ist, daß es in 15 Jahren Fortschritt offenbar keine wirklich großen Sprünge mehr gab. Den Siegeszug der GPUs hast Du natürlich wohlweislich übersehen und die Speicherdichte auf SSDs und Dreheisen krebst auch seit 15 Jahren nur so dahin. OK, das sind freilich keine CPUs.

Du wirst also schon Recht haben und mit einem Intel Core 2 Duo E7500 gut zurechtkommen. Oder einem Athlon II X2.

Volker

Volker Bartheld schrieb:

Zu deinen Beleidigungen kommt nun das Delirium hinzu. Morbus Haselbeck? Geht es dir nun besser?

Volker Bartheld schrieb:

Klar, für maximale FP8-Leistung ist eine H100 für 30 k€ geradezu ideal. Hast du sicher schon eingebaut.

Helmut Schellong, 2023-08-19 19:36:

Quelle?

Helmut Schellong, 2023-08-20 10:53:

Das NIST schreibt da aber nicht, dass man Makros definieren muss!

Es wird nur zur *Vereinfachung* in den Erläuterungen von Makros gebraucht gemacht, die vorher definiert wurden. Dass man eigene Implementierungen exakt so machen *muss*, und z.B. nicht ebenso gut Funktionen oder Klassenmethoden dafür bauen kann, finde ich da nirgends.

Rolf Bombach, 2023-08-31 20:16:

Deswegen dauert es bei höherer Lüfterdrehzahl länger, bis die CPU ihre maximale Arbeitstemperatur erreicht?

Am 19.10.2023 um 16:38 schrieb Arno Welzel:

Habe ich bereits vor Monaten 20.08.2023, 10:53 gepostet.

Am 19.10.2023 um 16:41 schrieb Arno Welzel:

Es wäre auch vom NIST extrem unprofessionell, dazu Forderungen zu stellen. Die Welt der Profis würde lachen, das NIST wäre untendurch. Das NIST stellt einen Algorithmus dar, wie es das NIST für gut hält - und das ist es dann halt.

Professionell ist es, genau so zu implementieren, wie die Urquelle es vorgibt. Allein schon wegen der Wiedererkennung.

Jede unnötige Abweichung im Implementations-Konzept ist unprofessionell und schädigt.

Helmut Schellong, 2023-10-19 18:49:

Und die gibt eben keine Makros vor sondern nur eine Methode der Berechnung. Zu behaupten, dass Du Makros benutzt, weil das NIST es so vorgeben würde, ist daher unsinnig.

Am 20.10.2023 um 10:26 schrieb Arno Welzel:

Du betreibst massive Haarspalterei. Schau mal nachfolgend /Makros:/ und /NIST:/ an:

------------------------------------------------------------------ Makros: ROTR(x,n) ((x)>>(n)|(x)<<32-(n)) SUM0(x) (ROTR((x),2)^ROTR((x),13)^ROTR((x),22))

NIST: ROTR^n (x) = (x >> n) v (x << w - n) SUM0 (x) = ROTR^2(x) (+) ROTR^13(x) (+) ROTR^22(x)

------------------------------------------------------------------

Wo gibt hier das NIST Makros vor? Ich behaupte nicht, daß das NIST Makros vorgibt. Schließlich schreibe ich "NIST:", nicht aber "NIST-Makros:".

Das NIST zeigt Darstellungen mithilfe einer _Pseudo-Programmiersprache_. Genau so, wie die Darstellungen in den RFCs vorliegen. Genau so, wie die Algorithmen /Rabbit/ und /Dragon/ dargestellt sind. Das ist seit Jahrzehnten weltweit Usus.

Das NIST bezeichnet seine Darstellungen als /Functions/ im Kapitel "4. Functions and Constants". Und ich habe diese Funktionen in C mittels /function-like/ Makros() implementiert. Das ist total logisch, sinnvoll und effizient!

Helmut Schellong, 2023-10-20 18:12:

Zitat von Dir aus <ubqj4f$9n5h$ snipped-for-privacy@solani.org auf meinen Einwand, dass der Code mit vielen verschachtelten Makros arbeitet und ich das als schlechten Stil ansehe:

"Die Vorgabe des NIST ist nun mal so. Es ist guter Stil, die wichtigen Komponenten des Algorithmus, erkennbar beizubehalten. Dies nicht zu tun, wäre das Verhalten eines Dämelacks."

Damit hast Du faktisch behauptet, dass das NIST die Verwendung von Makros vorgeben würde und Du die verschachtelten Makros nur deswegen so gebaut hast und nicht als Funktionen.

Makros *sind* aber keine Funktionen. Es gibt auch keine "function-like" Makros.

Makros werden bei der Compilierung zu Code expandiert, basierend auf der Definition des Makros. Wenn ein Makro 10x verwendet wird, wird auch der selbe Code 10x in das Binary eingebaut. Effizent ist das gegenüber einem Funktionsaufruf ganz sicher nicht und "logisch" ebenso wenig. Logisch wäre, dass man *Funktionen* auch als solche implementiert, damit diese im Binary auch nur *einmal* vorhanden sind und nicht mehrfach redundant.

Am 21.10.2023 um 10:17 schrieb Arno Welzel:

Es geht also um die Verschachtelung, die schlechter Stil sein soll.

Ich habe das jedoch mit keinem einzigen Wort geschrieben. Du willst das /rückwärts/ in Bedeutung bringen. Meine Aussage bezieht sich auf "Verschachtelung".

Siehe [19.08.2023, 19:36]:

-------------------------------------------------------------------------- > Ich rede nicht von Komponenten, sondern das in Form "mehrfach > verschachtelter Makros" zu tun.

Das ist auch Vorgabe des NIST.

Makros: ROTR(x,n) ((x)>>(n)|(x)<<32-(n)) SUM0(x) (ROTR((x),2)^ROTR((x),13)^ROTR((x),22))

NIST: ROTR^n (x) = (x >> n) v (x << w - n) SUM0 (x) = ROTR^2(x) (+) ROTR^13(x) (+) ROTR^22(x)

--------------------------------------------------------------------------

Meine Aussage bezieht sich auf "Verschachtelung". Fernab jeder Behauptung, das NIST würde seine Funktionen() als Makros() in der Implementation fordern. Das NIST stellt den Algorithmus vernünftigerweise _mit_ Verschachtelung dar.

Genau deshalb wählte ich Makros, weil diese deutlich besser sind.

Im C-Standard steht 26-mal "function-like macro".

Bei Google 24,5 Mio Resultate.

Das mußt Du mir, als Autor von drei C-Büchern, nicht erklären. Ich habe schon über 20-fach verschachtelte Makros definiert, mit enormer Problemlösungskraft.

Helmut Schellong, 2023-10-21 15:41:

Na dann ist ja alles gut. Wozu postest Du dann noch hier? Hast Du nix besseres zu tun?