Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1174 connectés 

  FORUM HardWare.fr
  Programmation
  Divers

  De la vitesse des langages...

 


 Mot :   Pseudo :  
 
 Page :   1  2  3  4
Page Précédente
Auteur Sujet :

De la vitesse des langages...

n°606667
kadreg
profil: Utilisateur
Posté le 09-01-2004 à 18:19:15  profilanswer
 

C est rapide comme l'éclair, java est lent. On entend souvent parler de vitesse d'éxécution de programme suivant leur langage. OsNews vient de publier un super benchmark entre plusieurs langages : Java 1.3.1, Java 1.4.2, C compilé avec gcc 3.3.1, Python 2.3.2, Python compilé avec Psyco 1.1.1, et les quatres langages de Visual Studio .NET 2003 : Visual Basic, Visual C#, Visual C++, et Visual J#.
 
En conclusion, quoi en retenir :
 
http://img.osnews.com/img/5602/results.jpg
 
- Les différents langages de microsofts sont très rapides, et occupent 4 des 5 premières places.
- gcc est plus lent que visual C++, confirmant ainsi ses rumeurs de charettes
- java 1.4 est plus lent que le 1.3, contrairement à ce que raconte sun.
- Python n'apparait pas dans le tableau tellement il est lent (même en compilé), puisque 40 fois plus lent que le visual C++.
- si on exclue le calcul trigonométrique, java est du même niveau que les autres langages de microsoft.
 
 
La news : http://osnews.com/story.php?news_id=5602


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
mood
Publicité
Posté le 09-01-2004 à 18:19:15  profilanswer
 

n°606682
antp
Super Administrateur
Champion des excuses bidons
Posté le 09-01-2004 à 18:35:43  profilanswer
 

Bon, je réouvre, mais faut que ce soit pour discuter sérieusement.
Ne pas oublier que si jamais vous voulez troller, y a ce topic-là :
 
http://forum.hardware.fr/forum2.ph [...] post=31321


Message édité par antp le 09-01-2004 à 19:02:59

---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
n°606695
chrisbk
-
Posté le 09-01-2004 à 19:03:21  profilanswer
 

bon ben si qqun sait pkoi java se vautre comme ca en trig....

n°606699
kadreg
profil: Utilisateur
Posté le 09-01-2004 à 19:17:56  profilanswer
 

chrisbk a écrit :

bon ben si qqun sait pkoi java se vautre comme ca en trig....


 
code source :  
http://www.ocf.berkeley.edu/~cowel [...] hmark.java
 
Pour infos, Math.sin délègue à StrictMath.sin  qui est une méthode native.


Message édité par kadreg le 09-01-2004 à 19:22:18

---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
n°606702
R3g
fonctionnaire certifié ITIL
Posté le 09-01-2004 à 19:25:16  profilanswer
 

En même temps qui c'est qui l'a codé le bench ? P'tet que le mec est juste meilleur en C++ qu'en java....
Sinon ca comprend quoi au juste le calcul trigonométrique ?
 
EDIT : ouais j'ai rien dis, je viens de lire le code et y'a pas à être bon ou pas..
 
EDIT2 : en fait ce qui me surprend le plus c'est les bonnes perfs de java en I/O, j'ai toujours pensé que c'était son point faible.


Message édité par R3g le 09-01-2004 à 19:28:40
n°606715
chrisbk
-
Posté le 09-01-2004 à 19:45:36  profilanswer
 

kadreg a écrit :


 
code source :  
http://www.ocf.berkeley.edu/~cowel [...] hmark.java
 
Pour infos, Math.sin délègue à StrictMath.sin  qui est une méthode native.


 
et donc ?

n°606732
the real m​oins moins
Posté le 09-01-2004 à 20:12:12  profilanswer
 

kadreg a écrit :


- java 1.4 est plus lent que le 1.3, contrairement à ce que raconte sun.

juste pour la trig. je trouve ça bcp trop louche pour être honnete.

n°606741
slvn
Posté le 09-01-2004 à 20:24:42  profilanswer
 

c est quoi le sens de ce graphe??? sachant que derriere il y a un scheduleur qui gere le temps alloue aux taches par le proc ?????

n°606762
os2
Posté le 09-01-2004 à 21:02:42  profilanswer
 

si t'enlèves la trigo, Java 1.4.2 est pas mal


---------------
Borland rulez: http://pages.infinit.net/borland
n°606764
os2
Posté le 09-01-2004 à 21:10:20  profilanswer
 

avec la version du benchmark en java j'arrive vraiment très très près de ses valeurs mis à part pour la trigo où c'est environ 4 secondes plus rapide...
 
en espèrant que sun corrige la trigo dans java 1.5...


---------------
Borland rulez: http://pages.infinit.net/borland
mood
Publicité
Posté le 09-01-2004 à 21:10:20  profilanswer
 

n°606767
kadreg
profil: Utilisateur
Posté le 09-01-2004 à 21:18:49  profilanswer
 


 
C'est plus un problème d'implémentation dans la bibliothèque standard (écrite en C) qu'un problème de langage.


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
n°606771
chrisbk
-
Posté le 09-01-2004 à 21:21:17  profilanswer
 

kadreg a écrit :


 
C'est plus un problème d'implémentation dans la bibliothèque standard (écrite en C) qu'un problème de langage.


 
eurf, je vois pas comment on peut se planter dans ce genre de fonctions

n°606775
noldor
Rockn'roll
Posté le 09-01-2004 à 21:29:15  profilanswer
 

je me méfie toujours de ce genre de bench, est ce vraiment représentatif de ce qui est utilisé en réalité ?

n°606778
kadreg
profil: Utilisateur
Posté le 09-01-2004 à 21:30:41  profilanswer
 

noldor a écrit :

je me méfie toujours de ce genre de bench, est ce vraiment représentatif de ce qui est utilisé en réalité ?


 
Vieux proverbe : le meilleur benchmark est l'application que l'on compte utiliser.


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
n°606779
Taz
bisounours-codeur
Posté le 09-01-2004 à 21:36:56  profilanswer
 

trollesque

n°606782
Taz
bisounours-codeur
Posté le 09-01-2004 à 21:39:12  profilanswer
 

1) le gcc est sous cygwin
2) le traitement int64 bits n'a aucun sens en Python
3) tiens les produits MS en premier
4) le code est loin d'être propre, c'est du travail de chaffouin
5) moi je prends le code C sur mon XP200+, je compile en -O0, je lance (seti@bg) et pan, je fais direct 49s ... super...

n°606783
chrisbk
-
Posté le 09-01-2004 à 21:42:02  profilanswer
 

taz a écrit :

1) le gcc est sous cygwin
2) le traitement int64 bits n'a aucun sens en Python
3) tiens les produits MS en premier
4) le code est loin d'être propre, c'est du travail de chaffouin
5) moi je prends le code C sur mon XP200+, je compile en -O0, je lance (seti@bg) et pan, je fais direct 49s ... super...


 
ca chiffone hein ? [:icon7]

n°606785
Taz
bisounours-codeur
Posté le 09-01-2004 à 21:45:44  profilanswer
 

chrisbk a écrit :


 
ca chiffone hein ? [:icon7]

ben c'est pas très fin comme troll enfin bon chez osnews d'un autre côté, faut pas trop attendre ... leur news sur linux/le_libre sont pathétiques (pas autant que clubic qui annonce mandrake quand même)

n°606787
chrisbk
-
Posté le 09-01-2004 à 21:47:12  profilanswer
 

taz a écrit :

ben c'est pas très fin comme troll enfin bon chez osnews d'un autre côté, faut pas trop attendre ... leur news sur linux/le_libre sont pathétiques (pas autant que clubic qui annonce mandrake quand même)


 
ah, donc si un bench place les produits MS en tete c'est un troll ?
Par contre le meme bench qui aurait mis du libre en tete, ca n'aurait pas été un troll ?
 
 
Ca ma l'air compliqué tout ca [:humanrage]
 
enfin entre deux "trolls", on se bornera de signaler que VC++ est  tres utilisé dans l'industrie du JV, sont pas mauvais en optimisation chez M$ (<< cado [:icon7])
 


Message édité par chrisbk le 09-01-2004 à 21:48:28
n°606790
Taz
bisounours-codeur
Posté le 09-01-2004 à 21:48:58  profilanswer
 

j'ai pas dit ça. je dis : tiens les produits MS sont en premier, la version de gcc_cywin est loin d'être la plus rapide, et bien qu'ayant une configuration plus modeste, et sans optimisation, j'obtiens avec gcc un meilleur score que VC++
 
bon t'es pas marrant ce soir

n°606792
chrisbk
-
Posté le 09-01-2004 à 21:50:30  profilanswer
 

taz a écrit :


bon t'es pas marrant ce soir


pourtant je donne tout ce que j'ai
 
au fait si j'ai bien compris c pas du C++ compilé natif (ou je me plante ?)
 
ah si je me plante


Message édité par chrisbk le 09-01-2004 à 21:51:05
n°606793
Taz
bisounours-codeur
Posté le 09-01-2004 à 21:52:13  profilanswer
 

pas mauvais en optimisation, mon oeil. un rapide tour en C++ montre clairement que le compilateur ignore certaines optimisations triviales. gcc_cygwin n'est pas aussi performant qu'un vrai gcc (comme sous linux par exemple)

n°606794
chrisbk
-
Posté le 09-01-2004 à 21:52:47  profilanswer
 

taz a écrit :

pas mauvais en optimisation, mon oeil. un rapide tour en C++ montre clairement que le compilateur ignore certaines optimisations triviales. gcc_cygwin n'est pas aussi performant qu'un vrai gcc (comme sous linux par exemple)


 
fo compiler en release [:icon12]
 
c koi les optims trivials qu'il rate ? source ? preuve ? et pas du VC4 hein ? [:icon11]


Message édité par chrisbk le 09-01-2004 à 21:53:15
n°606795
Taz
bisounours-codeur
Posté le 09-01-2004 à 21:54:25  profilanswer
 

bah je pense. n'ayant jamais utilisé VC, je suis mal placé, mais à chaque fois que je parle avec des gens, ils me montrent que certaines optimisations sont absentes
 
 
quand à python, quand tu vois la tronche du code, c'est tout sauf du python, faut pas s'étonner

n°606796
chrisbk
-
Posté le 09-01-2004 à 21:59:08  profilanswer
 

c'est leger comme argumentation, jeune homme, tres leger, limite trollationique [:shakalagoons]

n°606797
Taz
bisounours-codeur
Posté le 09-01-2004 à 22:00:34  profilanswer
 

parce que ces benchmarks ne le sont pas ?

n°606798
chrisbk
-
Posté le 09-01-2004 à 22:01:56  profilanswer
 

ce sont des fait, froids et reproductibles, pas des on-dit, des "j'ai un pote qui dit que", ou autre truc du genre :o
 
Maintenant si le type a pris un gcc d'avant-guerre, c'est sur que cette comparaison est a oublier.  
 

n°606800
Taz
bisounours-codeur
Posté le 09-01-2004 à 22:05:49  profilanswer
 

à oublier. et puis tout le monde sait que gcc est natif des *n*x sur lesquels ils règne. moi je te fais le meme truc avec wine et vc, on verra. bref gcc est pas la dans son environnement idéal.
 
et puis on teste sur une plateforme MS, les produits MS sont favoriés. je suis sur que la JVM sous solaris est bien plus rapide que ça par exemple
 
 
bon je vais au bar

n°606804
chrisbk
-
Posté le 09-01-2004 à 22:10:33  profilanswer
 

taz a écrit :

à oublier. et puis tout le monde sait que gcc est natif des *n*x sur lesquels ils règne. moi je te fais le meme truc avec wine et vc, on verra. bref gcc est pas la dans son environnement idéal.
 
et puis on teste sur une plateforme MS, les produits MS sont favoriés. je suis sur que la JVM sous solaris est bien plus rapide que ça par exemple
 
 
bon je vais au bar


une certaine lassitude m'envahi a la lecture de tout ceci. je crios meme que je vais pousser un leger baillement et voir si je peux trainer mon colloc au bar. vider des bieres, au moins, ca se passe d'os

n°606817
Kristoph
Posté le 09-01-2004 à 22:21:32  profilanswer
 

Les conclusions sont foireuses en effet. Java 1.4.2 est bien plus rapide que Java 1.3 sauf sur 1 seul test. Faire la somme des temps de calcul est vraiment une très très mauvaise idée.
 
Les seules conclusions que je tire de tout ça sont :
- Vous voyez bien que Java ce n'est pas si lent que ça
- Du C++ bien optimisé reste plus rapide que du C# sous .Net Pas ettonant quand même.
 
Au fait, vous savez que GCC sait faire du "profiled based optimisation" lui aussi ? -fbranch-probabilities

n°606826
antp
Super Administrateur
Champion des excuses bidons
Posté le 09-01-2004 à 22:37:00  profilanswer
 

Kristoph a écrit :


- Vous voyez bien que Java ce n'est pas si lent que ça


 
Selon moi (qui ne programme pas en Java) une des principales raison de cette "croyance" de lenteur de Java c'est surtout que les interfaces graphiques sont souvent pas très réactives. Un peu comme le XUL de Mozilla :/


---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
n°606836
os2
Posté le 09-01-2004 à 23:00:17  profilanswer
 

une version du bench vite fait en delphi

Code :
  1. program Benchmark;
  2. {$APPTYPE CONSOLE}
  3. uses
  4.   SysUtils,
  5.   MMSystem,
  6.   Math;
  7. var
  8.   startTime :Longint;
  9.   stopTime :Longint;
  10.   elapsedTime :Longint;
  11.   intMax :integer;
  12.   doubleMin :double;
  13.   doubleMax :double;
  14.   longMin :Int64;
  15.   longMax :Int64;
  16.   trigMax :double;
  17.   ioMax :integer;
  18.   intArithmeticTime: double;
  19.   doubleArithmeticTime :double;
  20.   longCountTime :double;
  21.   trigTime :double;
  22.   ioTime :double;
  23.   totalTime :double;
  24.   function intArithmetic(intMax:integer):Longint;
  25.   var
  26.     intResult :integer;
  27.     i :integer;
  28.   begin
  29.     startTime := timeGetTime;
  30.  intResult := 1;
  31.  i := 1;
  32.    
  33.  while (i < intMax) do
  34.  begin
  35.   intResult := intResult - i;
  36.       inc(i);
  37.       intResult := intResult + i;
  38.       inc(i);
  39.       intResult := intResult * i;
  40.       inc(i);
  41.       intResult := intResult div i;
  42.       inc(i);
  43.  end;
  44.  stopTime := timeGetTime;
  45.  elapsedTime := stopTime - startTime;
  46.  WriteLn('Int arithmetic elapsed time: ' + inttostr(elapsedTime) + 'ms with max of ' + inttostr(intMax));
  47.  WriteLn(' i: ' + inttostr(i) + ' intResult: ' + inttostr(intResult));
  48.  result := elapsedTime;
  49.   end;
  50.   function doubleArithmetic(doubleMin, doubleMax:double):Longint;
  51.   var
  52.     doubleResult :double;
  53.     i :double;
  54.   begin
  55.     startTime := timeGetTime;
  56.  doubleResult := doubleMin;
  57.  i := doubleMin;
  58.  while (i < doubleMax) do
  59.  begin
  60.   doubleResult := doubleResult - i;
  61.       i:=i+1;
  62.       doubleResult := doubleResult + i;
  63.       i:=i+1;
  64.       doubleResult := doubleResult * i;
  65.       i:=i+1;
  66.       doubleResult := doubleResult / i;
  67.       i:=i+1;
  68.  end;
  69.  stopTime := timeGetTime;
  70.  elapsedTime := stopTime - startTime;
  71.  WriteLn('Double arithmetic elapsed time: ' + inttostr(elapsedTime) + ' ms with min of ' + floattostr(doubleMin) + ', max of ' + floattostr(doubleMax));
  72.  WriteLn(' i: ' + floattostr(i) + ' doubleResult: ' + floattostr(doubleResult));
  73.  result := elapsedTime;
  74.   end;
  75.   function longArithmetic(longMin, longMax:Int64):Longint;
  76.   var
  77.     longResult :Int64;
  78.     i :Int64;
  79.   begin
  80.     startTime := timeGetTime;
  81.   longResult := longMin;
  82.   i := longMin;
  83.  while (i < longMax) do
  84.  begin
  85.       longResult := longResult - i;
  86.       inc(i);
  87.       longResult := longResult + i;
  88.       inc(i);
  89.       longResult := longResult * i;
  90.       inc(i);
  91.       longResult := longResult div i;
  92.       inc(i);
  93.  end;
  94.     stopTime := timeGetTime;
  95.  elapsedTime := stopTime - startTime;
  96.  WriteLn('Long arithmetic elapsed time: ' + inttostr(elapsedTime) + ' ms with min of ' + inttostr(longMin) + ', max of ' + inttostr(longMax));
  97.  WriteLn(' i: ' + inttostr(i));
  98.  WriteLn(' longResult: ' + inttostr(longResult));
  99.  result := elapsedTime;
  100.   end;
  101.   function trig(trigMax:double):Longint;
  102.   var
  103.     sine :double;
  104.     cosine :double;
  105.     tangent :double;
  106.     logarithm :double;
  107.     squareRoot :double;
  108.     i :double;
  109.   begin
  110.     startTime := timeGetTime;
  111.     sine := 0.0;
  112.  cosine := 0.0;
  113.  tangent := 0.0;
  114.  logarithm := 0.0;
  115.  squareRoot := 0.0;
  116.  i := 0.1;
  117.  while (i < trigMax) do
  118.     begin
  119.    sine := Sin(i);
  120.    cosine := Cos(i);
  121.    tangent := Tan(i);
  122.    logarithm := Log10(i);
  123.    squareRoot := sqrt(i);
  124.   i := i+1;
  125.  end;
  126.  stopTime := timeGetTime;
  127.  elapsedTime := stopTime - startTime;
  128.  WriteLn('Trig elapsed time: ' + inttostr(elapsedTime) + ' ms with max of ' + floattostr(trigMax));
  129.  WriteLn(' i: ' + floattostr(i));
  130.  WriteLn(' sine: ' + floattostr(sine));
  131.  WriteLn(' cosine: ' + floattostr(cosine));
  132.  WriteLn(' tangent: ' + floattostr(tangent));
  133.  WriteLn(' logarithm: ' + floattostr(logarithm));
  134.  WriteLn(' squareRoot: ' + floattostr(squareRoot));
  135.  result := elapsedTime;
  136.   end;
  137.   function io(ioMax:integer):Longint;
  138.   var
  139.     textLine :string;
  140.     i:integer;
  141.     myLine:string;
  142.     F:TextFile;
  143.   begin
  144.     startTime := timeGetTime;;
  145.     textLine := 'abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefgh';
  146.     i := 0;
  147.   myLine := '';
  148.     assignfile(F,'TestDelphi.txt');
  149.     rewrite(F);
  150.     while (i < ioMax) do
  151.  begin
  152.       Writeln(F,textLine);
  153.       inc(i);
  154.  end;
  155.     CloseFile(F);
  156.  stopTime := timeGetTime;
  157.  elapsedTime := stopTime - startTime;
  158.  WriteLn('IO elapsed time: ' + inttostr(elapsedTime) + ' ms with max of ' + inttostr(ioMax));
  159.  WriteLn(' i: ' + inttostr(i));
  160.  WriteLn(' myLine: ' + myLine);
  161.  result := elapsedTime;
  162.   end;
  163. begin
  164.   intMax := 1000000000;
  165.   doubleMin := 10000000000;
  166.   doubleMax := 11000000000;
  167.   longMin := 10000000000;
  168.   longMax := 11000000000;
  169.   trigMax := 10000000;
  170.   ioMax := 1000000;
  171.   WriteLn('Start Delphi benchmark');
  172.   intArithmeticTime := intArithmetic(intMax);
  173.   doubleArithmeticTime := doubleArithmetic(doubleMin, doubleMax);
  174. longCountTime := longArithmetic(longMin, longMax);
  175.  trigTime := trig(trigMax);
  176. ioTime := io(ioMax);
  177. totalTime := intArithmeticTime + doubleArithmeticTime + longCountTime + trigTime + ioTime;
  178.   WriteLn('Total Delphi benchmark time: ' + floattostr(totalTime) + ' ms');
  179.   WriteLn('End Delphi benchmark');
  180.   Readln;
  181. end.


 
dans la fonction trig j'ai fait  
 

Code :
  1. i := 0.1;


au lieu de

Code :
  1. i := 0.0;


car sinon la fonction Log10 plante
 
de plus puisque la fonction longArithmetic au lieu d'utiliser
des LongInt j'ai utiliser des Int64 car le LongInt de delphi permet pas d'aller aussi loin que les long en c....


---------------
Borland rulez: http://pages.infinit.net/borland
n°606838
antp
Super Administrateur
Champion des excuses bidons
Posté le 09-01-2004 à 23:03:03  profilanswer
 

Les long en C c'est 32 bits signés comme les int en C et les Integer en Delphi, non ?


---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
n°606841
schnapsman​n
Zaford Beeblefect
Posté le 09-01-2004 à 23:14:11  profilanswer
 

Il aurait été bien plus pertinent de faire les tests gcc et python sur hardware egal sous linux [:autobot]


Message édité par schnapsmann le 09-01-2004 à 23:15:27

---------------
From now on, you will speak only when spoken to, and the first and last words out of your filthy sewers will be "Sir!"
n°606847
os2
Posté le 09-01-2004 à 23:59:09  profilanswer
 

antp a écrit :

Les long en C c'est 32 bits signés comme les int en C et les Integer en Delphi, non ?


 
dans les test  
en c il utilise le long long int (64 bit il me semble)
en java le long (64 bit)
 
sur un amd 1800+, 512 mb  
a peut prêt son p4 car j'obtient des résultat quasi identique au sien
 
moyenne 50 test:
 
int aritmetic: 8121ms
double aritmetic: 11627ms
long aritmetic: 112101ms
trigo: 3896ms
io: 3835ms
total: 139580ms
 
meilleur score en int
4ième pour les doubles
derniers pour les long
deuxième pour la trio
premier pour le io (trop bas il me semble le score...)
 


---------------
Borland rulez: http://pages.infinit.net/borland
n°606848
Kristoph
Posté le 10-01-2004 à 00:00:37  profilanswer
 

J'aimerais quand même voir des resultats à machine égale plustot qu'un "A vue de nez ça se vaut"

n°606850
antp
Super Administrateur
Champion des excuses bidons
Posté le 10-01-2004 à 00:08:21  profilanswer
 

os2 a écrit :


en c il utilise le long long int (64 bit il me semble)
 


 
avec quel compilo ? j'ai tj connu les long en 32 bits moi sur PC :??:


---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire
n°606852
os2
Posté le 10-01-2004 à 00:17:28  profilanswer
 

antp a écrit :


 
avec quel compilo ? j'ai tj connu les long en 32 bits moi sur PC :??:


 
long long int et long c'est pas pareil
c'est toute spécifier au début du bench les types de donnée qu'il utilise (avec le nombre de byte)


---------------
Borland rulez: http://pages.infinit.net/borland
n°606853
os2
Posté le 10-01-2004 à 00:19:18  profilanswer
 

pourquoi vb.net c#.net et vc++.net n'obtiennet pas les même résultats?
 
au final ils ont tous le même "bytecode"


---------------
Borland rulez: http://pages.infinit.net/borland
n°606855
Kristoph
Posté le 10-01-2004 à 00:41:52  profilanswer
 

Code :
  1. [kristoph@vvardenfell c++]$ ./bench
  2. Start C benchmark
  3. Int arithmetic elapsed time: 8160 ms
  4. Double arithmetic elapsed time: 6010 ms
  5. arithmetic elapsed time: 20770 ms
  6. Trig elapsed time: 3650 ms
  7. I/O elapsed time: 1090 ms
  8. Total elapsed time: 39680 ms


 
gcc 3.3.1 sur Athlon XP 1800+ avec 256Mo de ram
 

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4
Page Précédente

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Divers

  De la vitesse des langages...

 

Sujets relatifs
En quels langages sont conçus les logiciels "pro" ?Comment parametrer la vitesse d'un défilement de texte ??
Windows - vitesse de connexion au réseau localComment controler la vitesse des ventilos comme speedfan ?
la fin des langages de programmation... sous Windows evidemment[Visual Basic] Changer la vitesse du ventilateur cpu ?
[tous langages Web]gestion de cookies SSO[Perl] Vitesse entre grep et defined
Vitesse d'exécution des dernières versions de DephiInclude / fonctions / vitesse d'execution
Plus de sujets relatifs à : De la vitesse des langages...


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR