Discussion :

[Rekin85]

Bonjour

Le setlength coûte cher en ms...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
function SupprCharV4(Const S: string; CharSuppr : Char): String;
var Sb : byte;
asm
  push   esi
  push   edi
  push   ecx             // garder adresse retour
  mov    Sb,dl           // garder Char
  mov    esi,eax         // esi pointe S
  mov    ecx,[esi]-$4
  add    esi,ecx         // esi pointe fin S + 1
  xor    eax,eax
  @compteur:             // compteur des suppressions
  dec    esi
  cmp    byte ptr[esi],dl
  jne    @non
  inc    eax
  @non:
  dec    ecx
  jnz    @compteur
  neg    eax
  add    eax,[esi]-$4   // longueur string retour
  call   System.@NewAnsiString
  mov    edi,eax      // edi pointe newString
  push   edi          // garder nouvelle adresse
  mov    ecx,[esi]-$4 // compteur copy
  mov    dl,Sb        // remise Char
  @Copy:
  mov    al,byte ptr[esi]
  inc    esi
  cmp    al,dl
  je     @SCopy
  mov    byte ptr[edi],al
  inc    edi
  @SCopy:
  dec    ecx
  jnz    @Copy
  pop    edi         // remise adr
  pop    eax         // rappel Result
  call   System.@LStrClr // déréférencement
  mov    [eax],edi   // place Résult
  pop    edi
  pop    esi
end;

A Tester car fait rapidement ! Salut à toi Gilbert...

[Gilbert Geyer]

Bonjour,

A Eric Eric Boisvert et à Rekin85 : OK je vais tester vos routines.

A Eric : J'avais retenu la boucle for car je pensais qu'une boucle repeat ou une while qui nécessitent un test à chaque tour ralentirait la cadence.

A Rekin85 "Le setlength coûte cher" : exact c'est la raison pour laquelle j'avais ajouté l'exemple de code d'utilisation RichEdit1.Text:=SupprCharV2(RichEdit1.Text,#09); en conséquence duquel le SetLength n'est activé qu'une seule et unique fois quel que soit le nombre de lignes présentes dans le RichEdit (Faudrait surtout éviter d'appeler SupprCharV2 dans une boucle pour faire un traitement ligne après ligne).

Mais je vais de suite passer aux tests.

A+.

[Gilbert Geyer]

Re-bonjour,

Voici les resultats des tests effectués en chargeant le même fichier de tests de 6,878 Mo d'hier dans un RichEdit : trois tests pour chacune des solutions :

- SupprCharV4 mis : 2859 ms, 2875 ms, 2875 ms (Rekin85)
- SupprCharV3 mis : 2890 ms, 2844 ms, 2828 ms (Eric Boisvert)
- SupprCharV2 mis : 2875 ms, 2860 ms, 2860 ms (G.G)

Les résultats sont très voisins et l'on peut se demander si les petits écarts proviennent des différences des codes ou plus simplement du fait que Windows prend la main entre-temps pour effectuer une tâche en arrière plan.

Je m'attendais à ce que l'Asm de Rekin85 allait se démarquer mais on se rend compte que les PChar sont bien optimisés.

En tous cas Aqs n'a que l'embarras du choix.

A+.

[Droïde Système7]

Bonjour,

Très intéressante cette partie d'optim

En effet, j'avais déjà lu et testé que contrairement aux idée reçues, l'Asm n'était pas toujours une Ferrari.

Au fait Gilbert, puisque je viens de tomber des nues au niveau de mon mur de feu, qui me joue des tours déplaisants (*), je me demandais si tes résultats étaient encapsulés avec une ou des applis tournants style mur de feu ou assimilé, sur ton PC. Car logiquement ça influe.

Merci de tes essais et tes codes

@+

(*) :
Il fait planter un programme en testing, car le temps de création d'un fichier, le mur de feu analyse ce dernier. Mais entre-temps le programme ne trouve pas son fichier et...

[Gilbert Geyer]

Salut Droïde,

En effet, j'avais déjà lu et testé que contrairement aux idée reçues, l'Asm n'était pas toujours une Ferrari.

... exact, il y a des cas de figure où les ingrédients de base de Delphi sont tellement optimisés qu'on s'en mord les dents en essayant de faire mieux avec l'Asm mais dans d'autres cas on y gagne parfois. (Bien qu'étant nul en Asm j'ai pu le constater en testant des codes pondus par un pote).

je me demandais si tes résultats étaient encapsulés avec une ou des applis tournants style mur de feu ou assimilé, sur ton PC. Car logiquement ça influe.

... J'ai en arrière plan uniquement Windows et Avast qui peuvent piquer la main. Mais en faisant 3 tests avec chacune des solutions on peut se faire une idée et comme dans le cas présent les écarts entre les résultats sont serrés dans un mouchoir de poche je n'ai même pas fait la moyenne des trois.

mon mur de feu, qui me joue des tours déplaisants ... Il fait planter un programme en testing, car le temps de création d'un fichier, le mur de feu analyse ce dernier. Mais entre-temps le programme ne trouve pas son fichier et...

... et avec des Application.ProcessMessages; placés au bons endroits, ça n'y change rien ?

A+.

[Droïde Système7]

Gilbert,

... et avec des Application.ProcessMessages; placés au bons endroits, ça n'y change rien ?

Pas bête, mais non, pas pensé. Quoique pour seulement le testing, je ne vais pas beurré mon code (ProcessMessages, qui fait dressé les cheveux de certains ), à divers endroits.

Mais si un jour, tu as la curiosité de neutraliser ponctuellement tes protects ; tu en seras certainement étonné, voire même sur les fesses

@+

Par cuirosité, faudta tout de même, que je teste avec ton ProcessMessages.

[Gilbert Geyer]

Re-salut,

ProcessMessages, qui fait dressé les cheveux de certains ), à divers endroits

... en fait j'ai dit "placés au bons endroits" au pluriel car il faut tâtonner pour trouver le ou les meilleurs endroits en espérant qu'un seul bien placé résolve le problème et en virant tous ceux qui ne servent à rien ainsi cela ne fera dresser les cheveux à personne.

A+.

[Gilbert Geyer]

Re-salut,

A Droïde :

car le temps de création d'un fichier, le mur de feu analyse ce dernier. Mais entre-temps le programme ne trouve pas son fichier et...

... Autre idée tu peux essayer de rendre le crétion de fichier prioritaire avec ceci que j'ai trouvé je ne sais plus sur quel site :

Pour changer la priorité de l'application
ex : lancer Prio($80) pour la placer en priorité haute, et Prio($20) pour revenir à une priorité normale.
Cela "peut" accélérer certains processus

procedure Prio(const PriorityClass : Cardinal);
var hProcess, pid : Cardinal;
begin
pid := GetCurrentProcessId();
hProcess := OpenProcess($40, true, pid);
SetPriorityClass(hProcess, PriorityClass);
CloseHandle(hProcess);
end;

dwPriorityClass : valeurs

HIGH_PRIORITY_CLASS : pour tâches à executer immediatement. : $80 = 128

IDLE_PRIORITY_CLASS : pour tâches à exécuter lorsque le système est désoeuvré. (sauvegarde d'écran par exemple ) : $40 = 64

NORMAL_PRIORITY_CLASS : pour process sans besoin spécial : $20 = 32

REALTIME_PRIORITY_CLASS : pour process à executer avec la plus haute priorité possible y compris face à des opération du système : $100 = 256

... Peut-être que Prio($100) rendrait la création de ton fichier prioritaire face à ton mur de feu. Ca coûte rien d'essayer.

A+.

[Droïde Système7]

Re Gilbert

Merci, merci pour toutes tes attentions

Mais puisque je sais que mon mur de feu flanque de b*****, je l'ai à l'oeil le coquin

En plus je ne dois pas ajouter du code, rien que vis à vis de ma configuration perso. En plus que lors du testing issu de l'EDI / compil.

Aller, pardon à tous de cet aparté.

[Rekin85]

Bonjour Gilbert

Voici ma solution asm repensée, mais je crains qu'elle n'apporte aucun gain significatif

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
function SupprCharV5(Const S: string; CharSuppr : Char): String;
asm
  push   ebx                       // registres de travail
  push   esi
  push   edi
  push   ecx                       // empiler adresse retour
  mov    ebx,edx                   // garder Char
  mov    esi,eax                   // esi pointe S
  mov    eax,[esi]-$4              // eax = length(S)
  add    esi,eax                   // esi pointe fin S + 1
  mov    ecx,eax                   // ecx = itérations comptage
  @compteur:                       // compteur des Char à supprimer
    dec    esi
    cmp    byte ptr[esi],bl        // chr = Char ?
    jne    @non
    dec    eax                     // si oui, décrémente longueur de S
    @non:
    loop   @compteur
  call   System.@NewAnsiString     // demander nouvelle chaîne de eax long
  mov    edi,eax                   // edi pointe newString
  pop    eax                       // rappel Result
  call   System.@LStrClr           // déréférencement
  mov    [eax],edi                 // place Nouvelle Str en Result
  mov    ecx,[esi]-$4              // compteur copy
  @Copy:                           // Copie de la nouvelle Str sans Char
    mov    al,byte ptr[esi]
    inc    esi
    cmp    al,bl
    je     @SCopy
    mov    byte ptr[edi],al
    inc    edi
    @SCopy:
    loop   @Copy
  @fin:
  pop    edi
  pop    esi
  pop    ebx
end;

Elle fait le même boulot que la V3 avec les PChar, mais si elle évite les Setlength, elle ne peut se passer de la création d'une nouvelle châine avec déréférencement de l'ancienne (pour éviter les fuites). Ce qui fait que le temps est pratiquement équivalent...

Les PChar sont une survivance de l'ancienne époque où Delphi gérait ses chaînes comme du C... Ceux qui savent s'en servir sont très proches du raisonnement asm.

[Gilbert Geyer]

Re-salut,

A Rekin85 : Résultats des tests de SupprCharV5 dans les mêmes conditions que les test précédants :

SupprCharV5 mis : 2812 ms, 2814 ms, 2813 ms

à comparer aux résultats de toute à l'heure pour la V4 :

SupprCharV4 mis : 2859 ms, 2875 ms, 2875 ms

On gagne environ 60 ms avec la version 5 soit 2 pour-cent.

Par contre comme elle évite les SetLength on gagne la possibilité de pouvoir l'utiliser le cas échéant dans une boucle pour un traitement ligne par ligne d'une partie d'un texte.

Sur ce, bon week-end.

A+.

Au fait je réalise Rekin85 : Salut René (... et mille excuses si je me trompe d'interlocuteur)

[Rekin85]

Oui c'est bien René
A Plus Gilbert

[Eric Boisvert]

Je veux pas parraître insistant mais c'est possible de
faire encore un peu mieux en utilisant SetString

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
{$O+}
Function SupprCharV3(Const S: String; CharSuppr: Char): String;
Var
  Transf: integer;
  pIn, pOut, pStop: Pchar;
Begin
  If s = '' Then Exit;
  Transf := Length(s);
  SetString(Result, Nil, Transf);
  pStop := @s[Transf];
  pIn := @S[1];
  pOut := @Result[1];
  Transf := 0;
  Repeat
    If pIn^ <> CharSuppr Then
    Begin
      pOut^ := pIn^;
      inc(Transf);
      inc(pOut);
    End;
    inc(pIn);
  Until (pStop < pIn);
  SetLength(Result, Transf);
End;

Faudrait selon moi, utiliser les registres spéciaux du cpu en asm
pour faire mieux que Delphi avec l'optimisation à ON.

[Rekin85]

SetString ! Mais bon sang mais c'est bien sûr ! La notification d'une nouvelle string sans copie... L'erreur que j'ai faite dans ma solution asm est de faire compter les suppressions a priori, ce qui revient à pratiquement recopier tout dans le vide une fois de plus... il est moins coûteux en temps de demander une string de même longueur qu'au départ, de la remplir sans les suppressions en les comptant au fur et à mesure puis de demander une petite rectification de longueur à la fin.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 Edit 4/08 code foireux

Là, c'est nettement plus optimisé !

[Rekin85]

Décidément, je ne maîtrise pas le SetLength appelé directement ! Ma solution approche de peu la célérité de celle de Eric Boisvert mais ne fait pas mieux... Alors les registres spéciaux ?

L'asm proposé ici n'apporte rien de significatif, désolé...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
function SupprCharV8(Const S: string; CharSuppr : Char): String;
var NewL: longword; Chr: byte;
begin
  asm
     push   esi
     push   edi
     mov    Chr,dl                    // garder Char
     mov    esi,eax                   // esi pointe S
     mov    eax,[esi]-$4              // eax = length(S)
     call   System.@NewAnsiString     // demander nouvelle chaîne de eax long
     mov    edi,eax                   // edi pointe newString
     mov    eax,ebx                   // rappel Result
     call   System.@LStrClr           // Déréférencement
     mov    [eax],edi                 // nouvelle chaîne en Result
     mov    ecx,[esi]-$4              // compteur copy
     mov    edx,ecx                   // décompteur longueur
     @Copy:                           // Copie de la nouvelle Str sans Char
        mov    al,byte ptr[esi]
        inc    esi
        cmp    al,Chr
        jne    @SCopy
        dec    edx
        loop   @Copy
        jmp    @fin
        @SCopy:
        mov    byte ptr[edi],al
        inc    edi
        loop   @Copy
     @fin:
     mov    NewL,edx
     pop    edi
     pop    esi
  end;
  SetLength(Result,NewL);
end;

[Droïde Système7]

L'asm proposé ici n'apporte rien de significatif, désolé...

Oui mais est-ce qu'un antivirus ou autre qui automatiquement analyse tout fichier lancé ; entre en ligne de compte ou non ?

Car le temps d'analyse de la souche par rapport aux bases, ça grignote quelques ms, non ?

Si oui, alors toutes les mesures sont faussées.

Surtout lorsque le mot "asm" est détecté au scan...

[Eric Boisvert]

Alors les registres spéciaux ?

Et bien disons que je ne maitrise pas l'assembleur
à ce point. Le domaine est très pointu. En plus,
qui dit registres spéciaux dit dépendant du CPU...
Intel=> MMX,SSE
AMD=> 3DNow

En plus, avec mon Delphi 5, faut tout convertire en
DB car plusieurs instructions ne sont pas reconnues.
(Et ça, c'est loin d'être évident à faire à la main!)
M. Sibert à écrit un article intéressant sur une technique de
prefetch
http://esibert.developpez.com/delphi/prefetch/

une recherche sur FastCode avec google te donneras probablement
des idées.

Ici (en anglais) on traîte seulement de l'optimisation asm des CPU Intel.
Il y a plein de contraintes et de choses à s'avoir pour bien exploiter
la cache, le pipeline (U-pipe et V-pipe), l'enlignement du data et du code, etc
http://www.tcs.informatik.uni-muench..._optimise.html

l'utilisation de Loop n'est pas toujours plus rapide que Dec(ECX) et jnz

Alors pour plein de raison comme celle là, j'essaie toujours d'optimiser à fond
en pascal...et bien souvent... c'est suffisant.

Surtout lorsque le mot "asm" est détecté au scan..

Je ne saisie pas bien cette remarque. Simplement qu'une fois compilé,
tout programme est transférer en opcode cpu, et donc en asm.

Les anti-virus utilise habituellement un system de notification de
changement sur les disques locaux pour détecter la création et/ou
la modification de tout fichier pour permettre
un scan en temps réelle de tout nouveau fichier.
(see ReadDirectoryChanges)

Finalement, c'est quand même certain qu'il y a moyen de faire mieux
que Delphi en asm... mais c'est hors de ma porté et de la plupart des gens
selon moi.

[Rekin85]

Envoyé par Eric Boisvert :
Finalement, c'est quand même certain qu'il y a moyen de faire mieux
que Delphi en asm... mais c'est hors de ma porté et de la plupart des gens
selon moi.

Je ne suis pas assez spécialiste de l'asm : je ne "finasse" que du code X86 sous Delphi et malheureusement, il y a des impondérables du compilateur qui font que souvent je suis obligé de faire du "mixte" asm-pascal pour m'en sortir. Dans le cas présent, il est impossible de faire call System.@LStrSetLength depuis un bloc asm sans déclencher une V.A. Pourquoi ? Mystère pour moi... un élément m'échappe. Alors je suis obligé de "sortir le SetLength du bloc, et là on n'optimise pas plus... L'emmerde pour ces routines de manipulations de chaînes en asm c'est de se "battre" avec le fichu gestionnaire des variables de Delphi. Et même avec les registres spéciaux, c'est toujours l'embrouille pour ne pas déclencher de V.A. ou de fuite mémoire... C'était mieux du temps des chaînes AZT.

N.B. Mon code asm est normalement compilable sans problème sous D5

[Eric Boisvert]

il est impossible de faire call System.@LStrSetLength depuis un bloc asm

Pourtant tu y était presque...
Le problème c'est que tu mettais dans edx la longueur initial de la chaine
et que tu le décrémente chaque fois que al<>bl....
à la limite, si le char à éléminer dans la string est non trouvé, tu
termine avec edx à zéro....

j'ai simplement corrigé ton code ici et le SetLength est bien
appeler en asm

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
 Code foireux! 
 voir V10

PS: Il y a un toujours un probleme avec call System.@NewAnsiString,
ont pert de cette facon le result.

N.B. Mon code asm est normalement compilable sans problème sous D5

Effectivement, et c'est justement le problème, il y a maintenant
des instructions asm que le compilateur n'utilise pas et qui sont
plus rapide dans certaine condition. Faudrait alors inclure un bloc asm
à coup de DB avec les bon opcodes
Exemple de M.Sibert:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
procedure Prefetch(p : pointer); register;
asm
  DB $0F,$18,$90,$00,$01,$00,$00  //prefetchT1 byte ptr [eax]+256
end;

Ça devient vite incompréensible et c'est impossible à maintenir
à grande échelle. Donc, avant de coder quelque chose en asm,
faudrait que cette petite routine soit critique et qu'elle soit appelé
plusieurs fois / sec avant que je m'y attaque pour sauver quelques
cycles CPU.

[Gilbert Geyer]

Bonjour,

Ayant remarqué que cette discussion continue, mais étant nul en Asm,
j'ai au moins testé la dernière version de SupprCharV5 (en fait SupprCharV5Bis) avec le fichier de tests habituel de 6,878 Mo :

SupprCharV5 mis 3375 ms, 3359 ms, 3359 ms

alors qu'avec :

SupprCharV8 mis 2859 ms, 2844 ms, 2860 ms

(Pentium III à 1,13 GHz)

N'ayant pas pigé comment on utilise le procedure Prefetch(p : pointer) le test de SupprCharV5 n'est peut-être pas significatif.

A+.