spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »3Angle«

Als Skeptiker bitte hier gucken :

Links das Gepackete und rechts das Ungepackte...

Ich seh da jetzt nichts, was einen Skeptiker umstimmen könnte !?
Da sind 2 Fenster, die irgendwie irgendeine Zahl hochzählen.

Durch vernünftiges Programmieren erreicht man auch einen netten Geschwindigkeitszuwachs.

Zitat von »3Angle«

Was daran umstimmen sollte ist, das .Net Framework ein eingeschränktes Performance-Limit hat, dies kann man per MTA auf das Maximum kurbeln. Denn irgentwo hat auch das gute Scripten seine Grenzen, deshalb könnte man aus diese Art und Weise noch mehr Performance herausholen. Was soll das Video zeigen? Das der Code per MTA extrem schneller abläuft als der Normale.

Was auf Kosten der Threadsicherheit geht da Komponenten die nicht Threadsicher sind nicht mehr von STA vor parallelem Zugriff geschuetzt werden.
Wodurch das ganze vermutlich zu Stabilitaetsproblemen fuert. Hast du das mal mit komplexeren Anwendungen probiert?

Oder glaubst du Microsoft hat just 4 fun eine Performancebremse eingebaut nur um die Entwickler zu aergern?

An dem Video ist nichts ueberzeugend, da wir ja noch nichtmal wissen was du da ueberhaupt Berechnest um die Performance zu testen.

Die Sache mit dem Komprimieren und Verschluesseln kann ganz interessant sein, den MTA Kram dagegen halte ich fuer Humbug. Lasse mich aber gerne Ueberzeugen.

Zitat von »3Angle«

Trotzdem könnte man die gepackete Datei wieder entpackt werden, wenn man den Unpacker decompiliert und einen Unpacker vom verschlüsselten Etwas schreibt.

Völlig unnötig. Die Tools sind alle da. OlliDbg/Shadow/LordPE und man dumped das Ding auf die Platte. Dann noch einen FileCorrector drüber laufen lassen und man hat's.
Mehr Sorgen macht mit aber das, was xardias angesprochen hat. Viele Algorithmen führen zu sehr sehr schweren Fehlern, wenn man versucht diese einfach so ohne spezielle Synchronisierung parallel auszuführen.

Was genau verstehst du unter MTA? Falls du damit auf die COM Thread Apartment Modelle anspielst: Das hat mit .NET überhaupt nichts zu tun und das gewählte Apartment Model eines Prozesses einfach umzustellen ist ein schwerwiegender Programmierfehler. Dass dir da nicht gleich alles um die Ohren fliegt ist pures Glück...

Was genau du unter "hardwareseitigem Multithreading" verstehst, würd mich auch sehr interessieren. Insbesondere inwiefern man das einfach aktivieren kann und wieso es standardmäßig nicht aktiviert ist.

Wenn ich die Performance einer .NET Anwendung optimieren müsste und sämtliche algorithmischen Möglichkeiten bereits ausgeschöpft wären, würd ich wohl zunächst mal zu Ngen greifen...

Ich habe bis jetzt noch nicht einen konkreten Grund gesehen, warum dadurch die Applikationen geschützt sein sollten. Mir ist es wiederholt ziemlich egal in welchem Zwischenformat du sie speicherst, der Code wird so oder so ausgeführt und ist somit so oder so exploitbar. Ein wirklicher Debugging-Schutz ist unter Windows sehr schwer auch nur in den Grundzügen zu erreichen, insofern würde ich daran auch zweifeln. Man kann zwar Debugger anhand einiger Tricks erkennen, man kann sogar explizit den OllyDbg erkennen, aber mehr als das Programm abzubrechen bleibt einem in dem Fall dann meistens nicht übrig.

Themida mach Laufzeitverschlüsselung und bewegt sich damit auf einem ganz anderen Gebiet. Zusätzlich ist der Code auch wenn er durch Themida geschützt ist, noch exploitbar. Die Analyse fällt nur schwer. Ein Grund, warum man Themida und VmProtect oft bei Viren findet...

Der C#-Compiler wird schon hochoptimiert sein und es wird viele Gründe haben, warum es nicht schon automatisierte Parallelisierung als Feature eingebaut wurden. Wenn man mal bedenkt, dass Microsoft ein riesiges Forschungsnetzwerk betreibt, welchem wir unter anderem Haskell zu verdanken haben, kann man sich grob vorstellen, welche Ressourcen Microsoft in Compiler-Bau steckt. Die haben Erfahrung in dem Business, verkaufen Compiler seit den 80ern. Ich glaube niemals, dass dein Programm wirklich universell mit .Net Applikationen funktioniert, jedenfalls kann ich mir das bei dem aktuellen Informationsstand schlecht vorstellen. Wie synchronisierst du Algorithmen, die strikt singlethreaded ablaufen müssen? Wie organisierst du die Ressourcen des Programms, damit keine Access Violations entstehen?

@Dot: Kann mir kaum vorstellen, dass er was anderes meint.

Schick mir das Tool und ich lasse es mal über mein Spiel laufen. Ich glaube aber nicht, dass es gut endet...

Ich habe ein "DJ-Programm" ( naja wenn man es so nennen darf) geschrieben. In diesem nutze ich viel Multithreading für Scannen von Dateien und Musik-Analyse. Wenn du magst, kann ich deine Anwendung mal testen.

MfG
Union_Freedom