Discussion :

[Garocat]

Bonjour,

Je dois choisir un outil de développement en vue d'un projet nécessitant des calculs intensifs (logiciel d'emploi du temps).
J'ai utilisé l'an passé Delphi pour une première version (qui assurait interface et calcul), mais il semble qu'il n'existe plus de version "amateur" gratuite et suis donc, à terme condamné à changer (d'autant que j'ai changé de machine). J'envisage maintenant Lazarus ou Visual C++ (seulement pour la partie calculs, l'interface sera probablement faite avec open office).
J'ai réalisé sous Delphi 2007, Lazarus, et Visual C++ 2008 une comparaison de la vitesse d'exécution d'une boucle réalisant 1 milliard de multiplications et de divisions (entières) d'entiers longs.
Résultats sur ma machine :
8s avec Delphi
14s en Visual C++
26s sous Lazarus

Je suis assez déçu de la performance de C++, que j'utilise pour la première fois, et que je pensais être le plus véloce... un facteur deux, ce n'est pas négligeable pour le type d'application que j'envisage.

Mes questions, si vous avez un peu de temps, sont les suivantes :
- Ma procédure de test vous parait-elle pertinente ?
- Ces résultats sont-ils conformes à ce que vous savez de ces langages/compilateurs ?
- Auriez-vous d'autres suggestions (langage - compilateur -éditeur) ?

Ci-dessous les différents codes sources (rien de mystérieux évidemment; je ne les indique que pour une détection d'éventuelle idiotie de ma part ralentissant tel ou tel programme).

Merci !


**************
Pascal (compilé avec Delphi ou Lazarus)
**************
procedure TForm1.Button1Click(Sender: TObject);
var k, N, x: LongInt;
T1, T2, D : TTime;

begin
N := 1000000000;
T1 := Time;
x := 24563;
for k := 0 to N - 1 do
begin
x := x*x+1;
x := x div x
end;
T2 := Time;
D := T2-T1;
ShowMessage(TimetoStr(D))
end;
**************
**************

C++ (compilé avec
******************
#include <iostream>
#include <time.h>

using namespace std;

int main()
{
time_t T1, T2;
double D;
long N,k, x;

cout << "Entrer le nombre d'iterations :" << endl;
cin >> N;
cout << endl << "C'est parti pour " << N <<" d'iterations !" <<endl;
time(&T1);
x = 23563;
for(k=0;k<=N-1;k++)
{x = x*x+1; x = x/x;}
time(&T2);
D = difftime(T2,T1);
cout <<D <<"\n";

return 0;

}

[Mat.M]

Mes questions, si vous avez un peu de temps, sont les suivantes :
- Ma procédure de test vous parait-elle pertinente ?
- Ces résultats sont-ils conformes à ce que vous savez de ces langages/compilateurs ?

la descrition des tests est incomplète :
-est-ce que ce sont des programmes en ligne de commande dans une boite ms-dos ?
-est-ce que c'est une version de Delphi en managed code ou code natif ?
-est-ce qu'avec VC++ tu as réglé les options de compilations

sinon je reste très perplexe c'est un peu comme les tests java contre C++.
En Java ils seront plus rapides.
Par contre dès que tu utilises une interface graphique avec des fenêtres c'est une autre paire de manche..
la VCL est assez lourde je trouve.
Je ne parlerais pas d'un certain antivirus programmé avec C++ Builder qui donc utilise aussi la VCL et qui met des plombes à tourner et à démarrer

[Garocat]

Bonsoir, et merci pour cette réponse.

-est-ce que ce sont des programmes en ligne de commande dans une boite ms-dos ?

Oui pour le programme en C++, non pour les deux autres. Ce qui favoriserait plutôt C++ me semble-t-il. Pas de beaucoup je pense, car en Delphi/Lazarus, le côté "visuel" n'est pas sollicité durant la boucle.

-est-ce que c'est une version de Delphi en managed code ou code natif ?

Euh... je ne sais. C'est Delphi 7 (Turbo me semble-t-il), dans sa configuration d'origine.

-est-ce qu'avec VC++ tu as réglé les options de compilations

Ah non... Il y certainement quelque chose à glaner là... Je débute complètement avec C++ (a fortiori avec Visual C++).

sinon je reste très perplexe c'est un peu comme les tests java contre C++.

Je ne crois pas, je n'ai choisi que des langages compilés.

En Java ils seront plus rapides.

Java plus rapide ? Lapsus ?
A priori cela ne me viendrait pas à l'esprit de comparer Java et C. Pour ce que j'en sais, C est compilé tandis que Java cause à une machine virtuelle, ce qui permet la portabilité mais nuit aux performances. Si je suis dans l'erreur quant aux performances de java (pour du calcul pur et dur, pas pour l'interface), je vais peut-être envisager cette possibilité.

[Mat.M]

Salut,

Java plus rapide ? Lapsus ?

non on a mal compris ce que j'ai écris : Java peut être plus rapide avec un programme compilé en ligne de commande avec un simple main
Par contre dès que tu utilises ce langage avec fenêtres et interface graphique avec AWT par exemple ( je ne suis pas trop spécialiste Java ) c'est une autre paire de manche

[Graffito]

Je ne suis pas sur que le test soit vraiment significatif:
On peut penser que la performance de Delphi dans ce cas est due à une bonne optimisation (c'est à dire à une utilisation exclusive des registres pour x, k et n).

Ceci serait dèjà un peu plus significatif :

Code :

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

1
2
3
4
5
6
7
for k := 0 to N - 1 do begin x:=F1(x) ; x:=F2(x) ; end ; 

function F1(x:longint) : longint ; 
begin result=x*x+1 ; end ; 

function F2(x:longint) : longint ;
begin result=x/x ;  end ;

Suggestion : Essayer aussi en C# (qui est pour la syntaxe semblable à C++ et pour les classes et l'environnement de develloppement assez proche de Delphi).

[Garocat]

Salut,



non on a mal compris ce que j'ai écris : Java peut être plus rapide avec un programme compilé en ligne de commande avec un simple main
Par contre dès que tu utilises ce langage avec fenêtres et interface graphique avec AWT par exemple ( je ne suis pas trop spécialiste Java ) c'est une autre paire de manche

Je vais essayer... Si je peux glaner la portabilité au passage, je ne cracherai pas dessus. Merci.

[Garocat]

Je ne suis pas sur que le test soit vraiment significatif:
On peut penser que la performance de Delphi dans ce cas est due à une bonne optimisation (c'est à dire à une utilisation exclusive des registres pour x, k et n).

Ceci serait dèjà un peu plus significatif (...)

Je vais essayer comme ça aussi, merci.

[Garocat]

Bon eh bien j'ai testé java en ligne de commande : je n'en reviens pas tellement c'est rapide. Dans mon esprit, la couche "machine virtuelle" induisait un ralentissement qui devait se mesure en facteur 10 voire 100. J'étais bien dans l'erreur. J'opte donc pour java !
Merci pour l'indication !

[Garocat]

Je complète, afin que ce fil soit utile à qui tombera dessus.
Je confirme le bon comportement de Java (à travers mes petits tests d'amateur). J'avais cependant mal évalué C, faute de maitriser convenablement l'outil Visual C++.
Une fois compilé en mode "release" plutôt que "debug", C reprend l'avantage.

Dans le test suivant (ou tout le monde est de type int)

Code :

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

1
2
3
4
5
6
7
8
S := 0;
  for k : 0 -> 10000
    [for i : 0 -> 1000
      [for j : 0 -> 2000
         S = S +j
      ]
    ]

Les performances sur ma machine sont
C : 6s
java : 10s
Delphi : 14s

[gl]

Pour info, je viens par curiosité de tester le code C++ avec Visual C++ 2010 en mode release (optimisation O2) et j'obtiens 0s.

Le résultat de la boucle n'étant pas utilisé, elle est visiblement tout simplement enlevée.

[Garocat]

En effet ! Je viens tout récemment de comprendre que le compilateur de Visual C++ était capable de supprimer du code inutile. C'est excellent, je pensais pour ma part qu'il se contenterait de "traduire" le code en assembleur, mais pas du tout. Cela suppose une analyse "intelligente" du code.

Une question : j'ai bien compris maintenant que Visual C++ pouvait compiler en mode release ou en mode debug, mais que signifie (et où règle-t-on) "optimisation O2" ?

[gl]

Une question : j'ai bien compris maintenant que Visual C++ pouvait compiler en mode release ou en mode debug, mais que signifie (et où règle-t-on) "optimisation O2" ?

Ça se règle dans les propriétés du projet (C/C++ >> Optimization >> Optimization pour être précis).

[Garocat]

Ah oui, vu. Et l'intitulé est suffisamment explicite. Merci bien !

[gl]

Au passage, je précise car mon post initial n'était absolument pas explicite à ce sujet. Mon but n'était pas de montrer une quelconque supériorité de tel ou tel langage mais bien de montrer que d'une part différents paramètres vont influer le résultat et d'autre part que ton bench n'est pas nécessairement suffisant à répondre à ta question.

[Garocat]

Oui, c'est clair, ce n'est qu'un vague indicateur (je ne revendique en aucun cas le terme de benchmark). Les performances vont largement dépendre des tâches demandées. Néanmoins, pour moi qui en suis encore au stade de la découverte des outils et cherche à les évaluer, cela me permet d'avoir une première idée pour ce qui est du calcul bourrin, plein de boucles, que j'ai à faire. J'ai en particulier réalisé que java n'était pas forcément aussi lent que je le présumais (néanmoins mes premiers tests faisant intervenir objets et méthodes non statiques semblent indiquer que l'on perd pas mal par rapport à des fonctions C).

En tout cas, je suis un peu en rogne contre Embarcadero. Tout l'investissement que j'ai fait l'an passé sur l'apprentissage de Delphi est passé par pertes et profits. Et à mon humble avis, ne plus permettre l'accès à une version allégée gratuite, c'est du suicide.

[Nono40]

En effet ! Je viens tout récemment de comprendre que le compilateur de Visual C++ était capable de supprimer du code inutile. C'est excellent, je pensais pour ma part qu'il se contenterait de "traduire" le code en assembleur, mais pas du tout. Cela suppose une analyse "intelligente" du code.

Delphi le fait aussi.

Si tu veux être sur que les calculs inutiles ne soient pas supprimés par chacun des compilateurs il suffit d'afficher X dans le ShowMessage en fin de calcul.

Maintenant ce genre de test est pour moi parfaitement inutile a moins de développer une appli de prévision météo. La gestion de l'interface prendra toujours plus de temps que le calcul lui-même.

Et surtout : la façon de programmer gagnera enormément plus de temps que le choix du compilateur. Un bon algo sera critique dans un calcul d'emploi du temps plutôt que la force brute de calcul.

[Nono40]

En tout cas, je suis un peu en rogne contre Embarcadero. Tout l'investissement que j'ai fait l'an passé sur l'apprentissage de Delphi est passé par pertes et profits. Et à mon humble avis, ne plus permettre l'accès à une version allégée gratuite, c'est du suicide.

Tu travailles gratuitement toi ?

[Garocat]

Maintenant ce genre de test est pour moi parfaitement inutile a moins de développer une appli de prévision météo. La gestion de l'interface prendra toujours plus de temps que le calcul lui-même.

Pas d'accord. L'interface, c'est rien à côté du calcul de l'emploi du temps, ni du point de vue conception, ni du point de vue temps de calcul. D'ailleurs ce n'est que pour la partie calcul que je me pose ces questions de performance, la partie interface sera du VBA.

Et surtout : la façon de programmer gagnera enormément plus de temps que le choix du compilateur. Un bon algo sera critique dans un calcul d'emploi du temps plutôt que la force brute de calcul.

Je suis plus d'accord là-dessus, mais choisir un mauvais compilateur pour un calcul intensif n'est quand même pas une bonne idée. Je ne suis qu'un programmeur très occasionnel, il me faut tout de même réfléchir au choix de l'outil sur lequel je vais, malgré tout, investir pas mal de temps.

Tu travailles gratuitement toi ?

Ça n'a rien à voir... mais ça m'arrive. Par ailleurs, je ne suis pas partisan du tout gratuit et je n'hésite pas à payer pour ce que je consomme via internet par exemple (presse, logiciels, etc.). C'est une question de proportion. Je suis un particulier qui écrira UN programme. Débourser 1600 euros n'est pas envisageable. Mais indépendamment de ça :
1°) Je ne pense pas que ce soit pour les beaux yeux de qui que ce soit que Microsoft, par exemple, propose Visual C++ 2008 en accès libre. C'est parce qu'il y a intérêt. Parmi les utilisateur gratuits d'aujourd'hui, il y a nombre d'utilisateurs payants et de prescripteurs de demain. C'est en ce sens que je pense que la politique de Codegear est suicidaire.
2°) Ce changement brutal d'attitude (où même la version 2006 qui était accessible auparavant ne l'est plus) laisse tout de même dans l'embarras tous ceux qui utilisaient la version gratuite, ce n'est pas très sympathique.

[Garocat]

@Nono40 :
Ce qui est curieux c'est que dans ce fil , tu semblais comme moi regretter l'attitude de CodeGear...

[Nono40]

Question performances, pour que le test soit valable il faudrait être dans les même conditions et j'espère que tu l'as fait dans ce cas :
- Toujours exécuter hors complateur
- Avoir le même nombre de process actifs dans windows lors du test.
Il y a tellement de paramètres externes qui entre en compte lors de ce genre de tests.

Ce qu'il faudrait voir dans ton cas c'est le code ASM généré par chacun des compilateurs que tu as essayé, c'est le seul moyen de voir lequel fera le moins d'instructions pour le même nombre de lignes de codes.

Par expérience je peux te dire qu'il faut passer beaucoup plus de temps sur l'algo que sur le reste, ce n'est pas un gain de quelques pourcents mais des résultats /10 /100 que tu peux changer en mettant au point un algo performat.

Si tu as acquis une expérience avec Delphi je ne pense pas que ce simple test soit une raison suffisante pour changer. Delphi 6 Perso et Delphi 7 perso existent encore.

Au besoin ecrit les quelques lignes critiques en ASM directement dans Delphi ou Visual Studio.

Dans le sujet que tu cotes, ou je regrète l'attitude de Codegear. Je ne crois pas que ce soit du suicide mais en tout cas certainement pas une voie appréciée par les développeur perticuliers ou occasionnel. Surtout que Codegear nous avait habitué à ces versions bien avant que MS ne s'y mette. Seulement sans doute trop de personnes s'en sont servis pour réaliser des applis commerciales

PS : ce n'est pas 1600Euros mais seulement 899Euros
http://www.microsigma.fr/codegear/index.html