Workstation: erste Tests...

[Rolf Bombach]

Volker Bartheld schrieb:

[Eigentlich traurig für 15 Jahre Fortschritt. Offenbar gibt es keine wirklich grossen Sprünge mehr.]

klingt in meinen Ohren halt wie weinerlicher Abgesang.

Falls sich tatsächlich jemand für die Fakten interessiert und nicht
für deine ad-personam-Ausfälle, dann findet er eventuell hier
eine interessante Zusammenstellung:

https://mlech26l.github.io/pages/2020/12/17/cpus.html

Bei den Intel-Prozessoren sieht es so aus:
Knapp 2 Jahre nach Pentium der core-2-Sprung. Ungefähr Faktor 2.
Etwa 4 Jahre später der Sandy Bridge-Sprung. Ungefähr Faktor sqrt(2).
Danach Einbiegen auf die +5%/y- Kurve.

AMD hat 2017 mit dem Ryzen zugeschlagen.
Und befindet sich seitdem auf der +15%/y-Kurve.

Intel muss sich was einfallen lassen.

--
mfg Rolf Bombach

 

[Helmut Schellong]

Am 31.08.2023 um 20:31 schrieb Rolf Bombach:

Volker Bartheld schrieb:

[Eigentlich traurig für 15 Jahre Fortschritt. Offenbar gibt es keine wirklich grossen Sprünge mehr.]

klingt in meinen Ohren halt wie weinerlicher Abgesang.

Falls sich tatsächlich jemand für die Fakten interessiert und nicht
für deine ad-personam-Ausfälle, dann findet er eventuell hier
eine interessante Zusammenstellung:

https://mlech26l.github.io/pages/2020/12/17/cpus.html

Bei den Intel-Prozessoren sieht es so aus:
Knapp 2 Jahre nach Pentium der core-2-Sprung. Ungefähr Faktor 2.
Etwa 4 Jahre später der Sandy Bridge-Sprung. Ungefähr Faktor sqrt(2).
Danach Einbiegen auf die +5%/y- Kurve.

AMD hat 2017 mit dem Ryzen zugeschlagen.
Und befindet sich seitdem auf der +15%/y-Kurve.

Intel muss sich was einfallen lassen.

Mir erscheint es so, als wolle Intel zukünftig aus Ansammlungen von Chiplets ICs bilden.
https://en.wikipedia.org/wiki/Chiplet
Aber so richtig große, riesige ICs.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Volker Bartheld]

On Thu, 2023-08-31 at 20:31 +0200, Rolf Bombach wrote:

Volker Bartheld schrieb:
[Eigentlich traurig für 15 Jahre Fortschritt. Offenbar gibt es keine wirklich
grossen Sprünge mehr.]
klingt in meinen Ohren halt wie weinerlicher Abgesang.
Falls sich tatsächlich jemand für die Fakten interessiert und nicht
für deine ad-personam-Ausfälle, dann findet er eventuell hier
eine interessante Zusammenstellung:
https://mlech26l.github.io/pages/2020/12/17/cpus.html

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.

AMD hat 2017 mit dem Ryzen zugeschlagen.
Und befindet sich seitdem auf der +15%/y-Kurve.
Intel muss sich was einfallen lassen.

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

 

[Rolf Bombach]

Volker Bartheld schrieb:

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

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

--
mfg Rolf Bombach

 

[Rolf Bombach]

Volker Bartheld schrieb:

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....

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

--
mfg Rolf Bombach

 

[Arno Welzel]

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

Am 19.08.2023 um 18:37 schrieb Arno Welzel:
[...]
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)>>|(x)<<32-)
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)

Quelle?


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

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

Am 19.08.2023 um 18:37 schrieb Arno Welzel:
[...]
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)>>|(x)<<32-)
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)

Quelle?


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

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

Am 19.08.2023 um 19:36 schrieb Helmut Schellong:
Am 19.08.2023 um 18:37 schrieb Arno Welzel:
Helmut Schellong, 2023-08-19 16:21:

Am 19.08.2023 um 09:53 schrieb Arno Welzel:
Helmut Schellong, 2023-07-29 16:10:

[...]
Man beachte die 7 Makros(), die teilweise ineinander verschachtelt sind.

Ja, und? Ich sehe das nur als schlechten Stil an und nicht als Zeichen
besonder hohe Ingenieurskunst. Bei einem Code-Review würde ich das ablehnen.

Die Vorgabe des NIST ist nun mal so.

Die Vorgabe des NIST ist, mehrfach verschachtelte Makros zu benutzen?
Das glaube ich nicht.

Die Vorgabe des NIST ist so, wie ich es oben beschrieben habe.

Es ist guter Stil, die wichtigen Komponenten des Algorithmus, erkennbar beizubehalten.
Dies nicht zu tun, wäre das Verhalten eines Dämelacks.

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)>>|(x)<<32-)
   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)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

Um den Inhalt zu verstehen [1], muß man mindestens ein fähiger
Programmierer mit Erfahrung sein. E-Tech-Ing ist nicht notwendig.

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.


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

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

Am 19.08.2023 um 19:36 schrieb Helmut Schellong:
Am 19.08.2023 um 18:37 schrieb Arno Welzel:
Helmut Schellong, 2023-08-19 16:21:

Am 19.08.2023 um 09:53 schrieb Arno Welzel:
Helmut Schellong, 2023-07-29 16:10:

[...]
Man beachte die 7 Makros(), die teilweise ineinander verschachtelt sind.

Ja, und? Ich sehe das nur als schlechten Stil an und nicht als Zeichen
besonder hohe Ingenieurskunst. Bei einem Code-Review würde ich das ablehnen.

Die Vorgabe des NIST ist nun mal so.

Die Vorgabe des NIST ist, mehrfach verschachtelte Makros zu benutzen?
Das glaube ich nicht.

Die Vorgabe des NIST ist so, wie ich es oben beschrieben habe.

Es ist guter Stil, die wichtigen Komponenten des Algorithmus, erkennbar beizubehalten.
Dies nicht zu tun, wäre das Verhalten eines Dämelacks.

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)>>|(x)<<32-)
   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)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

Um den Inhalt zu verstehen [1], muß man mindestens ein fähiger
Programmierer mit Erfahrung sein. E-Tech-Ing ist nicht notwendig.

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.


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

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

Arno Welzel schrieb:
Helmut Schellong, 2023-08-19 16:41:

Man nehme Luftdurchsätze von 1 m^3 bzw. 100 m^3 pro Minute an.
Dann wird die Verlustleistung einer im Gehäuse befindlichen Komponente jeweils um 100 W gesteigert.

Wie lange dauert jeweils das Erreichen der Endtemperatur bei 5 Tau?

Bei höherem Luftdurchsatz dauert es länger, weil mehr Wärme pro
Zeiteinheit abgeführt wird. Aber Du kannst mir das Gegenteil gerne
vorrechnen.

Bei höherem Luftdurchsatz werden die thermischen Zeitkonstanten
kleiner. Eigentlich trivial.

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

--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

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

Arno Welzel schrieb:
Helmut Schellong, 2023-08-19 16:41:

Man nehme Luftdurchsätze von 1 m^3 bzw. 100 m^3 pro Minute an.
Dann wird die Verlustleistung einer im Gehäuse befindlichen Komponente jeweils um 100 W gesteigert.

Wie lange dauert jeweils das Erreichen der Endtemperatur bei 5 Tau?

Bei höherem Luftdurchsatz dauert es länger, weil mehr Wärme pro
Zeiteinheit abgeführt wird. Aber Du kannst mir das Gegenteil gerne
vorrechnen.

Bei höherem Luftdurchsatz werden die thermischen Zeitkonstanten
kleiner. Eigentlich trivial.

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

--
Arno Welzel
https://arnowelzel.de

 

[Helmut Schellong]

Am 19.10.2023 um 16:38 schrieb Arno Welzel:

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

Am 19.08.2023 um 18:37 schrieb Arno Welzel:
[...]
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)>>|(x)<<32-)
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)

Quelle?

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


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.10.2023 um 16:38 schrieb Arno Welzel:

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

Am 19.08.2023 um 18:37 schrieb Arno Welzel:
[...]
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)>>|(x)<<32-)
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)

Quelle?

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


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.10.2023 um 16:41 schrieb Arno Welzel:

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

[...]

Das ist auch Vorgabe des NIST.

Makros:
   ROTR(x,n)  ((x)>>|(x)<<32-)
   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)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

Um den Inhalt zu verstehen [1], muß man mindestens ein fähiger
Programmierer mit Erfahrung sein. E-Tech-Ing ist nicht notwendig.

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.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.10.2023 um 16:41 schrieb Arno Welzel:

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

[...]

Das ist auch Vorgabe des NIST.

Makros:
   ROTR(x,n)  ((x)>>|(x)<<32-)
   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)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

Um den Inhalt zu verstehen [1], muß man mindestens ein fähiger
Programmierer mit Erfahrung sein. E-Tech-Ing ist nicht notwendig.

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.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Arno Welzel]

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

Am 19.10.2023 um 16:41 schrieb Arno Welzel:
Helmut Schellong, 2023-08-20 10:53:

[...]

Das ist auch Vorgabe des NIST.

Makros:
   ROTR(x,n)  ((x)>>|(x)<<32-)
   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)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

Um den Inhalt zu verstehen [1], muß man mindestens ein fähiger
Programmierer mit Erfahrung sein. E-Tech-Ing ist nicht notwendig.

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.

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.

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.

--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

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

Am 19.10.2023 um 16:41 schrieb Arno Welzel:
Helmut Schellong, 2023-08-20 10:53:

[...]

Das ist auch Vorgabe des NIST.

Makros:
   ROTR(x,n)  ((x)>>|(x)<<32-)
   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)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

Um den Inhalt zu verstehen [1], muß man mindestens ein fähiger
Programmierer mit Erfahrung sein. E-Tech-Ing ist nicht notwendig.

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.

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.

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.

--
Arno Welzel
https://arnowelzel.de

 

[Helmut Schellong]

Am 20.10.2023 um 10:26 schrieb Arno Welzel:

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

Am 19.10.2023 um 16:41 schrieb Arno Welzel:
Helmut Schellong, 2023-08-20 10:53:

[...]

Das ist auch Vorgabe des NIST.

Makros:
   ROTR(x,n)  ((x)>>|(x)<<32-)
   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)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

Um den Inhalt zu verstehen [1], muß man mindestens ein fähiger
Programmierer mit Erfahrung sein. E-Tech-Ing ist nicht notwendig.

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.

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.

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.

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

------------------------------------------------------------------
Makros:
ROTR(x,n) ((x)>>|(x)<<32-)
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!


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 20.10.2023 um 10:26 schrieb Arno Welzel:

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

Am 19.10.2023 um 16:41 schrieb Arno Welzel:
Helmut Schellong, 2023-08-20 10:53:

[...]

Das ist auch Vorgabe des NIST.

Makros:
   ROTR(x,n)  ((x)>>|(x)<<32-)
   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)

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

Um den Inhalt zu verstehen [1], muß man mindestens ein fähiger
Programmierer mit Erfahrung sein. E-Tech-Ing ist nicht notwendig.

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.

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.

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.

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

------------------------------------------------------------------
Makros:
ROTR(x,n) ((x)>>|(x)<<32-)
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!


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Arno Welzel]

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

Am 20.10.2023 um 10:26 schrieb Arno Welzel:
[...]
Ich behaupte nicht, daß das NIST Makros vorgibt.
Schließlich schreibe ich \"NIST:\", nicht aber \"NIST-Makros:\".

Zitat von Dir aus <ubqj4f$9n5h$2@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.

[...]

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!

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.

--
Arno Welzel
https://arnowelzel.de