divide a écrit :



J’ai l’impression que tu as complètement zappé toutes les applications qui sont basés sur les performances pures, sans aucun lien avec les problématiques de sécurité





Premièrement rien n’est “sans aucun lien avec les problématiques de sécurité” : tout code disposant de droits peut être subverti. Ton innocent jeu peut être utilisé pour miner des bitcoins, pour te soutirer ta monnaie virtuelle pour les revendre à d’autres joueurs (jeu en ligne), pour télécharger et installer un malware sur la machine, pour espionner ton navigateur et récupérer tes identifiants, etc. Et puis on ne compte pas le nb d’applis critiques en termes de sécurité encore codées en C/C++ aujourd’hui sans que ce soit nécessaire.





Ensuite l’exigence en termes de performances n’est absolument pas un pb parce que :

* Aujourd’hui les performances c’est une affaire d’algos, et notamment de parallélisation, pas de trois instructions CPU en plus ou en moins (je caricature un peu, voir la suite).



* Aujourd’hui les performances c’est une affaire de GPGPU et d’archi hétérogène. Il y a un travail spécifique à y faire en termes de sécurité mais les performances sont insensibles au fait que tu utilises lua ou le C pour piloter ton GPU.



* Avec un bon compilateur il est possible d’avoir d’excellentes performances en C#, souvent supérieures à celles d’un C++ moderne avec son cortège boost/stl qui répliquent les lourdeurs du C# (parfois en pire). Ne manque vraiment que la capacité de contrôler plus finement les allocations et d’avoir des objets plus légers et sans introspection, d’où un projet comme celui de M#, sûr mais léger. Et il manquait un vrai compilateur, ce qui est en passe de correction.



* Cela restera t-il plus lourd qu’un code C très optimisé ? Oui et il faudra faire avec, ce qui ne sera pas un gros problème.







psn00ps a écrit :



Une simple boucle for avec rien que des new dedans montre que le temps de chargement des libs est non négligeable. " />

Je pense plutôt à un binaire lambda dans la nature. Sans le source, tu perds l’assurance que le binaire sera exécutable sur ta machine. (à moins qu’il ne soit dès le départ dépendant d’une librairie native, mais là c’est autre chose)





Si tu voulais dire par là que le compilateur JIT ne peut pas être rendu plus efficace, nous sommes d’accord, il faut de l’AOT.

divide a écrit :



Chacun ses priorités; tu as visiblement une obsession pour la sécurité





Il suffit de voir la multiplication des APT (advanced persistent threat - malwares qui demeurent des années sur des machines sans jamais être détectés), des virus rançonneurs, ou le fait que de plus en plus de gens stockent des crypto-porte-monnaies sur leur disque. Je n’aime pas la sécurité non plus mais là on fonce dans le mur et quand on voit ces proliférations de menaces d’une part, et de l’autre le fait que les agences de renseignement entrent partout comme dans du beurre et peuvent tout écouter, il y a quand même de quoi se dire que notre industrie se complait dans l’amateurisme.



Parce qu’à part quelques exceptions nous ne nous sommes jamais donné les moyens de réaliser des systèmes fiables alors même que les systèmes informatiques sont utilisés pour des tâches extrêmement critiques, depuis des plateformes gérant des milliers de milliards d’euros jusqu’à des pacemakers en passant par des systèmes de pilotage. Et si tu tiens à me soutenir que ce n’est pas si mauvais que ça, qu’il y a d’autres sécurités derrière, etc, j’ai des hordes d’exemples dans tous ces domaines pour démontrer le contraire.



Il n’y a que dans le logiciel que l’on trouve des clauses dédouanant les éditeurs de toute responsabilité pour les défauts du produit ! Mais dans certains pays les ingénieurs sont pénalement responsables à titre personnel du fruit de leur travail. Un jour un logiciel va causer un désastre de grande ampleur et les médias et les politiciens vont se rendre compte que nous sommes une industrie de guignols et nous lyncher. Entre un bogue OpenSSL visiblement utilisé pendant des années par toutes les agences de renseignement de la planète pour nous fliquer et les Toyota qui te forcent à rouler à 150km/h, pour ne citer que les deux scandales les plus récents, il va falloir combien d’exemples encore ?





Dans mon cas, passer mon code en .Net serait un peu me tirer une balle dans le pied.



Je pense que tu sous-estimes de beaucoup les performances actuelles d’une part et, de l’autre, celles qui peuvent être atteintes avec un bon compilateur. L’écart ne serait pas si grand que tu le penses (sauf si tu passes ton temps à coder en C et assembleur - pas du C++ à grands renforts de STL et de smart pointers).







sepas a écrit :



Le CPU ne coûte plus rien et on préfèrera booster un peu les machine en sécurisant son code avec du langage managé que de se cantonner à gagner le moindre pet de CPU pour une requête.





Je ne suis par d’accord avec ce raisonnement : cette logique est valable pour les serveurs, où il vaut souvent mieux acheter un serveur de plus que d’optimiser (encore que le problème est différent si tu t’appelles Google ou Amazon et que tu achètes tes serveurs par millions).



Sauf que derrière il y a bien des cas où on ne peut pas acheter plus rapide parce que ça n’existe pas, et tu te retrouves avec un goulet d’étranglement. Ca fait belle lurette que les CPU ne coûtent plus grand chose et que la puissance par coeur stagne. Pas beaucoup de nouveauté de ce côté là.



Je pense qu’on ne doit pas dire qu’il n’y aura pas de pb. Seulement qu’il sera beaucoup plus rare que certains le pensent.







vampire7 a écrit :



C’est tout le contraire : il n’y a qu’à voir la course à la performance des navigateurs web. Dès que tu regardes une vidéo, c’est pareil : le décodage des flux H264 et cie. sont des concentrés d’optimisations.





Justement, la course aux perfs dans le web ce n’est pas de la micro-optimisation mais des algos très sophistiqués et complexes pour analyser le code, typiquement le genre de choses où tu veux un langage de haut-niveau pour garder une lisibilité et maintenabilité. Quant à la vidéo, même si à tout casser c’était deux fois plus lent que ce qu’on pouvait faire dans un langage sûr (et j’en doute foutrement), elle est de plus en plus traitée sur GPU et pour ça le fait d’utiliser lua ou le C ne fait aucune différence.





On peut ajouter à ça bon nombre de jeux, et les programmes traitant de grandes quantité de données, comme les logiciels de retouche photo, le chiffrement de données (les instructions AES-NI ne sont pas là pour rien)… Sur ce dernier point, on peut voir par exemple pas mal de gens se plaindre du manque d’optimisation de TrueCrypt.



On peut très bien exposer des API pour manipuler des fonctionnalités spécifiques du matériel. Et puis aujourd’hui les plus grosses innovations matérielles nécessitent de toute façon un changement de l’OS pour être adapté avec la fusion CPU-GPU, afin que le GPU ne soit plus un citoyen de seconde classe avec tout ce que ça implique pour les perfs.

vampire7 a écrit :



“Le web”, ça ne veut rien dire. Je parle des navigateurs : regarde un peu comme ça râle parce que sur certaines machines, l’interdiction de la compilation JIT empêche de concevoir des navigateurs performants sur le javascript… Ce genre de bidouille demande un travail énorme, et tout ça pourquoi ? Juste pour gagner un peu de perf.





Il n’est pas nécessaire d’interdire la génération de code à l’exécution pour avoir quelque chose de sûr : il suffit d’imposer que celui-ci soit au moins dans des pages mémoire différentes voire un processus différent avec des privilèges moindres sans partage mémoire (ou seulement via un protocole déclaré dans le binaire d’origine).



Cette interdiction pure et simple relève d’une volonté de vérification du code par le gérant de l’appstore. Mais c’est inefficace et des outils automatisés travaillant sur un bytecode de bas niveau vérifiable feraient bien mieux. De tels outils pourraient être invoqués à l’exécution.





2 fois plus lent ? Alors voilà un exemple. Cette opération est le cœur du mode d’opération XTS utilisé en cryptographie.



Les performances de ton exemple s’appuient sur des instructions particulières. Comme je l’ai dit rien n’empêche d’exposer des moyens de consommer ces instructions. Ce genre d’optimisations existerait donc toujours. En fait je ne les considère même pas comme des optimisations tant elles sont évidentes.



Ce qui serait inaccessible c’est :

* Le code directement en asm.

* Les alignements manuels de données.

* Les callbacks personnalisés pour les interruptions utilisées par le langage.

* Quelques autres bidouilles de ce genre.



Et ce qui serait imposé serait :

* Les vérifications des indices.

* L’initialisation de la mémoire.

* Un GC ou un comptage de références, ce qui veut dire 4 à 8 octets de plus par objet.





Est-ce négligeable ? Non. Mais entre ça et un code super-optimisé, je doute qu’on ait plus de 20 ou 30% de différence dans les pires cas. Est-ce négligeable ? Non. Est-ce que de tels ralentissements sur une poignée de programmes valent un environnement sécurisé ? Oui.





Quant au calcul déporté sur GPU, c’est loin d’être la solution miracle, à cause de toutes les latences nécessaires : transfert des données vers la VRAM, récupération des résultats, et les calculs eux-mêmes : tous les algorithmes ne sont pas parallélisables. Par exemple, un calcul de hash, c’est purement séquentiel.



Bien sûr, néanmoins c’est pour de plus en plus de programmes la voie à suivre. Et tout l’enjeu est justement de supprimer cette latence en virant le bus PCIe et en faisait du GPU un citoyen de première classe.





Ne sous-estime pas l’importance de la performance



Ne sur-estime pas l’importance des micro-optimisations et le coût d’un code sûr.

vampire7 a écrit :



Si le code généré dynamiquement n’a accès à rien, il ne sert pas à grand-chose…





Les données ne seront pas partagées mais elles pourront être communiquées : autrement dit on peut dupliquer les données d’un processus à l’autre via un protocole spécifié par le processus hôte.



Pour un navigateur ça revient par exemple à fournir initialement au processus JS une copie du DOM et JS envoie alors les modifications à effectuer au parent, chacun des deux modifiant sa propre copie. Le genre de construction qui est de toute façon nécessaire pour mettre en place un rendu concurrent de l’exécution javascript.





Ces instructions n’ont rien de “particulières”



Je sais pertinemment ce que sont ces instructions et ce qui importe c’est qu’elles peuvent être rendues accessibles par des langages sûrs, tout comme elles le sont aujourd’hui par le C++ 11. On pourrait même choisir d’exposer un contrôle plus fin que ce qu’a fait C++ 11 qui, de ce que j’ai lu, semble avoir masqué les complexités.





Le premier truc qui aurait dû te sauter aux yeux, même sans la moindre analyse, c’est le “if” du premier cas : un saut conditionnel rate statistiquement une fois sur deux, et dans ce cas, à cause d’une prédiction de branchement ratée, il y a tout le pipeline du CPU à recharger.



Sauf que le coût est en fait négligeable parce que le code asm produit est optimisé pour les algos “next line” typiquement mis en oeuvre dans les CPU.



Cet algo se base sur la différence entre la position courante et la cible du branchement pour optimiser les cas tels que :

1: aller à 3 quand vrai

2: aller à “fin de boucle”

3: début du corps de boucle



Pour simplifier à partir du moment où le compilateur est conscient d’une méthode pour optimiser les boucles sur la plateforme actuelle il est automatiquement conscient d’une méthode pour optimiser les vérifications aux indices. Le seul poids significatif qui demeure est l’obligation de charger la taille.



Enfin n’oublions pas tous les cas où les vérifications aux indices sont simplement virés, comme dans l’exemple suivant où le compilateur vérifiera simplement “quantité” : “pour i de 0 à quantité faire tableau[i] = tableau[i] + 1”





Mais ça nécessite de savoir à l’avance quelles instructions seront exécutées, ce que ne permet pas le code managé.



En quoi ne le permet-il pas ? Il n’y a aucune différence avec un autre langage de programmation. D’ailleurs inspecter le code asm généré est un jeu d’enfant sous VS.





C’est plus que des optimisations. L’algorithme lui-même doit être adapté ou adaptable. Par exemple, s’il faut accéder à des tables pour les calculs, s’il faut des sauts conditionnels, ou même parfois des trucs simples comme des rotations de bits fréquentes, c’est mort.



Et tu pourras très bien faire ça dans un code sûr.





La plupart de ces instructions nécessitent des données alignées sur 128 bits.



Ce qui ne pose aucun problème dès lors qu’un type ad hoc existe. Comme en C++.





Quant à une vérification matérielle



Les tables virtuelles ne peuvent pas être modifiées par un code en espace utilisateur et mon intuition me dit qu’elles sont certainement trop longues à altérer et peut-être même trop longues à lire.





Qu’appelles-tu “vérifications des indices” ? Une vérification logicielle est impensable : tu n’obtiendrais pas un code 10 fois moins rapide mais plutôt de l’ordre de 50 ou plus.



Un branchement conditionnel raté (avec vidange du pipeline) coûte trois à quatre fois le coût d’une addition d’entiers, pas cinq cent fois. Il est donc mathématiquement impossible que la plus sommaire des boucles (dix instructions dont un branchement) soit ralentie de plus d’une dizaine de pourcents par l’ajout d’une vérification indicielle statiquement invérifiable exécutée sur une plateforme exotique où l’on ne pourrait pas optimiser la prédiction des branchements.





Comme beaucoup d’autres, je veux rester maître de ma machine et pouvoir exploiter chaque composant comme je le veux.



C’est loin d’être le cas aujourd’hui : l’assembleur est de bien plus haut niveau que les instructions du processeur et ce dernier contient un sacré bazar qui ne te sert à rien. Par ailleurs tous tes programmes s’exécutent en espace utilisateur et le moindre accès mémoire passe sous les fourches caudines de la mémoire virtuelle.





Mais heureusement, ce n’est pas près d’arriver, car ça supprimerait bon nombre de jeux qui requiert des performances maximales, un marché que Microsoft ne peut pas se permettre de perdre.

@

Et je t’assure que ces jeux peuvent parfaitement être programmés dans un langage “sûr”.





D’ailleurs, je te rappelle que la sécurité absolue n’existe pas, et .NET est loin d’être à l’abri des failles.



Et la ceinture de sécurité ne soigne pas le cancer.







vampire7 a écrit :



92 euros de l’heure ? Euh… c’est quoi ta boîte ? " />





Une boîte où ils ont eu la bonne idée de payer les charges et taxes, de louer des locaux, de payer les factures, d’embaucher des secrétaires, des commerciaux, des comptables, des juristes, des traducteurs, etc.

Maxim Killigan a écrit :



Combien de développeurs ont participé aux commentaires ?



Parce que, perso, du C# natif sous Linux, ça me fout une demi molle.



Et bien que fan du cpp, il est évident qu’en matière de revenus générés, c# est loin devant car tellement facile.



Et il est évident que l’attitude de Microsoft a été vers l’ouverture depuis les dernières 5 ou 6 années.



Et encore une fois: je ne suis pas un fan de MS, loin de là, mais il faut aussi ouvrir ses yeux.





Et bien écoute, en tant qu’ancien dév C++ volontairement reconverti au C# presque depuis son introduction, ça me fait plaisir de lire ça.



Bon après moi j’en suis au stade où ses limites (*) finissent par me sortir par les yeux au point que je cherche un nouveau langage mais je crois que je vais chercher longtemps avant de trouver mieux.

" />





(*) Typage trop restrictif (sur ce point C# < Java < C++ !), absence totale d’optimisations des allocations (à voir si leur compilo AOT corrige ça) qui rend l’utilisation de certaines fonctionnalités prohibitives dans certains contextes, et une certaine verbosité dans certains cas, notamment des choses typiquement fonctionelles (types imputables & co, comme en Java ou C++)