COMPARER LES INSTRUCTIONS CASE OF, IF THEN ET IF THEN ELSE

Commentaire de jmp77 le 17/02/2005 21:32:32

Super initiative japee je testerais cela demain.

Pourrais tu juste préciser la version de delphi que tu as? Car je me souviens d'une reponse qui disait que a partir de delphi 7 les case of etait gérée pas dichotomie alors a verfier.

JMP77.

Commentaire de jmp77 le 18/02/2005 09:40:30

Nickel je viens de compiler avec Delphi 6 et le résultat est sans appel :
Case : 14ms
If then : 140 ms
If then else : 75 ms.

Une grande victoire du case qui me rassure.

Encore merci à toi pour ce superbe programme de test. Et ouais je pense que ca serait sympa d'en faire une machine a tester c'est toujours tres utile.

Au fait note finale : 10/10 pour moi.

Commentaire de MAURICIO le 18/02/2005 11:13:11

Je suppose que ces résultats sont similaires qques soit la nature de la comparaison char/byte/integer/word/int64 etc ...

Commentaire de ManChesTer le 18/02/2005 16:49:14 administrateur CS

essaye ca :
procedure TForm1.Way1Array(i: Byte);
const MyProcs : Array [0..59] of Tprocedure =
      (Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,
       Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,
       Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,
       Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,
       Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,
       Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien,Rien);
var
  j      : LongInt;
  h      : Word;
begin
  h := GetTickCount;
  for j := 0 to MaxBoucle do
   MyProcs[i];
  h := GetTickCount - h;
  Memo4.Lines.Add(IntToStr(h));
end;

Bon Coding....

ManChesTer.

Commentaire de grandvizir le 18/02/2005 20:38:42

Japee: ce code est... il est... pouf... Comment dire ? Peut-être très sûrement génial pour l'évolution des connaissances sur Delphifr (sans aucune ironie cachée!).

Mais pour l'exécution des tests, il faut prendre toutes ses précautions:
1) Générer les EXE dans différentes versions de Delphi.
2) Rebooter le PC pour vider la RAM et surtout pour killer le "Delphi's memory thread effect" (si je peux m'exprimer ainsi, car il ne faut pas croire, Delphi gruge la RAM)
3) Stocker les résultats dans des TStringList, car les affichages du mémo sont du temps de perdu et fausse l'analyse.
4) Threader à haute priorité (la plus haute, au même niveau que les threads multimédia) les 3 procédures afin de leur donner le flux maximal et moins indépendant d'autres processus

Au passage, 3 fichiers inutiles dans le ZIP ;)

Remarque à propos du ELSE IF avec D5. Nous avons la suite suivante:
206 - 214 - 253 - 272 - 301 - 320- 341 - 353 - 385 - 392 - 423 - 438 - 465 - 476 - 508 - 516 - 550 - 554. Elle est à peut près linéaire pour les 20 premières tentatives successives et la modélisation donne "T = 21 * x + 209", où T est exprimé en ms, et où X représente la x-ième tentative. Donc elle est certes rapide, mais nécessairement facteur de ralentissement du PC.

Je donne mes tests (même si vous en avez déjà faits). Je choisis "10 millions" pour minimiser statistiquement les écarts liés par exemple à des co-traitements du processeur, tels un mouvement de souris, une activité multimédia ou un scan antivirus, et surtout parce que je n'ai pas que ça à faire non plus. On essaye de travailler dans un petit environnement clos pour calmer le jeu.
D3: 58 - 273 - 158
D5: 58 - 277 - 157
D7: 58 - 274 - 158
Après avoir joué successivement avec les versions, je reboote et lance le teste D7 et: 58 - 275 - 156.

Là je conclus que les tests sont cohérents et que D3 est mon ami... Où est donc l'évolution apportée par Delphi 7 ?? Hein... A moins que je ne confonde avec quelque chose d'autre.

Reste à voir deux choses:
1) L'enchaînement des procédures a-t-elle une importance ?
2) Que dire du "Case avec des string" par rapport à des IF ? Quelqu'un avait fait un code sur Delphifr (je ne donne pas de nom, mais je crois quand même me souvenir qui c'était).

En conclusion, Japee va pouvoir nous implémenter tout ça, histoire de voir ce que ça donnera.

Commentaire de ManChesTer le 18/02/2005 21:08:37 administrateur CS

heuu kenavo, tu change rien a ma technique, c normal que si tu utilise un dword en entrée c'est plus rapide, delphi 32 est en 32bits dword aussi.

Bon Coding....

ManChesTer.

Commentaire de japee le 18/02/2005 21:54:01 administrateur CS

grandvizir> je t'ai trouvé plus accomodant que d'habitude avec mon code. T'es pas malade, au moins...  ;)

Sérieusement, je ne pense pas que l'affichage dans les Memo pénalise le test, car il se fait en dehors des boucles.

J'ai précisément fait attention de n'interférer aucunement par un affichage quelconque de la progression etc... pendant la boucle de chaque test.

Pour le reste, faut voir...

Commentaire de japee le 18/02/2005 23:08:22 administrateur CS

Résultats avec une boucle 0 à 50 000 000.

On a maintenant :

case of (1), if then (2), if then else (3), array avec i passé en byte (4), array avec i passé en DWord (5).


i          1         2         3         4         5
_______________________________________________________
0:  |    1035 |    6840 |     995 |     866 |     865 |
1:  |    1035 |    6675 |    1115 |     870 |     870 |
2:  |    1075 |    6760 |    1245 |     865 |     870 |
3:  |    1035 |    6730 |    1325 |     870 |     865 |
4:  |    1080 |    6661 |    1409 |     870 |     865 |
5:  |    1076 |    7525 |    1490 |     870 |     870 |
6:  |    1030 |    6750 |    1570 |     870 |     870 |
7:  |    1075 |    6680 |    1615 |     870 |     870 |
8:  |    1030 |    6695 |    1740 |     865 |     870 |
9:  |    1035 |    6635 |    1820 |     870 |     870 |
10: |    1075 |    6760 |    1900 |     870 |     870 |
11: |    1035 |    6675 |    1986 |     865 |     870 |
12: |    1075 |    6640 |    2025 |     870 |     870 |
13: |    1075 |    7410 |    2110 |     870 |     865 |
14: |    1035 |    6645 |    2235 |     870 |     870 |
15: |    1075 |    6560 |    2360 |     865 |     870 |
16: |    1035 |    6625 |    2485 |     865 |     870 |
17: |    1035 |    6675 |    2605 |     870 |     870 |
18: |    1075 |    6745 |    2730 |     871 |     869 |
19: |    1035 |    6725 |    2815 |     865 |     870 |
20: |    1071 |    6805 |    2895 |     870 |     870 |
21: |    1075 |    7630 |    2975 |     870 |     870 |
22: |    1035 |    6790 |    3060 |     865 |     870 |
23: |    1075 |    6715 |    3105 |     865 |     870 |
24: |    1035 |    6700 |    3225 |     865 |     870 |
25: |    1035 |    6775 |    3305 |     870 |     870 |
26: |    1075 |    6785 |    3390 |     870 |     870 |
27: |    1035 |    6720 |    3475 |     870 |     865 |
28: |    1075 |    6755 |    3515 |     865 |     865 |
29: |    1075 |    7656 |    3599 |     865 |     865 |
30: |    1035 |    6720 |    3720 |     870 |     870 |
31: |    1075 |    6770 |    3845 |     870 |     870 |
32: |    1035 |    6790 |    3970 |     870 |     865 |
33: |    1030 |    6765 |    4095 |     870 |     870 |
34: |    1075 |    6730 |    4215 |     865 |     870 |
35: |    1035 |    6975 |    4305 |     865 |     871 |
36: |    1074 |    6705 |    4380 |     870 |     870 |
37: |    1075 |    7520 |    4465 |     870 |     870 |
38: |    1030 |    6740 |    4550 |     865 |     870 |
39: |    1076 |    6839 |    4585 |     865 |     870 |
40: |    1035 |    6615 |    4715 |     871 |     869 |
41: |    1035 |    6695 |    4795 |     870 |     870 |
42: |    1031 |    6850 |    4880 |     870 |     870 |
43: |    1075 |    6785 |    4970 |     865 |     870 |
44: |    1036 |    6869 |    5005 |     870 |     865 |
45: |    1075 |    7550 |    5085 |     870 |     870 |
46: |    1035 |    6710 |    5210 |     870 |     870 |
47: |    1075 |    6730 |    5335 |     870 |     870 |
48: |    1030 |    6755 |    5460 |     865 |     865 |
49: |    1030 |    6705 |    5580 |     870 |     870 |
50: |    1095 |    6894 |    5705 |     870 |     870 |
51: |    1030 |    6810 |    5765 |     866 |     869 |
52: |    1080 |    6675 |    5835 |     870 |     865 |
53: |    1035 |    7555 |    5955 |     870 |     870 |
54: |    1035 |    6775 |    6080 |     865 |     870 |
55: |    1035 |    6680 |    6155 |     870 |     870 |
56: |    1035 |    6645 |    6205 |     865 |     865 |
57: |    1035 |    6730 |    6330 |     870 |     870 |
58: |    1030 |    6745 |    6450 |     870 |     870 |
59: |     990 |    6685 |    6410 |     870 |     870 |
    |_________|_________|_________|_________|_________|
    |    1051 |    6829 |    3736 |     868 |     869 |

La différence entre i en Byte ou i en DWord est statistiquement inexistante (j'ai fait d'autres tests).

Je pense qu'il doit en être de même avec case of, if then et if then else, mais je vérifierai.

A bientôt pour la mise à jour qui incorporera la procedure avec array et une petite fonctionnalité qui permet de récupérer les résultats dans un fichier txt (vous croyez tout de même pas que je me suis tapé tout ce tableau à la main, si ? :P

Commentaire de Delphiprog le 19/02/2005 10:32:08 administrateur CS

Erratum :
Au lieu de : Alors que le if then saute à la fin de la procédure après exécution de "Rien"

il faut lire :
Alors que le "if ... then  ... else" saute à la fin de la procédure après exécution de "Rien"

Commentaire de Kenavo le 19/02/2005 11:10:29

Salut tout le monde,

Pour voir les différences entre byte et DWord il faut contruire le projet sans l'optimisation du code (dans les options du compilateur). Toutes les méthodes "souffrent" de la non optimisation. Puisque tu aimes comparer, Japee, fais donc l'essai !

Par contre, en comparant les codes assembleur générés par le code de ManChesTer et le case of, il y a une différence qui apparait, c'est que le code de ManChester ne vérifie pas si le paramètre est bien dans les limites [0..59].
La prudence voudrait que l'on écrive :
if i in [0..59] then MyProcs[i];
ce qui ne ralentit quasiment pas les performances, surtout si le code est optimisé à la compilation !

C'est là d'ailleurs une différence essentielle entre case of et if : case verifie avant que le paramètre appartient bien à l'intervalle, alors que if teste toutes les comparaisons sans "réféchir"
Fais tourner ta boucle de 0 à 60, tu verras la dernière ligne est explicite !

Euh, alors, le vainqueur est ManChesTer ! Bravo !


Ken@vo

Commentaire de japee le 19/02/2005 15:23:26 administrateur CS

Delphiprog > Merci pour le 10/10. Je le partage avec l'ensemble des personnes qui participent à ce débat passionnant, et qui le méritent au moins autant que moi.

C'est un des ces moments rares où l'on se sent une communauté qui, dans sa diversité, se retrouve dans une même passion : la belle programmation en Delphi.

Kenavo et ManChesTer > lol, on a pas fini de se "prendre la tête" (dans le bon sens du terme) sur tout ce que vous avez amené au débat, c'est vraiment très intéressant.

Je vérifie la maj qui incorpore la méthode "array" proposée par Manchester et je la poste.

Bonne prog' à tous !

Commentaire de grandvizir le 26/02/2005 21:56:59

Votre ASM me rentre par les trous de nez... Et pour japee: «y'a pas écrit La Poste» sur le front de grandvizir. Si y'a pas grand chose à dire, y'a pas de raisons de "raler". Je t'avais mis d'ailleurs un 10 (malgré la pompe). Et si japee s'amuse à étiquetter ses petits camarades de préjugés virtuels, alors je répond modestement :
  asm
    JNE japee pas content
    JMP Coucou
  @Coucou:
    ECHO On retourne au code source
  end
Ca fait franchement pitié ce petit morceau de détresse, mais l'ASM en overdose, ça fait souvent mal... pas à se rendre malade quand même ?

Commentaire de aafi le 27/02/2005 11:23:24

moi non plus je ne pige pas le sens de l'intervention de Mr "GRAND VIZIR" ;
soyons "positif" comme dit la chanson et Mr raffarin !

le débat ici me semble etre :
a) constater la différence de rapidité entre plusieurs façons de programmer
b) d'expliquer le pourquoi.
c) d'approfondir si possible le sujet, en vérifiant les conditions de l'expérimentation.

si Grand Vizir ne veut pas entendre parler d'ASM, alors il n'arrivera jamais à comprendre le "pourquoi"

Commentaire de aafi le 02/03/2005 21:29:31

les commentaires de Grand Vizir m'ayant titillé et motivé ( amicalement bien sur) , ja'i pris une heure ou deux pour approfondir le sujet
a) il y a un deuxième forum sur un thème identique , à savoir n° ID 393257 "case of VS if then "
( celui ou nous sommes étant le ID 29593)

b) vous y trouverez aussi un commentaire parlant d'assembleur , fait par KENAVO, assez similaire au mien.

c) Grace à GrandVizir , je viens de m'apercevoir que mes certitudes quant au CASE OF ne sont plus totalement vraies avec les DELPHI récents. Voici ce que j'ai constaté sous DELPHI 5 professional ( je n'ai pas les suivants)

en résumé , CELA DEPEND DE ....
** si votre CASE OF énumére des valeurs consécutives , comme dans le cas proposé ( CASE XX Of ... toutes les valeurs de 1 à 50 par exemple ) , alors ce que je dis est vrai ( passage par une table d'adressage)

** si votre CASE OF n'énumère que quelques valeurs, discontinues , alors le compilateur génére en réalité l'équivalent d'autant de IF THEN ELSE que de cas, avec une petite optimisation
exemple :
  CX : char
  case CX of
    'B' : faire ceci ;
    'J'  : faire cela ;
    'L' : faire autre chose ;
    etc ...
   end ;
l'optimisation consiste à ne charger qu'1 seule fois la donnée ( ici CX ) dans le registre A ( ou AX ou EAX ) , puis par un jeu subtil de SUBtract ou Add , de tester simplement avec ZERO ( instruction JZ  Jump si zero )

Or, dans la pratique d'une vraie application, les cas que l'on teste ne sont que rarement des valeurs en séquence continue.
CONCLUSION : dans la pratique, l'écart de performance reste en faveur du CASE OF , mais l'écart devrait etre beaucoup moins important que celui constaté dans le cas d'école faisant l'objet du forum
par contre, la clarté de lecture d'un source en CASE OF est limpide, alors que des IF THEN ELSE imbriqués deviennent vite illisibles.

d) GrandVizir me demande comment je fais pour voir cela :
il est inutile de "Désassembler"
deux possibilités :
** allez dans ..\DELPHI\SOURCE\RTL\SYS\
  vous y trouverez plein de modules en SOURCE, la plupart en ASM ( par exemple OPENFILE.ASM ) et d'autres en Pascal , les 2 principaux étant
SYSTEM.PAS et SYSUTILS.PAS
par exemple SYSTEM.PAS contient des dizaines de routines écrites en Assembleur, par exemple
_COPY ( utilisé  par Copy(STR,pos , long) )  )
ou _POS ( utilisé dans pos('GrandVizir' , Message) )

** quand vous exécutez votre projet dans l' IDE ( via la touche <F9> par exemple ), mettez au préalable un POINT d'ARRET ( BreakPoint in english ) sur la ligne CASE .. OF
puis lors de l'arret, examinez le code assembleur en ouvrant la Fenetre de DEBOGUAGE "CPU" : vous y voyez tout le code ASM généré à proximité de votre CASE OF ( avant et après )
ainsi un CASE OF portant sur un Char avec valeurs continus de 'A' à 'K' (par ex.) se traduit par :
4 instructions de préparation ( XOR , MOV , ADD , CMP )
1 JUMP après le END pour les valeurs supérieures à 'K'
et le fameux JUMP indexé indirect , à savoir :
JMP dword ptr [eax*4+Tform1.Button1Click + $12D ]

la Table d'adressage est ici optimisée, elle n'occupe que N fois 4 octets ( N = 11 pour intervalle "A" à "K" )

NOTA : à vérifier pour DELPHI 6 , ou 7 ou 8 ou 2005 !

Commentaire de aafi le 02/03/2005 22:59:28

SUITE ... SUITE ....
( si je vous emm... dites le .... )

en tripatouillant le code à JAPEE, dans la routine WAY1 , amusez vous à supprimer quelques valeurs ( en les mettant en commentaires ) , ou en les énumérant dans un autre ordre ; l'examen de la fenetre CPU montre que ca ne change rien au principe.

par contre si vous supprimez plus de 52 valeurs ( en en laissant moins de 8 ) , alors vous voyez le code assembleur changer.

je modifie donc mes conclusions ainsi :
* ce n'est ni l'ordre d'énumération, ni la présence de discontinuités , qui dirige le compilateur DELPHI.
* DELPHI semble, au final, déterminer le nombre d'items dans le CASE , et il génére :
==> soit l'équivalent de IF THEN ELSE  lorsqu'il y a seulement 1 à 7 valeurs
==> soit la méthode de la Table d'Adressage, pour 8 et plus.

j'en déduit que les ingénieurs de BORLAND ont soigneusement chronométré les routines, et qu'ils considérent que la table d'adressage équivaut au temps processeur pris par environ 7 IF THEN
ET L'ON RETROUVE ICI LE RATIO EXPERIMENTAL du programme à JAPEE  .  CQFD !!!

Commentaire de grandvizir le 03/03/2005 12:45:44

Merci aafi pour toutes ces précisions ;). Je ne voulais pas être caustique avec vous, mais on ne peut pas être performant en tout, surtout avec l'ASM qui est d'un niveau bien plus puissant que Delphi, lequel n'a rien à voir avec ASM. La relecture de 29593 et de 393257 est intéressante, c'est pour cela que ça se tient très bien...

Commentaire de jinh68 le 03/03/2005 15:55:04

En fait, tout le monde est d'accord avec toi je pense, mais là n'est pas l'intérêt.

L'optimisation a toujours été un "sport" chez les développeurs et relève d'une compréhension approfondie du fonctionnement d'un processeur.

Donc pour l'utilisateur, aucun intérêt, mais je ne pense pas que tu développes juste pour lui.Après cela dépend bien sûr de ta vision, mais personnellement j'aime toujours en apprendre plus.

Tu dis que 10 secondes n'est rien, mais c'est comme dans tout domaine, la compétition fait avancer les esprits et affûtent les compétences ;).

Commentaire de jinh68 le 03/03/2005 18:25:48

Oui excuse moi pr la durée :).En fait il y'a effectivement des instructions propres à certaines architectures, mais les instructions de base depuis le 8086 sont acceptées partout.

@+ :)

Commentaire de aafi le 03/03/2005 18:50:58

Etant en arrêt pour cause d'accident de ski, je suis condamné à bosser sur ce passionant sujet, plutôt que me vautrer devant une Télé stupide ! Donc, en revenant au forum ID 29593, j'y trouve quelques pistes non explorées :
* quelqu'un demande ce qu'il en est si on teste sur un Integer
* un autre se souvient qu'il aurait lu quelque part que Delphi7 ferait de la "Dichotomie" avec un CASE OF , et l'ami JAPEE lui répond que cela lui semble impossible.
Moi aussi, j'aurai répondu idem en 3 secondes, mais en y réfléchissant, je me dis que ce n'est pas aussi idiot , et que nos super ingénieurs de Borland sont bien capables d'avoir fait la chose ...
Donc, dans le prog à JAPEE, je fait une proc "Way1bis" , ou je transforme I en un integer XI, puis fait un CASE XI OF , sur des valeurs non contigües de 0000 à $3B0 ( soit 60 fois 16) , espacées de 16 (au lieu de 1)
Et merveille, je constate qu'il y a bien DICHOTOMIE dans ce genre de cas : DELPHI génére une série de tests genre  caractéristiques d'un arbre dichotomique.
Ca débute par 4 tests découpant l'intervalle demi-bas :
    IF valeur >= $1E0
    IF valeur >= $0F0
    IF valeur >= $070
    IF valeur >= $030
puis dans chaque rameau final, 3 tests consécutifs du style
        IF valeur = $040  ...
        IF valeur = $050  ...
        IF valeur = $060

Au final, pour 60 cas , le nombre de tests se retrouve etre au plus de  14 tests ( soit 7 tests >    et 7 tests = )

le résultat chiffré est assez éloquent :
  Moyenne 33 , au lieu de 23 pour le CASE sur 1 byte de la routine JAPEE originale
  Variations de 21 à 38 , ce qui est logique, puisque le nombre de tests varie de 2 (dans le meilleur cas = $1E0  à 14 pour les cas les plus éloignés des valeurs dichotomiques)

ce résultat est par ailleurs bien meilleur ( 4 fois environ) que des IF THEN ELSE ( routine Way3 ), ce qui est assez extraordinaire !

Quelqu'un peut il me dire ou / comment UpLoader mon source "JAPEE modifié" ?  pour ceux qui veulent l'examiner ?

PS : Je fonctionne sous DELPHI5, et donc ça doit être valable pour les suivants D6 et D7

Commentaire de aafi le 03/03/2005 19:57:25

Derniere contribution,  sur les doutes émis sur l' ASM
a) je ne programme plus en ASM depuis belle lurette, mais la connaissance de l'ASM est un plus pour comprendre ( si vous avez suivi un cours de Mécanique Automobile, vous n'êtes pas obligé de mettre les mains dans le cambouis tous les jours, mais vous ne vous ferez pas niquer pas votre garagiste)

b) comme je l'ai dit précédemment , environ la 1/2 des routines de l'unité principale SYSTEM sont écrites en Assembleur ; alors, si c'était "DANGEUREUX" comme le suggère quelqu'un, alors vite mettez votre DELPHI à la poubelle !

c) un programme ou une routine écrite en ASM à l'époque héroique des processeurs 8 bits (Z80) ou 16 bits (Intel 8086) fonctionnera toujours sur votre super-machin ATHLON 64 bits  ( sous réserve des "Entrées/Sorties bas niveau" et des "interruptions" )
MAIS l'INVERSE N'EST PAS VRAI !
DELPHI et consorts usent et abusent des instructions sur registres 32 bits ( EAX par exemple), et des super instructions en Virgule Flottante  disponibles sur les processeurs récents.
d) faire soi-même quelques lignes d' ASM au sein d'une unité DELPHI, c'est très risqué si on est un gros débutant , en général le résultat est un beau plantage du genre "Violation d'espace mémoire"
e) je n'ai eu l'occasion de faire de l'ASM que 2 ou 3 fois, uniquement pour optimiser  des traitements sur des Strings, pour remplacer des boucles du style FOR X=1 to length(MonString) ....

Commentaire de aafi le 04/03/2005 09:33:23

On dévie subtilement sur un autre sujet, ne faudrait-il pas ouvrir un autre thème de forum ?
L'usage de quelques lignes d'ASM incorporé en "InLine" dans un projet DELPHI ( d'ailleurs DELPHI8 ou D2005 ont ils toujours cela ??? ) pour la frameWork .NET (DOTNET)  , voire meme un programme complet en ASM, cela va t il devenir une galère pas possible comme semble le promettre DelphiProg ?
J'EN DOUTE FORTEMENT , et comme indices vite fait glanés sur le Web :
a) pourquoi Microsoft développerait-il une version 64 bits de son assembleur MASM ==> voir masmforum.com
b) par principe fondateur, tous les languages pourront à terme être incorporés dans .NET ( VB, Php, Java , Cobol, Fortran, etc ...)
c) pourquoi le C# ( CSharp ) inclus dans Visual Studio for .NET ( toujours de Bill gates) offre t il la possibilité de faire de l'Assembleur InLine, de manière quasi-identique à delphi ==> instruction _asm { .... }

voir un exemple ici : http://www.codeproject.com/csharp/unmanage.asp

L'influence de la notion de "Code managé" ou non managé , j'attend d'en comprendre les contraintes pratiques...

voir ici une présentation fort claire (et in French) :
==> http://www.dotnet-fr.org/documents/andy_faqdotnet_fr.html

je suggère au modérateur d'ouvrir un autre forum sur ce thème.

Commentaire de MAURICIO le 04/03/2005 11:47:23

Ça y est, je me rappelle de ce que je voulais dire:
la REUTILISABILITÉ !!!!!!!!!!!!!!!!!!!!!!!!!!
Bon, j' arrête mes conneries.
Les limites à l' optimisation est celle lorsqu' on porte préjudice à la réutilisabilité/compatibilité.
A+

Commentaire de aafi le 04/03/2005 18:44:48

Bravo MANCHESTER ! d'apporter de l'eau au moulin dans le meme sens que moi :

a) de ramer à contre sens de ceux qui s'imaginent que la "Portabilité" et la "Reutilisabilité" serait le monopole des languages de "haut niveau" , et que les languages plus au raz des paquerettes ( l'ASM , le Forth par exemple) en seraient exclus comme des pestiférés

b) de donner envie aux curieux d'aller voir le "VisualASM" , et qu'avec des bibliothèques et macros ad-hoc, on arrive à un niveau agréable.

c) d'affirmer que l'ASM est parfaitement utile dans certains problèmes , qu'il faut l'utiliser à bon escient et aux endroits critiques sans en abuser cqfd.

le seul qui te fusillera, c'est INTEL qui ne pourra pas vendre aussi facilement son P5 20gigaHz !

Commentaire de Delphiprog le 05/03/2005 08:10:44 administrateur CS

Extrait de la documentation livrée avec Borland Delphi 8:
"Présentation de la syntaxe assembleur (Win32 uniquement)

L'assembleur en ligne est disponible uniquement dans le compilateur Delphi Win32. Les rubriques suivantes décrivent les éléments nécessaires à une utilisation correcte de la syntaxe assembleur.
"
Cela a le mérite d'être sans équivoque.

Commentaire de Delphiprog le 05/03/2005 09:40:04 administrateur CS

A la proposition "a", la réponse est : oui.
Le compilateur de Delphi, tout comme celui de tous les langages pour .Net produit du CIL (Common Intermediate Language). Ce code ne sera traduit en langage machine qu'au moment de l'exécution finale par le CLR (Common Language Runtime) pour donner du code binaire en fonction du processeur utilisé à ce moment là. On peut d'ailleurs faire un parallèle avec le code produit par les compilateurs Java qui n'est qu'un code intermédiaire traduit, lui aussi, par la JVM au moment de l'exécution.

A la proposition 'b' : la réponse est non. Cela est dû aux spécifications de la plateforme .Net. Il n'y a donc aucun espoir à avoir et les applications contenant du code ASM devront être revues pour être acceptées sous .Net.

Le côté positif de la chose, c'est qu'un code écrit avec un langage .Net devrait (notez la prudence des propos) pouvoir s'exécuter sur les plateformes Linux grâce au framework Mono (l'équivalent du Microsoft .Net  framework sous Linux).
Vous comprendrez alors mieux pourquoi Kylix n'évoluera plus.

Commentaire de ManChesTer le 05/03/2005 18:10:53 administrateur CS

Lol, faut lire CLI pas CLR qui est le runtime en question...

Bon Coding....

ManChesTer.

Commentaire de aafi le 06/03/2005 09:39:25

Voila, c'est fait ,
j'ai ouvert un message n° ID=406173 intitulé
DOTNET (.NET) : Utilité, Avantages, Contraintes

dans le thème DIVERS

j'espère avoir correctement traduit les intérrogations posées,
et j'espère ne pas vous avoir trahi !!!

Delphi#
******

Commentaire de grandvizir le 16/03/2005 13:42:10

================
Je voulais aussi repréciser une chose sur la vitesse d'analyse des conditions via la directive de compilation $B, qui est dans l'état $B- par défaut. Avec D3, on a ce qui suit:

AVEC B-:
   CaseOfEnd: 28
   IfThen: 138
   IfThenElse: 77
AVEC B+:
   CaseOfEnd: 30
   IfThen: 157
   IfThenElse: 85

================
Dans l'aide, voici ce qu'on peut lire:

La directive $B permet d'alterner entre les deux modèles de génération de code pour les opérateurs booléens and et or.

En mode {$B+}, le compilateur génère un code évaluant entièrement les expressions booléennes. Tous les opérandes des expressions booléennes contenant des opérateurs and et or sont alors évalués, même si le résultat de l'expression totale est déjà connu.

En mode {$B-}, le compilateur génère un code d'évaluation "court-circuit" des expressions booléennes. Cela signifie que l'évaluation s'arrête à partir du moment où le résultat de l'expression devient évident dans l'ordre d'évaluation de gauche à droite.

Pour plus d'informations, recherchez "opérateurs booléens" dans l'index de l'aide du langage Pascal Objet.

================
On peut alors se poser la question du pourquoi Delphi propose un mode $B+.

Commentaire de Kenavo le 16/03/2005 15:19:33

Grandvizir,

$B+ peut avoir son importance ! Prends par exemple cette boucle :

while fonction1 and  fonction2 do
begin
  .....
end;

où fonction1 et fonction2  sont deux fonctions booléennes. Si tu veux être sur que les deux fonctions soient  exécutées un même nombre de fois - pour une raison ou pour une autre - la directive $B+ est indispensable. Si fonction1 est fausse la première, elle aura été exécutée et fonction2 ne le sera pas !

Ken@vo