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]

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]

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.