ZFX + Developia

Für Schritt-für-Schritt-Anleitungen habe ich keine Zeit, aber die wichtigsten Fallstricke erläutere ich hier.

Visual C++ zieht ungenutzte Symbole in meine EXE. Nicht immer, aber immer öfter. Alle Fälle betreffen structs oder Arrays. Egal, ob ich sie static deklariere (C-Style) oder in ein anonymes namespace lege (C++-Style) – keine der in der EXE landenden Funktionen nutzt sie, aber sie stehen drin und verschwenden Platz. Richtig aufgefallen ist es erst, als dtoa.c ein 256 B großes Array mitbrachte, obwohl ich nirgendwo mit Strings arbeite.

Das muss ich irgendwie auf einen minimalen Repro reduzieren, aber das Wochenende ist schon wieder rum.

*Marge Simpson-Grummeln*

Nachtrag: Beschwerde über globale volatiles zurückgenommen; habe in die falsche Spalte geguckt :oops:

Auf dem Amiga gab es noch Dynamic HAM und Dynamic HiRes. Hier wurden mit dem Copper innerhalb eines Bildes die Frabregister neu gesetzt. So ne Art Multitasking für die Farbregister.

Ja, dem Archive Team nach:

http://fileformats.archiveteam.org/wiki/ILBM#Multi-palette_HAM hat geschrieben:There are at least three extended HAM formats designed to take advantage of the Amiga's ability to make changes to the palette in the middle of an image:

• SHAM (Sliced HAM) - Uses a SHAM chunk.
• CTBL (Newtek Dynamic Ham) - Uses CTBL and DYCP chunks.
• PCHG - Uses a PCHG (Palette Changes) chunk.

… und sie liefern sogar Beispieldateien. Gut, dass du mich erinnerst. Über das CRT-Gewusel hätte ich das jetzt fast vergessen. (Falls du Beispieldateien hast, immer her.)

Leider kann ich Dir keine keine Beispieldateien geben, da ich nicht mehr viel vom Amiga aufgehoben habe. Das habe ich selber schon bereut.

Aaaalso, ich habe mich an Sliced HAM und Dynamic HiRes versucht und wäre fast verzweifelt. Bis mir klar wurde, dass die Paletten von unten nach oben gespeichert werden. Was ich nie erwartet hätte, weil ich die Daten eh invertiert verarbeiten muss, um sie bottom-up in meinen Renderer zu schieben. Jetzt läuft es; also ab zum Aufräumen des Quelltextes.

An der Stelle Infos zur Notation:

1. Sliced Hold-and-Modify („SHAM“):
   • 5 oder 6 Bit Planes pro Pixel
   • werden als Hold-and-Modify dekodiert
   • wechseln ihre Palette
     • jede Zeile, falls nicht höher als 200 Pixel
     • jede zweite Zeile, falls nicht höher als 400 Pixel
     • können nicht höher als 400 Pixel existieren
   • Die Paletten kommen aus dem SHAM-Chunk
     • mit 2-B-Versionsnummer, die immer 0 ist
     • dann bis zu 200 Paletten in bottom-up-Reihenfolge, jede 16 Farben groß
     • jede Farbe als 0-R-G-B mit 4-4-4-4 Bits
   • Beispieldateien: http://cd.textfiles.com/fishandmore/Mor ... ures/Sham/
2. Dynamic HiRes:
   • von NewTek für ihr Videobearbeitungstool DigiView entwickelt
   • 4 Bit Planes pro Pixel
   • kein Hold-and-Modify o.Ä.
   • wechseln ihre Palette jede Zeile
   • keine Höhenbegrenzung (außer absurd hohe Werte wie 1024×768, mit denen sie warben)
   • die Paletten kommen aus dem CTBL-Chunk
     • exakt gleiches Layout wie SHAM, nur ohne 2-B-Versionsnummer am Anfang
   • Beispieldateien: http://aminet.net/search?query=demoreel
3. Dynamic Hold-and-Modify („DHAM“ oder „Dynamic HAM“):
   • 5 oder 6 Bit Planes pro Pixel
   • werden als Hold-and-Modify dekodiert
   • wechseln ihre Palette jede Zeile
   • wieder keine Höhenbegrenzung
   • die Paletten kommen aus dem CTBL-Chunk (siehe Dynamic HiRes)
   • Fun Fact:

     Since Dynamic modes must calculate a new palette for each scan line they take time to render. Low resolution Dynamic HAM takes about 2.5 minutes on a 512K Amiga.

That escalated quickly. Scheiße, mein Quelltext sieht jetzt aus wie die deutsch-französische Grenze vor 100 Jahren.

cbloom hat geschrieben:VC 2015 CRT

Did I mention already that this is fucking retarded and annoying? Jesus christ fucking heads up your fucking asses.

It looks like I'll be stripping CRT use from Oodle Core. It's not that hard. We have our own sprintf, so I'll use that, and for logging I already take func pointers, so people can install stdio logging if they want, I just won't provide it by default.

(05-04-16 | VC 2015 CRT)

Willkommen im Club! Ihm ging es aber wohl um was anderes als mir:

04-20-16 | CRT

So VC 2015 has broken CRT link compatibility. (So). It was one of the ways that VC was better than the gcc/Linux nightmare (thought they've been trying really hard to fuck everything up in VC-land, what with SxS and winRT and so on). Apparently someone at VC said "hey you know how in Linux you can never share a binary build of a lib with other developers, because they used some different libc and it's a total nightmare? we should have that on Windows!" and everyone went "yeah! cool feature!". So now you can no longer share binaries in Linux or Windows.
The best solution, IMO, is to remove as much CRT use as possible. (for example, for VC 2015 you just have to remove all stdio use)

So you're taken the most basic shared library in C and made it unusable. Awesome.

Aus der beliebten Serie „C ist ein Schrotthaufen“ heute die Episode „Ist eine Zahl ungerade?“ Mit Extra-Zusatz „StackOverflow ist voller Idioten“!

Also, ich habe ein int und davon weiß ich, dass es positiv ist. Ich muss wissen, ob es ungerade ist.

Schrott 1:

Ich kann das int nicht unsigned machen. Das würde nämlich eine Klasse vom Optimierungen verbieten:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html#signed_overflow hat geschrieben:If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN. This behavior enables certain classes of optimizations that are important for some code. For example, knowing that INT_MAX+1 is undefined allows optimizing "X+1 > X" to "true". Knowing the multiplication "cannot" overflow (because doing so would be undefined) allows optimizing "X*2/2" to "X".

Die Frage, ob das int ungerade ist, ist auf StackOverflow relativ schnell und sicher beantwortet:

  if(x % 2)

Oder, weit abgeschlagen und abgewertet:

  if(x & 1)

if(x % 2) erzeugt mit Visual C++ folgenden Maschinentext:

  mov  eax,ecx
  and  eax,80000001h
  jge  013F48291Eh
  dec  eax
  or   eax,0FFFFFFFEh
  inc  eax
  test eax,eax

Warum? Weil der Compiler – mit Recht! – annimmt, dass die Zahl negativ sein könnte.

Schrott 2:

Ich sage dem Compiler, dass die Zahl positiv ist und nicht überlaufen kann:
  __assume(x >= 0 && x < 65536);
  if(x % 2)

… und die Befehlsfolge bleibt identisch. Jetzt macht Visual C++ das nicht mehr mit Recht.

Schrott 3:

Ich muss also von Hand schreiben

  if(x & 1)

und bekomme zumindest jetzt die sauber optimierte Version

  and  eax,1
  test al,al

Schrott 4:

… das auf StackOverflow war noch nicht zuende, oder? In der Antwort wurde der Quelltext nur für positive Zahlen getestet, und GCC hat das korrekt optimiert. Daher die Vermutung:

I also doubt any modern (made in the past 20 years) non-arcane compiler, commercial or open source, lacks such optimization.

Unlikely to matter - argument is a constant. Easy for the optimizer

most good optimizing compilers will generate exactly the same code for 'and 1' as for 'mod 2'.

I don't think it's fair to say it's faster than using division or modulus. The C standard doesn't say anything about performance of operators, and any decent compiler will produce fast code for either.

I believe that any modern C/C++ compiler will boil the "% 2" operation down to a bit test.

doubt, unlikely, think, believe – Es ist immer toll, solche Spekulationen hinzuschreiben, ohne sie zu testen.

Schrott 4.2:

Modern compilers will optimized x%2 to x&1 if/when such an optimization is both correct and faster. In old days, it was likely not to be correct (1's compliment systems), now a days, it's not likely to be faster (all arithmetic done in 1 cycle).

Mit Einerkomplement zu argumentieren und dann zu behaupten, ein Modulo wäre in einem Takt erledigt, ist so viel Idiotie, dass es extra Erwähnung verdient. (Ein Modulo dauert auf aktuellen CPUs 15 bis 80 Takte, abhängig von den Operanden.) Die „Aber der Code geht dann nicht auf Einerkomplement!“-Keule kommt noch gefühlte hundert Mal.

Schrott 5:

Fast niemand widerspricht diesem ganzen bei den Haaren herspekulierten Müll.

I tested with SDCC, and the bitwise version gives a LOT more compact and fast code.

(Ohne Reaktion.)

The version that uses bitwise and (&) is much more efficient than the modulo (%) version.

Reaktion:

bullshit :)

(25 Up Votes)

Schrott 6:

… was bedeutet, dass niemand anders es getestet hat (weder die tausend Up-Voter, noch die 215.000 Leser).

Schrott 7:

34 upvotes to explain modulo? No offense, but I feel like we've had plenty more tricky questions...and more elaborate answers.

Genau.

Schrott 8:

Die Leute fangen jetzt an, die zwar langsame, aber korrekte Antwort umzudeuten:

I agree with everything, except one thing: I like to keep integers and truth values separate, conceptually, so I prefer to write "if (x % 2 == 1)". It's the same to the compiler, but perhaps a bit clearer to humans. Plus you can use the same code in languages that don't interpret non-zero as true.

== 1, wirklich? Ob Division und Modulo in C auf- oder abrunden, bleibt der Implementierung überlassen. Für negative Zahlen ergibt x % 2 auf allen aktuellen CPUs -1. Glückwunsch, dein Code ist besser strukturiert, klar lesbar für Menschen, einfacher zu kopieren, und – vor allem – falsch!

Schrott 9:

Wieder: Niemand widerspricht!

Schrott 10:

Früher hätte ich da sofort hinschreiben können, dass das alles Idioten sind, aber jetzt soll ich dafür erstmal ein verficktes Benutzerkonto anlegen?! WTF?!

Da ist es doch effizienter, wenn ich hier ohne Registrierung schreiben kann, dass man auf StackOverflow nur Antworten auf schwierige Fragen trauen kann. Je banaler die Frage scheint, desto dümmer der Thread-Inhalt und desto schneller sollte man da weg.

Schrott 11:

Falls ihr es eben oben überlesen habt: „Ob Division und Modulo in C auf- oder abrunden, bleibt der Implementierung überlassen.“

hast wohl kein google konto? :)
finde es irgendwie schade, wenn du es den idioten nicht sagst, dass sie idioten sind.
aber ja, es tummeln sich verdammt viele leute dort. halbwissen reicht für die meisten antworten aus, eine schneller antwort ist den meisten lieber als eine absolut korrekte.
wer optimiert heute schon nocht, macht ja der compiler wie du schön zeigst viel besser :D

ich fand es auf alle fälle interessant, was du geschrieben hast. bin auch gar nicht erstaunt das module teuerer ist als eine bit-operation. lustig, dass so viele an den compiler gott glauben.

Ja, und ich habe ebenfalls einen Brain Fart drin: Dass der Compiler das Modulo nicht durch AND ersetzt, liegt nicht an negativen Zahlen (denn für negative funktioniert das genau so). Sieht eher nach einer verpassten Peep Hole Optimization aus (Visual C++ will das Ergebnis der Modulo-Operation möglichst exakt annähern, ohne zu bedenken, dass am Ende nur Null oder nicht-Null entscheidend ist). Ich würd's gern mit ihrem neuen Optimizer testen, aber habe hier gerade zu kritische Dinge zu kompilieren um den zu installieren …

marcgfx hat geschrieben:hast wohl kein google konto? :)

Boah geh mir wech. Ich hatte mehrere, aber wollte dort nie meine Telefonnummer eingeben. Außerdem habe ich sie mit Tor angesurft, was sie wohl als Angriff werten. Deshalb ist alles gesperrt und kann nur noch via Telefon (das ich nicht angegeben habe) freigeschaltet werden.

Ich sehe das nicht einmal als Fuck-Up, sondern eindeutig als Strategie, an meine Telefonnummer zu kommen. Da setze ich nie mehr einen Fuß rein.

Huch, was hat denn Stack Overflow mit Google zu tun? Hab ich da was verpasst? O_O

Man kann sich dort mit seinem Google-Konto einloggen. War Marcs Antwort darauf, dass ich mich erst registrieren muss :)

Ah, jetzt. Ich dachte schon Google hätte auch das inzwischen eingemeindet :P

Nimm doch deinen Facebook Acc ... Na gut :D

Strawberry Perl (64-bit) cannot be installed in a directory with spaces or non-ASCII characters.

Vor 20 Jahren hätte ich das möglicherweise noch akzeptiert. Aber wer von denen denkt bitteschön, dass es heutzutage akzeptabel ist, wenn ich eine Software nicht im Standard-Pfad ("Program Files") installieren kann? Ich meine, ich sehe ein, dass wenn man viel mit der Kommandozeile arbeitet, Leerzeichen zu dusseligen Bugs führen können, aber das ist doch alles absolut vermeidbar. Ich habe ja bisher wenig mit Perl gemacht, aber soweit ich weiß, ist das irgendwie eine der Standard-Skriptsprachen, aber sie können trotzdem immer noch nicht mit Leerzeichen umgehen? Das finde ich jetzt schon ziemlich, ziemlich peinlich.

Chromanoid hat geschrieben:

Krishty hat geschrieben:UnsignedInt4B

<3 Explizität ftw

… und jetzt rücke ich davon ab, weil es zu viel Text ist. Insbesondere bei der Definition von Datenstrukturen hat man eine riesige Wall of Text, und das 1, 2, 4, oder 8 der Byte-Anzahl geht total unter. Wenn es sich dann noch spezialisiert (UnsignedInt4Bx4 für SIMD, UnsignedIntLeast4B für Registereffizienz, UnsignedInt4BLittleEndian für Dateidaten), ufert es völlig aus. Mal sehen, ob man mit UInt4B, UInt4Bx4, UIntLeast4B, und UInt4B_LE noch immer alles versteht.

P.S.: Schön, dass ich mich an vier Jahre alte Beiträge erinnere und sie in weniger als zehn Sekunden finde. Schade, dass ich nicht mehr weiß, worüber ich hier vorgestern gejammert habe.

Vielleicht kannst Du ja sonst Aliase pro Datei definieren. Keine Ahnung ob das eine gute Idee ist. So ähnlich läuft das ja manchmal bei Namensräumen usw.

BTW keine Ahnung was da mit der URL in Deinem Post los ist.

BTW keine Ahnung was da mit der URL in Deinem Post los ist.

Die enthält einen Umlaut. Löscht man den, geht, es. Ich wollte, dass ihr es seht ;)

————

Ich habe früher schon geschrieben, dass ich meinen Vektoren und Matrizen zwei Layouts verpasst habe – einmal für langfristige Speicherung (z.B. drei floats für X/Y/Z); und einmal für Rechnen/Parameterübergabe/temporäre Werte (z.B. __m128 für direktes Mapping zu SIMD-Register); mit load() und store()-Funktionen, die dazwischen konvertieren. Und dass das die einzige Variante ist, die mein Programm verschnellert hat (nur SIMD verlangsamt weil die Caches mit Padding verschmutzt werden; nur skalar verlangsamt weil man ALU wegschmeißt).

Irgendwann habe ich auch meine Farben darauf umgestellt (drei Bytes für R/G/B im Speicher gegenüber einem int32 im Register – wobei Compiler das teils automatisch machen, aber recht ineffizient).

Jetzt spare ich hier und da ein paar Takte und Bytes durch die Nutzung von int_least16_t bzw. int_fast16_t. Und da dämmert mir: Auch da muss man das eigentlich so machen – eine Klasse für Integer im Speicher; eine für Integer im Register (oder auf dem Stack); Funktionen, um dazwischen zu konvertieren. Das würde viele Fliegen mit einer Klappe schlagen:

1. Das Leistungsproblem, offensichtlich
2. dass man uint16_t nicht einfach durch uint_fast16_t ersetzen kann ohne das Programm zu zerstören
   • denn man kann dann nicht mehr vorhersagen, ob die Variable zu int oder unsigned int promoviert
   • also gehen schlimmstenfalls alle Überladungen im Programm kaputt
   • Klassen promovieren nicht (die chillen nur) – Problem gelöst!
3. das furchtbare Gefrickel mit Endianness bei Dateiformaten
   • deklariere Little-Endian-Dateistrukturen mit int_le32_t
   • die korrekte Überladung von load() und store() konvertiert automatisch
   • dazwischen rechnet man mit höchster Effizienz

… aber dann ist der Code sicher so voll von load() und store(), dass sich die Entwickler wie Assembler-Programmierer fühlen.

Amigas AIFF-Soundfiles haben eine 80-bit long double im Header. Kein moderner Compiler nutzt mehr long double auf x86-64 …

Kunden fragen, warum Asset-Export zu STL so quälend langsam ist. Krishty schmeißt den Profiler an. Krishty sieht die Visual C++-CRT, und nichts anderes.

Über 80 % der Ausführungszeit werden in _stdio_common_vsprintf() verbracht. Um pro Vertex drei floats auszugeben (keine besonders großen, kleinen, langen, oder krummen Werte). Tatsächlich kann meine alte magnetische Gammelfestplatte die Daten fünf Mal so schnell speichern, wie sprintf() sie erzeugt.

Und mit was hast du die Funktion jetzt ersetzt?

Wir gucken gerade, ob wir auf die Binärversion des Formats ausweichen können, damit das Problem erst garnicht entsteht.

Mein letzter Kenntnisstand ist, das schicke Dinge wie Streams einen gewissen Overhead haben und die guten alten, unsicheren C-Funktionen in Sachen Performance quasi ideal sind. Und wenn man bedenkt, dass man beim Exportieren ja auch wirklich jede zahl am Ende in der Datei haben möchte, würde das bedeuten, dass der Export im Grunde genommen eine optimale Laufzeit hat und quasi nicht mehr optimiert werden kann. Was dann wirklich ein nettes Ergebnis wäre.
Verbessern könnte man es dann überhaupt nur noch dann, wenn man etwas fundamental anders macht, wie das angesprochene Verzichten auf Textdateien.

Jonathan hat geschrieben:Mein letzter Kenntnisstand ist, das schicke Dinge wie Streams einen gewissen Overhead haben und die guten alten, unsicheren C-Funktionen in Sachen Performance quasi ideal sind.

Die benutze ich bereits, und wenn 50 % der Ausführungszeit in _iswalpha() verbracht werden, ist das vielleicht doch nicht so pralle implementiert :(

Verbessern könnte man es dann überhaupt nur noch dann, wenn man etwas fundamental anders macht, wie das angesprochene Verzichten auf Textdateien.

Bin gerade unterwegs, aber wenn ich zurück bin baue ich einfach mal ein, dass die float-Koordinaten auf Integer hochskaliert werden und ich schreibe die Integer weg. Mein Gefühl sagt mir, dass das schon deutlich schneller sein wird.

Ja, mit 'C-Funktionen' meinte ich schon das vsprintf.
Rein aus Interesse: Um was für Datenmengen und Zeitanforderungen geht es denn hier? Hätte nicht gedacht, dass Text-Formatieren mal zu so einem Problem werden kann.

Um einen Gigabyte Text geht es ungefähr, und wenn ich mich recht erinnere, war er in knapp zwei Minuten geschrieben. Dass meine Festplatte das fünf Mal so schnell kann, war wohl übertrieben -- bei 25 MiB/s sollten es 40 Sekunden sein -- aber bei meinem Kollegen mit modernem Core i7 und SSD dauerte es immernoch gut 30 Sekunden; das ist einfach nicht zumutbar.

CMake ist case-insensitive. Außer wenn es gerade mal nicht case-insensitive ist.
Aber das macht den Braten jetzt auch nicht mehr fett...

Statt selber nur zu meckern, zitiere ich jetzt einfach mal:

targets are everything in CMake. Unfortunately, not everything is a target though!

If you’ve tried do anything non-trivial in CMake

got stuck in this horrible swamp of confusion

all sorts of exciting limitations to make you forget everything you ever new about dependency management.

What makes it so hard is that there’s not one limitation, but several.

You may live to regret ever letting it in.

I found all of this quite difficult to work out

there is plenty of room for improvement

One can notice your frustration with cmake

Eine schöne Zusammenstellung. Ich bau aktuell mit QMake auf Linux und OSX und MSVC auf Windows. Alles doppelt machen, auch irgendwie doof.

Einen guten hab ich noch übersehen :D

How does this work? Actually it doesn’t!

Gollum hat geschrieben:It’s a shame for mankind, that a language like C++ ended up with CMake as its most popular build tool…

QFT