Sylvain SF wrote:
> Fabien LE LEZ wrote on 04/05/2008 17:40:
>>> [fscanf_s] est supporté par gcc, non ?
>> Mais du coup, ce n'est plus du C.
>
> qui, quoi ?
>
>> Et si j'ai bien saisi, l'OP a besoin de la portabilité.
>
> ces _s sont supportés par VC 14+ (second compilo listé par le PO)
> de nombreux posts (web) sur le net laissaient penser que gcc
> (et ses libraries usuelles !...) les supportaient aussi.
>
>> si on accepte ce code, il faudra refaire le test de performance.
>
> dans l'absolu oui, je commentais seulement le rique de BO.
> (ça n'impliquait pas que ce serait a priori moins ou plus rapide).
>
> Sylvain.


Malheureusement, le visual studio qu'on nous impose est loin d'etre
aussi récent...

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