compilation en DELPHI 2009

C'est juste un éclaircissement que je voudrais avoir sur le natif obtenu (exe) après compilation en 2009.
Comme on a ajouté beaucoup de "fioritures" (sans être péjoratif) surement nécessaires (génériques, ce qui m'enchante, du reste... et autres), qu'en est-il de l'exe obtenu, est-il aussi performant qu'avec les versions précédentes?, n'a-t'il pas changé ou amélioré.
Que le temps de compilation soit plus grand qu'en D2007, pourquoi pas, mais il ne faudrait pas qu'il produise un natif dégradé.

De plus, pour un même calcul scientifique, quel est le + rapide en tps d'exécution entre delphi 2009 et C++ builder?

Merci d'avance,

Fred

Deux fonctions faisant la même opération en asm et pascal:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

function SumAsm(N: integer):integer; asm Mov ecx,eax mov eax,0 mov ebx,0 @loop : add eax,1 cmp eax,ecx jl @loop mov Result,eax end; ... function SumFor(N : integer): integer; var i : integer; begin result := 0; for i:= 1 to N do begin result := result + 1; end; end;

---

Merci pour ta réponse mais mon problème était autre.
Je voulais savoir si on ne perdait pas en execution en passant en D2009.
Y a-t'il eu une amélioration dans l'objet obtenu.
De plus, C++ builder est-il plus rapide que Delphi en général ? ou les 2 produisent-ils le même objet compilé ?

Merci pour réponse,

Fred

L'exemple est trivial, je l'accorde, mais quand je fais le comparatif de ces deux méthodes sur plusieurs millions d'itérations en comparant Delphi 2009 et le code assembleur, il y a un pouième de différence.

Suggestion :D: Delphi et C++ builder peuvent executer du code assembleur, il suffit de comparer ... pour vérifier par soi-même.

Autre point intéressant, la façon dont la fonction est écrite peut conduire à des temps très différents, qui n'a rien à voir avec le langage mais simplement la façon dont on fait usage des possibilités du langage.

L'exemple le plus interessant, c'est de comparer les boucles "for in"(foreach en C#) et "for". Dans le cas de boucles imbriquées, mieux vaut être sûr de ses choix.

Je vous remercie pour votre réponse Chaplin mais mon problème est ailleurs (peut-être et sûrement me suis-je mal exprimé).
Je prends l'exemple de VS C# où on a essayé de faciliter la vie du développeur en introduisant le GC, le JIT et en compilant en MSIL et non en natif ce qui a provoqué une dégradation du temps de calcul des programmes scientifiques.
Je voulais juste savoir Delphi 2009 tout en compilant en natif et en se concentrant sur les nouvelles approches (provenant du .Net) ne produisait pas un natif moins puissant que celui de DELPHI 2007 ou antérieur.
Et mon 2ème point: si 2 procédures identiques (produit matriciel utilisant des boucles "for" normales et des pointeurs de tableaux) donnaient des tps de calcul identiques en DELPHI et en C++ builder.

J'espère que j'étais plus clair maintenant,

Fred

Delphi (2009 comme le 2010 qui sort dans quelques jours :)) n'a pas changé son mode de compilation, on passe toujours du "pascal objet" vers du code machine (ASM) directement exécutable par le processeur.

Pas de MSIL, pas de .class ou autre nouveau langage intermédiaire, c'est toujours du bon vieux Win32 natif. Avec toujours l'arithmétique des pointeurs, la gestion personnalisée de la mémoire (pas de GC), la possibilité de faire de l'asm, etc..

Pour les apports comme les génériques, là non plus ça ne change rien car c'est le compilateur qui se charge de tout traduire comme il faut de sorte qu'au final il n'y a plus de notion de générique au niveau des binaires de l'exécutable. D'un point de vue global je ne vois pas pourquoi les temps d'exécution seraient plus long qu'avant, voire même peut-être mieux le compilo étant de plus en plus efficace en optimisation entre les versions. Et il ne se traine pas non plus pour autant, loin de là.

Mais à ce niveau rien ne vaut le test par soit-même, les versions d'essai sont là pour ça ;)