Midori est un projet de système d’exploitation au sein de Microsoft sans aucun rapport avec Windows. Alors que l’actualité s’était faite discrète à son égard depuis un certain temps, plusieurs éléments récents laissent penser que son développement a nettement progressé et qu’il s’avance doucement vers une exploitation commerciale.
L'émergence après le calme
Midori est un nom de code abordé de nombreuses fois dans nos colonnes. Il prend sa source dans le projet Singularity d’un système d’exploitation basé sur un micronoyau et presque entièrement écrit en code managé. Durant des années, Singularity et Midori ont été abordés essentiellement comme des projets de recherche puis en phase d’incubation, cette dernière soulignant que ses concepteurs réfléchissaient déjà à une mise en pratique du travail accompli.
Il faut bien comprendre que si Midori devait sortir demain, il serait un produit très différent du Windows que nous connaissons. Il ne s’agit pas d’une question d’ergonomie et d’interface mais bien de base technique, sans aucun rapport avec les technologies actuelles ou encore le NT. On ne sait pas comment Microsoft pourrait commercialiser un tel produit et dans quelles directions, mais une arrivée sur les ordinateurs de tout un chacun ne semble pas en tête de liste.
Le projet a rejoint la division systèmes d'exploitation de Terry Myerson
Selon un article de Mary Jo Foley de ZDnet, Midori se rapproche cependant un peu plus d’un produit réel. Selon deux sources, c’est tout le projet qui est maintenant géré au sein de la nouvelle division systèmes d’exploitation de Microsoft, dirigée par Terry Myerson. Le même Myerson qui donnait ces derniers mois quelques bribes d’informations sur la convergence des systèmes chez le géant.
Cette information est complétée par une seconde sous la forme d’un billet de blog paru le 27 décembre et rédigé par Joe Duffy, l’un des développeurs de Midori. Il y explique un aspect important du développement du système sans jamais vraiment le nommer car il aborde le langage utilisé pour ce faire : M#. Il s’agit en fait d’un groupe d’extensions pour le C# pour composer un langage système hérité de l’ancien projet Sing#.
Ce langage de programmation système pourrait d’ailleurs devenir open source, ce qui laisse penser qu’il jouerait un grand rôle dans le futur de la firme. Ce projet est par ailleurs lié à Roslyn, un nouveau compilateur dont nous avons parlé le mois dernier, puisque l’équipe doit l’y implémenter. Mais les questions que l’on peut se poser devant les explications de Joe Duffy concernant à la fois l’utilité de M# et la manière dont tous ces projets pourraient s’intégrer dans l’informatique d’aujourd’hui.
De l'utilité et de l'intégration dans le paysage actuel
L’utilité de M# a justement été débattue dans les commentaires qui ont suivi. La décision de se baser sur C# est initialement expliquée dans le billet de Duffy : la réduction de la complexité, le nombre de développeurs sachant aujourd’hui l’utiliser et la nécessité de certaines notions telles que la sûreté de typage. Mais pourquoi ne pas utiliser des langages existants tels que D, Rust ou Go ? Selon Aleks Bromfield, qui a passé les quatre dernières années à développer ce langage mais qui travaille maintenant chez Google, M# reprend des éléments des uns et des autres : la sûreté et les performances de Rust, la simplicité de Go ainsi que la familiarité du D. Il explique par ailleurs que le M# peut être utilisé pour n’importe quelle application et qu’il devrait être le langage le plus bas niveau dont les développeurs pourraient avoir besoin.
Mais comment Midori et M# (la lettre M n’est certainement pas due au hasard) pourraient-ils s’intégrer aujourd’hui dans l’écosystème logiciel actuel puisque les bases techniques sont totalement différentes ? Il y a plusieurs aspects à la question, dont le premier concerne justement les applications existantes. Tout dépend en effet des API dont on parle : il est clair que les logiciels Win32 ne pourront pas fonctionner sur une telle nouvelle base à moins que Microsoft ne mette en place un mécanisme supplémentaire (Drawbridge ?), mais la situation est très différente dès que l’on aborde WinRT.
Des annonces sans doute à prévoir cette année
Cet environnement, apparu avec Windows 8 et constituant la base des nouvelles applications disponibles dans le Windows Store, apparaît comme relativement autonome. Lorsque nous l’avions abordé dans notre dossier Windows 8, nous avions souligné que WinRT reposait bien sur Win32 mais avec un nombre très limité d’attaches. Nous avions également suggéré qu’il était de fait possible d’imaginer que l’on pouvait « débrancher » WinRT pour le réinstaller sur une autre base. Une notion qui semble confirmée à demi-mots par Aleks Bromfield dans un tweet.
Dans tous les cas, l’élément important concerne bien l’inclusion du projet Midori au sein de la division de Terry Myerson. L’une des sources de Foley lui a indiqué à ce sujet que l’équipe devait décider quels éléments de Midori pouvaient être intégrés dans la stratégie en cours. L'année 2014 pourrait finalement voir plusieurs annonces concernant le système ainsi que le M#.
Commentaires (220)
#1
“The idea is that M# should be the lowest-level language that you’ll ever need. It sits at the very bottom of the stack. But it’s also safe and productive enough to be appropriate for writing higher-level systems, like Web services,”
" />
Vivement
#2
J’en avais parlé dans de précédents commentaires avec sr17 et harmattanblow.
Le M# est un langage derivé de c# qui est type et memory safe mais qui obtient les mêmes performances que le C++.
Joe duffy l’explique clairement. Les débats sur le sujet comparaient à l’implémentation actuelle du .NET. Mais ca ne marche pas du tout pareil. Joe duffy expose plusieurs points:
1)ce n’est pas de la compilation JIT mais un compilateur ahead of time. le codé est compilé directement en natif.
2)L’autre point débattu à l’époque c’était les mauvaises performances du garbage collector actuel. Visiblement ils ont travaillé dessus.
3)Le point majeur débattu: Avec des langages manages il y a une vérification des dépassement de tableaux par défaut pour éviter les buffer overflow. J’expliquais que ce serait largement compensé par de fortes optimisations avec le compilateur. C’est confirmé ici:
It is true that bounds checking is non-negotiable, and that we prefer overflow checking by default. It’s surprising what a good optimizing compiler can do here, versus JIT compiling.
Se renseigner aussi sur le tree shaking qui est une des optimisations importantes. Voir ici
De toute façon quand on voit le nombre de failles dans les navigateurs web par exemple ça prouve bien qu’on peut pas compter sur les développeurs pour éviter de pondre des failles.
Au final M# devrait bien obtenir les performances nécessaires pour la programmation système.
Je finirai sur le fait que joe duffy l’a annoncé clairement qu’il est arrivé au but. C’est fort probable que des milliers de développeurs vérifieront ses propos.
#3
#4
#5
“Lucky Williams : Lucky Williams, Expert PAKRAM sur MOS 32 H-track en bibande PADIRAK.
" />
Topper : Padirak ?
Lucky Williams : En circuit fermé Lieutenant.
Topper : Oui bien sûr.”
#6
#7
#8
#9
#10
#11
#12
M# n’est pas un langage associé à Microsoft. M# n’est jamais mentionné dans le blog de Duffy !!
(uniquement dans les commentaires de mecs qui ont fait des associations de mots)
M# est développé par une société britannique et mis en œuvre pour la réalisation de sites webhttp://en.wikipedia.org/wiki/M_Sharp_%28programming_language%29
#13
#14
#15
#16
#17
#18
Rien compris à l’article… Pas l’niveau…
" />
#19
#20
#21
#22
#23
#24
#25
#26
#27
#28
En fait la news en parle,c’est que j’avais prédis à l’époque dans le dossier sur Windows 8. WinRT a été conçu pour tourner au dessus de Midori.
Pour Win32 il y a drawbridge.
#29
#30
#31
#32
#33
#34
#35
#36
#37
#38
#39
#40
#41
#42
Putain, c’est affolant de lire des conneries pareilles. Aucun de vous n’y connais strictement rien en programmation c’est bien là le problème, et c’est pas en justifiant des âneries que n’importe qu’elle expert utilisera à vos dépends …
1- Il y a encore des gens qui doutent de l’utilité de l’assembleur pour écrire un OS ? Ton Pipalo-Pentium tu le passes comment en mopde protégé ?
2-Y’a encore des crétins qui utilisent autre chose en C++ que des vecteurs ou des liste, pour aller se plaindre que les structures n’ont pas de bound checking ? Et puis quelque soit le langage à partir du moment ou le compilo fait ton travail à ta place faut pas venir se plaindre des perfs, que ce soit en managé, compilé, précompilé, etc
3- En C c’est plus complique il faut tout se taper à la main mais quand on en a fait 3-4 ans sérieusement on connait -> pour ça qu’on se met au C++
4- En 20 ans j’ai jamais vu un bon programmeur java faire mieux qu’un bon programmeur C++, alors pour le reste on a encore sincèrement de la marge.
5- Avant de vendres vous programmes dites moi, vous avez bien eu le temps de les TESTER
#43
#44
#45
#46
#47
Les gens achètent (ou plutôt subissent l’obligation d’acheter) Windows pour deux raisons principales :
" />
-1) L’environnement est familier, je sais le faire marcher.
-2) Je peux faire tourner ma 100aine de crapware que j’ai amassé au fil du temps.
On a bien vu avec RT ce que ça a donné !
1 et 2 ne sont plus réunis => rejet massif.
Même si l’environnement est indépendant d’un noyau, je doute donc d’un succès d’un autre kernel qui foutrait en l’air l’affirmation numéro 2.
… ou alors ils mettent Wine en plus sur Midori pour faire tourner les crapwares !
#48
#49
#50
Voilà pourquoi j’aime pci ! Pas pour les les news Apple pu ça se tire dessus à coups de mauvaise foi bien puante mais pour les news techniques de de se genre.
#51
#52
#53
#54
#55
#56
#57
#58
Sinon GNU Hurd s’en est où ?
" />
#59
#60
#61
#62
#63
#64
#65
#66
#67
#68
#69
#70
#71
A vous lire, ça va vouloir dire changement de terminale de windows phone 8 à 9.
" />
#72
#73
#74
Midori open source ? Ce serait un très grand progrès
" /> et en même temps une menace pour linux 
" />
" /> comme j’aime bien le faire 
" />
Dommage je pourrais plus dire “le proprio c’est le mal”
#75
Je pense que c’est ce qu’ils commencent à faire en rapprochant RT de Windows Phone faire une api unique qui sera capable de tourner sur tout leur système, même sur midori.
Donc c’est pour ça qu’ils ont obliger les utilisateur de PC traditionnel à avoir cette interface Metro pour pousser les devs à sortir des apps dessus et à terme avoir un gros paquet d’appli à la sortie de Midori comme on a actuellement sur Win32 (pour éviter de perdre de grosse part de marcher sur le desktop)..
#76
#77
#78
#79
Je ne vois pas trop ce que vient faire le DO178 et des exemples issus de l’avionique dans la conversation… On ne connait pas précisément la cible de Midori, mais on peut imaginer PC/tablettes/smartphones, pas les systèmes temps réel, et encore moins embarqués avioniques qui tombent sous le coup du DO
" />
#80
#81
Je me pose une question qui peut paraitre con, pourquoi creer un nouveau language au lieu de se focaliser sur un compilateur natif C# qui aura du-coup grosso modo les memes perfs ?
#82
#83
#84
#85
#86
Ce n’est pas du blabla et c’est même une définition claire du domaine de ce langage. L’asm ne sera pas autorisé dans cet OS donc ce sera bien pour les dévs Windows le plus bas langage dont ils auront besoin, celui conçu pour écrire jusqu’aux pilotes de périphériques et pour écrire tous les pilotes. C’est la contrainte sur laquelle ils travaillent, par opposition à C# qui restera dédié à des applications de plus haut niveau.
Oui tout a fait, au niveau système le M# sera obligatoire pour éviter les bsod sur les pilotes entre autres et les failles de sécurités dans le système.
Par contre au niveau applicatif rien ne changera on devrait pouvoir toujours coder e C++ avec WinRT
#87
#88
#89
#90
#91
#92
#93
#94
#95
#96
#97
#98
#99
Au début je pensais aussi la même chose qu’harmattanblow :que le c++ ne marcherait plus sur Midori. Mais j’ai pu lire des brevets et certaines lectures qui m’ont fait changé d’avis.
Microsoft mise toujours sur le c++
Le but de WinRT était de mettre au même niveau tous les langages. Avant si on codais en C++ ,on ne profitait pas des mêmes api qu’en codant en .NET
Avec WinRT le framework est uniforme pour tous les langages.
.
En effet Windows est un os first class c++ et Midori un os first class M# mais le C++ devrait subsister.
De nombreux projets sont écrits en C++. Ca reste plus simple de porter le projet sur WinRT (surtout pour les projets multi) que de complètement tout réécrire en M#
Au final seuls les développeurs systèmes devront coder en M#. mais vu les gains en terme de rapidité de développement et de fiabilité, je doute que ce soit un problème.
#100
#101
#102
#103
Il existe bien le c++ CLI, ça sera peut être la même chose sur Midori.
#104
#105
#106
J’espère que Microsoft mènera a bien ce projet, et pourra sortir une version commerciale assez rapidement.
Pourquoi ?
Actuellement, il y a trois acteurs majeurs : Apple, Google et Microsoft.
Ce dernier serait le premier à sortir un OS “next-gen”.
Google et Apple travaillent aussi certainement sur ce type de projet, mais je pense qu’ils sont à un stade beaucoup moins avancé (Google part sur les réseaux sociaux, les robots, voitures etc.., Apple sur le prochain gadget révolutionnaire ?).
Vu les avantages supposés avec Midori, cela pourrait relancer Microsoft au premier plan avec :
Bref, à terme cela pourrait casser le WinDaube que tout le monde aime prononcer. Car à vrai dire, combien de personnes voient plus d’écrans bleus en comparaison du nombre de reboot/freeze de leurs téléphones/tablettes ?
#107
#108
#109
#110
#111
#112
#113
#114
j’ai oublié de mentionner quelque chose il semble que harmattanblow n’a pas saisi ce point.
Quand on code en C++ sur WinRT ,le code qui appelle les api doit être en C++/CX qui est un safe langage. C’est ce que j’ai expliqué au dessus les appels aux api WinRT sont type et memory safe. Ce point et la sandbox sont suffisantes pour faire marcher une application C++ au dessus de Midori. pas besoin de VM.
#115
#116
#117
#118
#119
#120
Vu qu’harmattanblow a des soucis de mémoire. Voilà une vieille offre d’emploi Microsoft dont nous avons débattu à l’époque:
" />
https://careers.microsoft.com/resumepreview.aspx?aid=86472
ou will write code in a language like C# that has the performance characteristics of C++
mais bien sur il a oublié
#121
Ah ça oui, vous en avez débattu (et vous vous êtes battu
" />) plein de fois tous les 2 de Midori 
" />
#122
J’ai retrouvé ce lien interessant sur les types en c++/cx:
http://msdn.microsoft.com/library/windows/apps/hh700121.aspx
UIntPtr
(For internal use only.) An unsigned 64-bit value that is used as a pointer.
IntPtr
(For internal use only.) A signed 64-bit value that is used as a pointer.
Ca explique bien ce que je disais plus haut, les pointeurs peuvent être utilisés uniquement en interne dans l’application. pas dans des api sinon une exception est déclenchée.(voir le lien avant)
#123
#124
#125
#126
Les API, oui. C++ CX, non. Il n’est pas vérifiable. Il n’y a absolument aucune restriction sur les pointeurs ou les instructions utilisées, tu ne peux pas le faire tourner en ring0 car tu ne peux pas avoir la certitude que telle variable ne pointera pas vers une adresse du noyau au moment où elle sera écrite.
faudrait que je retrouve un vieux ppt mais ils ont incorporé plusieurs mot clés pour s’aligner sur les langages managés. mais disons que la tu es d’accord pour les api.
Pour ce que tu dis sur le ring0 je suis d’accord mais regarde ceci ça va répondre en partie à ta question je pense:
https://careers.microsoft.com/resumepreview.aspx?aid=8160
Our Kernel is a non-traditional design divided between a native C++ microKernel and additional managed C# operating system functionality which is injected into each independent hardware address space.
C’est ce que j’avais entendu parler il devrait y avoir un espace d’adressage mémoire indépendant pour le natif. Du coup il n’y aucun risque que l’appli native corrompt le système.
Mais j’ai pas toutes les informations en effet la dessus. Par contre tu ne penses pas que si Microsoft sort une nouvelle plateforme de dev alors que win32 a duré plus de 20 ans, il ne va pas la jeter 3 ou 5 ans après?
Mais arrête de m’insulter enfin !
Je me rappelle avoir discuté de nombreuses fois avec toi de ces sujets mais je ne me rappelle pas s’ils avaient été révélés par toi ni à quel moment par rapport aux autres, c’est aussi simple que ça et il n’est pas du tout étonnant que la chronologie exacte m’échappe des années plus tard.
Et j’ai été très surpris et choqué par tes réactions tout au long de ce sujet. Je suis venu pour une discussion technique sur un sujet qui m’intéresse et je me retrouve avec des approximations et un problème d’égo sorti de nulle part.
Ok tu as oublié pas de soucis désolé
#127
Que viens faire Roslyn dans l’histoire ? Juste un projet annexe ou c’est lié ?
#128
Je pense que ce brevet de galen hunt devrait plus répondre à ta question:
http://www.freepatentsonline.com/7882317.pdf
Dans ce brevet Microsoft envisage d’utiliser les ring du cpu et donc l’isolation matérielle pour avoir la délimitation kernel/user mode. La différence par rapport à Windows est que les “process” qui tournent en kernel mode sont isolés logiciellement par des SIP.
C’est une sorte de compromis entre l’isolation matérielle et logicielle et ça devrait résoudre le problème que tu as mis en valeur plus haut.
#129
#130
Quand vous dites SIP c’est : Session Initiation Protocol O_o ?
#131
#132
#133
Ces SIP sont cencés êtres plus performants que l’utilisation du ring 3 des processeurs c’est ça ?
#134
#135
question débiles en fait : a supprimer
#136
L’isolation logicielle se fait au niveau du compilateur qui à la fin vérifie que le code généré soit bien vérifiable et qu’une adresse mémoire n’aille pas pointer sur un autre SIP.C’est une isolation par le langage. Harmattanblow a parlé plus haut de ce point.
#137
#138
Oui l’isolation matérielle est beaucoup plus coûteuse en performances.
hheeuuu ???? depuis quand ?
L’isolation logicielle se fait au niveau du compilateur qui à la fin vérifie que le code généré soit bien vérifiable et qu’une adresse mémoire n’aille pas pointer sur un autre SIP.C’est une isolation par le langage. Harmattanblow a parlé plus haut de ce point.
Ça a déjà beaucoup plus de sens ! Donc en clair, il n’y a PAS d’isolation.
Maintenant la question qui fache… qui maitrise le compilateur ?
Pärce que dans l’ère “je m’appelle nsa me faites pas chier”, ça veut dire “j’ai tour les droits, et tu n’as AUCUN moyen de controller ni vérifier quoi que ce soit, ni même de t’en proteger”
Moyen quand même comme concept…
#139
#140
#141
#142
Si il y en a une vu que tout ce qui tourne en kernel mode est du code vérifiable.
non il n’y en pas pas vu que la compote de pomme est trop sucrée et que les avions nagent à contre courant… -_-
Pour le compilateur il est dans la trusted base. Bartok avant de de générer du code natif génère du Typed Assembly language(TAL) , une sorte de pseudo code assembleur vérifiable. Le compilateur est compilé du TAL de mémoire.
je répète donc ma remarque, personne n’a de maitrise sur la chaine de compilation, et c’est à elle qu’il faut faire confiance pour la sécurité de l’os…
je vais le dire autrement…
“Ma maison est sure car les clés m’ont été données par l’ancien propriétaire et je n’ai aucun moyen de changer la serrure ni mettre d’alarme chez moi sans lui demander et qu’il l’installe lui même”
C’est une blague ???
#143
N’en change pas c’est de la bonne !!!
C’est tout ce que tu as comme argumentation pour ta réponse ??
J’en conclue que tu es d’accord avec moi ?
#144
#145
#146
Tout à fait : on vérifie en amont que tout le monde est honnête et du coup plus besoin de flics. Dit comme ça ça n’a pas l’air très sûr mais en fait ça l’est beaucoup plus que le système actuel.
Bien résumé c’est le principe de fonctionnement de singularity et Midori
Avec Windows on laisse faire et on tente de protéger les dégats avec plein de garde fous.
Avec Singularity/midori on établit les règles du départ. Du coup pas besoin de garde fous inutiles.
#147
#148
#149
Le certificateur, pas le compilateur. Le certificateur vérifie le code en bout de chaîne alors que les compilateurs ne seront pas dans l’OS et pourront être indépendants
Ça me parait pas si évident.
Je pense qu’on peut facilement inventer un langage dans lequel tout programme peut-être certifié (c’est d’ailleurs ce qui a été fait si j’ai bien compris, et ça existait avant cela)
Par contre, certifer le résultat d’un programme, au pif, d’un compilateur, c’est une autre histoire… qui ne doit pas être très loin de la question de la terminaison d’un programme, qui est indémontrable.
Je conçois qu’un peut facilement certifier un compilateur, mais pas le résultat de ce qu’il compile, seulement en lisant le code du compilateur.
Et là où il y a une différence d’indépendance par rapport au système actuel (qui est loin d’être parfait, on est bien d’accord) c’est que tu n’as pas la possibilité d’écrire du code qui va monitorer/manager un autre programme, car il sera invalide et te sera refusé à la compilation (quid d’un débogeur tiens, comment cela marche sur un tel système ?)
#150
#151
#152
#153
#154
#155
Par contre le TAL m’inquiète un peu. Aujourd’hui le bytecode dotnet contraint tous les langages dotnet à se taper le même système rigide de types. Impossible de l’enrichir sans implémenter une infrastructure complète au-dessus de l’infrastructure, avec les performances que tu imagines (il suffit de voir F#). Je trouverais dommage que Midori nous enferme ainsi dans un système de typage trop cloisonné. Pour moi c’est le gros point noir.
#156
Hum … Donc si j’ai bien compris la politique associée au langage concernant la mémoire, grosso modo on a un langage qui accepte l’allocation dynamique, on va recevoir les accès à ces zones par des références (au sens C++, pas des pointeur quoi), qui sont modifiables mais uniquement par affectation d’une référence valide (pas d’arithmétique des pointeurs, c’est pas pour me déplaire).
Sur un langage full-GC (même si j’aime pas les GC), je trouve ça ok effectivement.
Cela dit si on a du très bas niveau, on veut avoir une déalloc parfaitement déterministe. C’est quoi derrière ? Du comptage de référence ? Ce serait quand même plus correct d’être plus précis niveau responsabilité si on veut très efficace, non ? (comprendre shared_ptr/unique_ptr en C++11).
Grosse interrogation pour ma part également : quid des modèles mémoire faibles ? C’est oblitéré par des barrières fortes où l’on a toujours le choix de rester borderline ? Parce que dans ce contexte, faire de la certification même avec juste de l’allocation statique c’est déjà mission impossible alors avec du dynamisme … Waow !
#157
#158
#159
#160
#161
#162
#163
#164
#165
#166
Sinon pour le javascript il existe ce projet :
http://research.microsoft.com/pubs/121449/techreport2.pdf
SPUR compile le code javascript en .net. Même si une partie utilise bartok c’est de la compilation JIT donc ça ne répond pas au problème posé avec midori.
#167
#168
#169
#170
#171
Quelques objections qu’on ne peut pas malheureusement pas balayer d’un revers de main parce qu’un tel système restreindra de fait l’usage de certains optimisations :
-Les performances de certains logiciels reposent sur des morceaux de code assez courts, mais écrits directement en assembleur (Video, traitement d’image, chiffrement, etc). Même si ces optimisations concernent une portion marginale du code d’une minorité de programmes, l’impact final sur l’ensemble peut ne pas être négligeable.
-Une des optimisation très utilisée avec le C++ consiste à écrire des gestionnaires de mémoire spécialisés pour chaque tâche critique. Malheureusement, aucun “garbage collector” généraliste, aussi bon soit t’il ne peut rivaliser avec de telles stratégies spécifiques.
-Le système aura l’avantage d’éliminer les “context switch”, donc de permettre un gain de performance sur du code “managé”. Mais il y a un revers de la médaille : un simple accès à un élément d’un tableau peut se traduire par deux “cache miss” au lieu d’un à cause du bornage. Or, les accès mémoires sont l’un des facteurs limitant des processeurs modernes, bien plus que le coût des “context switch”. C’est particulièrement valable dans un environnement multicore.
Ma conclusion sur la question, c’est qu’on en saura plus sur l’opportunité de cette nouvelle architecture d’OS quand les éditeurs tiers porteront leurs logiciels dessus et que se dessineront les avantages et les défauts pratiques de l’idée.
#172
C’est histoire de proposer un langage rapide avec un développement qui requiert moins de temps.
" />
Donc une histoire de pognon et de manque d’expertise aussi.
Je bosse dans une boite une le chargé de recrutement m’avait lâché le morceau : “Aujourd’hui il est devenu très difficile voir miraculeux de trouver des experts en Assembleur +15.”.
Évidement le salaire s’en ressent
Le fait d’imaginer des idées de briscard pour diviser un temps de calcul par 10, n’est apparemment pas chose commune.
Cependant M# semble atteindre un bon compromis. Reste a voir ses domaines d’applications ;)
#173
#174
#175
#176
#177
Oui, je suis le premier à dire qu’il y aura une perte.
Cela dit :
* La valeur de ces micro-optimisations est souvent surévaluée, de moins en moins significative, surtout par à la parallélisation, et les humains font aujourd’hui rarement mieux que les compilateurs (la vectorisation automatique devient aujourd’hui monnaie courante).
* Il y aura des gains par ailleurs : la suppression de la mémoire virtuelle c’est un gros cadeau pour les performances.
Effectivement dans les précédents débats j’expliquais que les pertes pouvaient être compensées par d’autres points.
Joe duffy explique bien dans son post que le compilateur effectue tout un tas d’optimisations poussées.
It’s commonly claimed that with type-safety comes an inherent loss of performance. It is true that bounds checking is non-negotiable, and that we prefer overflow checking by default. It’s surprising what a good optimizing compiler can do here
Il y en a une sur la quelle j’ai débattu sur twitter qui semblerait être aussi utilisée dans project N. C’est letree shaking:
http://msdn.microsoft.com/en-us/magazine/cc163603.aspx
il y aussi le fait que M# devrait être conçu pour la programmation many core.
#178
Le travail sur Midori aurait peut être profité à RyuJIT ou peut être le contraire: RyuJIT
C’est quand même une bonne nouvelle qu’on puisse faire du bas niveau dans un langage proche du C#, ceci ouvre de nouvelle perspective pour nous.
#179
A propos du tree shaking je voudrais relever un détail. Felix qui est une des sources actives de mary jo foley a analysé freshpaint sur Windows RT 8.1. Il a trouvé des réferences à project N. Il a aussi remarqué que tout le code est désormais dans un binaire. Ce serait une spécificité avec le tree shaking. Sur Singularity la notion de librairies ou de DLL changent déjà vu que les SIP sont isolées. Une DLL sur les systèmes actuels se chargent dans l’espace mémoire du processus et de façon dynamique pour certaines.Avec Singularity une dll devrait tourner dans son propre sip ou être fusionné au code du programme.
D’après les tweets de felix il semblerait qu’au niveau binaire le programme avec toutes ses librairies forment une seule entité. Ce qui permettrait normalement de rendre le tree shaking beaucoup plus efficace.
https://twitter.com/h0x0d/status/400666665806860288
https://twitter.com/h0x0d/status/400916977062916096
https://twitter.com/h0x0d/status/400944442112086016
https://twitter.com/h0x0d/status/400944025533820928
https://twitter.com/h0x0d/status/405133742684897280
https://twitter.com/h0x0d/status/402071377915551744
#180
#181
#182
Beaucoup de discussions passionnées chez les INpactiens (et tiennes). Je ramène ma fraise de vieux qui a appris l’assembleur sur 6502, 8085 et 8031. Pour moi, un CPU n’exécute QUE de l’assembleur. Alors, un code managé, compilé ou semi-compilé est d’abord traduit en assembleur. Donc, dans un driver écrit en mode managé, on mettra POKE 53281,0 pour le traduire en mov 0xd020, #0 après un décodage de l’adresse, de la donnée, et une vérification qu’on ne déborde pas dans le SIP d’à coté. Très bien, mais avec cet exemple trivial j’ai du mal à croire qu’on pourra écrire un OS 2 fois plus performant, d’autant que la loi de Moore arrive à son terme, la limite physique du nombre d’atomes dans une jonction silicium. Certes, les architectures sont de plus en plus performantes, mais où sont les CPU à 5GHz qu’Intel nous avait promis à la sortie des P4-Netburst ? Je demande à voir le prochain driver NVidia doubler les performances en étant écrit en M# au lieu de C ou ASM.
Ensuite le micro noyau. Sur le papier c’est très bien, plus sécurisé, etc, etc… Sauf que la communication inter processus écroule les performances de cette belle théorie et démontre que ce qui fonctionne le plus rapidement, c’est le noyau monolithique. C’est d’ailleurs le choix du marché, voir le TOP500 des machines les + performantes trusté par Linux, noyau monolithique. Donc, il faut choisir : performance ou sécurité.
Je continue sur la sécurité qui ne se passe pas qu’au niveau du noyau ou même au niveau du langage. La dernière fois que j’ai dû virer un vers d’une machine, c’était sur un poste Windows7, et le vers était dans C:\USERS\Prénom\APPDATA\ROAMING\ZZYYXX\VILAINVERS.EXE. Un EXE en Win32. L’UAC n’a rien fait vu que le vers n’était ni dans C:\PROGRA~1 ni dans C:\WINDOWS. Alors le plus beau langage avec le plus beau noyau ne servira à rien tant que le dossier utilisateur sera exécutable par défaut (je l’ai déjà dit et redit). Un simple NOEXEC en option de montage sur le /HOME suffit à repousser tous les vers, mais ce n’est pas du monde Windows…
Ou alors on développe tout en JAVASCRIPT sans fonction OPEN en écriture et sans appel système pour ne pas écrire de fichier, et les données restent dans le cloud.
#183
Je relis mon poste et je me dis que le rêve, c’est l’OS en ROM, le dossier utilisateur en NOEXEC, et toutes les données et applicatifs dans le cloud avec abonnement.
#184
#185
#186
#187
#188
#189
#190
CaptainDangeax tu te méprends sur le but de l’UAC. Microsoft a toujours dit que l’UAC n’était pas une barrière de sécurité contrairement à la sandbox des applications Windows Store.
Mark Russinovich l’avait clairement dit à l’époque de Vista. Le but de l’UAC était de forcer les développeurs à ne plus écrire d’applications qui demandent les droits administrateurs inutilement. L’UAC n’arrête pas les virus ou malwares. Par contre si les applications tournent avec des droits utilisateurs(stratégie réussie quand Windows 7 est sortie), ça diminue la portée des attaques en cas de faille, ce qui est déjà pas mal.
#191
#192
#193
#194
#195
Actuellement Intel a une gamme de processeurs many core(TousLesDrivers fournit les drivers) en carte Pci Express je crois.
Je suis tombé sur cette news dernièrement où intel va bientôt sortir un vrai processeur manycore
A noter qu’intel a bossé en 2011 avec Microsoft sur le projet black cloud os. C’est un os dérivé de Singularity/Helios qui tourne sur leur gamme de processeurs many core.
Tout doucement on y arrive….
#196
#197
Managed code -> Bytecode dans une machine virtuelle. Ce n’est pas du langage machine, c’est donc de l’interprété. Donc perte de performances.
rien que ça prouve que tu n’as rien compris au sujet. le bytecode intermédiaire est compilé en natif à l’installation. Tu n’as pas de runtime. C’est même le titre d’une présentation de james larus sur singularity
C’est pas du troll, c’est l’approbation de la démonstration de l’INpactien ; c’est positif comme attitude, non ? Promettre des performances en hausse sans preuve, ça c’est du troll.
C’est moi que tu traites de troll. J’ai des sources internes qui m’en ont parlé comme quoi Midori serait globalement deux fois plus rapide que Windows. Ce sont des benchs internes effectués par l”équipe de développeurs Midori. Effectivement je ne peux pas le prouver. Libre à toi de me croire ou pas. mais j’en fous un peu de ton opinion.
Surtout que tu me traites de trolls alors que toi pendant une période tu étais le troll numero un sur PCI. Les personnes qui étaient là doivent s’en souvenir. Moi je n’ai pas oublié.
#198
#199
#200
Je pense qu’il faut que je précise les choses sur mes propos sur les performances. Je sens que ça va être détourné et mal interprété.
Ce sont des propos d’une de mes sources sur un papier qu’il a trouvé avec des benchmarks sur Midori. Mais il m’a juste donné une information globale. Il aurait été intéressant de savoir ce qui a été testé exactement.
Une personne plus haut a repris mes propos en expliquant que j’avais dit que M# serait deux fois plus rapide que c++. je n’ai jamais parlé du langage mais de l’OS.
De plus le résultat final peut encore changer. tout dépend comment ça va s’intégrer à Windows.
Mon propos était juste à titre informatif. Libre aux gens de me croire ou pas , je ne mens pas, je ne fais que reporter des propos.
PS: ceci dit il existe déjà un papier sur le site du MSR sur certains points qui sont testés sur Singularity comme les appels systèmes et c’est plutôt bon. Ou des tests avec la protection de ring cpu désactivé/activé et le MMU activé ou pas.
#201
#202
#203
#204
#205
#206
#207
En plus, ça n’est pas très compliqué : il suffit de combiner des structures nombreuses et disséminées et un accès aléatoire.
Tu peux toujours sortir quelques structures de données où l’on accède à un seul élément d’un tableau (ex : un dico dont l’index du tableau racine est donné par les premiers bits du hash code). Mais ça reste l’exception plutôt que la règle : en général quand on accède à un tableau c’est pour en lire de nombreux éléments et la taille reste en cache (rien à voir avec le prefetch).
#208
Cela dit j’argumente avec toi mais je suis d’accord sur le fond : un tel projet n’est pas gratuit en termes de performances. Même s’il restera à mon avis acceptable et présentera aussi des gains.
#209
…troll…
#210
#211
#212
#213
#214
#215
#216
#217
#218
#219
#220