Jammer-Thread

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Benutzeravatar
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: Jammer-Thread

Beitrag von xq »

ICh glaube, ich muss tatsächlich mal den Post über die Arbeit anfangen, damit dürfte dann einiges klarer werden. Ich beschäftige mich jetzt seit über nem halben Jahr mit der Maschine und fange langsam an, zu verstehen, wie man das Gerät programmiert... In der Maschine ist so ziemlich alles anders, als in anderen Computern... :)
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Jammer-Thread

Beitrag von Alexander Kornrumpf »

Einerseits ja, andererseits gelten die Sachen die ich gesagt habe (natürlich nur als grobe Skizze zu verstehen) für jedes Optimierungsproblem und damit vermutlich auch für deine Maschine, egal wie sie funktioniert. Gerade wenn deine Maschine auf irgendeine Weise besonders chaotisch ist (was hier immer als Argument mitzuschwingen scheint) sollte es im Durchschnitt egal sein, welche 10.000 Permutationen du nimmst. Wenn du dagegen weißt, dass es nicht egal ist, muss dieses Wissen irgendwie in den Optimierungsalgorithmus einfließen, damit er funktioniert. Das ist praktisch ein Naturgesetz :)
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Schrompf »

Um hier mal was Richtiges zu jammern:

Ich (und die halbe Firma) sollen einen Code Generator benutzen. Ein Python-Script, dass ein C++-Executable aufruft, dass irgendwie eine Java-Rich Client Platform-Anwendung ausm Eclipse-Umfeld startet, die eine Domain Specific Language einfachster Sorte parst und daraus Code generiert. Das Ding läuft leider nur in der massiv veralteten "offiziellen" Firmen-VM, aber nicht in all den VMs, die wir uns zum täglichen Arbeiten bauen. Alle Dateien kommen aus diversen Git-Repos gerollt und sind damit identisch. Aber irgendwas in der VM ist anders, so dass es dort funktioniert und überall sonst nicht. Grmpf.

Die Fehlermeldung sieht übrigens so aus:

Code: Alles auswählen

!SESSION 2017-03-09 10:29:13.816 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.7.0_80
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE
Framework arguments:  idl/api.fidl -d ./definition/public -sk
Command-line arguments:  -os linux -ws gtk -arch x86_64 idl/api.fidl -d ./definition/public -sk

!ENTRY org.eclipse.equinox.launcher.win32.win32.x86 2 0 2017-03-09 10:29:15.455
!MESSAGE Could not resolve module: org.eclipse.equinox.launcher.win32.win32.x86 [34]
  Unresolved requirement: Require-Capability: eclipse.platform; filter:="(& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86))"


!ENTRY org.eclipse.osgi 4 0 2017-03-09 10:29:15.456
!MESSAGE Application error
!STACK 1
java.lang.RuntimeException: Application "org.genivi.commonapi.console.application" could not be found in the registry. The applications available are: org.eclipse.emf.codegen.CodeGen, org.eclipse.emf.codegen.JMerger, org.eclipse.emf.codegen.ecore.Generator, org.eclipse.emf.mwe.core.WorkflowRunner, org.eclipse.equinox.app.error, org.eclipse.jdt.core.JavaCodeFormatter, org.eclipse.jdt.core.JavaIndexer.
	at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:248)
	at org.eclipse.equinox.internal.app.MainApplicationLauncher.run(MainApplicationLauncher.java:29)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
        ...
Und viele Lösungen im Internet sprechen von "Klick die Dependency an und exportiere neu". Tja... nur leider hab ich die Quellen nicht. Andere Ideen empfehlen, obskure kleine Verzeichnisse zu löschen und dann neu zu exportieren. Grmpf.

Ganz zu schweigen davon, dass ich in der Zeit, die ich jetzt in diesen Mist verschwendet habe, auch nen Parser hätte From Scratch neuschreiben können.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: Jammer-Thread

Beitrag von xq »

Alexander Kornrumpf hat geschrieben:Einerseits ja, andererseits gelten die Sachen die ich gesagt habe (natürlich nur als grobe Skizze zu verstehen) für jedes Optimierungsproblem und damit vermutlich auch für deine Maschine, egal wie sie funktioniert. Gerade wenn deine Maschine auf irgendeine Weise besonders chaotisch ist (was hier immer als Argument mitzuschwingen scheint) sollte es im Durchschnitt egal sein, welche 10.000 Permutationen du nimmst. Wenn du dagegen weißt, dass es nicht egal ist, muss dieses Wissen irgendwie in den Optimierungsalgorithmus einfließen, damit er funktioniert. Das ist praktisch ein Naturgesetz :)
Das Problem ist, dass ich mich seit nem ca. nem viertel Jahr mit dem speziellen Problem beschäftige, seit zwei Wochen intensiv und ich immer noch keine klare Struktur oder überhaupt eine verlässliche Vorangehensweise finde. Ich kann halt Code und Daten nicht einfach verschieben, da sich durch Verschiebung des Codes der Code an mehreren Stellen gleichzeitig verändern muss, um wieder auf ein funktionierendes Programm zu kommen. Das heißt, die Verschiebung von einem einzigen Codeblock kann mit etwas Pech schon gar nicht möglich sein, da sonst das ganze Programm wie ein Kartenhaus zusammenfällt und dann gar nicht mehr übersetzbar ist. Einen Block verschieben läuft im schlimmsten Fall auf alle Blöcke verschieben raus, aber mindestens auf einen.
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Jammer-Thread

Beitrag von Chromanoid »

@Schrompf: OSGi ist kacke. Eclipse ist auch ein Moloch... Mal abgesehen von der Chaos-Plugin-Architektur ist der duale Build der absolute Horror, aber das Problem haben ja sehr viele IDEs... Ich würde raten, dass da irgendwo über ein Modul ne harte Abhängigkeit auf Win-32 reinkommt, in diesem komischen GENIVI-Repository wäre das vielleicht diese yamaica-Komponente, mal geschaut ob die irgendwie geladen werden soll? - aber das hast Du Dir sicher auch schon gedacht...
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Argh, Multithreading. Jedes verdammte Mal.

Habe meine UI asynchron gemacht. Die ist schnell geworden. So verdammt superschnell, dass sogar ich keinen Optimierungsbedarf mehr sehe.

Dafür stürzt einer von 600 Vorgängen mit kaputten Zeigern ab. Natürlich reproduziert es nicht; natürlich sehen die Fehler völlig unerklärlich aus.

Jedes verdammte Mal.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
gdsWizard
Establishment
Beiträge: 237
Registriert: 04.02.2005, 09:12
Benutzertext: www.gamedevstudio.com
Echter Name: Thomas Mittelsdorf
Wohnort: Meiningen
Kontaktdaten:

Re: Jammer-Thread

Beitrag von gdsWizard »

Krishty hat geschrieben:Habe meine UI asynchron gemacht.
Warum hast Du deine UI asynchron gemacht ? Nur das Rendering oder auch anderes ?
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Bisher nur das Laden von Dateien. Das soll man abbrechen können, und während des Ladens soll die UI vernünftig reagieren (maximieren, verschieben, Rendern, schließen, etc).

[Der Absturz war ein Dangling Pointer in einer Message Queue, nachdem eine Datei beim Laden abgebrochen wurde und der nächsten Datei vom Memory Manager exakt der selben Pointer zugewiesen wurde.]

Rendering ist momentan noch schnell genug, und ich muss in D3D mit Deferred Contexts anfangen, um das asynchron zu machen – das nervt. Wird aber irgendwann kommen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
joggel

Re: Jammer-Thread

Beitrag von joggel »

Ich bin so undiszipliniert beim Software-Design.
So lange die Ansprüche von vorn herein klar sind, ist alles schick. Sollen weiter funktionalitäten hinzukommen wird der Code zusehenst unübersichtlich und hässlich.
Eigentlich müßte ich da immer re-designen.....aber meine Disziplin :(
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Alle meine Visual Studios haben fast zeitgleich beim Kompilieren gejammert: cannot write to PDB, check access rights or insufficient disk space (in der Art).

Natürlich besteht kein Problem, und nach Rebuild hat das Kompilieren wieder normal funktioniert. Ich befürchte, dass irgendwo ein Timer abgelaufen ist (oder dass CIA/NSA jetzt endgültig die Kontrolle über meinen Rechner übernommen haben).
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Anforderungen an eine Funktion, die floats als Text einliest:
  • stürzt bei ungültigen Buchstaben oder Dateiende nicht ab
  • kann +, -
  • kann fehlende Ziffern vor Dezimalpunkt, z.B. .1 oder ,1
  • kann Komma statt Punkt und warnt dann (aber nur, wenn ein Flag übergeben wird)
  • kann Exponentschreibweise
  • gibt bei Müll INF oder NAN zurück (z.B. INF bei 1.e+19999999)
  • ist halbwegs genau
Ich weiß jetzt schon, dass das der hässlichste Code des jungen Jahres 2017 wird.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
B.G.Michi
Establishment
Beiträge: 163
Registriert: 07.03.2006, 20:38
Alter Benutzername: B.G.Michi
Kontaktdaten:

Re: Jammer-Thread

Beitrag von B.G.Michi »

Ließe sich bestimmt ganz hübsch per regex lösen. Performant geht aber vermutlich anders ;)
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Warum der Artikel mit Ace Combat nicht weitergeht? Wegen dem scheiß Win32-Tree View.

Ich habe die Levels schön extrahiert, aber halt mit einem Objekt für jede Kachel der Landschaft. Macht fast 100.000 Objekte pro Level. Mein Tool lädt alles in einen Win32-Tree View (wie jedes Modeling-Tool, das es gibt), und der ist … langsam.

1. Hinzufügen: Dauert für 100.000 Items ungefähr 40 Minuten. Der Trick ist, ihn von hinten nach vorn zu befüllen. (Warum? Raymond Chen erklärt.) Dann ist man nach zwei Sekunden fertig. Tolles Design!

2. Löschen: Dauert für 100.000 Items ebenfalls ungefähr 40 Minuten. Aber: Es gibt keinen Trick. Was ich schon vergeblich ausprobiert habe:
  • TreeView_DeleteAllItems()
  • TreeView_DeleteItem(TVI_ROOT)
  • TreeView_DeleteItem(NULL)
  • TreeView_DeleteItem() von vorn nach hinten
  • TreeView_DeleteItem() von hinten nach vorn
  • TreeView_DeleteItem() von innen nach außen
  • LockWindowUpdate()
  • vor dem Löschen unsichtbar schalten, danach wieder sichtbar
Aber nein, es ist alles gleich langsam. Guess what? Wenn’s meiner gewesen wäre, wären da eh keine 100.000 einzelnen Allokationen, sondern nur ein großer Pool, den ich wegschmeißen könnte, und die Sache wäre sofort erledigt.

Jedenfalls muss ich jetzt jedes Mal, wenn ich in den Levels arbeite, meine Tools via Task Manager killen, damit sie nicht 45 Minuten weiterlaufen. Sowas macht mir die Motivation kaputt und nun habe ich eben keinen Bock mehr. Wenn ich mein eigenes OS geschrieben habe, nehme ich die Sache wieder auf.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Jonathan
Establishment
Beiträge: 2352
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Jonathan »

Krishty hat geschrieben: Ich habe die Levels schön extrahiert, aber halt mit einem Objekt für jede Kachel der Landschaft. Macht fast 100.000 Objekte pro Level. Mein Tool lädt alles in einen Win32-Tree View (wie jedes Modeling-Tool, das es gibt), und der ist … langsam.
Ja ok, aber wie es im Artikel schon so schön heißt: The treeview isn't optimized for this case because you don't optimize for the case where somebody is mis-using your system. Ich meine, auf welche Art ist ein Tree-View mit so vielen Elementen denn sinnvoll?
Und wenn man dann sagt "der Benutzer soll sich ja nicht alles ansehen, sondern sich durch die einzelnen Ebenen zu einem ganz bestimmten Node klicken können", könnte man dann nicht den Treeview dynamisch befüllen? Es müsste da doch eigentlich ein OnExpand Event oder ähnliches geben (Soetwas habe ich mal in Qt für ein Menü gemacht, das halt die zuletzt geöffneten Dateien angezeigt hat - das wurde dann bei jedem Öffnen neu befüllt).
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Man kann ihn nur in die Tiefe virtualisieren, nicht in die Länge. Um die 200×200 Grundkacheln komme ich also nicht herum.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Montaaaag! Guten Morgen, Jammer-Thread! Fuck Microsoooooft!

Habe auf die neuen PDB-Formate von Visual Studio 2015 umgestellt (/DEBUG:FASTLINK), die ja so viel schneller sein sollen. Ich weiß nicht ob sie’s sind, aber die ganze DbgHelp API (SymGetLineFromAddrW64() usw.) hört auf zu funktionieren (im Sinne von „vier Access Violations pro Aufruf“). Meine Debug-Hilfsfunktionen sind alle kaputt. PIECE OF SHIT, also alles reverten
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: Jammer-Thread

Beitrag von xq »

Javascript-basierte Seiten sind scheiße zu automatisieren....
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

MasterQ32 hat geschrieben:Javascript-basierte Seiten sind scheiße
fixed that for you

————

Boah hab’ ich wieder ’nen Kragen:
ltcg.png
LTCG:incremental ist bei Visual C++ seit einiger Zeit Standardeinstellung in Release Builds. FUCK. FUCK FUCK FUCK FUCK FUCK.

Zwei Gründe, das auf keinen Fall zu benutzen:
  1. Es ist keine volle Optimierung. Der Optimizer hält sich in dem Modus mit Inlining und Constant Propagation zurück, damit möglichst wenig neu optimiert werden muss, wenn man den Code nochmal ändert. Ihr liefert also keine voll optimierte EXE an die Kunden aus.
  2. Ohne Rebuild ist die EXE voller Müll. Der Linker hängt einfach alle Änderungen immer wieder hinten dran bis man Clean oder Rebuild aufruft. Wer also vor der Auslieferung 20 Mal was ändert und weder Clean noch Rebuild aufruft, liefert eine sechs Mal so große EXE aus, in der die 19 letzten Änderungen tot herumliegen.
Boah ist das zum Kotzen. Diese scheiß Mother Fuckers haben mir mit ihrer stillen Änderung das letzte Dutzend ausgelieferter Programme verhagelt.

NATÜRLICH war ich zu faul, die Ursache für den Größen- und Leistungsunterschied (grundsätzlich kleiner weil weniger Inlining; grundsätzlich langsamer aus dem selben Grund) zu ermitteln, weil, fuck, ich kann ja nicht den ganzen Tag optimieren und muss was fertigkriegen und sie haben halt einfach was am Compiler geändert, oder? NEIN SIE HABEN EINFACH ALLES KAPUTTGEMACHT DIE SCHWEINE

Nach Windows-Update sind Compiler-Updates also das nächste, was ich nicht mehr installieren darf. FUCK THIS SHIT

Nachtrag: Sie wollten es für Update 2 beheben, aber es ist immernoch drin?!
Zuletzt geändert von Krishty am 26.03.2017, 03:41, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: Jammer-Thread

Beitrag von xq »

fixed that for you
Danke, Recht hast du!

und ich bin grade irgendwie echt froh, hier mit gcc/clang rumzuwerkeln, da rantest du nicht so drüber rum
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Die benutze ich ja auch garnicht ;)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
kaiserludi
Establishment
Beiträge: 467
Registriert: 18.04.2002, 15:31

Re: Jammer-Thread

Beitrag von kaiserludi »

Krishty hat geschrieben: Es ist keine volle Optimierung. Der Optimizer hält sich in dem Modus mit Inlining und Constant Propagation zurück, damit möglichst wenig neu optimiert werden muss, wenn man den Code nochmal ändert. Ihr liefert also keine voll optimierte EXE an die Kunden aus.
Das macht das als Default für Releasebuilds reichlich dämlich, denn Releasebuilds sind ja gerade dazu gedacht, erst gebaut zu werden, wenn der Code releasefertig ist und man nicht noch mitten in der Entwicklung eines neuen Features ist.
Auf Entwicklungsrechners sollte man eigentlich nur die Debug Config bauen, außer, man muss akut was optimieren und die Performance testen, aber dann will man ja wieder die volle Optimierung haben.
Krishty hat geschrieben: Ohne Rebuild ist die EXE voller Müll. Der Linker hängt einfach alle Änderungen immer wieder hinten dran bis man Clean oder Rebuild aufruft. Wer also vor der Auslieferung 20 Mal was ändert und weder Clean noch Rebuild aufruft, liefert eine sechs Mal so große EXE aus, in der die 19 letzten Änderungen tot herumliegen.!
Und damit hast du gleich noch einen Grund mehr, warum du nicht in deiner lokalen Codebase, in der du auch entwicklelst, Releases bauen solltest, sondern diese in einem Clean Checkout durchführen solltest, idealerweise via Autaamted Build Script und ausgeführt durch eine spezialisierte Buildsoftware und auf dedizierter Hardware.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da
:)

"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

kaiserludi hat geschrieben:Und damit hast du gleich noch einen Grund mehr, warum du nicht in deiner lokalen Codebase, in der du auch entwicklelst, Releases bauen solltest, sondern diese in einem Clean Checkout durchführen solltest, idealerweise via Autaamted Build Script und ausgeführt durch eine spezialisierte Buildsoftware und auf dedizierter Hardware.
Bei den großen Programmen wird das natürlich so gemacht; ich habe aber auch ein Dutzend kleinerer Projekte, die quasi Standalone-EXEs sind und für die es weder Source Control gibt, noch wären Build Scripts erforderlich. Und da trifft das natürlich richtig.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Baue gerade Objektnamen in meinen TreeView ein – was man nicht alles in CAD-Dateien findet …
hangs.png
hangs.png (3.75 KiB) 5819 mal betrachtet
Zuletzt geändert von Krishty am 24.03.2017, 01:39, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
joggel

Re: Jammer-Thread

Beitrag von joggel »

Ich bekomm langsam ein Knoten im Kopf!!!!
SINNLOS hier, echt!!!

CSV-Dateien parsen und die Daten verwenden ist ja nicht sooo schwer.
Diese CSV-Datei hat einen Header.
Nun verändert sich der Header aber immer mal wieder zwischen den Versionen....
Ändert die Anzahl der Einträge, die Reihenfolge der Einträge und manchmal auch die Bezeichnung der Einträge!!!
Muß ich immer in der software anpassen.
Damit es aber richtig behindert wird, soll auch noch die Abwärtskompatibilität erhalten werden!!!! :x :x :x :x

ich kann und will nicht mehr....
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Oh, es hat wieder jemand Probleme mit 32-Bit-BMPs. Na sowas.

Die Bilder stammen aus Photoshop, und im Zusammenhang mit BMP ist das übrigens bekannt dafür, dass ihre 32-Bit-Exporte nicht mit der Spezifikation kompatibel sind (ein DWORD zu viel im Header). Das scheint aber nicht ihre Schuld zu sein, sondern ein Microsoft-Techniker scheint ihnen vor Jahrzehnten eine falsche Spezifikation gegeben zu haben und dann konnten sie es nicht mehr korrigieren weil die ganzen Content Pipelines der Spieleentwickler auf das falsche Format zugeschnitten waren. Möglicherweise haben sie es auch mit einem Format verwechselt, das Microsoft für Windows CE 5.0 entwickelt hat (und danach wieder eingestellt hat).

Jedenfalls zähle ich in meinem Code sieben verschiedene Header-Formate und vier verschiedene Kompressionsmethoden, und nothings hat recht wenn er sagt, dass sich BMP immer sehr einfach anhört aber äktschuälly eines der furchtbarsten Formate überhaupt ist.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Wenn man Visual C++ auf Größe optimieren lässt statt auf Geschwindigkeit, arbeitet der Optimizer besser. Insbesondere das alte Problem „ich lese zwei Mal aus einem Member, und der Compiler erzeugt dafür auch tatsächlich zwei Lade-Operationen, statt in einem Register zwischenzuspeichern“ tritt viel seltener auf.

Ich glaube nicht, dass das eine rationale Entscheidung war („wenn wir zwei Mal laden, lässt sich die Ausführung besser parallelisieren“ oder so).

Microsoft empfiehlt seit Jahren, gar nicht mehr auf Größe oder Geschwindigkeit zu optimieren, sondern ausschließlich Profile-Guided Optimization zu nutzen. Die wiederum optimiert nur die inneren Schleifen auf Geschwindigkeit, und den großen Rest des Programms auf Größe. Naturgemäß ist dann das meiste Disassembly, das man sieht, Ergebnis der Größenoptimierung, und vielleicht haben sie deshalb mehr Ressourcen investiert, die zu verbessern.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Tiles »

Sommerzeit. Im Frühling. :shock:
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Benutzeravatar
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: Jammer-Thread

Beitrag von xq »

Krishty, das passt doch sicher perfekt in deine Sicht zu VS: https://blog.fefe.de/?ts=a6278e32
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

MasterQ32 hat geschrieben:Krishty, das passt doch sicher perfekt in deine Sicht zu VS: https://blog.fefe.de/?ts=a6278e32
Lass mich da bitte Ordnung reinbringen:
  1. Timing-Attacken nutzen aus, dass Rechenoperationen mit verschiedenen Werten unterschiedlich schnell ablaufen. Klassisches Beispiel: Wenn ein Koeffizient Eins oder Null ist, können wir eine Multiplikation komplett überspringen und das Programm läuft schneller. Wenn ein Wert nicht im CPU-Cache liegt, dann wird es dauern, bis die CPU weiterrechnen kann, und das Programm läuft langsamer.
  2. Ein Angreifer kann die Verarbeitungsgeschwindigkeit der CPU messen, während sie Dinge ver- oder entschlüsselt. Durch die feinen Zeitunterschiede kann er sagen, wann im Algorithmus welcher Sprung genommen wurde; wann etwas im Cache lag oder nicht. Da all das abhängig vom Inhalt – also dem Schlüssel und der zu verschlüsselnden Sache – ist, kann man mit ausreichend langer Beobachtungszeit (bei einigen Attacken keine Sekunde) rekonstruieren, wie der Schlüssel aussieht. Das ist eine wirklich beeindruckende Leistung, aber auch eine wirklich beängstigende – es funktioniert durch Sandboxes und über das Internet (wie in fefes Link, dort allerdings mit drei Monaten Beobachtungszeit).
  3. Aus diesem Grund versucht man, sicherheitskritische Algorithmen so zu entwerfen, dass sie möglichst keine Sprünge oder Speicherzugriffe beinhalten, die irgendwie abhängig vom Schlüssel oder der zu verschlüsselnden Sache sind. Das Programm im Link nutzt so einen:
    The targeted implementation called Curve25519-donna essentially follows the prescriptions of the informational RFC 7748 Elliptic Curves for Security.
  4. Das Programm nutzt 64-Bit-Arithmetik:
    The type limb is a 64-bit integer.

      static void fscalar_product(limb *output, const limb *in, const limb scalar) {
        unsigned i;
        for (i = 0; i < 10; ++i) {
          output[ i] = in[ i] * scalar;
        }
      }
  5. Das Programm ist ein 32-Bit-x86-Programm und es wurde mit Visual C++ kompiliert.
  6. 32-Bit-x86-CPUs können nicht 64·64 Bits multiplizieren.
  7. Dennoch kann man in seinem 32-Bit-Programm auto x = 0x123456789ABCDEFull * 0x123456789ABCDEFull; schreiben und es funktioniert. VISUAL C++ IST EINE HEXE! Nein, natürlich nicht: In diesem Fall emuliert Visual C++ 64-Bit-Arithmetik, indem es eine Funktion __allmul() aus der Laufzeitbibliothek aufruft. (Genau so werden übrigens 64-Bit-Divisionen und Shifts emuliert, und für unsigned long long dann nochmal das gleiche.)
  8. Diese Funktion ist handoptimierter Assembler-Code. Er prüft, ob die oberen 32 Bits null sind, und überspringt dann einen Großteil der Multiplikations, weil’s so viel viel schneller geht. (Ihr merkt, wohin das führt …)
  9. Jemand misst die Ausführungszeit, und …
  10. #AUFSCHREI!
Okay. Die Katastrophe ist eingetreten und wir haben rekonstruiert, wie es dazu kommen konnte. Was hätte vermieden werden können?
  1. Visual C++ hätte diese Routine nicht „verkacken“ (Zitat fefe) dürfen!
    Ich würde mal dagegenhalten, dass 99,9 % der Fälle, in denen von Visual C++ eine 64·64-Bit-Multiplikation gefordert wird, nicht zeitkritisch sind im Sinne von „wir brauchen Konstante Ausführungszeit damit kein Angreifer unsere Schlüssel erfährt“ sondern zeitkritisch im Sinne von „Warum zur Hölle ist mein Programm mit Visual C++ so langsam; Herrgott warum habt ihr so eine langsame Multiplikation; optimiert doch mal!“. Und das auch nur, nachdem der Code bereits andere Anforderungen à „Stürzt nicht ab“ und „funktioniert auf einem 1993er Pentium I“ erfüllt. Kurz: Die Compiler-Entwickler wären mit jeder Entscheidung die Deppen. Also haben sie einfach den Code dringelassen, der die letzten 10 Jahre gut funktioniert hat (da hat nie jemand über Side Channel Attacks nachgedacht).
  2. Visual C++ hätte warnen müssen, dass es eine nicht unterstützte Multiplikation emuliert! Oder es überhaupt erst garnicht tun dürfen!
    Antwort StackOverflow: Wie beseitige ich warning C3999: unsupported MUL has been emulated?! Mein Code ist doch total in Ordnung!
    Antwort aller MS-Hasser: LOL MS kann kein unsigned long long in 32-Bit-Programmen; genau DESHALB bleibe ich bei GCC, n00bs!!!
  3. Visual C++ sollte zulassen, dass man eigene Multiplikationsroutinen verwendet!
    Tut es. Man muss die Funktion bloß mit dem richtigen Namen und der richtigen Calling Convention definieren, dann ruft Visual C++ sie auf. (Dass ich sowas ständig tue ist wohl auch der Grund, warum Felix [MasterQ32], nicht fefe {oder sind es die selben? Waren sie schonmal zur gleichen Zeit im selben Raum?}] die Nachricht erstmal auf mich bezogen hat.)
  4. Das hätte nie jemand als 32-Bit-Programm kompilieren dürfen!
    Jetzt nähern wir uns des Pudels Kern: Die Punkte 3., 4., und 5. oben stehen im Widerspruch. Da wurde ein Modell theoretisch bewiesen. Die Implementierung folgt dem Beweis. Aber die Implementierung setzt 64-Bit-Multiplikationen voraus, und die CPU kann nur 32 Bits multiplizieren! Natürlich geht das schief!
Wer nun irgendwas bewerten will, muss sich erkundigen:
  1. War an dieser Stelle eine 64-Bit-Multiplikation nötig?
    Hätte 32·32=64 gereicht? Das können 32-Bit-CPUs nämlich ohne Emulation. Bei auto x = (unsigned long long)a * (unsigned long long)b nutzt Visual C++ diese Fähigkeit auch, wenn a und b 32-Bit-Zahlen sind. In der Beispielfunktion werden aber explizit 64-Bit-Werte zur Multiplikation reingereicht. Das hier klingt sehr faul:
    In the elliptic curve implementation the 32 MSB of the coefficients are only not zero when they are negative (two’s complement is used to represent the negative numbers).
    Also sind bei allen positiven Zahlen die oberen 32 Bits Null? Und bei Negativen sind alle Eins nicht? Sicher, dass eine 64·64-Multiplikation da unbedingt nötig ist?
  2. Setzt der Algorithmus zwingend 64-Bit-Multiplikationen voraus?
    Falls dem so ist, hätte ihn niemand ohne weiteres als 32-Bit-Programm programmieren dürfen!
Ich schiebe das in diesem Fall zu 99 % auf die Implementierung. Entweder
  • war den Leuten nicht klar, dass ihre Ziel-Architektur long long * long long nicht kann, und sie haben es aus Unwissenheit trotzdem so hingeschrieben um einen durchgängigen Datentypen zu haben
  • oder die Funktion hat früher int als Parameter genommen und jemand hat (long long)in[ i] * (long long)scalar; „optimiert“, indem er die Parameter zu long long umgeschrieben hat, und nicht begriffen, dass er damit dem Compiler die Information nimmt, dass die oberen 32 Bits nutzlos sind.
Der Artikel selber denkt wohl ähnlich. Sie schreiben ja nicht Visual C++ ist scheiße!, sondern Passt mit dieser fehlerhaften Implementierung auf! und Implementierungen müssen noch mehr berücksichtigen als die Spezifikation – nämlich auch Architektur, Compiler, und Optimierungen.


P.S.: Sind Stichpunktaufsätze für euch anstrengend zu lesen? Ich schreibe so, weil ich sie angenehmer als Walls of Fließtext finde (vor allem, wenn es komplex wird, und man mittendrin nochmal oben was nachgucken will, bevor man weiterliest). Wenn’s euch stört, gibt’s das demnächst halt wieder als Aufsatz.
Zuletzt geändert von Krishty am 28.03.2017, 16:47, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: Jammer-Thread

Beitrag von xq »

Danke für die ausführliche Antwort! Genau sowas wollte ich hören.

Und zu deinem schreibstil: Das ganze lässt sich so wesentlich besser und häppchenweiser erfassen als mit Fließtext, von daher: top!
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Antworten