kade a écrit :



C et CPP c’est des jouets comme tu dis.

Depuis les temps que Rust existe et fait ses preuves, CPP aurait du être enterré depuis tant d’années





a) J’ai dit que CPP était un empilage de bric et de broc, pas un jouet.

b) La première version alpha de Rust ne date que de 2012. Cela dit il est dores et déjà utilisé pour écrire Firefox OS qui fait tourner certains smartphones.







brokensoul a écrit :



C’est aussi le souci avec ces nouveaux languages, sympa mais c’est rare que tu refasses tout de zéro, tu prends aussi des libs existantes dans la vraie vie. Plus facile d’innover aussi quand tu te fous de la compatibilité ascendante..





Bien sûr, je ne dis pas qu’il peut aujourd’hui remplacer le C++ partout, même si ça viendra. J’ai simplement voulu fournir un point de comparaison pour souligner que le C++ est aussi moderne que Fortran ou Cobol.



Mais bien sûr le C++, Fortran et Cobol demeurent indispensables.

kade a écrit :



OK. Ne peut-être pas oublier le F# dont j’ai entendu le plus grand bien.





Mais F# cible un domaine très différent, on ne peut pas le comparer à Rust qui se place vraiment en compétiteur du C++, pour de la programmation bas-niveau (mais pas système, plutôt le domaine réservé du C).



Chaque langage a son domaine en raison ses spécificités.

* Les applicatifs lourds ont besoin de langages puissants, faisant abstraction de toute considération bas-niveau (mémoire), mais rigides pour faciliter la maintenance (système de types). C# / Java.



* Pour des incrémentations rapides, de la recherche ou du RAD dans lequel on ne mettra plus jamais les mains mieux vaut un typage dynamique et surtout de très bonnes biblios. Javascript, Php, F#, Python, Haskell.



* Pour les systèmes embarqués il faut souvent un langage bas-niveau extrêmement vérifiable, permettant au compilateur de prouver un large nombre de propriétés dont le déterminisme dans les circonstances les plus extraordinaires : la régulation de la vitesse d’un véhicule ne doit pas être affectée par un éventuel débordement de la pile d’appels. Ada.



* Pour du calcul scientifique il faut une solution qui facilite le parallélisme distribué : immutabilité, distribution, réplication, synchronisation. C++ MPI, Haskell, Go, F#.



* Pour de la grosse analyse statistique il faut un langage capable d’exprimer effacement certaines concepts mathématiques tout en bénéficiant de très bonnes libs. R, F#, Python.



* Pour du temps réel critique il faut une gestion mémoire déterministe, un découplage en composants parallèles pouvant redémarrer individuellement à la volée et du patchage à chaud. Erlang.



* Pour de la performance et la capacité à dialoguer directement avec le matériel il faut du bas-niveau. C++, Rust.





Et comme le disais brokensoul, avec raison, il faut une sacrée implantation (et tant de temps…) pour implanter un langage, surtout en open. Quid de la pérennité, celle de la communauté ?



Pour Rust je pense qu’on peut être tranquille : celui-ci est soutenu par la fondation Mozilla, plusieurs dizaines de leurs ingénieurs travaillent avec, ainsi que certains constructeurs de smartphones, et la communauté commence à être assez large (67 personnes visitent à l’instant même le reddit Rust).



Mais, oui, un DSI a souvent raison d’attendre et il y a bien des freins légitimes à résoudre avant qu’un langage puisse remplacer le C++ dans un projet.







Tkop a écrit :



Tu aurait pu rajouter que Rust est un langage natif et que en tant que tel il pourrait linker avec d’autre langage natif (mais je ne suis pas certain que ce soit déjà possible, le C certainement, le C++ j’en doute)





C’est possible pour le C depuis le début, quant au C++ c’est plus compliqué à cause de certaines de ses fonctionnalités qui n’ont pas d’équivalent côté Rust (pas de pointeurs de fonctions membres car directement remplacés par des lambdas) et de concepts spécifiques au C++ (enums bizarres). Ça devrait s’améliorer avec le temps.

kade a écrit :



Par contre, je ne connais pas vraiment le CPP par manque de pratique, et je ne vois pas dans ton argumentaire en quoi il ne pourrait pas être adapté au dév. de bas niveau.





Beaucoup de fonctionnalités du C++ sont dangereuses en kernel mode.



* Tu réponds à un IRQ en appelant une méthode virtuelle ? Pas de bol, la VTABLE était en mémoire paginée et elle est couramment indisponible. Du coup, c’est l’héritage lui-même qui devient dangereux. Même problème avec les RTTI.



* Tu peux également oublier les exceptions et tu devras passer par les fonctions d’allocation système donc pas de new.



Alors, certes, tu peux toujours écrire du C et prétendre que c’est du C++. Mais c’est un appel de pied au danger pour un bénéfice nul.







kade a écrit :



Je ne connais personne qui met en jeu la vie de sa boite et de tous ses salariés (genre +100, +300…) sur de l’open source et des langages où on ne trouve personne. C’est malheureux mais c’est ce que je constate.





C/C++, Php, Javascript, … Il me semble que les langages ouverts ont un joli passif.

Quant au reste, dans la mesure où la moitié des serveurs mondiaux tournent sous Linux, là aussi je dirais que tout va bien.



Le fait est qu’il y a nombre de prestataires de service open source. Que l’open source puisse rebuter, oui, mais tout autant que le propriétaire dans d’autres circonstances (avoir le support d’un gros acteur c’est bien, te retrouver à la merci d’un unique gros acteur pour toute correction de bug, fonctionnalité ou support c’est moins bien). Et de là à dire que “personne ne met en jeu la vie de sa boîte et de tous ses salariés sur de l’open source”, c’est un propos déconnecté de la réalité en 2015.

CaptainDangeax a écrit :



As-tu entendu parler du langage D et de son implémentation DMD ?





Je connais, oui, mais sans avoir d’expérience personnelle avec lui. Cela dit de ce que j’en sais c’est un bon choix : productif avec de bonnes performances. Mais à mon avis elles resteront légèrement en retrait de ce que tu pourrais obtenir avec le C.



Si je devais les mettre sur une échelle…

* C/C++ : 1

* D : 1.5

* C# : 2

* Java : 2.5

* Haskell : 2.5-10

* Python : 50



* J’ai mis le C++ au même niveau que le C car par rapport à ce dernier le C++ ne fait que t’offrir des choix supplémentaires, entre abstractions et performances. Si tu ne veux pas les utiliser, libre à toi, mais garde à l’esprit qu’une méthode de classe ne coûte pas plus cher qu’une fonction à laquelle on passe une struct en premier argument.



* Le D ensuite parce qu’il peut échapper au GC (pas de surpoids) et inclure de l’ASM (note que si tu voulais utiliser des instructions SIMD le fossé se creuserait rapidement à l’avantage du D/C/C++). Par ailleurs il utilise LLVM ce qui donnera de bonnes performances. Cela dit je me demande à quel, point il peut exposer des mécanismes unsafe avec son GC, à moins d’avoir un mauvais GC (non-compactant).



* C# après ça grâce à ses structs (existence sur la pile, pas de surpoids dû au GC) et son code unsafe. Gare à utiliser un bon compilo toutefois (les plus récents de MS).



* Java : avec lui tu devras toujours payer la taxe d’un univers sécurisé (surpoids du GC et effets sur le cache, vérifications des indices du tableau).



* Haskell : très variable parce que certains algorithmes et structures de données ne sont pas du tout adaptés aux langages fonctionnels.



* Python : c’est du typage dynamique, pas de miracle. Le JIT ne change pas grand chose à l’affaire. La seule exception c’est JS parce qu’il a des compilateurs extrêmement avancés capables d’inférer un code statique équivalent et de complètement abandonner le côté dynamique quand c’est possible.







46 75 63 6b 20 6f 66 66 a écrit :



As-tu regardé du coté de Cython?





C’est une excellente suggestion. Par contre pour vraiment obtenir une amélioration il faut quand même définir des classes et réécrire une bonne partie du code pour y ajouter les annotations de types. Et après ça on restera au mieux dans l’intervalle d’un C#/Java.

46 75 63 6b 20 6f 66 66 a écrit :



Il faut effectivement reprendre ses classes pour définir les types et utiliser des fonctions bas niveau quand c’est nécessaire. Après, niveau perfs, on est plutôt proche du C++. Et niveau usage, le module une fois compilé s’utilise comme un simple module python.





Dans la mesure où ils doivent conserver un ramasse-miettes, une vérification des bornes des tableaux, une vérification des instances nulles, une vérification des dépassements d’entiers, des membres variants, un support pour les appels dynamiques, etc - des surcoûts très importants demeurent forcément. Le surpoids des en-têtes des objets et du code est significatif, avec ce que ça implique pour le cache CPU. Plus bien sûr les cycles supplémentaires.



Quant à optimiser cela tu peux oublier : le module compilé reste un module python normal dont chaque méthode et chaque champ peut être manipulé de n’importe quelle façon par l’appelant. Donc impossible de faire une analyse extensive (pas de “whole program optimization”)



Il me semble impossible d’atteindre des performances simplement égales au Java.

46 75 63 6b 20 6f 66 66 a écrit :



Portant le projet arrive à de bonnes performances:

http://www.matthiaskauer.com/2014/02/a-speed-comparison-of-python-cython-and-c/

&#160http://nbviewer.ipython.org/github/rasbt/One-Python-benchmark-per-day/blob/maste…





Ce sont des tests sur une simple boucle sur un tableau, se déroulant entièrement au sein d’une méthode (là où aucun code externe n’ira mettre ses gros doigts, laissant le compilateur libre d’inférer des certitudes) et ne faisant pas intervenir le parcours d’un graphe d’objets par exemple (ce qui aurait mis en évidence le coût du surpoids de chaque objet).



N’importe quel langage avec un JIT correct en fait autant (*). JS le faisait en 2000, Lua le fait, etc. Mais ces belles démos ne sont pas révélatrices des performances dans un cas ordinaire.



(*) J’exagère : ils se sont débrouillés pour prouver que tous les indices sont dans l’intervalle du tableau, ce qui n’était pas trivial ici.