Bonsoir!
 
En voyant que le langage java n'est pas aussi performant que le C ou le C++, et qu'il n'existe pas d'alternatives où l'on puisse programmer de manière rapide et sécurisée sur plusieurs plateforme à la fois...
 
J'ai pensé qu'un concurrent au java pourrait avoir une place dans le monde informatique.
 
C'est pourquoi j'ai commencé à programmer un tel logiciel, je n'en suis qu'au tout début.
 
Ceux qui trouve cela étant une bonne idée ou non, n'hésitez pas à me le dire.
 
Ceux qui veulent participer, n'hésitez pas à me le dire!
 
 
Il y a plusieurs problème face à un tel projet:
_ C'est extrêmement long à créer. (être à plusieurs pourrait aider)
_ Il y a des difficultés techniques pour créer un logiciel qui va faire tourner dans sa mémoire en assembler un autre logiciel de manière sécurisée et rapide.
 
 
Je m'explique sur ce dernier point très technique, mais dont je pense avoir la solution:
 
(pour l'instant je programme le logiciel en question uniquement sous linux, j'essaie d'oganiser les sources pour que celui soit facilement portable)
Il y aurait un compilateur qui à partir d'un ou plusieurs fichiers source en langage C ou C++ par exemple, compilerait dans un  fichier contenant un bitecode admettons que son extension soit .BVM .
 
Mon logiciel reprendrait ce fichier .BVM pour le charger dans sa mémoire, le compiler en langage natif du processeur sur lequel tourne mon logiciel et lancerait ce programme, récupérait les system call pour les traiter et les envoyer aux système d'exploitation si besoin.
 
La difficulté vient du fait de lancer un programme en language machine à l'interieur d'un autre programme et qui ne doit pas avoir accès au reste de la mémoire, ni au system call vers l'OS, c'est à dire en étant sécurisé.
Voila comment je ferais:
 
Lors de la compilation du bitecode en langage machine natif, le logiciel devrait créer uniquement des opcodes autorisés, pas d'intéruptions entre autres, et pas de saut vers des opcodes invalides.
 
Par contre on pourrait créer des opcodes pouvant écrire n'importe où dans la mémoire. Mais cela pose deux problèmes:
 
_ Si le programme ainsi compilé, c'est à dire celui qui tourne à l’intérieur de mon application a accès à tout la mémoire, alors ce programme pourra changer les opcodes, par exemple remplacer n'importe quel opcode par une intéruption (qui lancera un system call) qui sera captée par le système d'exploitation, et qui aura par exemple pour ordre d'effacer de nombreux fichiers.
    Pour palier à cela, c'est assez simple il suffit de mettre en lecture seule le code du programme qui tourne à l’intérieur de mon logiciel. Les appelles à mmap sur Linux autorisent cela.
 
_ Deuxième entrave qui est plus compliquée à résoudre: Si le programme à l’intérieur de mon application peut faire des sauts n'importe où à l’intérieur de l'espace mémoire, alors il pourrait sauter au milieu d'un opcode ou au milieu des données et ainsi exécuter du mauvais code ( comme je l'ai dit plus haut, par exmple exécuter un system call capté par L'os et qui effacera des fichiers).
    Pour résoudre cela, je vois une solution: créer dans la mémoire un espace où les adresses de toutes les fonctions du programme (commençant par des opcodes valides) sont listées, cet espace serait en lecture seule pour le programme qui tourne à l’intérieur de mon application, ainsi chaque fois que le programme à l'intérieur aura besoin de faire un saut à un autre endroit de la mémoire de manière dynamique, il chargera l'index dans cet table et sautera à l'adresse indiqué à l’intérieur de cette table... Ainsi le programme lancé à l’intérieur de mon application ne pourra pas lancer de mauvais opcodes.
 
 
 
Pour être plus précis:
Chaque fois que mon application passerait à l’exécution du programme à l’intérieur, il cacherait l'ensemble des plages mémoires accessible en temps normal par un appelle à mmap (change les droits d’accès des pages sous linux).
Inversement Lorsque le programme à l'intérieur ferait un system call vers mon application (pas vers l'os) , celui ci rendrait les droits d’accès des pages à leur état précédent et laisserait l’exécution du programme à mon logiciel dans le but de prendre en charge le system call.
 
 
 
Voilà cette explication est bien complexe, mais est nécessaire pour montrer qu'on peut créer un java meilleur, plus rapide et sécurisé!
 
 
 
J'ai également parlé de aspect très technique sur stack overflow: https://stackoverflow.com/questions [...] 5_49406786
 
Merci de me dire si ce projet vous intéresse!
 
 
 

 
Tu sais qu'il y existe déjà d'autres langages que C++ et java ?
Que leur mise au point à tous a pu demander des années, voire des décennies à des gens hautement qualifiés ?

Jovalise ? C'est toi ?

T'as regardé le langage D, Python... ?
C'est vachement ambitieux de vouloir créer un nouveau langage de dév plus performant que java, tout seul  
Ca nécessite énormément de compétences en programmation système sur plusieurs OS, en analyse syntaxique et techniques de compilation, en ASM, en paradigmes... Bref, des domaines complexes et nombreux qu'une seule personne maîtrise rarement complètement tous les aspects
 
Du coup, après plusieurs années, tu arriveras peut-être à un résultat exploitable. Maintenant, qu'il soit plus performant que java qui a bénéficié de nombreuses années d'optimisations par des centaines voire des milliers de personnes compétentes, ça me paraît compliqué. A moins que tu sois un génie...

Merci pour vos réponses!
 
Il est vrai que ça prend un temps vraiment colossal de créer un nouveau langage, et en fait surtout un nouveau compilateur correspondant à ce langage.
 
Ce que je souhaite c'est créer un langage de bytecode. Et non un nouveau langage tel que le C ou le C++.
 
L'idée serait de prendre en source un fichier en langage C ou C++ pour le transformer dans mon bytecode.
 
Puis de ce bytecode en langage machine lors de l'execution du programme.
 
Je souhaite m'appuyer sur le compilateur gcc pour transformer le langage C ou C++ en mon bytecode, ce qui simplifierait la tache.
 
 
 
Pour ce qui est de la performance, il y a un débat sur les performances entre le java et le C++.
Par exemple la page wikipedia suivante en parle : https://en.wikipedia.org/wiki/Java_ [...] #Java_SE_6
 
Je pense personnellement que les contraintes du java (faire en sorte que ce soit sécurisé et rapide) l'on poussé à être un peu plus lent que le C ou le C++ (biensur ça dépend du code que l'on benchmark et des autres conditions).
 
Si je ne me trompe pas l'astuce que je souhaites utiliser devrait lever ce problème, en bonne partie, du coup je pense qu'il est possible de faire tourner un programme presque aussi rapidement que du C ou du C++ sur plusieurs platformes, sans problème de sécurité.
 
Cependant i lest tout à fait vrai que l'optimisation du compilateur pour obtenir un bon langage machine, bien optimisé, est vraiment très complexe, sans cela le langage machine que je souhaite faire tourner sera un peu lent!!
 
 
Après il y a le fait de le programmer seul, et bien sûr ça prendrait un temps très important.
 
Ce que je peux faire c'est de commencé la programmation (d'abord sur linux, sur x86_64) seul, puis de voir ce que cela donne au bout de quelques temps, et de partager avec les personnes ce résultat.
 
 
 

Non mais il y a Go, et il y a D.
 
Et pour la partie "sécurisée" vu que tu es sur Linux, chroot fait le taff.
 
Bref tu t'emmerdes vraiment pour pas grand chose là.

Je vois pas en quoi t'appuyer sur gcc te simplifierait la tâche, bien au contraire

nicobzz, le C/C++ sur plusieurs OS, ça dépend beaucoup des libs employées. Y'a pleins de programmes codés sous un OS qui ne seront pas portables "comme ça direct" En particulier si y'a une IHM. Si je code un programme en VC++ avec les API Win32, tu peux toujours courir pour que ça compile sous Linux, ou alors, au prix de sacrées bidouilles...

Je suis au courant de cela.
 
Je ne sais pas j'ai bien expliqué mon projet, mais l'idée est de faire un equivalent au java(dans sens où le java est compatible sur toutes les plaformes, pas besoin de recompiler pour une platforme particulière), mais dont le langage de base serait le C ou le C++.
 
Ainsi mon logiciel serait écris différement pour chaque OS et pour chaque processeur, mais permettrait de faire tourner de manière protégé à l'intérieur de mon logiciel un ficher contenant du bytecode.
 
Mon logiciel aurait pour rôle de faire l'interface entre le programme qui fonctionne à l'intérieur et l'OS, comme java le fait, avec des librairies communes pour toutes les platformes.
 
Evidemment ça risque de demander du temps, pour l'instant je souahite faire ça uniquement sous linux en x86_64.
 
Je ne sais pas si j'ai été clair?

Oui, on a bien compris que tu voulais refaire une machine virtuelle (différente de la JVM, que tu trouves lente), et compiler des sources C ou C++ en bytecode pour cette machine virtuelle.
Cher ami, tu es un doux rêveur. Mais ça n'est que mon avis. De plus, tu peux essayer le C++ CLR qui tourne sous .NET.

Du coup, tu perds le côté cross-OS avec un code source de programme unique comme le permet Java. C'est quand même l'une des raisons du succès de Java par rapport au C/C++...
S'il ne te reste plus que l'aspect "faire tourner de manière sécurisée", les OS modernes s'en chargent déjà pas mal et tu as le C# sous Windows, par ex. Du coup, je ne vois plus l'intérêt de ton programme

Si, rufo, l'idée serait de garder le coté portable, car sur chaque platforme le programme qui devra tourner à l’intérieur de mon application aura accés aux même bibliothèques.
 
C'est comme en Java: sur linux, windows ou macos ce sont les même bibliothèque que l'on peut utiliser quand on écrit un code java.
 
Quand on écrira un code C ou C++ pour être compilé en .BVM (mon bytecode) ce code pourra lorsqu’il sera lancé, pourra accéder aux même bibliothèque sur Linux, mac os, windows.
 
L'avantage : rapidité, portabilité et sécurité.

Pour être plus précis, les bibliothèque devront être chargé dans la partie de la mémoire correspondant aux instructions, aux opcodes lors du lancement du programme en .BVM.

Juste 2 remarques:
 
 

 
En gros tu veux faire un JIT (Just In Time compiler). Ce "simple sujet" (convertir le bytecode en natif) si tu veux vraiment t'intéresser à la performance à de quoi t'occuper plusieurs années.  
 
 

 
Oui ok, tu peux prendre l'analyseur lexical et syntaxique et "juste remplacer" le générateur de code, mais là non plus il ne faut pas sous-estimer la tâche. GCC est disponible pour une très grande quantité d'architecture et de processeur. Je doute qu'ils n'aient pas factorisé leur code pour en réutiliser le maximum. De plus les mécanismes d'optimisation du code (par exemple inlining de fonction, démontage d'une boucle pour la remplacer par une séquence, utilisation optimale de la "prédiction" des processeurs, etc) sont vachement poilus.  
 

 
Euh, la dernière version est Java-10. Il y a eu pas mal de chemin parcouru depuis JavaSE 6. De plus la "lenteur" de java par rapport à C++ est une jolie légende urbaine. Faudrait que je retrouve les articles, mais  certaines mesures donnent un ralentissement de moins de 2%. Le problème de C++ c'est que le langage est tellement complet et complexe que la plupart des programmeurs peinent à utiliser toutes les possibilités et souvent écrive un code moins efficace qu'en Java (je parle ici d'une moyenne statistique, je sais qu'il y a des spécialistes qui peuvent comprendre toutes les subtilités syntaxiques et sémantiques de C++).  
 
Juste un petit exemple : on entend souvent que le garbage collector de Java est une des sources principales de ralentissement. Oui c'est vrai, si on ne comprends pas exactement comment et quand il est lancé. Si on sait le "gérer" alors son influence néfaste est nettement diminuée. D'ailleurs, C++ ?17? ou ?14? reprend aussi l'idée d'un garbage et recommande de ne plus écrire de destructeur dans les classes.
 

 
Ton projet est très intéressant, mais il y a de quoi occuper plusieurs personnes à plein temps sur plusieurs années. Les équipes qui développent les compilateurs sont des "grosses" équipes de gens très pointus. Si tu as une formation académique, tu pourras sûrement trouver pleins d'articles sur le sujet (voir google scholar) et comprendre l'amplitude de la tâche.. Si tu es "juste" un amateur passionné (nous sommes pleins dans ce domaine, donc ce n'est pas du tout négatif), alors vas-y, commence, fait déjà un "proof of concept"  et tu te rendras compte de la difficulté de la tâche.
 
Enfin moi ce que j'en dis...

Excuses moi de te répondre un peu tardivement, j'étais chez des amis toute la journée.
 
Dans un premier temps, effectivement ce serait bien que je fasse un "proof of concept" pour montrer que techniquement c'est possible, et en suite attirrer les personnes sur l'idée.
 
Je sais bien que la tache est difficile, mais dans un premier temps, j'avais l'idée de faire quelque chose de pas très optimisé, même à vrai dire très très peu optimisé ,juste question de monter que sur le principe l'idée fonctionne.
 
Mais surtout il faut aussi que je vérifie ce qui se dit sur l'écart de performance entre le java, et le C++. J'ai du mal à concevoir que le java soit autant rapide (sauf dans certains cas où le compilateur java fait de belle optimisation) car je sais que, en particulier pour l'accès aux données dans les tableau est ralenti en java, car java doit vérifier à chaque fois que la valeur entrée est dans les limite du tableau.
 
 
 
 
 

Et si pour savoir un peu de quoi tu parles et dans quoi tu t'embarques tu commençais à faire réellement des tests comparatifs entre Java, C++, .Net Core sur des trucs aussi basiques que des manipulations de collections/tableaux ?
Ensuite fais ton PoC (en version ultra optimisée) si tu juges que ça en vaut toujours la peine, et si d'ici 2 ans tu arrives à faire mieux que les langages multiplateformes avec GC, alors on pourra reprendre cette conversation...

DE plus, dans le cadre du C ou du C++, ça existe déjà, suffit de se renseigner un peu sur LLVM et sa représentation intermédiaire IR qui est un bytecode, en général transformé en code machine par un back-end, mais qui est aussi interprétable par lli.
 
A+,

Faire un nouveau language qui fonctionne, pas forcément intéréssant ni performant est jouable en quelques mois, par ex pour un thésard ou le projet de fin d'étude d'un Master Recherche. Probablement pour quelqu'un qui se spécialiserait dans ce sujet.
 
Mais ça resterait un truc un peu jouet, bien évidement. Peut être que sur un aspect précis il pourrait être innovant, mais le reste serait du pur standard.
 
Comme indiqué au dessus, il est rare de réinventer la roue sur tout. Donc probablement que tu va réutiliser les techno de parsing de code standard, du byte code intermédiaire standard et des outils qui vont générer le code machine optimisé standard.
 
LLVM serait un bon point de départ pour tout ça.
 
Cela dit tu va trop loin dans ton projet à mon sens tu veux un nouveau language, une nouvelle JVM, tu veux un truc ultra perf. Tout ensemble c'est trop.
 
Des gens se sont déjà attelé à ton problème mais ils l'ont résolu par morceau. Par ex il existe des JVM propriétaire récente plus performantes que l'inplem open source ou que celle d'Oracle. On en as essayé une de nos applis en prod. On a pu observer autour de 40% de gain sur notre application en nombre de transactions par second mais aussi en temps de réponse pour chaque transaction. Et pour ça on a rien eu besoin de compiler, ni de changer de language. On a juste changé de JVM.
 
A l'inverse tu peux concevoir de nouveaux languages et garder un bytecode standard.
 
Enfin C++ n'est vraiment plus rapide que lorsque tu n'utilise pas les fonctionnalités haut niveau du language. Si tu fais de la programmation objet avec du polymorphisme, alors le compilateur est obligé de créer des VTable pour appeller tes méthodes par ex. Si tu veux simplifier ta gestion de la mémoire avec des shared pointer, tu as un surcout associé. Tout est affaire de compromis.
 
Mais ta déjà plusieurs languages comme Rust ou Go qui visent à remplacer le C++ en étant à la fois performant et fiable. Peut être que tu pourrais participer à ces projets.
 
Au final, ce que tu veux faire demande une bonne maitrise du sujet, de rassembler une bonne équipe et de réutiliser ce qui existe pour l'essentiel et ne faire du custom que là ou tu es certain d'apporter une vrai valeur ajoutée.
 
Si tu te spécialise à l'université ou en école dans les compilateurs et les languages de programmation, que tu  prend ensuite quelques années d'XP sur un ou plusieurs projets du genre, que tu es reconnue et arrive a convaincre une équipe de bosser avec toi, alors tu pourra peut être y arriver.
 
Et d'ici là, se pourrait bien que la problématique ne se pose plus de la même façon. En admettant même qu'elle se pose aujourd'hui. Souvent l'aspect le plus important d'un language de programmation n'est ni sa syntaxe, son expressivité ou sa performance pure, mais son échosystème. Java/C++/python/scala et bien d'autres ont leur propre communauté de développeurs, d'outils, d'IDE de libraries. Si ton système n'a pas de communauté suffisante, il n'aurai jamais ce qu'il faut pour être vraiment utilisé.
 
D'aileurs tu trouvera déjà plusieurs projets matures sur des problématiques proches de la tienne et pourtant tu n'en a même pas entendu parlé ! Ca montre bien qu'il suffit pas la VM, la language et le compilateur pour être utilisé, loin de là .

Merci foudres pour ta réponse, en effet il est difficile de dire si un tel projet a de l'avenir ou non, et oui il faut tout un écosystème autour pour qu'il rencontre un succés.  
 
Je m'étais dit qu'il y avait peut etre une place pour un tel projet, car par exemple quand on veut programmer un logiciel compatible sur windows, mac, linux, il est encore un peu compliqué de passer de l'un à l'autre surtout si l'on veut que ce logiciel soit au maximum de la performance, comme par exemple un jeu video. Et je m'étais dit que si une telle machine virtuelle avait un succés, on pourrait penser à l'adapter cette machine virtuelle sur encore d'autres plateformes tel android (bien que l'interface soit différente de celle des ordinteurs et que du coup il faille une petite adaptation au programme)
 
D'abord je ne suis plus sur ce projet, je n'ai pas vraiment le temps de réaliser, vu que je travaille, que j'ai quelque soucis de santé et que je suis sur un autre projet qui m'interesse plus.
 
En fait je m'étais interessé à cette idée car j'ai imaginé un systeme, en utilisant certaines fonctionnalité des processeurs x86, et en utilisant d'autres fonctionnalités d'autres processeurs, où l'on peut allier une certaine performance (en laissant la possibilité au programme d'utilisier bon nombre des fonctionnalités haut niveau du langage) et le fait que ce programme n'ait pas accés à ce qu'il n'aurait pas droit d'acceder. Ce qui me semble n'est pas possible sans certaines astuces.
 
Si tu veux , que ça t'intéresse, je peux te décrire comment fonctionnerait un tel systeme.
 
L'idée est que le programme ne puisse pas sauter sur n'importe quelle adresse en mémoire du programme à des endroits non prévu à cette effet.
Comme le pointeur de retour de fonction est dans la pile lors d'appel à une fonction, il faut utiliser quelques astuces pour que le programme qui peut écrire sur la pile librement ne puisse pas pas sauter à des endroits non prévus.
 
Cependant, même si je pense qu'on gagnerait par rapport a java par exemple sur les fonctionnalité haut niveau du langage, on y perdrait au moins un peu en performance dans nombreux cas, il est vrai.
 
Ainsi meme si on laisse le programme accéder en lecture et écriture à la partie de la mémoire réservée aux données et à la pile, et uniqument en lecture à d'autres partie de la mémoire, alors le programme pourra pourrir les données, mais il n'aura pas moyen d'executer des instructions inadaptés.
 
 
 

Aussi il me semble que le java est relativement lent (par rapport au c ou c++ dans certaines situation) car lors de l'acces à des tableaux il doit vérifier la taille du tableau pour ne pas être dehors, si cela est vrai ce serait une raison de contreperformance dans certains type de calculs.
 
Si je me trompe sur ce point (si java ne vérifie pas les limites des tableaux) alors je crois que mon astuce n'a pas vraiment d'interet.
 

Non java n'a pas vraiment de gestion de la mémoire, et il ne vérifie pas les accès dans les tableaux. Quand une IndexOutOfBoundsException est levée, personne ne sait vraiment ce que ça veut dire, c'est juste un accident.
Tu peux développer tranquillement ton nouveau langage révolutionnaire.

Total Recall, je suis disposé à te répondre aimablement, à avoir un conversation constructive, à condition que tu ne me traites pas avec mépris, je répondais poliment à foudres, sur le sujet et j'ai bien l'impression que tu utilise le sarcasme pour te moquer.
 
De plus tu n'as pas bien compris ce que je voulais dire:
 
Justement, si la vérification des limites de tableaux s'effectuent sous java (ce qui semble être le cas d'après ce que tu me dis), cela représente un perte de temps pour les programmes qui effectuent beaucoup de calculs sur les tableaux en java, et alors peut être le système que je souhaitais mettre en place aurait un interet.
 
Inversement: si la vérification des limites de tableaux ne s'effectuent pas sous java, mon système n'aurait pas d'interet, car il n'y aurait pas de gain de performance.

Java a été créé en partie pour limiter les bugs liés à la gestion de la mémoire et en particulier se passer des pointeurs du C/C++. Une étude américaine dans les années 80 je crois avait conclu que 2/3 des bugs des programmes écrits en C/C++ provenaient des pointeurs et d'une mauvaise gestion de la mémoire.
Java a donc implémenté tout un tas de mécanismes pour empêcher que le programme parte en sucette si on tape au mauvais endroit. Mais forcément, tous ces mécanismes de contrôle ont un coût en temps d'exécution.

Effectivement, c'est ironique. Pas forcément pour être cassant et désagréable, mais surtout pour souligner que tu t'attaques à des problèmes extrêmement ardus que des gens selon toute vraisemblance bien plus qualifiés ont déjà abordé.
Si tu veux un langage performant tu enlèves la VM et ses implications en matière de la gestion de la mémoire et tu accèdes directement au système, dans la mesure où l'OS te le permet.
Si tu veux encore plus performant, tu enlèves aussi l'OS et tu attaques le HW (bon courage).
 
A la fin tu te retrouves avec un langage "temps réel" minimaliste. Genre le C ou l'ASM (soyons fous).

Si tu veux te familiariser avec ça, rien ne t'empêche de le faire avec les solutions existantes. Mais en tout cas n'espère pas faire "mieux" ou "plus innovant" que ce que des experts ont pu concevoir au fil de 70 ans de programmation informatique, si tu penses parvenir au contraire c'est que tu n'as pas conscience du sujet auquel tu te frottes (ce qui n'empêche pas d'y réfléchir dans un but d'apprentissage).

Pour du C temps réel, il y a le système "Tornado". Mais je crois que la licence coûte une blinde (100 K€ ?) du fait que justement, c'est vachement optimisé avec un OS minimaliste et qui respecte les contraintes du temps réel.
 
Après, pour accélérer certains types de calculs, il me semble qu'il y'a des langages qui se "compilent" pour générer du code optimisé pour certaines architectures (profiter de l'accélération des cartes graphiques, par ex). Là, je parle pas de Cuda (qui est du C, il me semble) qui est fait pour tirer partie des CG Nvidia.
Je pense plutôt à des routines de Matlab qui exploitent les CG pour paralléliser les calculs. Mais ça reste très spécifique.

 
J'ai 12 ans d'XP Java sur des systèmes sensibles à la performance et aussi en gros  1ans d'XP en C++ 11 vu qu'on nous a demandé de réécrire certaines programmes critiques en C++.
 
Si tu écris un programme non trivial un peu naivement en Java et un autre en C++, le Java ne sera pas forcément plus lent, mais au contraire la performance sera comparable. Je dirai même que le C++ est lent par défaut vu que les parametres sont passé par copie et que pour éviter la cata niveau gestion mémoire soit les données sont copiées plus que nécessaire, soit des structure comme des smart pointer sont utilisées avec le coût associé.
 
Par ailleur en C++ l'échosystème est extrémement pauvre par rapport aux libraries disponible en Java qui sont souvent très optimisées et d'excelante qualité. Le standard C++ addditionné de boost est extrement pauvre comparativement et les libraries tierces peu nombreuses. Le plus probable quand un dev va réimplémenter la fonctionnalité manquante pas lui même en C++ c'est qu'il n'aura pas le temps d'en faire une implémentation ultra optimisée.
 
Le programme sera plus rapide à développer, plus facile à maintenir, demandera moins de compétences en Java qu'en C++.
 
Par contre prends de bon développeurs en C++, laisse leur le temps nécessaire pour aller au bout des choses et met comme priorité la performance, ils pourront aller plus loin qu'en java. Et en optimisant les structure de données pour le cache processeur, on tunant à fond la gestion mémoire, en générant du code ultra optimisé pour chaque cas avec les template etc, en utilisant pourquoi pas à l'occasion un peu d'assembleur, ils vont aller beaucoup plus loin.
 
Les forces du Java sont aussi ses faiblesses. le garbage collector sauf sur certaines VM payantes met l'application complète en pause pendant certaines étapes de son execution, il n'est pas rare d'avoir un programme bloqué pendant 200-500ms voire dans certains cas quelques secondes. Ca s'optimise mais c'est presque impossible d'éviter des pauses d'au moins 100-200ms. Même si le garbabe collecteur est extrement efficace, peut être plus que la gestion manuelle en C++, le fait que ça puisse arriver au mauvais moment est problématique.
 
Le Java est portable mais du coup n'est pas très bien intégré au système. Les UI ont un look bien distinct et les API du système d’exploitation ne sont pas disponibles. Au final Java est  très utilisé en entreprise pour développer des serveurs d'applications mais très peu pour des applications client native (hors Android).
 
Niveau perf pure, une des plus grosse limitations est de forcer que tout objet soit accédé par référence et qu'il ne soit pas possible de regrouper plusieurs objets ensemble dans un bloc contigu de mémoire pour diminuer l'empreinte mémoire et la fragmentation des données. C'est quelque chose qui je crois devrais être supporté un jour ou l'autre. Mais en attendant, c'est une limitation.
 
A noter que Java et C++ sont 2 langages dépassés au niveau expressivité confort de coding et sécurité. Ils restent leader à cause de leur popularité.

Comme ton orthographe
 

 
je passe une fois l'an et voilà ce que je lit. Mec, les références c'est pas pour les chameau.
T'as aussi le droit d'utiliser la stack plutot que l'allocation sur le tas.
 
Juste chut
 
 

Oh putain un revenant

j'aurais mieux fait de rester chez moi vu le niveau
je part et c'est la fete à la saucisse

 
Par ce que genre la STL alloue les éléments géré par défaut dans la stack peut être (je te dit pas les soucis quand tu passe ton vector à une autre fonction et que la stack a été purgée entre temps ...) ? Et par ce qu'elle n'incite pas à faire plein de copie et fonctionne super bien avec des références aussi. C'est à ce demander pourquoi les concepteur de C++ se sont emmerdés avec les move semantics.
 
Donc ouais, juste chut...

Tu dis du caca mec. J'y peut rien si tu a appris le C++ en 1492.
 
Ta phrase  là : "Je te dit pas les soucis quand tu passe ton vector à une autre fonction et que la stack a été purgée entre temps ..." démontre juste que tu sais pas comment ça marche.
 
Donc chut.

 
Citation hors contexte.  
 
Ton vector alloue pas ses elements dans la stack et quand tu le passe de parties à l'autre du programme il est copié ou au mieux dans quelque cas utilisera les move semantics. Ta aussi la RTO dans quelque cas.
 
C'est à au developpeur d'utiliser des references ou pointeurs pour éviter ces déconvenues. Et les références sont peu utilisables dans les containers sans la lourdeur des std::reference_wrapper...
 
Dans tous les cas, il faut donc faire + d'efforts pour avoir un code propre et performant.

 
Peter Cordes n'a pas l'air convaincu et je suis toujours sceptique quand je vois une personne lambda intervenir sur un sujet complexe. Je fais confiance à ceux dont c'est le job. Le sujet est complexe et il y a des gens compétents qui font ça, par exemple Understanding Compiler Optimization - Chandler Carruth
 
 
 

 
Ca peut-être pour Matlab ? GPU Computing in MATLAB
Dans tous les cas, les 2 principales API pour du GPGPU sont CUDA et OpenCL. Pour plus d'infos sur comment sont exploitées les cartes graphiques en traitement d'images, il y a ArrayFire ou Halide. Pour du Deep Learning et concurrencer Nvidia, les alternatives sont le fork de TensorFlow par Codeplay qui utilise OpenCL + SYCL (il y a différentes présentations disponibles, par ex 1, 2) ou AMD avec MIOpen et HIP.  
Je ne fais pas du GPGPU ni du calcul haute performance. Par contre, c'est des sujets qui m'intéressent et il est formidable de pouvoir trouver sur le net toutes ces librairies open source, toutes ces ressources pour qui est curieux, désireux d'apprendre.
Dans le même genre, pour du traitement d'images sur ARM ? ==> ARM Compute Library.
Pour du Deep Learning sur du Intel ==> MKL-DNN. Ils utilisent Xbyak pour générer à la volée les instructions assembleurs pour les différents types de kernel (What are the advantages of using a JIT for several operators ?).
 
 

 
J'oscille entre du "oui c'est vrai" et du "WTF total".
Oui je pense qu'en général C++ et Java doivent donner des performances similaires. Oui, probablement qu'il est plus facile et rapide de développer en Java. Il est plus facile aussi de se tirer une balle dans le pied avec le C++, ça s'est sûr. Et il faut de bonnes connaissances pour tirer parti du C++. Par contre, je vois pas en quoi les librairies C++ seraient de moins bonnes qualités et moins optimisées qu'en Java mais j'ai peut-être mal compris. Chaque langage a aussi des domaines de prédilections, donc reprocher que certaines lib n'existent pas en C++ ne me convainc pas vraiment. Si je fais des stats, il y a R. Si je fais du traitement d'images il y a tout ce qu'il faut en C++, etc.
 
Dans le "WTF total". Passer les paramètres par référence, ça fait partie du langage C++ tout comme en C il y a les pointeurs. C'est les bases du langage qui est fait comme ça et on apprend ça la première semaine en informatique.
Return Value Optimization par RTO.
Il y a quoi de compliqué d'écrire ça :
 

 
Après il y a Eigen si l'on a besoin et d'autres prétendants comme xtensor.
 
12 ans d'XP en Java + 1 an en C++. Ok, le langage C++ a ses défauts mais certainement pas ceux mentionnés précédemment. Et il y a des discussions autour du langage, cf le C++ Standards Committee.
Vous avez eu une formation spécifique au C++ ou c'est de l'auto-formation ? C'est quoi le retour d'expérience pour optimiser des traitements Java en C++ ? Vous avez pu atteindre les perfs désirées ?
 
Pour finir, l'histoire de Kazushige Goto. Si vous avez dû utiliser Lapack, si vous faites du calcul matriciel, les opérations de base sont accélérées par des libs dédiés via BLAS (Basic Linear Algebra Subprograms). Pour du Intel c'est Intel MKL et OpenBLAS pour le successeur de GotoBLAS.

 
J'ai eu des formations sur le sujet, par quelqu'un qui siège au C++ standards Commitee, il est très réputé et connais bien son domaine oui. Ca fait très longtemps que ma boite travaille avec lui meme s'il n'est pas un employé.  
 
Sinon j'en fait full time depuis 1 an et je me renseigne toujours sur ce qui est possible. Quel que soit le language ou la technologie je me content pas de quelques tutoriaux et du hello world. Je m'en sort pas trop mal je pense vu que maintenant beaucoup de dev bien plus expérimenté que moi en C++ me posent des questions dessus. C'est juste que j'aime aller au fond des choses et si il y a quelque chose que je comprends pas ou maitrise pas, je vais me renseigner jusqu'à maitriser le sujet.
 
Mon employeur met un énorme accent sur la performance car notre trafic augmente de 50% par an mais les revenus seulement 8%. Le coût des machines fini par devenir prépondérant.
 
A chaque fois toutefois vu de l'intérieur ce qui a été le facteur limitant n'est pas le langage mais les librairies tierces développées en internes par des équipes qui n'ont pas les même priorités et de rester "in policy".
 
Toutefois, bien évidement si les perfs seront jamais aussi bonne qu'on le voudrait (perf infinie), de mon expérience si l'on investi vraiment sur le sujet, obtenir un gain très significatif est possible. Un facteur 10X est souvent possible sur la durée après plusieurs campagnes d'optimisations ayant supprimés plusieurs bottleneck. J'ai travaillé sur de l'optim de programme par intermittence depuis des années vu que c'est une des préoccupations clefs de mon employeur. Que ce soit en Java, SQL ou C++. Je commence à bien connaitre ces problématiques oui.
 
Pour l'instant le nouveau programme C++ écrit par une bonne part d'expert C++ avec de nombreuses années d'XP est senssiblement plus lent que la version Java (facteur 3X). Sachant que le même investissement de réécrire le programme en C++ s'il avait été mis sur la perf du Java aurait senssiblement amélioré les choses.
 
Par ailleurs, debugger et compiler prend plus de temps et il faut traiter des erreurs qui n'arrivaient jamais avant comme des segmentation fault. Le code est généralement plus verbeux.
 
Si la perte de productivité des développeurs me semble inévitable, c'était après tout une des raisons essentielles pour l’utilisation de langage comme C#, Java ou python, le problème de performance n'est pas du tout lié au langage. Il est lié à l'architecture que nous impose le middleware utilisé mais que nous n'avons pas réussit politiquement à éliminer.
 
Nous travaillons donc à changer les choses à ce niveau maintenant que nous avons la preuve par des mesures qu'ils est le facteur limitant. Les gens n'apprécient pas, car pour eux le fait même d'utiliser C++ devrait être une garantie et le fait que la même chose en java soit nettement plus rapide les perturbe profondément. Au début du projets ils étaient tous persuadé que le programme qu'ils écrivaient en C++ ne pouvait être que plus performant car ils étaient forcément de bon développeurs et utilisaient un langage forcément supérieur.
 
Perso je voyais déjà les problèmes dans l'archi du middleware comme problématique, mais il n'y a que maintenant qu'on a tous les chiffres et les résultats de profiling qu'on est obligé d'admettre que ça vient du middleware et de l'architecture plutôt que du code applicatif.
 
De mon expérience, celà a toujours été le plus difficile niveau performance. Non pas de rendre son propre code plus performant, mais d'arriver à ce que d'autres départements et équipes collaborent pleinement et aient le budget pour améliorer les performances des libraires qu'ils produisent et dont on dépend.
 
Le pire étant la gouvernance et la politique. Tous les problèmes doivent être traités pareil pour beaucoup de décideurs avec les mêmes technologies et framework. Il leur est difficile d'admettre qu'une problème différent puisse nécessiter des solutions différentes.

Intéressant comme retour.
 
Que devait faire en gros votre appli ?
Si dans le domaine considéré les librairies C++ n'existaient pas alors qu'elles existent en Java, c'est peut-être déjà problématique.

 
Notre appli doit orchestrer des requête de search en passant par le bus de l'entreprise avec son protocole propriétaire. C'est ce dernier point qui nous force à utiliser les librairies internes à l'entreprise pour bénéficier de leur implémentation du protocole. Malheureusement au lieu d'être de simple librairies à inclure et gérant just le protocole réseau, c'est plutôt tout un framework qu'ils imposent que ce soit en Java ou C++ avec beaucoup de limitations, contraintes associées.