Ultraedit macht auch große Dateien, aber das ist Löhnware...
Posts from muffi in thread "Heute so gecodet..."
-
-
Please login to see this link. 
Das ist der Packer, bei dem unterschiedliche Bitlängen codiert werden. Der Nachkompressor vom 64er Packer/Happy Packer ist so ein Packer. Das häufigste Byte wird mit einem Bit codiert: 0. Alle anderen erhalten dann immer mehr Bits, die seltensten Bytes werden dabei sogar verlängert.
-
Tausende Bits sind richtig, aber am Ende hat der Code Schluckauf bekommen.
Da geht es (wieder) um Deinen RLE-Packer? Wobei es eher ein Nibbler ist, oder?
-
Vielleicht war das ein Bug in früheren .NET Versionen? Ich programmiere im Job ja auch in VB.Net, aber ich hatte noch nie Probleme ohne .Flush() (das benutze ich nur zu Debugging-Zwecken).
-
StringReader und Writer sind doch einfach.
Nur sicherstellen, dass beim Writer auch geflushed wird
STREAMwriter, nicht StringWriter
Bei der Methode .close() flusht .Net aber automatisch. Und alle paar MB. Wenn Herrn Z80 der Stringbuilder nicht reicht, sind es mehr als 2 GB, da flusht Windows dauernd.
-
Schöne Formel, die ich aber bis zur nächsten Anwendung wieder vergessen habe.
Berechnest Du nach dem Tanken Deinen Verbrauch? Ist eine ähnliche Formel. Oder über den Dreisatz dürfte es auch gehen.
-
KI für so eine Berechnung? AUA.
Was erwartest Du? Ein Z80 kann nix...
-
Bei Make wurden damals sogar 2*Kerne+1 empfohlen
Die paar wenigen Threads, die ich bisher programmiert habe, habe ich immer mit Kerne*2 (aber nicht im Sinne von Cores) programmiert. Aber da macht die von Dir erwähnte Thematik keine Probleme, denn die laufen dann Minuten- bis Stundenlang.
-
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
-
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?
-
Wofür benötigt man CRC32 auf einem C64?
Und wofür am Z80?
Ganz einfach: WEIL ES GEHT
-
Also nix großartig mit wie normalisiert man Datenbanken
Also ich mache beruflich auch viel mit Datenbanken. Das Thema Normalisierung muss man ab einer gewissen Größe einfach klein schreiben, sonst braucht der Optimizer mehr Zeit als die Abfrage selber
Warum hat man früher denn überhaupt normalisiert? Ganz einfach, weil der Speicherplatz knapp war. Die Zeiten sind vorbei und ich habe durchwegs gute Erfahrungen mit "so-gut-wie-keine-Normalisierung" gemacht.
-
Wie man die abschaltet, weiiß ich auch nicht. Ich drück immer F5 und dann läufts weiter...
-
Was immer interessant ist, ist die brute-force Variante für die Gleichung
T I E R
+ B A U M
= L E B E N
Auf dem 6510 habe ich es noch nicht laufen lassen, aber auf dem Z80 unter Turbo Pascal. Ich habe nicht alle Schleifen implementiert, weil ich nicht vor hatte, dass der Rechner tagelang läuft
Wenn ich mich recht erinnere, war ab 6 Schleifen schon wahnsinnige Laufzeiten. Ob man da ein parallel.for unter VB irgendwie sinnvoll einsetzen kann, habe ich noch nie probiert. -
Heute wollte ich mein GeoRamCopy um die FD-2000 und 4000 erweitern, aber ich habe noch keine Möglichkeit gefunden, wie man den physischen Track 81 lesen (und schreiben) kann. Schade.
-
Aber alles noch besser als seine wenige Jahre alten Visual-Studio-Projekte nicht mehr öffnen zu können, weil die "kostenlose" Lizenz abgelaufen ist
Kann ich so nicht bestätigen.... ich kann auch heute noch meine Projekte aus VS2005 öffnen.
-
Ich mag halt die recht einfache Lesbarkeit von VB. Mit Java habe ich auch schon mal Zeug gemacht, aber da ich beruflich hauptsächlich Datenbank-Zeugs programmiere, bevorzuge ich .Net (C# ist für mich genauso schrecklich lesbar wie Java übrigens), denn schon alleine die Parameter sind um Längen komfortabler als mit Java. Wobei sich da inzwischen ja so Einges getan haben kann, das ist ja auch schon ein paar Jahre her.
Und nachdem ich ja vom 6502 Assembler komme, sind für mich die meisten Sprachen einfach nur schrecklich zu lesen, so nebenbei
-
Wenn Du Java magst, schau Dir mal TornadoVM an.
Ich glaube, oobdoo hat die gleiche Leidenschaft wie ich, und die nennt sich VB.Net.
Wobei ich mich immer frage, was schneller ist... Java oder ein Z80
-
Ob OpenCL oder CUDA ist mir im Grunde egal, wenn ich denn nur gute Beispiele finden würde wie ich das nutzbar machen könnte.
Also wenn Du da was Ordentliches findest, das interessiert mich auch. Ich wollte mich schon lange mal mit der GPGPU beschäftigen.
-
Davon lese ich zum ersten mal etwas.
Die TaskFactory ist gar nicht so übel, nur komischerweise wenig bekannt. Ist auf jeden Fall auch wert, sich mal (kurz) mit zu beschäftigen. Damit kann man auch schöne Nebenläufigkeiten machen.
Ich vermute Du meinst damit Zwischenergebnisse? Da bin ich gerade dran am basteln, damit ich die Berechnungszeit verkürzen kann.
Nein, race condition = zur Laufzeit. Da gibt es zum Teil minimalste Fehler, an die man erst mal gar nicht denkt. Ich hatte da auch mal ein Problem, das ich parallel lösen wollte (und dann auch gelöst habe). Da hatte ich das Problem, dass ich in der Theorie aus einer Queue Zeugs wieder entnommen habe (.Dequeue). Im Single Thread lief das geil, aber lahm (weil rechenintensiv). Also: her mit allen Kernen, die die Kiste hat
Nur hatte ich nicht bedacht, dass die Queue nicht threadsicher ist (das Pendant ist ConcurrentQueue). Also kam es zur race condition zu Doppelberechnungen, deren Grund ich mir erst mal nicht erklären konnte. War das verständlich erklärt? Damit hab ich nämlich gerne mal meine lieben Probleme...
