Workstation: erste Tests

Jun 07, 2023 Last reply: 2 years ago 293 Replies

Hanno Foest, 2023-07-28 13:52:

Na ja - heutige PCs haben auch mal 32, 64 oder 128 GB RAM. Das wird dann schon etwas zeitaufwendiger.

DDR4 ECC unbuffered läuft auch auf vielen AMD-Boards mit Ryzen 7. Sowas gibt's auch halbwegs günstig - z.B. 32 GB PC4-3200, ECC unbuffered von Kingston ca. 80 EUR pro Modul.

Helmut Schellong, 2023-07-26 16:24:

[...]

Und meine SSDs weit weniger als 900 EUR, trotzdem reicht's für fast 8 TB Speicherkapazität mit 0,9 - 3 GB/s Durchsatz lesend und schreibend und entsprechend hohen IOPS-Zahlen. 128 GB ECC-RAM gibt's für die von mir benutzte Plattform auch für unter 400 EUR (aktuell ca. 320 EUR). Und das Mainboard hat weniger als 200 EUR gekostet.

Ja, das ist ja auch keine Kunst. So ziemlich *jede* aktuelle Hardware ist vielfach schneller als das.

Helmut Schellong, 2023-07-27 00:49:

100 GB Daten durchsuchen würde mein "Mainstream-PC" vermutlich auch in weniger als 5 Minuten durchlaufen.

Wo sind die Kategorien von regulären Ausdrücken definiert?

Warum?

[...]

Nein, das ist das Ergebnis des Kaufs. Der Sinn dahinter, warum sie so schnell sein soll, ist nicht klar.

In meinem (Arbeits-)Alltag komme ich mit Laptops der Sorte Dell Latitude

5430 gut aus und daneben gibt es noch einen PC mit AMD Ryzen 7, viel RAM und viele SSDs, auf dem in der Regel 2-3 VMs fast immer laufen. Da merke ich auch nichts davon, dass irgendwas langsam wäre. Eine 4K-Video mit 2 Stunden Laufzeit umkodieren dauert je nach Codec und Einstellungen mit Beteiligung der GPU ca. 10-15 Minuten - das reicht mir.

Am 28.07.2023 um 00:02 schrieb Hanno Foest:

Sehr lustig? Ich schrieb nicht, daß da nur 1 Pass eingestellt werden soll.

Voreingestellt sind 4 Passes, was erhöht werden kann. Es ist doch ganz klar, warum da 4 voreingestellt ist, und warum es überhaupt einstellbare Passes gibt!

Es gibt zwei 'memtest'. Das 'memtest86' von Passmark finde ich besser. In einer knappen Stunde ist 1 Pass erledigt.

Arno Welzel schrieb:

Nunja, der Kompressor kennt ja den Inhalt nicht und geht nach Schema F vor. Würde er den Inhalt verstehen und tatsächlich den Code komprimieren, nicht auszudenken, was bei heutiger Bloatware passieren würde. Wahrscheinlich Kompression auf 0 Bytes und der Code passt in den Filenamen.

Des Lesens mächtig hast du sicher erkannt, dass es hier um die Single-Fred-Leistung geht. Ausserdem mag es dich überraschen, dass es sehr viele, auch prozentual, User gibt, die nicht Cryptos schürfen oder CERN-Daten auswerten. Und eher noch nach der N(atürlichen)I suchen *duck*. Und nicht jeder "publiziert" auf youtube.

Du redest von Zeuch, dass sich parallelisieren lässt oder das schon von sich aus tut.

Tut eigentlich LTspice auch, allerdings ist bei nicht allzu grossen Schaltungen der Geschwindigkeitsgewinn nur etwa -0.2% bis +1% (95% Konfidenz) pro zugeschalteten Kern, bei nur schwach von 0 verschiedenem Korrelationskoeffizienten.

Also sind wir wieder bei single thread. Und ja, Serverprozessoren mit 256 Kernen oder so was gibt es. Ideal für Leute, welche beim Mining von 'in 100 Jahren nicht fertig' auf 'in vier Jahren nicht fertig' beschleunigen wollen. (Falls sie überhaupt so doof sind, das auf einem PC-Prozessor machen zu wollen).

Kann ich nicht bestätigen. i7-2600 und 32GB RAM hat über Nacht mehr als einen Durchlauf geschafft, also nutzbar.

cu Michael

Am 28.07.2023 um 08:49 schrieb Arno Welzel:

Ich glaube nicht daran. Siehe unten.

Man muß natürlich die beiden Tests in möglichst unterschiedlichen RAM-Situationen durchführen.

Diese Testläufe sind ein gänzlich anderer Algorithmus als eine Hash-Generierung. Einerseits klarer als ein Hash, andererseits vielleicht weniger sicher.

Ich habe da meine Zweifel, weil ich Hash-Algorithmen selbst implementierte. Diese verrechnen ihre Eingabe mit einer Art Fleischwolf-Maschine, die qualitativ dicht an echten Zufall herankommt. Die Eingabe wird also komplett mit einem Zufallsgenerator vermischt.

Ich meine daher, es kommt nur auf die Gegenüberstellung an, wie viele Zahlen der Hash bilden kann, und wie viele verschiedene Dateien es geben kann. Kollisionen sind vorprogrammiert; die Hash-Werte müssen daher besonders gut statistisch verteilt sein.

Das ist mir bekannt, lange Zeit, bevor ich mehrere Hash-Algorithmen selbst implementierte.

Am 28.07.2023 um 09:03 schrieb Arno Welzel:

Kenne ich. Aber ich meine SCO (Santa Cruz Operation), FreeBSD, Linux, Solaris. Windows benutze ich überwiegend für Programme, die ich woanders nicht starten kann.

Am 28.07.2023 um 09:13 schrieb Arno Welzel:

Ich verstehe Deine Denkweise nicht. Ich definiere einen großen Testlauf, der 110 GB Daten aufwendig filtert. Und der braucht seine Zeit - also sind wir bei Zeit. Während dieser Zeit können RAM-Fehler die Daten verfälschen. Wenn dieser riesige Testlauf am nächsten Tag erneut gestartet wird, andere RAM-Adressen verwendend, und exakt die gleichen Resultate (8 MB) generiert, gab es keine RAM-Fehler in beiden Läufen - als Praxis-Beweis.

Ein besserer Beweis wäre die mehrfache Hash-Generierung von einer 50 GB großen Datei.

Am 28.07.2023 um 09:23 schrieb Arno Welzel:

Ja, teilweise. Siehe meine Webseite.

Nein, muß sie das, damit ich die Notwendigkeit einer Workstation belegen kann? Das heißt, die Resultat-Datei habe ich hier veröffentlicht.

Am 28.07.2023 um 09:26 schrieb Arno Welzel:

Nein, das war nicht die Frage. Die Frage war, _was_ dieses dann eigentlich genau tut. Und die habe ich beantwortet.

Ja, wurde hier kürzlich umfangreich durchgekaut. DDR5 arbeitet zu hochfrequent.

Ja, die Spuren werden schon ineinander positioniert.

Am 28.07.2023 um 15:43 schrieb Arno Welzel:

Um wieviel schneller? Messung! Ich hatte eine Messung gemacht.

Am 28.07.2023 um 15:48 schrieb Arno Welzel:

Wirklich? Messung! Ich hatte gemessen.

Beispielsweise in den Manual-Seiten meiner bish-Shell.

Beantworte ich nicht.

Ist mir egal; beantworte ich halt nicht.

Hallo Wolfgang,

Du schriebst am Thu, 27 Jul 2023 08:25:00 -0400:

...

Auch da gibt's Verluste.

Helmut Schellong schrieb:

Hättest du tatsächlich eine ingenieurmäßige Ausbildung erfolgreich absolviert oder auf andere Weise solche Kenntnisse erworben, dann _wüsstest_ du, dass diese Aussage einfach nur Blödsinn ist. Nur weil man zweimal dasselbe Ergebnis sieht, heißt das in keinem Fall, dass die Daten bzw. deren Verarbeitung korrekt sein _müssten_. Lediglich die statistisch herzuleitende Wahrscheinlichkeit, dass Daten bzw. Algorithmus korrekt sein könnten, steigt. Ein Beweis ist etwas deutlich anderes

Es ist hier egal, ob der Unterschied nur in einem einzigen Bit oder vielen vielen Bits besteht

O Gott! Ja, dann ist schon klar, woher deine Fehlvorstellungen mal wieder kommen. Selbst gebastelte und damit unbrauchbare Algorithmen erzeugen natürlich unbrauchbare Ergebnisse. Wer hat deine Hash-Algorithmen denn hinsichtlich ihrer Qualität geprüft?

Aha...

Nicht wirklich. Einfach ausgedrückt ist der Clou bei derlei Dingen doch nur, einen Algorithmus zu finden, welcher es möglichst schwierig macht, eine Datei zu finden, welche denselben Hash-Wert wie die Originaldatei ergibt. Und es muss natürlich auch unmöglich sein, aus dem Hash-Wert auf die Eingabedaten Rückschlüsse zu erhalten. Diese, und weitere, Voraussetzungen sind durch einzelne Menschen kaum (besser: nicht) erreichbar, schon garnicht durch Amateure.

MfG Rupert

Arno Welzel schrieb:

Die Story mit dem ersten ARM1 kennst du sicher....

Und ca. 2015 kam ja ein Apple-Rechner raus, der doppelt so viel Rechenkraft hat wie die Cray 2.

Helmut Schellong schrieb:

Das ist wohl zuvörderst deiner zwangsläufig laienhaften Herangehensweise an wissenschaftliche Fragestellungen geschuldet

Das ist kein Beweis. Ein Beweis nach wissenschaftlichem, nach ingenieurmäßigem Ansatz ist nicht das zufällige Ergebnis amateurhafter Überlegungen. Dazu bedarf es eines wohldefinierten, beliebig wiederholbaren und jederzeit auch für Dritte nachvollziehbaren Vorgehens.

Ein Beweis ist genug. Es gibt keinen "besseren" Beweis

MfG Rupert

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required