Hab meinen Rechner mehr ausgereizt. Ein mehrdimensionales Array mit ListOfString darin angelegt und getestet wie weit ich die Kapazität bei dem ListOfString angeben kann, bevor mir der Speicher ausgeht. Dabei auch alle Schleifen nach ParallelFor umgebaut, damit es schneller geht. Als nächstes wird der Inhalt des Array auf SSD gespeichert und weiter experimentiert. Dann wird sich zeigen wieviel Terrabyte eine zu kaufende Festplatte haben muss. ![]()
Posts from oobdoo in thread "Heute so gecodet..."
-
-
Nicht direkt gecodet, aber weiterhin Excel/VB Experimente gemacht. Hashcat und Cuda installiert und nach einigem Gefrickel auch beides zum Laufen bekommen.
Schon geil, drei Videos über die GPU zu kodieren und nebenbei mit der freien 3D Leistung Hashcat nutzen, wärend die CPU Langeweile hat.
Wegen der Hashcat und Cuda Probleme wieder KI benutzt, was prima funktioniert hat. -
Hab eine Formel getestet und von 0 bis 2^32 rechnen und die Ergebnisse in zwei Textdateien schreiben lassen. Nach 45 Minuten war mein Rechner (ohne Multithreading) fertig und hat einmal 246GB und 3,6GB Text geschrieben. Das war sogar für Notpad++ zum Anzeigen zu groß.

Mit Please login to see this link. geht die kleine Datei auf jeden Fall. Bei der großen zählt das Programm noch die Zeilen der Textdatei.

-
Nachdem mein Projekt mit einem FileStream zu funktionieren scheint, habe ich am Wochenende mal die Zwischenergebnisse meiner Berechnungen in eine Textdatei geschrieben und diese in Excel importiert. Interessant welche Schlussfolgerungen man so ziehen kann, wenn man die verschiedenen Ergebnisse über die Filter von Excel sichtbar macht.

-
Stelle in meinem Projekt gerade auf FileStream um, weil StringBuilder, ListOF & Co. nur 32 Bit schaffen.

-
Ich weiß natürlich nicht, was Du da treibst, aber die Tatsache, daß die ersten 33Bits OK sind und die letzten 7 Bits nicht, sieht schon ein klein wenig nach einem Problem jenseits der 32bit aus.
Ich hatte vergessen das zwischendurch nochmal was konvertiert wurde und das die Menge an Bits nicht durch acht teilbar war.

Das hatte mich auf die falsche Spur (Gedanken) geführt. Den Fehler hatte ich dann spät in der Nacht wegbekommen.

-
Tausende Bits sind richtig, aber am Ende hat der Code Schluckauf bekommen.

Da geht es (wieder) um Deinen RLE-Packer?
Nein. Der hatte nichts damit zu tun.
Wobei es eher ein Nibbler ist, oder?
Please login to see this link. 
-
Tausende Bits sind richtig, aber am Ende hat der Code Schluckauf bekommen.

Richtig: 0111010011110011100101011001111111001000
Falsch : 0111010011110011100101011001111110100100
Die 01 sind falsch. Da wo sie gelesen werden stehen sie aber als 10 drin.

Diese 40 Bits wurden nicht einzeln gelesen und geschrieben, sondern am Stück.
Ich habe gefühlt schon 100 Logfiles und momentan keine Ahnung wie ich den Fehler finden soll.

Das sind Momente wo Coden keine Freude bereitet...


-
Ärgerlich. Da hat man einen 64Bit Rechner mit 64GB Hauptspeicher zur Verfügung und dazu nur ein StringBuilder.Insert(Int32, String, Int32) = System.OutOfMemoryException.

Jetzt darf ich mit StreamWriter experimentieren.

-
Display More
Laut KI habe ich 87,84% gespart.

KI für so eine Berechnung? AUA.
Alles was man machen muss um den Prozentsatz-Quotienten zu berechnen:
(gesparte Bytes) / TotalBytes
Als Prozentsatz: (gesparte Bytes) / TotalBytes * 100
Calc.exe oder online scientific calculator verwenden:
Please login to see this attachment.
Schöne Formel, die ich aber bis zur nächsten Anwendung wieder vergessen habe.

-
Hab zum Spaß eine RLE (Lauflängenkodierung) geschrieben. Diesmal hat es funktioniert, im Gegensatz zum Versuch in Z80 Ende der 80er Jahre.

Ich habe mir nochmal eine andere Version einer RLE erstellt. Demnach ist es mir gelungen 13107 Bit auf 1594 Bit zu komprimieren.

Laut KI habe ich 87,84% gespart.

Der in .net eingebaute ZIP braucht 365 Byte, bei mir sind es 1594/8=199,25 Byte.

Bei den Bits gibt es aber nur wenige Einer. Bei meinem Test kommt ungefähr auf 85 Nullen eine Eins.
-
Hab zum Spaß eine RLE (Lauflängenkodierung) geschrieben. Diesmal hat es funktioniert, im Gegensatz zum Versuch in Z80 Ende der 80er Jahre.

-
Einige kleine Optimierungen haben eben zwei Minuten Ersparnis gebracht. Am Wochenende werde ich weitere Test machen.
Dauerte der erste Durchlauf noch 12min, so hatte ich gestern mit Optimierungen 10min und später 8min gebraucht.
Vor dem Schlafen noch ne Idee bekommen, welche noch viel mehr Zeit sparen könnte, sofern die Rechenergebnisse
brauchbar sind.

-
Rechenzeit gegen Speicher tauschen? Das ginge nur wenn ich einen Cache bauen würde, sonst gibt es da keine Möglichkeiten.
Einige kleine Optimierungen haben eben zwei Minuten Ersparnis gebracht. Am Wochenende werde ich weitere Test machen.
-
Dim MaxThreads As New ParallelOptions
MaxThreads.MaxDegreeOfParallelism =31
Da muss man auch erst mal drauf kommen, dass das ein PARALLEL.FOR beeinflusst... Microsoft ist also seiner Linie über Jahrzehnte treu geblieben, dass nicht alles eindeutig sein muss

Das hatte mir die KI von Perplexity gesagt.

-
mit ParallelFor in VB.net zu knapp 100 Prozent ausgelastet bzw. ich hatte max. 31 Thread zugelassen.
Ich dachte Parallel.For macht das automatisch? Wie kann man da steuern, wie viele Freds da starten?
Ich habe folgenden Code davor gesetzt.
Dim MaxThreads As New ParallelOptions
MaxThreads.MaxDegreeOfParallelism =31
Mit einem Wert von 3 sieht es rechts unten im Taskmanager auch fast immer nach 100% aus. Schaut man aber direkt die Leistung der einzelnen Thread im TM an, dann sind einige Lücken zu sehen.
Please login to see this attachment.
Das war auch schonmal ganz anders die Tage, da war alles auf Volllast, da stotterte sogar XMPlay ganz kurz.
Möglich das man mit einzelnen gestarteten Threads anders steuern kann. Damit hatte ich auch experimentiert.
Da liefen aber mehr verschachtelte For-Schleifen als jetzt.
-
Nach viel Arbeit hat mein Nebenprojekt endlich funktioniert.

Nach 12 Minuten waren die Berechnungen durch und der AMD 9950X3D war mit ParallelFor in VB.net zu knapp 100 Prozent ausgelastet bzw. ich hatte max. 31 Thread zugelassen.
Wenn die Benchmarks im Web stimmen, dann hätte der alte Threadripper 2950X die doppelte Zeit benötigt.

Am Wochenende werde ich schauen was sich noch optimieren lässt. Sollte dabei zuwenig rauskommen, dann habe ich noch Ideen wie sich das mit einem Cache beschleunigen lassen sollte.


-
Da muss ich noch einiges lernen, bis ich durch den Code steige.
Mit CPC wäre das nicht passiert, der kennt keine Sprites.

-
Wofür benötigt man CRC32 auf einem C64?
-
Es gibt PC Demos mit 64kb Begrenzung.

Please login to see this media element.