Geht das noch schneller? - Bitmap-Verrechnung

[Dejan Vu]

Zitat:

Zitat von mensch72 (Beitrag 1280834)

Ich würde aber eine zusätzliche Sicherheitsklammerung einführen, damit auch wirklich erst multipliziert wird und erst dann dividiert(shr 8) wird...

Wie kann ich mir das vorstellen? Ohne Sicherheitsklammerung wird erst multipliziert und dann dividiert, aber *mit* Sicherheits(!)klammerung wird wirklich erst multipliziert und erst dann dividiert, richtig? Woran erkennt man den Unterschied? Ist das eine Ergebnis richtig, aber das andere voll korrekt?

Im Ernst: Mit Sicherheitsklammerung wird ein Programm nicht besser, nur der WTF-Faktor* erhöht sich. Nun ist es aber gerade erstrebenswert, den WTF-Faktor auf 0 zu setzen.

(*) WTF-Faktor: WTF-Shouts / LoC.

PS: Muldiv hat eingebaute Sicherheitsklammerung.

[mensch72]

=> solange alles es in der Wertebereich der Operatoren passt, bei Ganzzahl-Arithmetik IMMER erst "vergrößern" (also addieren oder multiplizieren oder "shl") und dann verkleinern(also subtrahieren, dividieren oder "shr")

=> weil Pascal hier nicht immer das mach was ich will oder ich auch oft zu nur faul zum Nachzudenken, was der Kompiler draus macht, gebe ich es lieber vor), klammere da lieber einmal zuviel wie zu wenig, außerdem merkt so ein anderer welcher das liest, das man hier besonderen Wert auf die Rechenreihefolge gelegt hat und kommt nicht auf die Idee, weil's eventuell schöner "aussieht" aus "100 * 128 div 256" etwa "128 div 256 * 100" zu machen... mit "WTF" hat dies also nix zu tun!

=> Mein Vertrauen in die math. & logische Hierarchie der Operatoren von Pascal ist leider etwas getrübt, denn wenn man von C/C++ kommt ist das in Pascal bei AND & OR ständig nötige Klammern, weil hier kein "And vor Or" gilt sehr lästig... für mich echt vergleichbar dem wenn der Compiler nicht Punkt vor Strich rechnen könnte... daher klammere ich zur Sicherheit in Pascal eben da wo es mir drauf ankommt noch etwas mehr wie in C/C++.


Hier im Fall wird es nicht "richtiger", sondern WorstCase falsch, auch wenn mathematisch oder mit Fließkomma es an sich hier völlig egal ist ob man erst multipliziert oder erst dividiert.

Bei Ganzzahl-Arithmetik spielt es eben doch eine Rolle, denn wir haben in diesem Fall einen begrenzten Rechenwertebereich von 32Bit, jeder Operator hat einen Wertebereich von zum Glück nur 8Bit, das heißt dann hier im Detail für ein mathematisch eigentlich identisches Beispiel:

128 div 256 * 100 = !0! weil (128 div 256) * 100 = !0!
aber
128*100 div 256 = !50! weil (128*100) div 256 = !50!

Und da finde ich die sicherheitsgeklammerte Schreibweise sehr sinnvoll, weil wenn das keine kurzen Zahlen sondern lange Variablennamen in einer Kette von Operatoren sind, erschließt sich ohne Klammern die Konsequenz falscher Rechenreihenfolge nicht mehr jedem Codebetrachter sofort.

[Dejan Vu]

Es wird von links nach rechts ausgewertet, da werden keine Klammern benötigt. So einfach kann die Sinnlosigkeit der 'Sicherheitsklammern' zusammenfassen. Der Compiler macht das so. Genau so. Jedes mal. Bei C(++) mögen deine Sicherheitsklammern ja sinnvoll sein, aber bei Delphi nicht.

Dein fehlendes Vertrauen könntest Du durch einmaliges Ausprobieren aufbauen, aber dazu bist Du ja leider zu faul (deine Worte). Daher meine Bitte: Verbreite aber deine Faulheit und deine dadurch bedingte Unsicherheit nicht weiter, insbesondere nicht durch Tipps, wie 'Sicherheitsklammern'. Klammen sind entweder sinnvoll oder sinnlos. 'Zur Sicherheit' werden diese nicht benötigt. Zur Lesbarkeit: Jeder mathematisch halbwegs versierte Programmierer wird hier WTF rufen, denn alles, was überflüssig ist, ist eben 'falsch' (weil überflüssig). Lies mal Bücher über sauberes Programmieren, und was genau den Unterschied zwischen einem sauberen Programm und Schrottcode ausmacht (nämlich genau der WTF-Faktor).

Was Du natürlich in deiner Freizeit und privat auf deinem Rechner machst, bleibt Dir überlassen. Klammere ruhig zu viel als zu wenig. Wie wäre es noch mit Sicherheitsblöcken à la "Begin End" (man kann ja nie wissen)? Oder doppelte Zuweisungen, damit es richtig hält. :stupid:

[Daniel]

... Grundgütiger - was für eine schroffe Zurechtweisung. War die in dieser Schärfe tatsächlich nötig?
Sei Dir bitte bewusst, dass es sich hier um Deine Meinung handelt - ich beispielsweise finde sehr wohl, dass sinnvoll gesetzte Klammern zur Lesbarkeit beitragen können, selbst wenn sie mathematisch nicht erforderlich sind.

[himitsu]

Zitat:

Es wird von links nach rechts ausgewertet, da werden keine Klammern benötigt.

Njain, Gleichrangiges wird von links nach rechts ausgewertet.

Klammer haben Vorrang vor Allem, dann kommt nacheinander die Gruppe der unären Operatoren

Delphi-Quellcode:

@ not

, dann die Multiplitationsoperatoren

Delphi-Quellcode:

* / div mod and shl shr as

, danach die Additionen

Delphi-Quellcode:

+ - or xor

und zum Schluß die Vergleichsoperationen

Delphi-Quellcode:

= <> < > <= >= in is

dran,
so wie man es aus dem Matheunterricht kennt. (Klammer, Multiplikation/Division und Addition/Subtraktion)

Gut, hier sind * / div und shr gleichrangig, dann stimmt die Aussage zufällig.


Und ja, ich mache Klamern auch nur dann, wenn es nötig ist, somit fällt gleich auf, was los ist und man wird nicht unnötig abgelenkt,
aber Andere sind sich mit der Reihenfolge nicht sicher und da sind Klammern dann (für sich) sicherer.

[Dejan Vu]

Zitat:

Zitat von Daniel (Beitrag 1280847)

... Grundgütiger - was für eine schroffe Zurechtweisung. War die in dieser Schärfe tatsächlich nötig?

Nein, nötig war das natürlich nicht. Aber ich kämpfe täglich gegen schlechten Code und da gehen einem manchmal die Gäule durch.
Was Du gut findest, sind aber keine Sicherheitsklammern, sondern Übersichtlichkeitsklammern. Auch 'falsch' (nimm lieber sprechende Zwischenvariablen).... Aber eben I-M-H-O. Das hätte ich stärker betonen müssen.

[samso]

Der Befehl "shr 8" bringt nach meinen Tests gegenüber "div 256" keine Verbesserung, weil der Compiler (zumindestens ab XE4) die 2er Potenz korrekt erkennt und selbstständig aus dem div einen entsprechenden Shift-Befehl macht (logisch/arithmetisch bei Cardinal/Integer).

[Dejan Vu]

MulDiv könnte etwas bringen, aber -wenn überhaupt- nur marginal.
Was auch helfen könnte: Statt 'RGBA_Unten^[w]....' nur 'RGBA_Unten^...' und am Ende ein 'Inc(RGBA_Unten)'... Damit wird der Zeiger weiter bewegt (ich schätze, automatisch um 4 Bytes).

allgemein sind Array-Zugriffe fast immer etwas langsamer, als Dereferenzierung über einen Pointer und anschließendes Pointer-Increment.

[manfred42]

Ich hatte mich gestern bei DP angemeldet, weil mich das Thema "Bitmap"
interessiert, ich auch etwas dazu beisteuern kann und ich mich gern an
sachlichen Diskussionen beteilige.

Heute beschleichen mich etwas gemischte Gefühle, wenn ich mir den Verlauf
der Diskussion ansehe. Aus meiner ersten Sicht wirkt das nicht sehr sachdienlich.

Als Praktiker kann ich beim Debuggen des CPU-Codes einschätzen,
welche Eskapaden der Compiler machte und dann am Quellcode schrauben.
um eine 'Linderung' zu versuchen.
Auf diese Weise habe ich ein Antialiasing mit MMX-Assemblercode passabel
hinbekommen.

Ich 'tethere' mit einem Androiden. Es gelingt mir nicht, eine korrekte
Zip-Datei eines kompletten Delphi-Projektes oder ein Refernzbitmap
abzusaugen. Heruntergeladene Zip-Files werden von RAR, AntekZIP
und anderen als inkorrekt abgewiesen.

Was habe ich nicht beachtet?

[Harry Stahl]

@manfred42:

Habe mal das Zip-Paket (mit einem anderen ZIP-Programm gepackt) an Deine private Mailadresse geschickt, wie gewünscht.