pasBill pasGates a écrit 16309 commentaires

On parlait de sociétés qui prennent des risques.

Les risques, ca marche parfois, parfois pas, c'est ce que la liste représente.

Je n'ai personellement absolument rien à prouver.

C'est toi qui accuses formellement Microsoft de certaines pratiques, à toi de les prouver.

Tu n'as aucune preuve mais juste des suppositions ? Ben arrètes d'affirmer des choses sans preuves.

Déjà avant il y en avait plein, pas grand chose n'a changé de ce côté là.

Genre …

TabletPC il y a 15 ans ?

HoloLens ?

IllumiRoom ?

Kinect ?

etc…

Non soyons sérieux, Google est très bon pour faire un joli marketing autour de trucs que d'autres ont déjà essayé (lunettes, voitures, …) mais au final il ne va pas forcément plus loin que Microsoft.

Par ex., j'entends par là qu'ils ne sont pas à la source de la reconnaissance d'image (par rapport au fait que tu cites la reconnaissance de squelette), ou à la source des consoles (par rapport à la XBox)

Euh… t'as déjà entendu parler de Microsoft Research ?

L'opinion et les préferences du petit ingénieur système ou du petit développeur de Microsoft, la direction s'en cogne (c'est pareil dans toutes les grandes entreprises).

Pas totalement faux et pas totalement vrai non plus.

Il y a de nombreux exemples de choses qui ont passablement changé dans MS et qui ont démarré depuis le petit dev (ok d'habitude c'est pas un junior, mais plutôt un gars avec plusieurs années d'expérience…)

Tout est affaire de convaincre sa hiérarchie étape après étape. C'est plus long à faire chez MS que dans une startup c'est sûr, mais c'est aussi bien plus rapide que le faire chez IBM.

Je doutes que cela change quoi que ce soit de ce côté.

Notamment car ce n'est pas de leur fait, mais du fait des constructeurs.

L'histoire du serveur email en fait est très peu importante…

https://theintercept.com/2016/11/09/democrats-trump-and-the-ongoing-dangerous-refusal-to-learn-the-lesson-of-brexit/

est à mon avis une très bonne explication de ce qui s'est passé (trop long pour un snippet, faut tout lire)

C'est con, ils ont plus de 50% du sénat et de la chambre des représentants aussi… Et il y a entre 20 et 30% des membres de la cour suprème à choisir ces prochaines années.

Bref, je suggères aux français de ne pas attendre l'année prochaine pour faire tout leur possible pour éviter la même chôse avec Marine.

Et je suis sérieux, les anglais croyaient que Brexit n'arriverait pas, les Américains croyaient que Trump n'y arriverait pas, … les prochains sont les Français.

La plupart des puces ARM sont 32bit donc bon, pas trop possible d'oublier :)

Oui. C'est un compromis mais uniquement pour permettre une solution générale. Tu peux certainement imaginer le délai comme étant un paramètre configurable par processus auquel cas tu as le meilleur des 2 mondes.

Oui mais tu remarqueras que la différence est très importante.

STL te permet de réessayer ou de sortir proprement. Il ne crashe pas sans te donner au moins une chance de gèrer la chose.

Non, c'est basé sur une autre idée :

• Mon soft n'est pas un gros bouffeur de RAM, et ne ré-essaie que pour les petites allocations.

Et c'est tout.

Partant de là, on assume que les autres processus ne vont effectivement pas bouffer TOUTE la RAM de manière permanente, auquel cas le système serait gelé de manière permanente de toute facon, et ces softs seraient coupable du gel.

T'as pas compris. Ce n'est pas mon soft qui gèle le système, c'est le système qui est gelé, peu importe la présence de mon soft ou pas.

Mon soft essaie d'allouer disons 16Kb, et fais un loop avec attente si il n'y arrive pas.

Si il n'y a pas 16Kb de dispo sur la machine de manière permanent, inutile de te dire que, avec ou sans mon soft, rien ne fonctionne sur la machine.

Cela arrive notamment si le tas est fragmenté. En fonction des heuristiques utilisées, un allocateur peut garder beaucoup de mémoire disponible qui ne sera pas allouable par d'autres processus.

De nos jours la fragmentation, pour les petites allocations, c'est fini.

Les allocateurs utilisent un systeme de free list ou un bloc est alloué, coupé en morceaux de la taille demandée, et un morceau retourné.

Le moment ou le morceau est libéré, il est mis sur la free list pour cette taille là, et quand un autre morceau de cette taille est demandé, si la free list n'est pas vide, le morceau est retourné de là plutôt qu'aller faire une allocation qqe part.

Résultat, il n'y a plus de fragmentation lors d'allocations de petite taille (sauf dans cas totalement pathologiques qui n'existent pas vraiment en réalité), les blocs restent compacts. Le seul cas ou tu as encore un tel problème est quand tu fais une énorme allocation, et tu remarqueras que mon allocateur ne fait pas de loop en cas de grosse allocation.

Mais imaginons un autre cas. Ta technique se répand, tous les softs s'y mettent.

Tu as bien raison !

Maintenant, la réalité en pratique est que ce n'est pas le cas et ne le sera jamais.

Mais au cas oû je deviendrais soudainement un exemple à suivre par toute l'industrie, je me contenterais de rajouter un compteur incrémenté à chaque tentative d'allocation ratée, et remis à zero en cas de succes. Si le compteur atteint un certain nombre, le soft sort proprement avec un exit().

Tout à fait, mais j'utilises cet allocateur en sachant évidemment comment mon soft alloue et gère sa mémoire.

Non, si tu épuises ta mémoire, tu dois au moins avoir la possibilité de décider si tu veux essayer de faire de la place et continuer plutôt que t'écraser.

Même la STL ne le fait pas que je sache (tu as un std::string dont tu consomme tout la capacité, il alloue 2 fois sa taille et va planter si ça marche pas, pas réessayer avec juste ce qu'il faut).

Non il ne va pas planter, il va lancer une exception. Ce n'est pas la même chose, et de loin.

ben en fait si. Tu peux marquer ton soft comme "prioritaire" histoire que OOM killer aille massacrer quelqu'un d'autre. Mais faut être admin.

• tu utilises tout ton espace d'addresse sous Linux, et ton malloc se ramasse à cause de cela. Tu ne check pas le NULL, te choppes un segfault immédiatement à l'accès. Tu regardes le core dump, et tu vois que tu faisais des mappings de fichier et oubliais de les libèrer, ou que tu ne faisais pas gaffe qu'un des fichiers que tu essaies de mapper est énorme et bouffe tout l'espace…

• sous Windows, ton malloc se ramasse car le processus d'à côté a décidé temporairement de tout allouer mais libère la plus grande partie 3 secondes après. Ton soft fait son malloc au milieu, se ramasse, tu regardes le crash dump et te rend compte que tu as oublié de gèrer le fait que malloc peut retourner NULL pour des raisons tout à fait valides sur une des plateformes que tu supportes.

vu qu'aucun soft n'est capable d'allouer (rappel: je ne fais cela que pour des allocations plutôt petites, si elles échouent systématiquement sur le long terme, c'est que plus grand chose ne fonctionne sur le système), ben l'utilisateur ne fera rien car le système sera gelé de toute facon… ssh / bash / RDP ne pourra rien allouer pour permettre à l'utilisateur de se connecter ou lancer des commandes, etc… donc bref, ca ne changera rien.

Au contraire.

Sous Linux, si tu chopes un segfault en accédant a un NULL malloc sous Linux, tu as soit :

• bouffé tout ton espace d'addresse, et c'est clairement un problème à corriger
• TON soft bouffe trop de RAM (car Linux utilise OOM killer et ne te fera pas un segfault pour une petite alloc ici ou la)

Sous Windows, si tu chopes un sefault en accédant à un NULL malloc :

Même situation, et aussi cela pourrait être un autre soft ayant bouffé la RAM pendant quelque secondes, et ton code n'est pas assez solide pour le gèrer

Bref, dans tous les cas, c'est super important de le savoir.

Perso c'est simple, je considère que ne pas gèrer un NULL retourné par malloc est une faute grave si malloc peut retourner NULL.

Pourquoi ? Parce que le comportement de malloc entre Linux et d'autres OS est diffèrent, et que si tu ne gères pas le cas, alors ton soft va exploser en vol sur d'autres plateformes.

Exemple tout simple : code qui est sensé être multiplateforme entre Windows et Linux, et le code fait une allocation de 256Kb.

256Kb c'est petit hein, c'est genre rien du tout.

Pourtant sur Windows, si ton soft tourne alors qu'un soft super vorace tourne en background, il pourrait tout à fait se retrouver dans la situation ou il n'y a effectivement pas 256Kb de mémoire dispo, car Windows ne tue pas les processus au hasard pour faire de la place. Ce pourrait être juste quelque secondes parce qu'un soft a décidé de faire une énorme allocation qu'il libère tout de suite après hein… et là malloc retournera NULL sous Windows, là ou Linux serait allé trouver un processus à tuer pour faire de la place.

Est-ce que laisser le soft exploser en vol parce qu'il n'y avait pas 256Kb de RAM dispo pendant qqe secondes est une bonne chose ? A mon avis non, c'est très mauvais.

Donc perso l'approche que j'utilises est la suivante :

J'ai un allocateur custom, qui ne retourne JAMAIS NULL pour les allocations plus petites qu'une certaine limite (genre 1Mb ou 4Mb, selon les besoins). Il se contente de ré-essayer avec une petite pause car le mode de pensée est que si le système n'a pas 1-4Mb de dispo, ce ne sera pas indéfiniment sinon le système entier est à plat.

Résultat, dans tout mon code, je n'ai des checks pour NULL que lorsque je sais que la taille allouée peut potentiellement être plus élevée. Dans les autres cas, mon allocateur prendra peut-être 30 secondes à retourner (mais c'est pas grave car si le système est à genoux niveau RAM, il ne ferait rien de toute facon), mais il ne retournera pas NULL.

L'avantage est que je n'ai pas besoin de me soucier de mettre des exception handlers pour la plupart de mes utilisations de STL, ou des NULL checks pour la plupart de mes allocations. Il n'y a qu'un très faible nombre de cas ou j'ai besoin de le faire, et l'approche permet au code de rester lisible et supporter plusieurs OS proprement.

La raison est problablement que ce n'est pas exploitable à distance.

Et important-critical n'a probablement aucune incidence sur la vitesse à laquelle le patch sort.