IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Pourquoi la programmation fonctionnelle n’est-elle pas la norme de l’industrie du code ?


Sujet :

Débats sur le développement - Le Best Of

  1. #41
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par fredoche Voir le message
    je vois pas en quoi le fonctionnel pèserait sur la performance ?
    Si on applique le style fonctionnel jusqu'au bout alors, au niveau des collections, pour éviter la muabilité, on n'utilise que des structures de données persistantes. Ce sont des structures de données telles que, quand on veut "modifier" une collection, on en crée une nouvelle qui partage la majorité de son contenu avec l'ancienne. Pour les performances, ce ne sont généralement pas les structures de données les plus judicieuses. Par exemple, si on veut retrier les éléments d'une collection en fonction d'un critère donné, la structure de donnée idéale pour cette opération sera un tableau muable ou un vecteur muable.

  2. #42
    Membre extrêmement actif
    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    1 616
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 616
    Points : 3 965
    Points
    3 965
    Par défaut
    C'est de la théorie ça non ?

    Moi aussi je programmais avec ces idées là il y a 20 ans, quand j'avais un serveur du genre avec un pentium pro à 200 MHz et grassement 64 Mo de RAM, pour servir des sites ou des intranets européens. Des machines qui faisaient un demi mètre cube

    Mais c'est de la théorie, n'est ce pas ? qui s'appliquent dans quels cas concrets quand on passe au réel aujourd'hui ? Où on va dimensionner pour ce qui va réellement être utilisé, où toute l'architecture logicielle et matérielle va être découpée, où on peut bosser sur du cloud qui va grossir à la demande, où on peut carrément faire tourner les fonctions en stand-alone avec des structures comme AWS lambda.

    Le moindre serveur dédié à 100€/mois, tu as 8 coeurs/16 threads et 64 Go de RAM sur un lien gigabit. J'ai 1000 fois le serveur que j'utilisais il y a 20 ans en une seule machine.

    On a des langages avec des garbage collector optimisés.

    Pour moi à vous lire on applique un raisonnement générique dénué de contexte. Il est probable que cela s'applique dans certains voir beaucoup de contextes, mais de là à en faire une généralité sur la notion de "programmation fonctionnelle" et de performance... ?
    Et quand on se met à manipuler de grosses structures de données, je ramène ma question, mais est-ce que l'environnement programmatique standard du langage lui-même est réellement pertinent ? Quand on a des outils comme les SGBD relationnels ou non ? Question d'architecture. Ces derniers apportent beaucoup d'autres services au delà de la persistance
    Émotion
    Infantilisation
    Culpabilisation

    Christophe Alévèque - 18 Mars 2021

  3. #43
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Aujourd'hui, en informatique de gestion, la majorité des applications n'ont pas besoin de performances si élevées que la programmation fonctionnelle poserait des problèmes de performances. On est d'accord. Sinon, on coderait tout dans des langages sans ramasse-miettes comme C et C++. D'ailleurs, en ce moment, je code en Python, qui est un langage lent.

    Mais c'est el_slapper qui a commencé à parler de performances dans ce fil, dans un contexte où un traitement qui prenait quelques heures quand il était codé en COBOL prenait plusieurs jours en Java. Dans un tel contexte, dire que le fonctionnel peut poser des problèmes de performances est probablement justifié.

  4. #44
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    D'ailleurs, en ce moment, je code en Python, qui est un langage lent.
    Hum...

    C'est ce que j'aurais pensé il y a encore quelques jours, mais Python peut faire des calculs sur GPU avec PyTorch/TensorFlow de manière très très intelligente.
    Sans aller jusqu'à du calcul sur GPU, numpy peut aussi être très intelligent si bien installé. Pour obtenir des performances similaires en C/C++ tout en gardant un code portable... il faut utiliser des bibliothèques dédiées.

    À ce niveau là les bibliothèques utilisées importent bien plus que le langage.


    Je pense que la différence est plus que négligeable dans ces cas de figures, et ce qui importera sera plus le temps de développement.
    Sachant qu'au pire on peut toujours essayer de compiler le code python au lieu de directement l'interpréter.


    Pour les cas plus "généraux", je pense qu'on est d'accord sur le fait que python sera légèrement plus lent que C/C++, mais que cela n'est pas très important au vu des machines actuelles, et qu'il y a d'autres facteurs plus limitants comme les I/O, la complexité de l'algo implémenté, etc.

  5. #45
    Membre chevronné
    Avatar de emixam16
    Homme Profil pro
    Chercheur en sécurité
    Inscrit en
    Juin 2013
    Messages
    333
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Chercheur en sécurité

    Informations forums :
    Inscription : Juin 2013
    Messages : 333
    Points : 1 827
    Points
    1 827
    Par défaut
    Citation Envoyé par neckara
    C'est ce que j'aurais pensé il y a encore quelques jours, mais Python peut faire des calculs sur GPU avec PyTorch/TensorFlow de manière très très intelligente.
    Sans aller jusqu'à du calcul sur GPU, numpy peut aussi être très intelligent si bien installé. Pour obtenir des performances similaires en C/C++ tout en gardant un code portable... il faut utiliser des bibliothèques dédiées.
    Pour les Pytorch/Tensorflow toutes les opérations nécessitant de la performance sont écrites en C++, le python est juste là sous forme de surcouche (binding) pour que ces frameworks soient utilisables facilement. Du coup certes tu utilises du Python, mais une bonne partie des calculs sont faits dans un langage "rapide" en interne.

    Ceci dit, je te rejoins complétement quand tu dis que l'algo peut être plus important que le langage: un bon code python peut être plus rapide qu'un mauvais code c++.

  6. #46
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par emixam16 Voir le message
    Pour les Pytorch/Tensorflow toutes les opérations nécessitant de la performance sont écrites en C++, le python est juste là sous forme de surcouche (binding) pour que ces frameworks soient utilisables facilement. Du coup certes tu utilises du Python, mais une bonne partie des calculs sont faits dans un langage "rapide" en interne.
    Complètement d'accord. Beaucoup de devs citent ces libs pour dire que python peut être performant. Mais pytorch c'est 50% de C++ et 30% de python, tensorflow c'est 60% de C++ et 30% de python. Ca n'enleve rien à l'intérêt de python mais il ne faut pas oublier que c'est surtout la combinaison python/c++ qui est intéressante au final.

  7. #47
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par emixam16 Voir le message
    Pour les Pytorch/Tensorflow toutes les opérations nécessitant de la performance sont écrites en C++, le python est juste là sous forme de surcouche (binding) pour que ces frameworks soient utilisables facilement. Du coup certes tu utilises du Python, mais une bonne partie des calculs sont faits dans un langage "rapide" en interne.
    J'ai envie de dire oui, mais non. C'est mon côté enculeur de mouche.

    La surcouche ne se contente pas de faire du binding, mais va aussi fournir une interface et va chercher parmi les bibliothèques installées, celles qui sont les plus adaptées à l'architecture/environnement d'exécution (notamment pour numpy).
    Pour les calculs sur GPU, tu vas aussi avoir des optimisation d'arbres d'exécutions, ceci dit, l'optimisation est peut-être codée en C/C++ derrière.


    Après les bibliothèques utilisée peuvent en effet être écrites en C/C++, mais aussi en assembleur, FORTRAN, ou que sais-je encore.
    J'ai envie de dire que le langage dans lequel est codé la bibliothèque que tu utilises importe peu. Si tu as une bonne bibliothèque, tu peux coder dans le langage que tu veux quitte à faire quelques bindings toi-même.
    À partir de là, si tu codes en natif (C/C++/ASM/Java -pour certains processeurs ?-) ou dans un langage interprété (JS/Python/Lua), la différence en terme de vitesse d'exécution risque d'être nnégligeable ou peu pertinante, et ce qui importe sera plus la rapidité/confort de développement.

    Disons que ma logique est de dire que dans le cas général, tu utilises les bibliothèques, tu ne les développes pas (on va éviter de recoder TensorFlow/PyTorch ), et le langage dans laquelle ta bibliothèque a originellement été écrite ne conditionne pas nécessairement le langage que tu vas utiliser.



    EDIT: J'ajoute aussi que même si C++ est utilisé dans un bibliothèqe Python, cela ne signifie pas pour autant que tu aies à disposition une bibliothèque équivalente en C++.
    Donc potentiellement, des choses que soit tu ne pourras pas utiliser, soit qu'il te faudra recoder, soit qui sera plus ou moins instable.

    Notamment pour TensorFlow, l'API C++ (utilisation, pas serving), n'a pas de garantie de stabilité.
    https://www.tensorflow.org/api_docs


    Ce que je voulais dire, c'est que ce qui importe est plus la bibliothèque (peut importe son langage), que le langage via lequel tu utilises cette bibliothèque, la différence de perfs dans ces cas là étant pas énormes, les opérations "sensibles" étant généralement pris en charge par la bibliothèque. Après oui, je suis d'accord que si vous développez une bibliothèque il peut être intéressant de faire des bouts en C++. Mais pour des calculs vraiment intensifs, ces bibliothèques existent normalement déjà, donc il n'y a pas besoin de les redévelopper.

  8. #48
    Futur Membre du Club
    Homme Profil pro
    Développeur multimédia
    Inscrit en
    Juin 2016
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur multimédia
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juin 2016
    Messages : 3
    Points : 7
    Points
    7
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Hum...

    C'est ce que j'aurais pensé il y a encore quelques jours, mais Python peut faire des calculs sur GPU avec PyTorch/TensorFlow de manière très très intelligente.
    Sans aller jusqu'à du calcul sur GPU, numpy peut aussi être très intelligent si bien installé. Pour obtenir des performances similaires en C/C++ tout en gardant un code portable... il faut utiliser des bibliothèques dédiées.

    À ce niveau là les bibliothèques utilisées importent bien plus que le langage.


    Je pense que la différence est plus que négligeable dans ces cas de figures, et ce qui importera sera plus le temps de développement.
    Sachant qu'au pire on peut toujours essayer de compiler le code python au lieu de directement l'interpréter.


    Pour les cas plus "généraux", je pense qu'on est d'accord sur le fait que python sera légèrement plus lent que C/C++, mais que cela n'est pas très important au vu des machines actuelles, et qu'il y a d'autres facteurs plus limitants comme les I/O, la complexité de l'algo implémenté, etc.
    Oui, sans oublier que c'est surtout l'implémentation de base de python (CPython) qui est réputée de lente alors que d'autres implémentations utilisant la compilation JIT, comme PyPy par exemple, permettent palier ce problème.

  9. #49
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Ce sont des structures de données telles que, quand on veut "modifier" une collection, on en crée une nouvelle qui partage la majorité de son contenu avec l'ancienne.
    Oui mais ça fait bien longtemps que les compilateurs "fonctionnels" optimisent la gestion mémoire, par exemple en réutilisant les zones mémoires ou avec des optimisations internes à base de mutables.

  10. #50
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Oups... j'ai édité mon message pendant que vous répondiez.


    Je vous met l'edit ici pour ceux qui seraient passé à côté.
    Citation Envoyé par Neckara Voir le message
    EDIT: J'ajoute aussi que même si C++ est utilisé dans un bibliothèqe Python, cela ne signifie pas pour autant que tu aies à disposition une bibliothèque équivalente en C++.
    Donc potentiellement, des choses que soit tu ne pourras pas utiliser, soit qu'il te faudra recoder, soit qui sera plus ou moins instable.

    Notamment pour TensorFlow, l'API C++ (utilisation, pas serving), n'a pas de garantie de stabilité.
    https://www.tensorflow.org/api_docs


    Ce que je voulais dire, c'est que ce qui importe est plus la bibliothèque (peut importe son langage), que le langage via lequel tu utilises cette bibliothèque, la différence de perfs dans ces cas là étant pas énormes, les opérations "sensibles" étant généralement pris en charge par la bibliothèque. Après oui, je suis d'accord que si vous développez une bibliothèque il peut être intéressant de faire des bouts en C++. Mais pour des calculs vraiment intensifs, ces bibliothèques existent normalement déjà, donc il n'y a pas besoin de les redévelopper.

  11. #51
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Neckara Voir le message
    J'ai envie de dire oui, mais non. C'est mon côté enculeur de mouche.
    ....
    Désolé mais tout ça c'est de la rhétorique. Les performances de pytorch/tensorflow viennent de la partie C++, point. Citer ces libs pour justifier que "python peut être performant", c'est juste malhonnête. Sinon autant dire que C++ est facile d'utilisation parce c'est facile d'écrire un script python qui utilise pytorch/tensorflow...

  12. #52
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Désolé mais tout ça c'est de la rhétorique. Les performances de pytorch/tensorflow viennent de la partie C++, point. Citer ces libs pour justifier que "python peut être performant", c'est juste malhonnête. Sinon autant dire que C++ est facile d'utilisation parce c'est facile d'écrire un script python qui utilise pytorch/tensorflow...
    Ah ben dans ce cas, t'as pas le droit de dire que C/C++ est performant, car ils utilisent des libs en ASM/FORTRAN.

    Si on veut aller par là, on peut même dire que C/C++ n'est pas exécuté comme ça, mais est compilé en ASM/LLVM.



    Franchement quand je code un logiciel en Python, qu'est-ce que j'en ai à faire que la bibliothèque que j'utilise soit codé en C/C++, ASM, BrainFuck, ou que sais-je-encore.
    Ce qui compte c'est la vitesse d'exécution de mon application finale par rapport à mes besoins.

    EDIT: Surtout si c'est pour que derrière mon appli passe 90% de son temps à attendre des I/O.

  13. #53
    Membre extrêmement actif
    Profil pro
    Inscrit en
    Décembre 2003
    Messages
    1 616
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 616
    Points : 3 965
    Points
    3 965
    Par défaut
    Oui donc en gros de l'architecture logicielle, et utiliser le meilleur de chaque composant/service/library...

    Neckara, tente l'asynchrone, si 90% de ton temps, c'est attendre des I/O. JS fait ça très bien

    Et la programmation fonctionnelle n'aura que peu d'influence sur ces facteurs en fin de compte
    Émotion
    Infantilisation
    Culpabilisation

    Christophe Alévèque - 18 Mars 2021

  14. #54
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par fredoche Voir le message
    Neckara, tente l'asynchrone, si 90% de ton temps, c'est attendre des I/O. JS fait ça très bien
    Ce n'est pas tout à fait ce que je voulais dire.
    Je pensais plus au cas où tu attends une I/O sans avoir à faire d'autres choses à côté.


    Par exemple, je lances un calcul sur le GPU, j'attends la réponse, et puis j'ai fini. Une grosse partie de mon temps sera d'attendre le GPU.
    Un autre exemple pour une GUI, j'attends un événement utilisateur afin de modifier l'état de mon application, une grosse partie du temps, je n'ai juste rien à faire à part attendre un événement.
    Idem pour un serveur web, je vais attendre qu'une personne me demande une page.

    Ce qui n'empêche pas de faire des opérations en parallèle, mais quand y'a rien à faire, y'a rien à faire.




    Au passage pour préciser ma réponse sur le débat Python/C++/ASM, faut pas oublier que les bibliothèques de calculs ont ultimement une couche ASM afin d'utiliser des instructions particulières spécifique au matériel, notamment des instructions de calculs sur matrices/vecteurs, qui se feront bien plus rapidement qui si on les codes directement en C/C++.

  15. #55
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Neckara Voir le message
    Au passage pour préciser ma réponse sur le débat Python/C++/ASM, faut pas oublier que les bibliothèques de calculs ont ultimement une couche ASM afin d'utiliser des instructions particulières spécifique au matériel, notamment des instructions de calculs sur matrices/vecteurs, qui se feront bien plus rapidement qui si on les codes directement en C/C++.
    Ok tu m'as convaincu : gcc n'est pas capable de générer du SSE et pytorch/tensorflow reposent sur des grosses libs ASM sans lesquelles on aurait des perfs pourries.

    Et si on revenait au sujet de la discussion qui est l'utilisation de la programmation fonctionnelle ?

  16. #56
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Ok tu m'as convaincu : gcc n'est pas capable de générer du SSE et pytorch/tensorflow reposent sur des grosses libs ASM sans lesquelles on aurait des perfs pourries.
    GCC est capable d'utiliser quelques instructions SSE, mais :
    • expliciter aide à l'optimisation, GCC n'est ni magique ni devin ;
    • pas sûr que GCC supporte toutes les instructions de ton CPU, même avec -Ofast -march=native.


    Notamment pour les opérations BLAS, il est courant que les fondeurs les implémentent (pas forcément toutes) sous forme d'instruction processeur et proposent une bibliothèque pour les utiliser (et implémenter les manquantes de manière optimisées) :
    Most libraries that offer linear algebra routines conform to the BLAS interface, allowing library users to develop programs that are agnostic of the BLAS library being used. Examples of BLAS libraries include: AMD Core Math Library (ACML), ATLAS, Intel Math Kernel Library (MKL), and OpenBLAS.
    Ce ne sont généralement pas des bibliothèques énormes, le nombre d'instruction BLAS n'est pas infini :
    https://www.netlib.org/blas/#_blas_routines

    Tu dois en avoir à peine 150, à chaque fois, c'est quelques lignes à peine. En revanche, ça va être les briques de bases par dessus lesquelles tu vas tout construire.
    GCC ne pourra pas deviner certaines choses si tu ne lui dis pas. Par exemple, il ne peut pas deviner que ta matrice est triangulaire, symétrique, ou hermitien, si tu ne lui dit pas. De même il ne lui sera pas toujours facile de détecter l'algorithme que tu appliques sur ta matrice.

    Ce n'est pas pour rien que le fait d'installer ces bibliothèques augmentent de manière très significatives les performances de numpy.


    Pour Torch/TensorFlow, tu as de bien meilleures performances grâce à CUDA (AMD) que si tu utilisais directement OpenCL, qui n'a pas toutes les instructions de CUDA.
    Pour Intel, c'est apparement clGPU, cependant pour utiliser PyTorch avec intel : https://software.intel.com/en-us/art...ion-of-pytorch

    D'ailleurs, CUDA, tu ne peux pas compiler avec GCC, il te faut utiliser nvcc. Le langage étant même "C for CUDA", ce n'est pas du "vrai" C.


    Bon… j'ai appris tout cela il n'y a que quelques jours à peine.

  17. #57
    Membre averti
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    181
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 181
    Points : 419
    Points
    419
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    Ok tu m'as convaincu : gcc n'est pas capable de générer du SSE et pytorch/tensorflow reposent sur des grosses libs ASM sans lesquelles on aurait des perfs pourries.

    Et si on revenait au sujet de la discussion qui est l'utilisation de la programmation fonctionnelle ?
    Ceci-dit quand je lis un exemple de code gcc/SSE, je me dis que ce n’est pas loin de l’assembleur

    __m128d mm_a = _mm_load_pd( &a[i] );
    _mm_prefetch( &a[i+4], _MM_HINT_T0 );
    __m128d mm_b = _mm_load_pd( &b[i] );
    _mm_prefetch( &b[i+4] , _MM_HINT_T0 );
    __m128d mm_c = _mm_load_pd( &c[i] );
    _mm_prefetch( &c[i+4] , _MM_HINT_T0 );
    __m128d mm_r;
    mm_r = _mm_add_pd( mm_a, mm_b );
    mm_a = _mm_mul_pd( mm_r , mm_c );
    _mm_store_pd( &r[i], mm_a );
    Pour revenir au langage fonctionnel, rappelons que Ocaml compilé obtient de très bonnes performances. Une des raisons possibles est le typage statique où toutes les vérifications de type sont faites à la compilation et non à l’exécution.

    La page http://blog.gmarceau.qc.ca/2009/05/s...ty-of.html?m=1 qui compare les langages par performance et concision du code place Ocaml très bon sur ces deux axes. Haskell compilé par GHC et Clean sont pas mal aussi en matière de performance.

  18. #58
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par floyer Voir le message
    Ceci-dit quand je lis un exemple de code gcc/SSE, je me dis que ce n’est pas loin de l’assembleur
    Oui, je sais, ma remarque précédente était ironique. En fait, ça fait des années que je bosse sur des calculateurs CPU et GPU, notamment avec tensorflow et pytorch, mais je ne me sentais pas trop d'entamer une discussion stérile et hors-sujet où Neckara m'aurait appris mon boulot, du haut de son expérience d'une semaine.

    Citation Envoyé par floyer Voir le message
    Pour revenir au langage fonctionnel, rappelons que Ocaml compilé obtient de très bonnes performances. Une des raisons possibles est le typage statique où toutes les vérifications de type sont faites à la compilation et non à l’exécution.

    La page http://blog.gmarceau.qc.ca/2009/05/s...ty-of.html?m=1 qui compare les langages par performance et concision du code place Ocaml très bon sur ces deux axes. Haskell compilé par GHC et Clean sont pas mal aussi en matière de performance.
    Merci pour ces infos. Ton lien date de 2009, ce serait intéressant de voir comment ça a évolué. Et effectivement, on ne pense pas forcément au fonctionnel pour faire du calcul intensif mais il y a des gens qui font ça. Par exemple avec ocaml : Jane Street, owl https://ocaml.xyz/ ...

  19. #59
    Inactif  


    Homme Profil pro
    Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Inscrit en
    Décembre 2011
    Messages
    9 012
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Doctorant sécurité informatique — Diplômé master Droit/Économie/Gestion
    Secteur : Enseignement

    Informations forums :
    Inscription : Décembre 2011
    Messages : 9 012
    Points : 23 209
    Points
    23 209
    Par défaut
    Citation Envoyé par SimonDecoline Voir le message
    En fait, ça fait des années que je bosse sur des calculateurs CPU et GPU, notamment avec tensorflow et pytorch, mais je ne me sentais pas trop d'entamer une discussion stérile et hors-sujet où Neckara m'aurait appris mon boulot, du haut de son expérience d'une semaine.
    Dans ce cas tu dois très bien connaître les libs constructeurs que je cites, et savoir qu'ultimement, ce sont des briques de bases écrites en assembleur.

    Ou alors tu vas me dire que GCC supporte les instructions BLAS ? Dans ce cas il faudra m'expliquer pourquoi on s'emmerde à installer ces bibliothèques constructeurs ?
    Mais aussi et surtout pourquoi ces bibliothèques nous font gagner en perfs comparé à du pur C/C++ compilés avec GCC ???


    Pour ton expérience, si ce n'est que TensorFlow/PyTorch, ce n'est guère plus de 2 ans, si tu étais sur Distbelief avant, 8 à 9 ans.
    Mon expérience d'une semaine, ce n'est pas juste lire un tutoriel sur Internet. J'ai justement demandé conseil à une personne qui travaille dans l'optimisation depuis une bonne décennie, et dont la compétence n'est plus à démontrer. C'est justement cette personne qui, entre autre, m'a parlé de la problématique BLAS, en me montrant plusieurs ressources. Je ne fais donc pas que répéter ce qu'elle m'a dit, j'ai compris et intégré ce qu'elle ma dit.

    Bref, ce n'est pas parce que je n'ai qu'une semaine d'expérience d'utilisation que je raconte de la merde.



    D'ailleurs ironiquement, tu utilises TensorFlow et PyTorch… mais attends… ça veut dire que tu utilises du Python !
    Faut pas utiliser un langage aussi lent, d'autant plus pour des calculs intensifs comme ça, utilises donc plutôt l'API C++ tu gagneras en perfs…
    Oups… les API C++ dans les deux cas n'ont pas de garantie de stabilité. C'pas grave, recode ta propre API où tu pourras garantir ta propre stabilité.
    Tu seras bien plus rapide à l'exécution, tu pourras même gagner jusqu'à 1s d'exécution sur les 168h de ton calcul… ça en valait vraiment la peine de passer 2 ans à recoder ta propre API, à l'optimiser, et à devoir la maintenir au fil du temps.


    C'est vrai que je dois être super inexpérimenté de dire qu'on s'en fout du langage, qu'on s'en fout de ces 1s de temps d'exécution supplémentaire, et que ce qui importe, c'est surtout la bibliothèque qui te permet de faire tes 400 semaines de calculs en à peine 168h. Et qu'à 1s près de lenteur d'exécution, c'est négligeable.

    Il faudra aussi me dire comment TensorFlow/PyTorch arrivent à utiliser le GPU en pur C/C++. Je ne savais pas que les GPU interprétaient directement du C/C++.
    Ah non je suis con, c'est compilé en ASM (PTX/SASS)… à partir de… "C for CUDA"… ah zut, c'est pas du C/C++ ça, ça compile pas avec gcc.
    Mais attend, on peut aussi faire cette étape directement en Python ça aussi : https://github.com/ContinuumIO/gtc20...20Basics.ipynb

    Ah mais c'est peut-être aussi de la triche si l'interpréteur Python est écrit en C/C++.

    EDIT: D'ailleurs si tu veux aller par là, moi aussi ça fait "des années" que j'utilise des serveurs de calculs à 60 cœurs, pire, en JS !
    Juste que jusqu'à présent j'avais pu me débrouiller pour m'en sortir sans GPU ou super-calculateurs de 48 nœuds avec 8 GPU chaque.

    Faire des calculs, ce n'est pas plus ton métier que le mien. Juste que jusqu'à présent, je n'avais pas eu besoin d'utiliser cet outil particulier.
    Donc oui, c'est aussi "mon boulot".


    Pas la peine donc de prendre ton air hautain à t'offenser qu'un "petit jeune" puisse te répondre, puis d'invoquer ton expérience en argument d'autorité.

  20. #60
    Invité
    Invité(e)
    Par défaut
    Merci beaucoup, j'ai appris plein de choses et c'est complètement en rapport avec la discussion. Je ne m'y attendais vraiment pas.

Discussions similaires

  1. Pourquoi ce programme ne m'affiche pas le bonjour
    Par phenix1988 dans le forum C++
    Réponses: 6
    Dernier message: 29/01/2009, 18h15
  2. Réponses: 3
    Dernier message: 04/03/2007, 10h34
  3. Réponses: 4
    Dernier message: 19/08/2006, 23h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo