Beste IsHEX( AChar : Char ) Methode um Character auf HEX zu prüfen ?

[TiGü]

Himi, hast du das eigentliche Problem bzw. die Fragestellung verstanden?

[himitsu]

Es ging darum zu prüfen ob es HEX ist und mein Vorschlag war ja einfach zu konvertieren und wenn es nicht geht, dann isses das nicht.

Und um nicht alles neu entwickeln zu müssen, kann man ja auch eine der fertigen Funktionen/Klassen benutzen, falls man was findet, dass zur Aufgabe passt.
(bissl blöd ist nur, dass viele der Funktionen bei falschem Input eine Zugriffsverletzung werfen oder meistens den Fehler einfach wortlos ignorieren :wall:)

[Michael II]

Wenn du TiGüs #6 noch ein inline spendierst, dann läuft's auf meinem Uraltnotebook drei Mal schneller (100 Mio Entscheide in 203ms statt 713ms).

Delphi-Quellcode:

function IsHEX(const AChar: Char): Boolean;inline;

[Stevie]

Delphi-Quellcode:

function IsHEX(const AChar: Char): Boolean;
{$OVERFLOWCHECKS OFF}
{$B+}
var
  w1, w2: Word;
begin
  w1 := Ord(AChar) - 48;            // '0' = 48
  w2 := Word(AChar) and -33;        // kleiner Trick um aus kleinen Buchstaben große zu machen
  w2 := w2 - 65;                    // 'A' = 65
  Result := (w2 <= 5) or (w1 <= 9); // wenn zwischen 'A'..'F' oder '0'..'9'
end;

Branchloses asm:

Code:

Project26.dpr.16: w1 := Ord(AChar) - 48;
004F5874 8BD0             mov edx,eax
004F5876 6683EA30         sub dx,$30
Project26.dpr.17: w2 := w2 and -33;
004F587A 6625DFFF         and ax,$ffdf
Project26.dpr.18: w2 := w2 - 65;
004F587E 6683E841         sub ax,$41
Project26.dpr.19: Result := (w2 <= 5) or (w1 <= 9);
004F5882 6683F805         cmp ax,$05
004F5886 0F96C0           setbe al
004F5889 6683FA09         cmp dx,$09
004F588D 0F96C2           setbe dl
004F5890 0AC2             or al,dl
Project26.dpr.20: end;
004F5892 C3               ret

[Rollo62]

Hallo Stefan, genau solche Tricks meinte ich :)
Ich hatte mich dunkel daran erinnert das es da noch irgendwas mathematisches gab.
Das mit dem case ist aber auch schon weit vorne.

Gefühlt würde ich trotzdem sagen das die Sprungtabelle gewinnen könnte, zumindest bei Performance,
Aber meine Lieblingslösung ist das sicher nicht, wegen der Platzverschwendung.
Da gab es aber doch auch Tricks um nicht 256 Byte Tabellen zu verbrauchen, vielleicht in Kombination mit deiner Rechnung.

Werde das nächste Woche mal Testen.

[himitsu]

Wenn es geht (Codeoptimierung und so), dann macht CASE auch derartige Berechnungen.

Delphi-Quellcode:

case i of
  1: x := 1;
  5: x := 2;
  30: x := 3;
end;

// Pseudocode, den Delphi generieren könnte, so in etwa (die mathematik)
t := i;
dec(t); if t = 0 then begin x := 1; exit; end;
dec(t, 4); if t = 0 then begin x := 2; exit; end;
dec(t, 25); if t = 0 then begin x := 3; exit; end;

// wobei Delphi GOTOs exterm gern hat und es dann eher so aussehn könnte (im Assembler ist das DEC und CMP vom IF zusammengefasst)
t := i;
dec(t); if t = 0 then goto 1;
dec(t, 4); if t = 0 then goto 2;
dec(t, 25); if t = 0 then goto 3;
goto 4;
1: x := 1; goto 4;
2: x := 2; goto 4;
3: x := 3; //goto 4;
4:

Vom "Speicher" zur Laufzeit ist Konstante und Variable kein Unterschied.
Die Variable braucht aber anfangs bissl Zeit, zum Füllen,
und bei der Laufzeit sind es zwei Pointer ... zur Variable und von da zum Speicher, wo es bei einer echten Konstante nur ein Zeiger ist, der beim Start von Windows berehnet wird. (ReallocationTabelle, falls die EXE im RAM verschoben wurde)

PS: 256 wird nicht reichen, denn Unicode sind ja 2^16 und nicht 2^8.
Wobei man das auch auf 2^7 (ASCII) und weniger kürzen/casten könnte, wenn man vorher den Bereich prüft.

Delphi-Quellcode:

if (Ord(C) < 256) and Byte(C) ......

Statt 64KB (Boolean/Char) könnten auch 8KB (1 Bit/Char) reichen,
aber vom Tempo kommt es bestimmt mit einem LongBool am Besten, da dort die CPU optimaler drauf zugreifen kann, auf einen "Integer" im RAM.

Delphi-Quellcode:

array[0..$FFFF] of LongBool

Und ganz im Ernst, bei all dem platzverschwendenden Mist, den dir Delphi schon unterjubelt, fällt es bestimmt nicht auf, wenn man die paar 256KB als Daten in die EXE einkompiliert.
(Konstante, Ressource oder ganz böse als Assembler DB versteckt)

[Stevie]

Himi, lies mal bitte etwas über branchless programming. Quasi jedes if statement in Delphi generiert einen bedingten Sprung, und auch noch so optimierte case Anweisungen tun das. Und die sind nunmal selbst bei den Sprungvorhersagen der modernen CPUS nicht so gut, als ob man gar keinen Sprung hat.

Wenn man bis in die Haarspitzen optimierten Code möchte (und in Delphi bleiben will) und ein bisschen Ahnung von C++ und assembler hat, nimmt man sich am besten den Compiler Explorer zur Hand, schreibt seinen Code in C++ und schaut sich an, was gcc oder clang daraus generieren. Entweder übernimmt man den asm Code dann so (an die Aufrufkonvention denken bzgl Register,

Delphi-Quellcode:

__attribute__((regparm(3)))

über die Routine hilft) oder man bekommt eine Idee, wie man den code schreiben könnte, damit der Delphi Compiler etwas ähnliches ausspuckt, aber die Chance für letzteres ist eher gering (im Beispiel hier hatte es geklappt).

Und immer dran denken, ob man sich gerade mit den 97% oder den 3% beschäftigt:
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." - Donald Knuth

P.S.: Ah und bevor man meint, nur weil man nen bisschen gammeliges assembler schreiben kann, was dann bestimmt rattenschnell ist - bitte https://www.agner.org/optimize/ gründlich zu Gemüte führen.

[freimatz]

Kann ich nur unterstützen. Investiert Eure Zeit lieber damit sauberen Code zu schreiben.

Zu den Speichertabellen: Das könnte auch nach hinten losgegen, weil man damit schneller den Cache füllt und so früher zum Nachladen zwingt.