TheKillerOfComputer a écrit :



Mais ne pas se diversifier, c’est la mort assurée à moyen-terme. D’accord c’est une fondation et non une entreprise, mais quand on voit à quel point Chrome a gagné en terrain, on ne peut pas ne pas envisager une éventuelle mort de Firefox non plus. Se recentrer dessus peut permettre de maintenir sa place… ou ne rien changer, et là avoir d’autres projets en main est une bonne chose.

Mais bon... Au final, Thunderbird, Hello, Firefox OS... Ça fait beaucoup d'abandons. Mozilla se meurt lentement et sûrement, et on n'aura bientôt plus que les outils Google.

La diversification, c’est à double tranchant.



Quand on disperse ses moyens, on risque aussi d’aboutir a plusieurs produits dont aucun n’est assez bon pour être compétitif. Et ça, c’est la mort assurée.



Ensuite, rien ne dit que les projets de diversification auraient été meilleur que le créneau du navigateur.



Si Chrome a réussi à tailler des croupières a Firefox, c’est en partie parce qu’il a réussi à une époque à le dépasser largement sur le plan des performances.



Nous sommes dans un monde ou il n’y a plus de place pour les second.



Le recentrage sur coeur de métier est un classique de la gestion d’entreprise.

zefling a écrit :



En même temps, l’exemple du JV n’est peut être pas le bon, vu qu’une très grosse partie c’est la CG et de ce côté là, j’ai pas franchement l’impression qu’il y ait un ralentissement, surtout vu les besoins à venir en 4K puis 8K. Par contre, niveau processeur, pour pas mal de chose, les besoins sont loin d’être aussi important.







Non, c’est une idée reçue totalement fausse.



L’usage du processeur touche le plus souvent au coeur du jeu lui même et il n’est pas facile de faire “varier la qualité” comme pour les graphismes. Et comme les éditeurs sont obligés de tenir compte des machines modestes, ceux qui ont une machine puissante peuvent avoir l’impression que ce n’est pas le facteur limitant.



Mais entre un moteur de jeu qui est écrit en C# ou Java et un autre qui est écrit en C/C++, on voit nettement la différence.







Uther a écrit :



On en a déjà parlé sur d’autre sujets : tu surestimes énormément le coût du bound checking. Ce qui coûte beaucoup en performance dans les langages managés c’est plutôt le typage dynamique, le GC, et autres mécanismes lourds qui imposent un runtime.



 A priori WebAssembly évite tout ça. Et même pour le bound checking, l’optimiseur est capable de détecter et de supprimer les bound checks inutiles.







Non, je ne surestime pas du tout le cout du bound checking. Et sincèrement, je pense que tu devrait en discuter avec des programmeurs spécialistes de l’optimisation.



D’abord, les accès mémoire, c’est la bête noire des ordinateurs modernes. Un processeur peut se tourner les pouces pendant des dizaines de cycles pour un simple “cache miss”. Et sur certains algo, le bound checking ça coûte cher.



L’optimisation dont tu parles, elle n’est possible que sur des cas très simple ou le compilateur peut déterminer précisément l’intervalle d’accès.



Bien sûr, avec de la programmation courante qui va au plus facile et qui gaspille l’essentiel de la puissance dans l’usage immodéré des balayages simples de tableaux, tu peux avoir l’illusion que cela fonctionne aussi bien avec du bound checking que sans.



Mais sur un programme extrêmement optimisé, on fait usage de structures beaucoup plus variées et complexes et d’algorithmes beaucoup plus sophistiqués. Et c’est sur ce genre de programmation que le vrai cout du bound checking apparaît clairement.

Uther a écrit :



Normalement un bound check ne nécessite pas d’accès mémoire supplémentaire et ne pose pas de problème de branche. Je ne vois pas pourquoi il devrait faire perdre des dizaines de cycles.







Pour réaliser un bouncheck, le CPU doit forcément disposer d’une information de borne. Et il n’y a pas de magie, celle ci viens forcément de quelque part.



Même si c’est codé en dur dans le programme en LM… ça viens aussi de la mémoire et il faut donc bien un accès mémoire pour l’obtenir(ainsi que pour les instructions proprement dite).



Mais je comprendre ce que tu as voulu dire. Quand la borne est connue à la compilation, ça peut être intégré dans le code, ce qui est un moindre mal en terme d’accès mémoire. Mais dans le cas contraire, il faut bien aller chercher l’information quelque part et c’est le genre d’accès qui fait mal. Et l’on ne peut quand même pas dire que dans un programme il soit possible ou optimal de fixer en dur la taille de toutes les zones avec lesquelles le programme devra travailler.





Je ne nie pas que le bound checking peut avoir en effet un impact sur certains cas particuliers. Mais dans la très grande majorité des cas l’impact est négligeable voire nul s’ils peuvent être éliminés.





Encore faut t’ils qu’ils puissent être éliminés. Qui dit optimisations poussées dit bien souvent stratégies d’accès mémoires sophistiquées basées sur des calculs d’adresse, des structures complexes. L’optimiseur ne pourra rien déduire sur les adresses d’accès, donc ne pourra pas éliminer le bound checking. Encore une fois, on ne peut pas résumer un programme à des cas particuliers simples.



Quand au débat sur le nombre de cas de figure qui prennent un gros ralentissement avec le bound checking, c’est juste un très mauvais débat. En informatique, tous les algo (ou presque), toutes les stratégies d’accès mémoire ont leur utilité à un moment ou un autre.



L’optimisation, c’est justement l’art de rendre optimal des cas particuliers, parce que les performances d’un programme peuvent dépendre d’un cas particulier. Si c’est l’algo dont tu as absolument besoin pour ton programme qui n’est pas optimal avec le bound checking, ça te fera une belle jambe de savoir que tu est dans “un cas particulier”. En informatique, selon la loi de Murphy il y a des cas particuliers tous les jours et particulièrement dans l’endroit le plus critique du programme que tu est en train d’écrire. " />



Pour conclure, je dirais que cela fait des décennies que les deux écoles s’affrontent. Ce n’est pas demain que le débat cessera…