Un truc étrange... Différence entre Windows et Linux

Un truc étrange... Différence entre Windows et Linux - C - Programmation

Marsh Posté le 11-10-2007 à 13:24:03    

Bonjour,
 
J'ai codé un ptit programme qui écrit dans des fichiers.
 
Le programme crée 96 fichiers dans chacun desquels il écrit 2000 lignes.
 
Lorsque le code tourne sous Linux, il tourne pendant 10 ou 15 secondes à tout casser. Lorsqu'il tourne sous Windows, il lui faut 10 ou 15 secondes pour écrire UN SEUL fichier. Ce qui rend le traitement un peu long sous Windows.
 
J'ai un processeur Dual Core, donc déjà il ne sait pas le gérer. Il ne tourne que sur un seul processeur, mais tout de même, la différence avec Linux est nettement marquée.
 
C'est normal que Windows soit aussi long ?

Reply

Marsh Posté le 11-10-2007 à 13:24:03   

Reply

Marsh Posté le 11-10-2007 à 13:29:04    

Le code est exactement le meme sur les deux plateforme ? Tu utilises quel API pour ecrire dans un fichier ? Tu fais de la manipulation de texte avant, si oui quel genre de manipulation ?

Reply

Marsh Posté le 11-10-2007 à 13:32:50    

Le code est en effet exactement le même sur les deux plateformes.
 
Pour info voici le code :

Code :
  1. #include <stdio.h>
  2. #include <stdlib.h>
  3. #include <string.h>
  5. #define LONG 1024
  7. int main (int argc, char *argv[])
  8. {
  9. int lineCount, atomCount ;
  10. char line[LONG], scaleInfo[LONG], space[] = " ", *energyMax, *energyMin, *energyStep, *fermiLevel, dosFilePath[LONG] ;
  12. FILE *doscarFile, *dosFile ;
  14. lineCount = 1 ;
  15. atomCount = 0 ;
  16. energyStep = "0" ;
  18. /* Opening DOSCAR file */
  19. doscarFile = fopen ("DOSCAR", "r" ) ;
  21. /* Testing the opening procedure */
  22. if (doscarFile == NULL)
  23. {
  24.  fprintf(stderr, "Error while opening the DOSCAR file.\n" ) ;
  25. }
  27. else
  28. {
  29.  fprintf(stderr, "DOSCAR file opened successfully in read only mode.\n" ) ;
  31.  /* Reading POSCAR file line by line */
  32.  while (fgets(line, LONG, doscarFile) != NULL)
  33.  {
  35.   /* Importing basic scales for DoS plotting */
  36.   if (lineCount == 6)
  37.   {
  38.    if (atomCount == 0 )
  39.    {
  40.     mkdir("DOS_FILES", 0755) ;
  41.     strcpy(scaleInfo, line) ;
  42.     energyMax = strtok(scaleInfo, space) ;
  43.     energyMin = strtok(NULL, space) ;
  44.     energyStep = strtok(NULL, space) ;
  45.     fermiLevel = strtok(NULL, space) ;
  46.     fprintf(stderr, "Energy Min : %s eV\nEnergy Max : %s eV\nEnergy Step: %s eV\nFermi Level : %s eV\n", energyMin, energyMax, energyStep, fermiLevel) ;
  47.     atomCount ++ ;
  49.     /* Setting name of first atom DoS file */
  50.     sprintf(dosFilePath, "DOS_FILES/DOS_%d", atomCount) ;
  51.    }
  52.   }
  54.   else if (lineCount > 6 && lineCount < 7 + atoi(energyStep))
  55.   {
  58.    /* Opening Partial DOS file */
  59.    dosFile = fopen (dosFilePath, "a" ) ;
  60.    fputs(line, dosFile) ;
  62.    fclose(dosFile) ;
  63.   }
  65.   else if (lineCount == 7 + atoi(energyStep))
  66.   {
  67.    lineCount = 6 ;
  68.    atomCount ++ ;
  70.    /* Setting name of next atoms DoS files */
  71.    sprintf(dosFilePath, "DOS_FILES/DOS_%d", atomCount) ;
  72.   }
  74.   lineCount ++ ;
  75.  }
  77.  fprintf(stderr, "Number of atoms in cell : %d\n", atomCount) ;
  78. }
  80. /* Closing the DOSCAR file */
  81. fclose (doscarFile) ;
  82. }


 
Edit : Euuuh. En fait non. Je viens de le tester sous Linux au bureau, et c'est long aussi. Pourtant sur mon PC ça carburait :/
 
Edit 2 : Je viens de retester. Sur mon portable, Dual Core avec Mandriva Spring 2007.1 sous VMWare, le code met 10 secondes pour écrire les 96 fichiers.
 
Sur le PC du bureau, il faut quelques minutes.


Message édité par Sinner le 11-10-2007 à 13:52:15
Reply

Marsh Posté le 11-10-2007 à 14:16:32    

C'est pas un peu bourrin d'ouvrir et de fermer le fichier de sortie à chaque écriture ?
 
Tu pourrais peut-être l'ouvrir, écrire toutes tes lignes, et fermer à la fin (juste avant d'ouvrir le fichier suivant). Ca devrait être plus efficace je pense. (mais je dis peut-être des conneries parce que j'ai parcouru le code vraiment brièvement)

Message cité 1 fois

---------------
TriScale innov
Reply

Marsh Posté le 11-10-2007 à 14:23:15    

Ah peut être.
 
Je vais tester.

Reply

Marsh Posté le 11-10-2007 à 15:39:49    

bof, le problème c'est que avoir tous ces descripteurs de fichiers ouverts, tu peux vite atteindre une limite système si ton programme évolue (genre 1024 par exemple).

Message cité 1 fois
Reply

Marsh Posté le 11-10-2007 à 15:50:06    

Taz a écrit :

bof, le problème c'est que avoir tous ces descripteurs de fichiers ouverts, tu peux vite atteindre une limite système si ton programme évolue (genre 1024 par exemple).

Ouais, mais là si j'ai bien lu, il n'a besoin que d'un seul fd ouvert à la fois puisqu'il écrit dans les fichiers les uns à la suite des autres.


---------------
TriScale innov
Reply

Marsh Posté le 11-10-2007 à 15:51:30    

bah oui ... je soulignais le problème potentiel de ton idée

Reply

Marsh Posté le 11-10-2007 à 16:07:34    

Tu utilises quoi comme compilateur sur Windows ?
Les resultats attendus sont-ils correct dans les deux cas ?

Reply

Marsh Posté le 11-10-2007 à 16:25:52    

là c'est a priori limité par le E/S, le compilateur n'y peut pas grand chose.

Reply

Marsh Posté le 11-10-2007 à 16:25:52   

Reply

Marsh Posté le 11-10-2007 à 17:07:15    

Lorsque je parlais de compilateur, je pensais plus aux librairies fournies avec le compilateur.

Message cité 1 fois
Reply

Marsh Posté le 11-10-2007 à 17:35:08    

J'dit ça comme ça, mais t'es obligé de faire du C ou pas ?  
 
Non parce que avec du C++ en utilisant le fichier comme un Stream ça devrait allé pas mal plus vite. :o


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
Reply

Marsh Posté le 11-10-2007 à 17:56:22    

Olivier51 a écrit :

Lorsque je parlais de compilateur, je pensais plus aux librairies fournies avec le compilateur.


Wof, ça devrait pas différer des masses. La vraie différence, je pense qu'elle peut venir de NTFS qui aura tendance à fragmenter comme un goret, voire créera un fragment par écriture.

Reply

Marsh Posté le 11-10-2007 à 18:00:32    

192000 ouverture/ecriture/fermeture de fichier + 96 mkdir, c'est sur que c'est lent. :D


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
Reply

Marsh Posté le 11-10-2007 à 18:41:00    

franceso a écrit :

...mais je dis peut-être des conneries parce que j'ai parcouru le code vraiment brièvement...


Non non, t'as bien lu. fopen+fclose dans le while => pas tiptop
 

franceso a écrit :

Ca devrait être plus efficace je pense.


Ouaip. Avec le système de bufferisation ça ira nettement mieux. Sûrement pas aussi rapide que Linux (où le C est une seconde langue pour lui) mais entre "un fopen/fclose par boucle" et "un seul fopen/fclose par fichier" la différence sera quand-même bien visible...


Message édité par Sve@r le 11-10-2007 à 18:41:21

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 11-10-2007 à 19:02:12    

Il faudrait voir pour utiliser un outils d'analyse pour tracer le temps dans chaque fonctions, ca irait plus vite (je n'ai pas de nom en tete pour Windows).

Reply

Marsh Posté le 11-10-2007 à 21:08:19    

y'a un anti-virus sur les machines lentes ?

Reply

Marsh Posté le 11-10-2007 à 21:11:16    

Hehe ah oui ça l'antivirus sur 192000 I/O ca fait mal... surtout si c'est un truc style AVG :D


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed