Hier die Antwort welche ich auf die gleiche Frage bekommen hatte. #2
Beiträge von oobdoo
-
-
ADAC Nein bist Du nicht. Hab den falschen Link gepostet. http://www.spriters-resource.com
Dekay Da die CPC User immer mehr werden, könnte das eines Tages passieren.
-
Gibt Tools auf csdb.dk, komme aber gerade nicht auf den Namen. Gibt aber auch ne Webseite für sowas. https://spritedatabase.net/
-
Wollte kürzlich Visual Studio 2018 "Community Edition" nochmal starten und da wurde mir mitgeteilt, daß meine freie Lizenz abgelaufen ist.
Das wäre ärgerlich wenn es keinen Ersatz von MS geben würde. VS 2022 ist aber verfügbar und um einiges besser als alle kleineren Versionen.
-
bevorzuge ich .Net (C# ist für mich genauso schrecklich lesbar wie Java übrigens)
Da sind wir auf einer Wellenlänge.
Zum Glück gibt es heute Konverter von C#<>VB. Das macht das Coden einfacher.
Und was ich beim Coden nicht hinbekomme, das kann ich immer wieder gut in
Excel visualisieren.So wie jetzt wieder. In Excel die Gedanken visualisieren, wie ich
mit meinem Multiprozessing Problem weiterkommen könnte.
-
Ich dachte, OpenCL ist der neue Standard?
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.
Alternativ gibt es ja bei ebay diese günstigen MS Catapult fpga Beschleuniger Karten.
Da dürfte für mich die Nutzung noch schwieriger sein als bei OpenCL und CUDA.
Aber evtl kann man sogar beim Algorithmus mehr rausholen. Dafür müsstest Du halt mal sagen, was Du da genau berechnen willst.Verschachtelte FOR-Schleifen und innen wird nochmal ein MD5 erzeugt.
-
Bei mir klappt es mit den Zwischenergebnissen. Ein Kern und es dauert >30min. Alle 16 Kerne, mit 2x Zwischenergebnissen und einer anderen Opitmierung und schon dauert die gleiche Rechenaufgabe <3min.
Jeder der 16 Kerne verbraucht nur 3% der CPU Leistung. Das dürfte mit VB.net weitgehend ausgereizt sein. Ich wollte aber eine weitere FOR-Schleife für Berechnungen drin haben. Also nochmal nachgedacht. Dann kam mir der Gedanke das ich die Schleife auch doppelt durchlaufen könnte, also 16 Prozesse vorwärts und 16 Prozesse rückwärts. Einer der 32 Prozesse wird dann ein Ergebnis liefern. So kam es auch und es dauerte ca. 30 Sekunden. Nun konnte ich wie gewünscht eine weitere FOR-Schleife einbauen. Die benötigt ca. 12min. Immer noch lang, aber viel besser als vorherige Versuche wo teilweise nach Stunden nix sinnvolles raus kam. Mal schauen ob ich bei den Zwischenergebnissen noch was verbessern kann. Noch mehr Prozesse starten macht aber keinen Sinn mehr, weil jetzt die CPU gesamt bei 100% liegt. Mal schauen ob ich verständliche Beispiele in CUDA finde. Meine nVidia 2080 RTX Ti hat viel Power, wäre super wenn ein Teil der Rechenaufgaben auch auf der GPU laufen würden.
-
-
-
Falsche Farbe.
-
War das verständlich erklärt?
Teilweise.
Damit hab ich nämlich gerne mal meine lieben Probleme...Kenne ich.
Bei mir klappt es mit den Zwischenergebnissen. Ein Kern und es dauert >30min. Alle 16 Kerne, mit 2x Zwischenergebnissen und einer anderen Opitmierung und schon dauert die gleiche Rechenaufgabe <3min.
-
Ich trigger Dich mal mit diesem Bild... #CPCshining ...
CPC Mörder. Dir sollte man den Puller absägen.
-
Wird der arme CPC in ein Brotkastengehäuse gezwungen?
Das würde ich doch einem Z80 nicht antun...
Schlimm genug das der erste CPC (Prototyp) mit einem 6510 ausgestattet war.
-
Werde es dann bei Fertigstellung auch präsentieren, wobei oobdoo sicher einen Herzinfarkt bekommt, wenn er das sieht...
Wird der arme CPC in ein Brotkastengehäuse gezwungen?
-
die TaskFactory ist auch nicht zu verachten
Davon lese ich zum ersten mal etwas.
...und dann hat man was gefunden, dann funken die race conditions dazwischen und es geht doch nicht
Ich vermute Du meinst damit Zwischenergebnisse? Da bin ich gerade dran am basteln, damit ich die Berechnungszeit verkürzen kann.
-
Damit sind wir in der Tat schon wieder möglicherweise bei der GPGPU...
Ich verwende u.a. ein MD5. Dürfte schwer werden das auf einer GPU umzusetzen, was dann noch schneller als die eingebaute Version von Windows ist.
denn ich hatte das mal so gelöst: eine List(of Thread) machen, die 16 Threads starten und ab in die Liste. Und dann regelmäßig prüfen, ob alle fertig sind.Ich bleibe erstmal bei meinen Prozessen. Das ist zwar ein Rumexperimentierprojekt, aber noch mehr Zeit ins Threading wollte ich nicht reinstecken.
-
Ach komm.... das geht doch schöner. Soll ich Dir bisserl helfen?
Nö, nicht nötig. Mir geht es nicht um Schönheit beim Coden, sondern das meine Experimente funktionieren.
Die BackgroundWorker Klasse kennst Du?
Ja. Auch Multithreading und ParalellFor. Hat bei mir alles nicht funktioniert. Wäre Cuda und Co. einfacher umzusetzen dann würde ich auch die GPU verwenden.
-
Du hast jetzt 16 Threads, die jeweils auf 1 externes Programm warten? Was war das Problem mit 16 Threads die selbst rechnen?
Nein. Ich haben ein GUI-Programm, welches ein externes Konsoleprogramm 16x als eigenen Prozess startet.
-
Ich hatte vor längerer Zeit mit Multithreading experimentiert. Das klappt aber nicht richtig bzw. die CPU wurde nicht wirklich belastet. Hab das ganze mal umgestrickt. Die Berechnungen laufen nun in einem externen Programm, welches mit den verschiedenen Parametern 16x aufgerufen wird. Nun liegt die Auslastung der CPU vom 16-Kern Threadripper 2950 bei 65-75%. Wenn gleich alles klappt, dann sollte ein Prozess bei der Berechnung das passende finden und das Ergebnis in eine Datei schreiben. Das Hauptprogramm prüft alle paar Sekunden ob diese Datei angelegt ist. Wenn ja, dann werden alle Berechnungsprozesse gekillt.
-
Technisch haben die 264er Einschränkungen, das ist klar. Keine Sprites, schlechterer Soundchip usw. Nur was da trotz all dem raus geholt wird, ist beeindruckend.
Wie sieht es beim Scrolling aus? Ist das genauso leistungsfähig wie im 64er?