Discussion :

[Charlemagne]

Malheureusement ICL coute cher (500$ si je me souviens bien).
Une version est disponible gratuitement pour la durée d'un mois, il faut faire la demande sur le site d'Intel.
Ca s'installe facilement, et il s'intègre tout seul comme un grand dans l'environnement visual. Il suffit juste de convertir le projet Visual en projet Intel (click droit sur le projet dans le 'solution explorer' de Visual.
Sinon, on peut effectivement l'utiliser en ligne de commande, ou avec NMAKE, mais c'est pas mon cas.

Il existe une version totalement gratuite sous Linux (ICC), mais mes tests de vitesse ne sont pas probants pour l'instant, tout comme GCC.

Je trouve GCC avec cygwin pas trop mal si on peut se passer de l'environnement graphique.
Sinon y'a aussi DevCpp qui utilise également GCC, qui ne semble pas trop mal pour un programme gratuit, mais j'ai jamais essayé.

[Selenite]

En fait, je ne suis pas intéressé par ICL en particulier. Je pensais qu'il y avait une méthode générale d'intégration, autre que les pénibles NMAKE. Tant pis ;-).

[Luc Hermitte]

[...Des bibliothèques ...]
Blitz++ & co sont effectivement compliquées si tu regardes le code. Certainement le prix à payer pour eliminer les temporaires inutiles et fournir une sémantique de déplacement.
Ce qui me surprend, c'est l'inadéquation avec certains processeurs. Surtout que ce genre de choses se gère côté compilateur et non côté bibliothèque C++ normalement.
Tu veux dire que même en compilant avec les bonnes options, les instructions spéciales ne sont pas utilisées ? Alors que les mêmes compilos savent profiter de ces instructions avec ta bibliothèque ?

[...de boost...]
C'est quoi le problème avec boost ? Tu n'aimes pas les design des diverses bibliothèques (pour le moins nombreuses) ? Ou c'est un problème de licence car tu suivrais saint RMS, le pape (/apotre) du GPL ?
Note en passant, une licence à la boost ou à la MIT, BSD, ... t'ouvrirais plus de portes d'utilisateurs qu'une licence GPL -- ce qui fait que je ne comprends pas trop ta remarque de dire que tu veux pouvoir capter un public.

[zdra]

J'utilise la GPL qui est déjà trop libre à mon goût.
Mais bon, il faut bien une certaine liberté, si je veux que ma bibliothêque ait une petite chance de capter au moins un petit public.

Pour une bibliotheque mieux vaut mettre sous LGPL ! La différence c'est qu'une bibli GPL ne poura pas être linkée dynamiquement avec un programme qui n'est pas GPL. Tandis que la LGPL permet à un programme non GPL de se linker dynamiquement avec ta lib.

Donc si je developpe un programme propio je peux utiliser une lib LGPL extérieur que je ne fournis pas moi meme (ou que je fournis avec code source). Si ta lib est GPL alors mon programme proprio sera automatiquement en GPL (donc plus proprio).

[JolyLoic]

J'ai jetté un petit coup d'oeil au code sous VC8 beta1, pour l'instant, il a l'air d'avoir du mal à se débrouiller avec des trucs du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
template <class T, class U>
class B
{};
 
template <class T>
class A : public B <T, typename T::subtype::subtype>
{
};

alors que ce genre de choses, il gère... J'investigue un peu...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
template <class T>
class A : public B <T, typename T::subtype>
{
};

[JolyLoic]

Bon, avec la béta 2 du produit, cette erreur disparaît. Mais il en reste d'autres, que je vais avoir du mal à regarder sans une plus profonde compréhension de la bibliothèque.

[Charlemagne]

1)Je vais y penser et me renseigner au sujet de LGPL.

2)Je trouve cool que tu t'intéresses à ma bibliothèque.

Effectivement ce genre de syntaxe est légion dans ma libairie, et j'ai pas vraiment moyen d'y renoncer. Et puis de toute façon ça parait être un bogue de visual. Je vais pas changer profondément mon code pour un bogue de Microsoft.

Si tu veux essayer de porter ma bibliothèque avec la plus récente version de Visual, n'hésite pas à me demander de l'aide.

[Charlemagne]

Réponses aux questions de Luc Hermitte

Blitzz et Co sot effectivement compliqué, mon code n'est pas simple non plus pour résoudre les temporaires. Je ne peux plus juger lequel est le plus simple, en tout cas je l'ai conçu aussi simple et extensible que possible, pour aller au dela des limites que je pensais à l'époque avoir identifiées dans Blitz,MTL,Pooma

Honnetement, je n'avais consacré à Boost que 2 ou 3 heures, donc il faut prendre ce que je dis avec des pincettes.
Dans l'ensemble je n'aime pas Boost, parceque:
-j'avais eu des difficultés d'installation à l'époque (y'a 3-4 ans). Si il faut lire plusieurs pages pour installer une bibliothèque, et que si en plus l'installation pose problème, j'abandonne assez facilement estimant que c'est pas un bon signe.
-Boost est très hétéroclite, et pas vraiment programmée sur le modèle de la STL (beaucoup de 'cpp').
-J'avais à l'époque regarder Boost pour ces 'smart pointeurs'. Mais le concept m'avait paru plutôt compliqué, peu performant et j'étais pas certain que ça marche avec des classes de base (copier la bonne class dérivee, appeler le destructeur virtuel...). J'ai alors programmé les "smart pointeurs" moi-même et je le regrete pas (cf fichier "memory.h", non documenté).


Je crois que je vais rester sur ma décision du GPL. Le LGPL ne semble pas avoir de sens pour une bibliothèque (quasiment) uniquement basée sur des templates, donc pas vraiment 'linkable'.

[Charlemagne]

Ce qui me surprend, c'est l'inadéquation avec certains processeurs. Surtout que ce genre de choses se gère côté compilateur et non côté bibliothèque C++ normalement.
Tu veux dire que même en compilant avec les bonnes options, les instructions spéciales ne sont pas utilisées ? Alors que les mêmes compilos savent profiter de ces instructions avec ta bibliothèque ?

C'est faire beaucoup trop confiance au compilateur. Il est totalement incapable de comprendre un quelconque algorithme.
Il ne sont capable que d'optimiser l'agencement dans les registres, inliner les fonctions... Bref des optimisations locales.

Par exemple, pas la peine d'escompter qu'un quelconque calcul sera n fois plus rapide parce que l'otion MMX/SSE est donnée au compilateur.
Par contre ma bibliothèque peut découper les données en paquets (cf fonction simd_block), chaque paquet étant un registre MMX/SSE

[Charlemagne]

LoicJoly, J'ai connu quelqu'un avec les mêmes nom/prénom.
C'est un pseudo, ou ton vrai nom? Dans ce cas tu viendrais pas d'un bled de Lorraine, Blénod?

[Luc Hermitte]

Honnetement, je n'avais consacré à Boost que 2 ou 3 heures, donc il faut prendre ce que je dis avec des pincettes.
Dans l'ensemble je n'aime pas Boost, parceque:
[...]
a-Boost est très hétéroclite, et pas vraiment programmée sur le modèle de la STL (beaucoup de 'cpp').
b-J'avais à l'époque regarder Boost pour ces 'smart pointeurs'. Mais le concept m'avait paru plutôt compliqué, peu performant et j'étais pas certain que ça marche avec des classes de base (copier la bonne class dérivee, appeler le destructeur virtuel...). J'ai alors programmé les "smart pointeurs" moi-même et je le regrete pas (cf fichier "memory.h", non documenté).

(c) Je crois que je vais rester sur ma décision du GPL. Le LGPL ne semble pas avoir de sens pour une bibliothèque (quasiment) uniquement basée sur des templates, donc pas vraiment 'linkable'.

a- Tout à fait, très hétéroclite, mais au contraire de toi, je la trouve très STL-like (sauf quand il n'y en a pas besoin, certains parlent de l'inutilité d'itérateurs dans la MTL). Les itérateurs sont au coeur de beaucoup de bibliothèques. Une va même au delà en proposant des facilités pour écrire simplement nos propres itérateurs.
Mais il faut dire, que j'y ai trouvé des changements intéressants depuis leur début.

b- Ca marche très bien maintenant. Avoir un type dérivé n'a jamais posé de problème (ca marche même avec std::auto_ptr<>), quant au downcasting, je ne sais plus si il y étais au début ou s'il est arrivé en cours de route.
Faut aussi noter que malgré le nom, ils ont un petit côté smart/scoped/.../_ressource<> au delà de _ptr<>

c- Il faut que je relise tout cela. Je crains que le GPL interdise l'utilisation d'une bibliothèque (100% template ou non) dans un projet propriétaire. Le LGPL sert tout particulièrement aux bibliothèques. Est-ce pour cela que boost, Adam&Eve, ... utilisent d'autres licence ? Je vais reregarder.

[Charlemagne]

Je crains que le GPL interdise l'utilisation d'une bibliothèque (100% template ou non) dans un projet propriétaire

Je crois bien aussi, et c'est bien mon but.

Si quelqu'un veut utiliser ma bibliothèque, il doit rendre public son code, ou alors je veux des royalities. Je trouve que c'est honnête.

Là ou je trouve la GPL un peu trop libre, c'est qu'une entreprise peut fabriquer un produit intégrant ma bibliothèque et le vendre. Mais bon, il faut quand même qu'elle rende son code public.

Enfin... c'est de la théorie. En pratique y'a surement souvent des copier-coller de code, ni vu ni connu...

[JolyLoic]

LoicJoly, J'ai connu quelqu'un avec les mêmes nom/prénom.

Par contre, je ne pense pas avoir connu quelqu'un se prénommant Charlemagne...

C'est un pseudo, ou ton vrai nom?

C'est mon vrai nom.

Dans ce cas tu viendrais pas d'un bled de Lorraine, Blénod?

Pas à 100%, puisque je suis originaire de Jezainville... (Pour ceux qui connaissent pas, c'est un bled encore plus petit à côté de Blénod). Je propose qu'on continu les retrouvailles en message privé, parce que je ne suis pas certain que ça intéresse tout le monde ici, ces réunions d'"anciens combattants"...

[Charlemagne]

Sacré hasard.
On était sur les mêmes bancs, de la maternelle au CM2 !!
A tout de suite en privé

[Charlemagne]

Ma Bibliothèque mathématique est enfin compatible avec Visual 2005 beta 2 (VC8b2).
Vous trouverez un projet pour VC8 à télécharger sur mon site:
http://www.ient.rwth-aachen.de/team/laurent/genial/genial.html

Il y a néanmoins quelques restrictions avec VC8:
- Elle est entièrement compilable uniquement en mode 'release'. Il semble y avoir un sérieux bogue dans VC8b2, puisque dans mon implémentation de la FFT, le compilateur essaye en mode 'debug' d'appeler l' 'operator=' plutôt qu'un constructeur !!! Ce bogue de Visual ne devrait pas trop gêner dans l'utilisation de la bibliothèque. Je n'ai pas réussi en moins de 20 mn à reproduire l'erreur dans un exemple simple afin de le poster à Microsoft: Avis aux amateurs...
- Quelques optimisations ne sont pas disponibles. Ceci est dû à un bogue de VC8b2, qui est déjà corrigé dans la version finale (d'après le service de Microsoft).
- Des warnings que je considère comme superflus, voire erronés.


Je donne un exemple de programme consistant à calculer 1000 fois une FFT d'une matrice réelle 256x256
A titre de comparaison, j’obtiens les résultats suivants sur un Pentium 4 3.2GHz:
- Intel C++ Compiler(ICL): 1.17ms/matrice avec SSE
- Visual 2005 beta 2: 2.85ms/matrice avec SSE
En ce qui me concerne, ICL a encore de beaux jours devant lui. D'autres essais sont encore bien moins avantageux pour VC8. Et en plus ICL compile beaucoup plus vite!
A moins que quelqu'un n'ait un meilleur paramétrage de VC8 à me proposer...

La FFT sans SIMD est extrêmement lente avec VC8, ceci est en bonne partie dû à la mauvaise STL de microsoft. Je vous conseille d'installer www.STLport.org, dont l'arithmétique des nombres complexes est beaucoup plus rapide. Malheureusement STLport ne se laisse pas encore compiler avec VC8, j'y travaille...


Un lien sur ma bibliothèque est dorénavant disponible sur Developpez (Rubrique C/C++ -> Bibliothèques):
http://c.developpez.com/bibliotheques/

Pour tout problème, remarque, question, suggestion, n'hésitez pas à me contacter...

PS: VC8b2 est téléchargeable à http://lab.msdn.microsoft.com/express/visualc/default.aspx

[Charlemagne]

Les versions betas des compilateurs d'Intel sont disponibles sur:

http://www.intel.com/software/products/compilers/beta/compilers9beta.htm

L'essayer, c'est l'adopter.
Non, je n'ai pas d'action chez Intel.

[Selenite]

Beau boulot ;-). Je n'ai pas pu tester car je n'ai pas VC8, mais félicitation pour cet effort de compatibilité.

Par contre, je en comprend pas, VC est prèt de deux fois plus rapide que ICL, mais tu préfère toujours ce dernier... A moins que tu n'ais inversé les deux dons ton post.

[Charlemagne]

Beau boulot ;-). Je n'ai pas pu tester car je n'ai pas VC8, mais félicitation pour cet effort de compatibilité.

Merci pour tes encouragements.
Tu peux télécharger VC8b2 sur http://lab.msdn.microsoft.com/express/visualc/default.aspx , mais c'est un peu long.

Par contre, je en comprend pas, VC est prèt de deux fois plus rapide que ICL, mais tu préfère toujours ce dernier... A moins que tu n'ais inversé les deux dons ton post.

Non, non, c'est bien ICL qui est environ 2.5 fois plus rapide. (J'avais effectivement tout d'abord échangé les 2 mesures par inadvertance, mais j'avais corrigé dans la demi-heure qui a suivi)
Et encore, en général l'écart est nettement plus grand dans d'autres configurations de la FFT.

[Selenite]

Par contre, je en comprend pas, VC est prèt de deux fois plus rapide que ICL, mais tu préfère toujours ce dernier... A moins que tu n'ais inversé les deux dons ton post.

Non, non, c'est bien ICL qui est environ 2.5 fois plus rapide. (J'avais effectivement tout d'abord échangé les 2 mesures par inadvertance, mais j'avais corrigé dans la demi-heure qui a suivi)
Et encore, en général l'écart est nettement plus grand dans d'autres configurations de la FFT.

Au temps pour moi. J'avais mal lu: je croyais que c'était VC le plus rapide.

[Charlemagne]

Ca a été un peu plus long que prévu, mais ça y est: j'ai réussi à compiler STLport avec VC8 beta 2.

Pour ma bibliothèque ça apporte un gain de vitesse significatif sur les calculs complexes (environ 3x pour la FFT sans instructions SSE).

ICL (Intel C++ compiler) reste néanmoins toujours imbattable.
Temps d'execution d'une FFT sans instructions SIMD d'une matrice 256x256:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
-ICL   + STLport      :  2.1 msec/matrice
-VC8b2 + STLport      :  5.0 msec/matrice
-VC8b2 + STL d'origine: 12.4 msec/matrice

Pour rappel les temps d'execution avec SSE:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
-ICL   :  1.17 msec/matrice
-VC8b2 :  2.85 msec/matrice

Etapes de l'installation de STLport avec VC8b2:
1) Télécharger et installer Micorsoft SDK (qui n'est pas fournit avec VC8b2)
2) Télécharger la version CVS de la branche 5.0 de STLport avec:
cvs -d :pserver:cvs@cvs.stlport.com:/stlport login
cvs -d :pserver:cvs@cvs.stlport.com:/stlport checkout -r STLPORT_5_0 STLport
3) lancer la fenêtre de commandes DOS
4) executer 'vcvars32.bat' dans 'Microsoft Visual Studio 8\VC\bin'
5) changer 2 variables d'environnement avec qqch comme:
set INCLUDE=C:\Program Files\Microsoft SDK\Include;%INCLUDE%
set LIB=C:\Program Files\Microsoft SDK\Lib;%LIB%
6)Dans le répertoire STLport/build/lib exécuter les commandes:
nmake -f nmake-vc8.mak dbg-static
nmake -f nmake-vc8.mak release-static
7)déplacer les fichiers stlport_static_d50 et stlport_static_r50 dans le répertoire STLport/lib/vc8
8)Dans le projet de VC8b2, pour les modes debug/release:
-ajouter le chemin STLport/stlport/ pour les includes
-ajouter le chemin STLport/lib/vc8/ pour les librairies
9) S'assurer dans les modes debug/release que la génération de code est bien 'Multi-threaded debug/Multi-threated' (plutôt que 'Multithread Debug DLL')