Salut à tous!
 
Voici un petit programme (ne pas se préoccuper des controles d'erreurs et de l'utilité du code, ce n'est pas le but).
Sachant la manière dont tout bon compilateur C++ traite les instructions de streaming C++, et la manière dont le formattage de chaine est traité avec les fonctions C standard, à votre avis, quel devrait être la parti de code la plus rapide:
 

 
Je precise que les tests on été fait en mode release, avec "Maximize Speed" dans les settings du project.
 
Et bien avec Visual, le plus rapide c'est avec des fprintf...  
(Lancement de l'application une vingtaine de fois dans les 2 mode, avec le #if 1 ou #if 0 , et moyenne effectuée)
La différence va du simple au double (en moyenne, 2fois plus vite avec les fprintf!!!         )
 
Alors 2 choses l'une:
1) Ou bien je n'ai rien compris à la lib iostream    
2) Ou bien l'implementation de STL par Microsoft est délibéremment baclée, voir ralentie...   (sachant le support desastreux des templates par le compilo de Visual, ça ne m'etonnerait pas...)

quand tu compiles en mode DEBUG, chaque appel de routine est alourdi par des routines de protection & co...
 
dans le cas du printf, autant en DEBUG qu'en release, le code de printf utilisé est le même.
 
dans le cas des iostreams, en DEBUG c'est extrêment ralenti par rapport au release...
 
as-tu comparé en DEBUG ou en RELEASE ?

et effectivement je suis d'accord avec toi, la vitesse des iostream en debug sont une horreur....

 
Humm, oui le problème est que ce project est compilé en release avec optimisation maximum... c'est sur le debug n'est pas fait pour faire ce genre de test.
 
J'ai éditer le 1er message pour le préciser.

ca vient de deux chose:
 

• dans la version C, chaque boucle declenche 3 ecritures (3 fprintf alors que je compte 20 << dans la version C++.

si tu mets un printf par données, ca devrait aller nettement moins vite

• l'equivalence C++ de '\n' c'est '\n' et pas endl qui est en fait un '\n'+flush

oki, sympa pour le endl, je savais pas qu'il flushait tout seul

 
J'avais lu que que les streams etaient plus rapide que les fprintf du fait que dans le fprintf la chaine de caractère est interprété au runtime, alors que ce n'est pas le cas pour les streams. Je n'avais pas pensé au fait que chaque << prenait du tout vu que, en effet, ce sont des opérateurs, donc equivalent à un appel de fonction si ils ne sont pas inline.
Il doit y a voir certain cas ou tu gagnes quand même un peu.  
 
Si tu as du code de ce style qui doit être optimisé à mort, tu utiliserai quelle technique pour ecrire dans un fichier (pas d'assembleur, le code doit être multi-plateforme) ?
 
Merci beaucoup en tout cas pour cet eclairage très lumineux!!!
Faut vraiment que je mette aux STL! Voilà le gros problème d'être soit disans un spécialiste des techno Microsoft et patati et patata... c'est que t'oublie d'être un pro dans les technos de bases, parceque tu les utilises jamais! Je vais vraiment devoir remedier à ces lacunes inacceptables!  

je bufferiserais avec des ostringstream, par exemple.

 
J'vais regarder ça! Si je trouve une version qui va vraiment plus vite que les fprintf, je la posterai ici comme example...
 
Merci beaucoup!  

garde surtout a l'esprit que l'avantage du C++ ce sont aussi des E/S simplifiées

 
Oui tout à fait, mais dans ce que je recherche pour un cas précis, c'est la performance maximale avant tout et que le code soit portable, peu importe si l'approche n'est pas vraiment OO et si le source est plus complexe. En général, j'utilise la sérialization (surtout en MFC) pour stocker le contenu de mes objects... mais question perf, c'est pas ça; mais comme ce n'était pas critique jusqu'à maintenant...
 
Remarque, la serialization, même à la sauce MFC, ce n'est rien d'autre que de définir des operateur << et >> pour tes objects... j'aurai du m'en douter un peu.

Désactiver la gestion d'exception n'a rien changé, ce qui m'étonnes...
A mon avis, la STL bought-by-Microsoft ne casse pas des briques.
 
Ce serait bien d'avoir le test de quelqu'un disposant de la YASLI (Yet Another Standard Library Implementation).
(C'est la meilleure en fait)

 
ou la SGI

 
A mon avis aussi. D'ailleurs il me semble que les "fstream" sont basés sur des FILE* chez MS.
Et en général j'ai lu que les perfs des "ostream" font pas top en général (c'est de la faute des implémentations) alors qu'en théorie ca devrait être plus rapide.

 
ben ouais. apparemment MS a implémenté les stream comme des surcourches ou E/S du C ... alors ca peche.

 
et je crois que c'est un avis quasiment unanimement partagé par tous...

fprintf est sans doute plus rapide mais il n'est pas type safe.
 
si tu pars dans la performance, il faut savoir qu'il vaut toujours mieux ecrire un gros bloc d'un coup, plutot que plusieurs petits blocs et de regrouper les appels d'ecriture plutot que de les disperser dans des tas de petites fonctions.
Ce qui est un objectif qui contrarie un peu la conception objet.
 
A mon avis la lecture/ecriture la plus rapide, c'est la lecture ecriture asynchrone mais ca n'est pas disponible a ton niveau d'abstractions. De meme l'utilisation des fichiers mappes est surement preferable pour des lectures aleatoires.
 
Le fichier d'entree sortie a la C/C++ n'a pas ete pense pour les performances mais pour la standardisation du code, et celui du C++ a apporte une plus grande extensibilite et une type safety nouvelle, ce qui se traduit dans cette implantation par une perte de performance.
 
Avant de passer des jours a optimiser tes entrees-sorties demande toi aussi si cela en vaut la peine et si cela te posera probleme a ton utilisateur. Et si le surcout apporte par la maintenance de ton code sera compensee parl'augmentation des performances.
 
LeGreg

+1  

En C++ il y a souvent moyen d'avoir une conception gagnante sur tout les tableaux: plus performante, plus sûre, plus simple d'emploi, plus compacte.
 
L'inline résoud le problème de la segmentation en petite fonctions.
Un cache/buffer transparent adoucit les E/S segmentées.
 
Et il me reste bien d'autres choses à apprendre.
 
J'ai utilisé le mappage en mémoire une fois. Ça pulvérise tout le reste, et de loin.

 
vive mmap!

Non, c'était sous Fenêtres, et il faut une belle série d'APIs.
C'est bête, j'ai perdu le code.
 
Existe t'il une librairie multi-plateforme pour le mappage ?

aucune idée

 
ça utilise des fonctionalités bien spécifiques du Kernel de Windows, et je ne sais pas si il y a des implémentations digne de ce nom sur d'autres système. Et si il y en a, apportent t'elles autant de performances?
 
Sinon j'ai le code dans un bouquin, j'avais fais des essais avec, ça t'intésse?

 
Ben sous Unix il y a mmap...

Nickel alors!  

Pas la peine, je sais que j'ai le code sur une feuille de mes cours.
 
Dans une pile de 20 Kg de papier .