Fabien LE LEZ wrote:
>> Après quelques essais, j'ai bien l'impression que parser soi-même les
>> données apporte un gain de performances assez confortable.
>
> Ça se confirme. Et je me suis aperçu que mmap() ne change pas
> grand-chose.
>
> Le code que j'avais proposé, avec une fonction main() plus standard
> (cf ci-dessous), donne d'aussi bons résultats.
>
> Manifestement, au moins dans gcc, scanf est effroyablement lent, et >>
> encore plus.
>
> Seule autre modification : dans la série "cachez ce char const* que je
> ne saurais voir", j'ai uniformisé pour n'utiliser que std::string,
> même dans Source.
>
> Voici donc un programme en C++ standard, certes un peu long, mais qui
> est très largement plus rapide que ton code en C (et, a fortiori, que
> ton code en C++).
>

C'est effectivement très rapide : de l'ordre d' 1min 6s chez moi (37.7
Millions de lignes, 1.3Go) contre 1min 35s dans la version c.

J'aurais cru que les ifstream seraient plus rapides.
En tout cas, je pense que si on décide de passer cette partie en c++, on
parsera le fichier 'à la main'.

Merci pour les conseils.

Ploc.

Fabien LE LEZ wrote:
> On Sun, 04 May 2008 19:18:40 +0200, Ploc <ploc@clop.invalid>:
>
>> La remarque sur l'extraction des labels est très interressante.
>
> Qu'est-ce que tu dois en faire exactement, de ces labels ?


Dans le format original qui est un peu plus complexe, les lignes peuvent
contenir des références à d'autres labels définis en amont pour
construire une structure d'arbre.

On Sun, 04 May 2008 19:53:16 +0200, Ploc <ploc@clop.invalid>:

>C'est effectivement très rapide : de l'ordre d' 1min 6s chez moi (37.7
>Millions de lignes, 1.3Go) contre 1min 35s dans la version c.

Quel type de machine as-tu, et quelles options de compilation
utilises-tu ?
J'obtiens un temps comparable pour ta version en C (79 secondes), mais
un temps bien plus réduit pour ma version (24 secondes).
Par contre, sans optimisation, mon programme est impressionnant de
nullité : 2 minutes 40 secondes !
Le fait que l'optimisation change considérablement le temps
d'exécution est d'ailleurs compréhensible, puisque le code fait tout
le boulot, quasiment sans appel de fonctions externes.

Ploc wrote on 04/05/2008 19:39:
>
> Malheureusement, le visual studio qu'on nous impose est loin d'etre
> aussi récent...

cl.exe version 14 n'est "que" VS 2005, cela devait être présent dans
la version 2003 également, les versions express (gratuites) peuvent
gérer certains cas, mais qu'importe puisque _s est non conforme.

Sylvain.

Fabien LE LEZ wrote:
> On Sun, 04 May 2008 19:53:16 +0200, Ploc <ploc@clop.invalid>:
>
>> C'est effectivement très rapide : de l'ordre d' 1min 6s chez moi (37.7
>> Millions de lignes, 1.3Go) contre 1min 35s dans la version c.
>
> Quel type de machine as-tu, et quelles options de compilation
> utilises-tu ?
> J'obtiens un temps comparable pour ta version en C (79 secondes), mais
> un temps bien plus réduit pour ma version (24 secondes).
> Par contre, sans optimisation, mon programme est impressionnant de
> nullité : 2 minutes 40 secondes !
> Le fait que l'optimisation change considérablement le temps
> d'exécution est d'ailleurs compréhensible, puisque le code fait tout
> le boulot, quasiment sans appel de fonctions externes.
>

Athlon XP 2500+/ 1Go RAM + DD un peu poussif (debit à 40Mo/s d'apres
hdparm -t).
Pour la compilation, c'est tout du -O2.
Il est clair que dans mon cas, ma machine de dev bloque au niveau du
debit disque + memoire. Mais je le sais et j'attendais des perfs
comparables au C, sans forcément les éclater comme c'est le cas ici.

Sans optimisation, j'obtiens >= 3min 40s.

On Sun, 04 May 2008 23:18:19 +0200, Ploc <ploc@clop.invalid>:

>Athlon XP 2500+/ 1Go RAM + DD un peu poussif (debit à 40Mo/s d'apres
>hdparm -t).

J'ai 2 Go, ce qui explique que le fichier tienne en cache chez moi et
pas chez toi. Mais...

>Il est clair que dans mon cas, ma machine de dev bloque au niveau du
>debit disque + memoire. Mais je le sais et j'attendais des perfs
>comparables au C,

....justement, time affiche (sur sa deuxième ligne) le temps processeur
réellement utilisé par le programme, ce qui, en cas d'E/S lentes, est
très inférieur à la durée entre le début et la fin de l'exécution.

On May 3, 9:46 pm, Ploc <p...@clop.invalid> wrote:
> j'ai un fichier du style :

> label 2.3 4.5 5.6
> label2 1.2 1.0 -2.
> ...

> qui est assez gros (près d'1 Go).

> J'avais un programme C à base de fscanf. En passant de C (à
> base de fscanf) à c++ avec ifstream (voir le code en bas), je
> passe de 1min 40s en C à 3min 10s en c++. Je trouve que ca
> fait un gap quand même. Comme je n'ai pas trop d'expérience
> sur les fichiers en c++, je m'en remets à vous.

> Vous pouvez me dire si vous voyez des choses à améliorer pour
> avoir de meilleures performances (plus proches du C)?

> Je joins un bout de code avec uniquement la lecture du fichier
> et l'extraction des données. Le code C fait la même chose
> mais avec fscanf et feof.

Je doute que la reste du code est identique, parce que....

> Je peux le donner si ca peut aider.

> #include <iostream>
> #include <fstream>

> using namespace std;

> int main(int argc, char ** argv)
> {
> ifstream ifs("fichier.toto");

> float x,y,z;
> string lc;

Tu ne peux pas lire un std::string avec fscanf. Il y a donc des
allocations dynamiques (probablement) ici que tu n'as pas dans
l'autre. Ce qui peut faire une différence.

(Aussi, en passant, tu n'as pas inclu <string>. L'utilisation de
std::string est donc un comportement indéfini. Mais ce n'est
certainement pas la raison de ton problème de performance.)

> int count =0;
> int i;
> while (! ifs.eof())
> {
> ifs >> lc>>x>>y>>z;

Aussi : pourquoi pas simplement :

while ( ifs >> lc >> x >> y >> z ) ...

C'est nettement plus idiomatique.

> if (!ifs.eof())
> {
> count ++;
> }
> }
> cout <<"count = "<<count<<endl;

> return 0;
> }

Selon les implémentations, il peut y avoir plus ou moins de
différences de performances entre iostream et FILE*. En général,
en faveur des FILE* (mais ce n'est pas forcement universel). Une
partie des différences, en revanche, c'est qu'on a une tendance
à utiliser des idiomes plus sûrs avec iostream, de lire dans un
std::string, par exemple, plutôt que dans un char[].

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Mon, 5 May 2008 02:42:08 -0700 (PDT), James Kanze
<james.kanze@gmail.com>:

>Selon les implémentations, il peut y avoir plus ou moins de
>différences de performances entre iostream et FILE*. En général,
>en faveur des FILE* (mais ce n'est pas forcement universel).

Ce que je ne comprends pas, c'est pourquoi mon implémentation
(bricolée en quelques minutes) est très largement plus rapide que
"operator >> (istream&, double&)".
D'autant que je commence par lire une ligne dans un string avec
getline(), puis je parse cette chaîne (en faisant les vérifications
qui vont bien), alors que operator>> ne passe pas par cette étape
intermédiaire.

Comme je ne pense pas être meilleur que les auteurs de g++ dans leur
propre domaine, je me doute qu'il y a une explication quelque part,
mais je ne vois pas où. Et on ne parle pas ici de quelques % de
différence, mais bien d'un facteur 4 (grosso modo).

Fabien LE LEZ a écrit :
> On Mon, 5 May 2008 02:42:08 -0700 (PDT), James Kanze
> <james.kanze@gmail.com>:
>
>> Selon les implémentations, il peut y avoir plus ou moins de
>> différences de performances entre iostream et FILE*. En général,
>> en faveur des FILE* (mais ce n'est pas forcement universel).
>
> Ce que je ne comprends pas, c'est pourquoi mon implémentation
> (bricolée en quelques minutes) est très largement plus rapide que
> "operator >> (istream&, double&)".
> D'autant que je commence par lire une ligne dans un string avec
> getline(), puis je parse cette chaîne (en faisant les vérifications
> qui vont bien), alors que operator>> ne passe pas par cette étape
> intermédiaire.

Peut être l'indirection causée par le codecvt. Ton code ne prends pas en
compte la localisation bien que ça n'explique pas un facteur 4.

> Comme je ne pense pas être meilleur que les auteurs de g++ dans leur
> propre domaine, je me doute qu'il y a une explication quelque part,
> mais je ne vois pas où. Et on ne parle pas ici de quelques % de
> différence, mais bien d'un facteur 4 (grosso modo).

Ou peut être il n'y a pas eu d'effort de la part des auteurs de g++ pour
optimiser iostream.

D'après B.Stroustrup, iostream est plus rapide (en théorie)
http://www.research.att.com/~bs/new_learning.pdf.

Michael

On May 5, 6:20 pm, Fabien LE LEZ <grams...@gramster.com> wrote:
> On Mon, 5 May 2008 02:42:08 -0700 (PDT), James Kanze
> <james.ka...@gmail.com>:

> >Selon les implémentations, il peut y avoir plus ou moins de
> >différences de performances entre iostream et FILE*. En général,
> >en faveur des FILE* (mais ce n'est pas forcement universel).

> Ce que je ne comprends pas, c'est pourquoi mon implémentation
> (bricolée en quelques minutes) est très largement plus rapide que
> "operator >> (istream&, double&)".
> D'autant que je commence par lire une ligne dans un string avec
> getline(), puis je parse cette chaîne (en faisant les vérifications
> qui vont bien), alors que operator>> ne passe pas par cette étape
> intermédiaire.

> Comme je ne pense pas être meilleur que les auteurs de g++ dans leur
> propre domaine, je me doute qu'il y a une explication quelque part,
> mais je ne vois pas où. Et on ne parle pas ici de quelques % de
> différence, mais bien d'un facteur 4 (grosso modo).

Est-ce que tu es sûr que ton implémentation est 100% correcte,
dans tous les cas ? Entre les options de formattage et les
problèmes d'arrondi (voir "How to read floating point numbers
accurately", de William Clinger,
http://portal.acm.org/citation.cfm?id=93557), il y a pas mal de
choses qui peuvent rendre une implémentation « correcte »
nettement moins rapide qu'une à peu près correcte. (Évidemment,
l'arithmétique entière à 64 bits, ce qui est universalement
disponible aujourd'hui, simplifie déjà beaucoup.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On May 6, 9:23 am, Michael DOUBEZ <michael.dou...@free.fr> wrote:
> Fabien LE LEZ a écrit :

> > On Mon, 5 May 2008 02:42:08 -0700 (PDT), James Kanze
> > <james.ka...@gmail.com>:

> >> Selon les implémentations, il peut y avoir plus ou moins de
> >> différences de performances entre iostream et FILE*. En général,
> >> en faveur des FILE* (mais ce n'est pas forcement universel).

> > Ce que je ne comprends pas, c'est pourquoi mon
> > implémentation (bricolée en quelques minutes) est très
> > largement plus rapide que "operator >> (istream&, double&)".
> > D'autant que je commence par lire une ligne dans un string
> > avec getline(), puis je parse cette chaîne (en faisant les
> > vérifications qui vont bien), alors que operator>> ne passe
> > pas par cette étape intermédiaire.

> Peut être l'indirection causée par le codecvt. Ton code ne
> prends pas en compte la localisation bien que ça n'explique
> pas un facteur 4.

La localisation coûte cher dans std::filebuf. Ailleurs, ça
dépend; d'après ce qu'on m'a dit, c'est possible d'en minimiser
le coût. (Au moins une personne m'a dit la même chose pour
std::filebuf. Mais il avoue que c'est assez compliqué, et que
les implémentations aujourd'hui ne le font pas.)

> > Comme je ne pense pas être meilleur que les auteurs de g++
> > dans leur propre domaine, je me doute qu'il y a une
> > explication quelque part, mais je ne vois pas où. Et on ne
> > parle pas ici de quelques % de différence, mais bien d'un
> > facteur 4 (grosso modo).

> Ou peut être il n'y a pas eu d'effort de la part des auteurs
> de g++ pour optimiser iostream.

> D'après B.Stroustrup, iostream est plus rapide (en
> théorie)http://www.research.att.com/~bs/new_learning.pdf.

Attention. La date sur cet article est 1999. Ce qui fait penser
qu'il parle des iostream classique, et non des iostream
standard. La gestion de la facette codecvt dans filebuf rend
l'optimisation nettement plus difficile.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Tue, 6 May 2008 01:35:27 -0700 (PDT), James Kanze
<james.kanze@gmail.com>:

>Est-ce que tu es sûr que ton implémentation est 100% correcte,
>dans tous les cas ?

Effectivement, c'est probablement là l'explication.

On 6 mai, 13:38, James Kanze <james.ka...@gmail.com> wrote:
> La localisation coûte cher dans std::filebuf. Ailleurs, ça
> dépend; d'après ce qu'on m'a dit, c'est possible d'en minimiser
> le coût. (Au moins une personne m'a dit la même chose pour
> std::filebuf. Mais il avoue que c'est assez compliqué, et que
> les implémentations aujourd'hui ne le font pas.)

Il y a eu un débat récemment là dessus sur les ML C++, sans pour
autant qu'un consensus clair se dégage à mon avis.

Je serais curieux de voir ce que donne le programme par exemple avec
les fastreams : http://www.msobczak.com/prog/fastreams/