Par exemple Rust interdit qu'il y ait en même temps, sur une même variable, deux références mutables (en termes C, deux pointeurs non constants) . Le compilateur peut s'en servir pour optimiser, alors qu'en C il faut déclarer manuellement les pointeurs 'restrict' pour promettre au compilateur que les pointeurs sont uniques, ce que presque personne ne fait et pratique.
D'ailleurs quand Rust a activé cette optimisation, ça a permis de détecter des bugs dans le backend LLVM. On s'est rendu compte que les implémentations de "restrict" dans clang (mais aussi GCC au moins) étaient incorrectes, mais on ne s'en était pas rendu compte car cette fonctionnalité est peu utilisée en C alors qu'elle est implicite en Rust.
Je ne sais pas avec quoi tu compiles en C, mais GCC depuis un moment fait automatiquement cette hypothèse. ça fait un moment que je ne déclare plus mes pointeurs avec le mot clé restrict. D'ailleurs le code assembleur n'est absolument pas modifié. La dernière fois que j'ai du mettre du restrict, c'était parce que le code servait de doc en même temps et que donc il fallait préciser ce point.
Donc en gros Rust interdit aliasing de pointeur.
Hier à
18h
54
Il faut sortir du mythe du C qui permet de prédire ce qui sera compilé. Les compilateurs modernes font énormément d'optimisation qui font que plus grand monde a part des experts n'est capable de prédire les opcodes générés pour tout code non trivial. La seule chose qui est vraiment prévisible c'est l'arrangement mémoire, et c'est également le cas en Rust si on le souhaite.
Rust a des performances comparables au C, parfois meilleur, parfois en dessous, globalement au même niveau. Les règles d'ownership permettent notamment certaines optimisations difficiles en C.
Quelles sont les optimisations difficiles en C que permettent les règles d'ownership ?
Le
10/02/2025 à
20h
44
Dans mon expérience limitée de Rust (datant de quelques années), le gros gros mur est le borrow checker, le vérificateur qui empêche qu’une variable (et celles qu’elle référence) ne puisse être utilisée de manière non-sûre par plusieurs threads ou plusieurs contextes (pour éviter les accès concurrents et les libérations multiples, entre autres): ça rend certains algos et structures de données difficiles à implémenter quand on reste dans les paradigmes des autres langages. Ça rajoute aussi de la complexité dans la syntaxe quand on doit spécifier la portée des paramètres, mais ça m’a moins gêné que le point précédent.
Il me semble que la crate rayon vise à adresser ce problème.
Ce qui m'a le plus gêné en Rust, c'est la complexité inutile de sa syntaxe et, dans une moindre mesure, la difficulté à faire produire un code performant par le compilateur. Je trouve que pour un langage qui se dit concurrencer le C on est en deçà de ce point essentiel.
Le
10/02/2025 à
20h
42
Hmm... Pas convaincu.
Le code C tellement proche du hardware que c'est limite du code machine, c'est une infime portion du noyau.
La plupart du code c'est celui des sous-systèmes, et eux ils manipulent surtout des états dans des zones mémoire. Donc un langage "memory-safe by design" aurait tout son intérêt.
Actuellement c'est du "memory safe by good coding practices". Ca nécessite de l'expérience/rigueur, et des phases d'intégrations + non-régressions.
Un langage memory-safe by design oui. Mais Rust est très restrictif en ce qui concerne la gestion mémoire en parallèle. Après ça reste quand même un défi.
Le
10/02/2025 à
18h
56
Parce que les PR demandent des changements dans des sous-systèmes existants... donc du code C en maintenance (par des gatekeepers :). L'idéal pour Rust serait la création d'un tout nouveau sous-système écrit from-scratch en Rust. Mais c'est pas tous les jours que Linux a besoin d'un nouveau sous-système :)
Et puis faut bien avouer que Rust... Comment dire... C'est légèrement chiant comme syntaxe et frustrant en terme de limitations quand tu viens du C.
Perso j'ai découvert Zig et je ne veux pas retourner à Rust. Ca me fait le même effet que TypeScript vs Javascript.
+1 le plus gros soucis de Rust est sa syntaxe complexe et totalement peté ! Et dès qu'on essaye du fonctionnel ça devient très vite illisible et la POO avec Rust est encore plus immonde qu'en Fortran.
Je crois que concernant le respect de la vérité la plus simple, lui et ses ministres sont déjà depuis longtemps dans la post-vérité (plus que par le passé). Ex:
Les autres exemples sont légions (Borne et les cartes vitales qui ne marcheraient plus si la loi de finance n’était pas voté; Darmanin déclarant qu’aucun LBD sur quad et aucune arme de guerre [les grenades de désencerclement le sont] n’avaient été utilisées à Sainte-Soline; Castaner annonçant que des gilets jaunes avaient envahi un hôpital…).
Bref, on est déjà en situation où des politiques au pouvoir multiplient les infox à la télé en toute impunité (certes à une échelle bien plus petite que Trump, mais c’est pas une référence), donc j’ai dû mal à attendre du président qu’il commence à promouvoir l’esprit critique.
Ce qui me choque plus, c’est l’inanité de cette communication.
ça fait bien longtemps que les mass medias ne sont que des réseaux sociaux privatisées pour politique. Ce n'est pas nouveau. Ce qui est dommageable, c'est qu'on appelle ces personnes des journalistes...
Pour l'inanité (merci j'ai appris un mot), c'est pas choquant. Macron ne peut plus véritablement gouverner. Une démission incomprise, un précédent gouvernement censuré, Bayrou qui s'impose à lui et qui fait le boulot (en bien ou en mal ce n'est pas mon propos ici), et une sorte de détestation franche de la majorité des français. Concrètement à part l'internationale et faire acte de représentation il n'a franchement plus la main. ça doit peut-être long à l'Elysée des fois...
Le
10/02/2025 à
19h
01
La seule chose qui m'attriste c'est de voir que malgré l'aspect comique des parodies, le président n'est pas un mot pour rappeler que si c'est drôle dans ce contexte, la manipulation de l'image par l'IA et par extension, de l'information, est dangereuse et qu'il faut garder un esprit critique.
Le problème est que si on ne fait rien, on utilisera encore les outils américains, car non, on n'empêchera pas l'IA d'entrer dans nos vies quotidiennes, surtout au travail. Donc, la question c'est: est-ce qu'on fait rien, et youpi on est tous avec Copilot, ou est-ce qu'on essaie d'être autonome sur le sujet ? (je parle de la partie logicielle bien sur, celle qui nous intéresse, surtout pour des raisons de donnée personnelles, etc...). Et pour être autonome, ben faut des datacenter en France, et donc effectivement de l'énergie pour les alimenter. Mais le nucléaire reste une bonne solution pour produire plus d'énergie, tout en minimisant au maximum nos émissions. Il n'y aura pas vraiment de solution magique hélas.
De toute façon, on utilise déjà des outils américains avec aucune volonté politique de changer la tendance en France comme en Europe. Regarde le nombre de boîtes françaises qui utilisent du MS, du GCP, AWS... Alors qu'on pourrait la même chose (bon ok MS est un peu à part) en utilisant des solutions d'OVH, ScaleWay et autres acteurs locaux et/ou européen.
Il en sera de même pour l'IA. Mistral est là et c'est français mais combien de boîte utilise ChatGPT et, O combien les geeks, DSI et XXSI, ne font rien pour inciter à utiliser Mistral.
Et même si on incite à passer sur des solutions françaises, la riposte américaine serait probablement des droits de douane sur les CPUs & GPUs rendent les entreprises françaises et européennes non-compétitives. On a perdu la "guerre" de l'IA et de l'informatique. Mettre 100 G€ ne changera rien tant qu'on ne sera pas capable, nous Européen, de produire nos propres puces ou d'utiliser des puces provenant d'autres pays.
Je suis globalement d'accord avec le fond, mais attention à ne pas diffamer. Parler de détournement de fond ou de bakchich sans en avoir les preuves peut vous mener devant un tribunal dans un état de droit (et c'est tout à fait normal). Je suis également en totale opposition à Macron sur quasiment tous les plans, mais restons droit dans notre opposition; il y a déjà assez de faits contre Macron (Alstom...) sans avoir besoin d'en inventer qui ne soient pas prouvés.
A supprimer.
Le
08/02/2025 à
21h
40
L'Emirat investisse et blanchissement probablement de l'argent au pasage. S'il achète les terrains au passage, ils doivent pouvoir les revendre avec quelques exonérations d'impôts sur les plus-values. En outre, il s'achète un peu d'image internationale et de pays moderne, vert et bienfaiseur. Mais surtout, il récupère des savoirs-faire en IA voir même des cerveaux (autres que du MBA qui pullule aux émirats).
Pour la France, Macron s'offre une réussite (vu la page blanche de son CV, ça va l'aider) et un peu d'image internationale. J'imagine qu'il a aussi participer (mais ça fait parti de son rôle) au négociation, mais je serais curieuse d'en connaître les dessous comme pour d'autres affaires.
Edit: Modification pour reformuler un propos alambiqué (merci jgguitare).
Merci pour ces précisions, effectivement je me doutais que les optims sont côté microcode et donc inaccessible à l'utilisateur, je suis également assez curieux de la partie microcode, c'est documenté / bidouillable / flashable ?
a priori oui : https://misc0110.net/files/cpu_woot23.pdf
Le microcode est chargée très tôt au démarrage du kernel. Je ne sais pas si le BIOS/UEFI peut aussi s'en occuper.
Concernant sa modification, elle est uniquement de l'ordre du reverse-engineering et assez limité. Le papier que tu cites ne fonctionne que Goldmont (en gros les Atoms). Et personnellement modifié un micro-code c'est prendre le risque de transformer son processeur en cale-porte si ce n'est pas fait officiellement.
Le
02/02/2025 à
21h
24
C'est le cas sous Linux, il y'a toute une rubrique dédiée à ça dans le paramétrage du noyau, c'est directement à la racine de menuconfig "Mitigations for CPU vulnerabilities"
Autre piste les paramètres de gcc (j'ai un peu la flemme de lire les 20000 lignes de manpage :p) : un simple -march=i386 compile du code Intel 386, mais je ne suis pas sûr que ça suffise (le microcode est compilé par la partie frontend du CPU, et ça ne me surprendrait pas que la prédiction de branchement reste active au niveau du back avec un code "i386" en entrée). -funroll-all-loops un peu violent mais déroule toutes les boucles à la compilation, tu coup y'a moins (aucune ?) prédiction de branchements possible. ... y'a des centaines (milliers ?) d'options disponible dans gcc...
A noté que GCC ne fera rien si le code source C inclus des optimisations en code assembleur.
Il faut bien avoir conscience qu'enlever ces optimisations, c'est revenir 30ans en arrière (le pentium pro qui a introduit la majorité des prédictions de branchement modernes date de 1995 !)
Les "Mitigations for CPU vulnerabilities" ne permettent pas de désactiver ou non l’exécution spéculative. Elles permettent de contrôler logiciellement l'activation de contre-mesures au sein du noyau pour réduire les failles comme Spectre & co. En n'aucun cas elles ne désactivent l’exécution spéculative.
@Nozalys parle de l’exécution spéculative au sein du microprocesseur, utiliser -march=i386 ne changera en rien la capacité du CPU à essayer de prédire le futur. C'est une fonctionnalité intrinsèque aux microprocesseur sur lequl on n'a, à l'heure actuelle pas de contrôle direct, seulement de l'indirect.
Le -funroll-all-loops ne sert pas au prédicat de branchement. Il y a déjà des unités dans le CPU pour ce genre de choses (cf mon post du dessus). Cette option sert surtout à dérouler des boucles pour pouvoir 1. permettre au compilateur d'optimiser via les unités vectorielles du code, 2. de saturer les unités calculs 3. cacher la latence et maximiser le throughput. Mais ce n'est pas aussi simple en réalité à utiliser surtout sans aller lire & comprendre l'assembleur pour s'assurer que le compilateur ne fait pas n'importe quoi.
De manière générale, la seule façon possible de désactiver totalement l’exécution spéculative serait via le microcode. Mais j'avoue que pour le fun, ça serait sympa de pouvoir essayer.
Quand à GCC ne fera rien si le code source C inclus des optimisations assembleur, tout dépend de comment ça a été inclus. Si c'est via le linker, il ne fera rien car ce n'est pas de sa "juridiction".Si c'est du GAS (inline assembleur), alors oui GCC peut y mettre son nez si celui-ci n'a pas l'attribut volatile.
Le
30/01/2025 à
15h
41
De manière simple non. On peut désactiver les caches mais ça demande de bidouiller des registres processeurs en kernel mode. Pour l'execution spéculative, il y a certainement des bits pour ça dans le microcode...
Mais oui, désactiver la spéculation se verrait sans soucis, en particulier si tu as des interfaces graphiques.
Le
30/01/2025 à
15h
38
Ce que tu décris existe déjà si je m'abuse. De mémoire, depuis Sandy Bridge il y a une unité LSD (Loop Stream Detector) qui est en charge de ce que tu décris.
Pour aider le processeur, ça peut se faire déjà au niveau du code mais ça dépend des langages et surtout du niveau des devs. Et comme dans un monde où on favorise le pissage de code à l'efficacité (sauf niches mais c'est l'exception que la norme), ce genre de choses n'arrivent pas très souvent ou manière fortuite.
Ok, mais faire un scale-up d'un avion, c'est très, très loin d'être trivial, surtout si on parle de vol supersonique. En pratique, c'est refaire l'avion depuis quasi zéro.
En pratique tu ne refais pas l'avion de zéro.
Il y a des grandeurs dites "adimensionnées" qui permettent d'étudier une même physique à différentes échelles. C'est aussi le but des maquettes qui sont réalisés en ce sens. Les dimensions sont ajustées de sorte à ce que certaines grandeurs physiques soit identiques que le modèle 1:1.
Et ce n'est pas forcément une règle de 3. En outre, ces grandeurs sont très souvent utilisés dans les modèles physiques afin d'avoir des nombres assez petits pour les calculs (et ceux indépendamment que tu résolves ton équation sur une maquette de 10 cm ou à l'échelle réelle), mais également pour d'autres propriétés plus numériques.
Emancipation par rapport aux USA. Pour rappel le PIB de l'UE est équivalent au PIB de la Chine soit le 2nd au monde. L'UE n'est pas faible.
L'UE est faible. Oui économiquement c'est une chose mais politiquement nous ne sommes pas en mesure de contrer le duo Musk & Trump. L'Italie, la Hongrie et possiblement prochainement et partiellement l'Allemagne sont déjà du coté de ce duo US. La commission européenne en le nom d'Ursula vient de déposer les armes et, comme en parle @Fred42, il y a peu de chances d'une destitution.
La France aurait pu encore avoir un mot à dire, mais Macron nous a tellement affaiblit et, il est religieusement pro-US, que nous pouvons rien faire.
Tu rajoutes à ça que Trump & Musk font de la division au sein de l'UE et oui nous sommes faibles et incapables de lutter contre eux pour le moment. Ce qui va suivre, sauf surprise, ne sera que gesticulation.
Le
08/01/2025 à
10h
37
Tu y crois ?
Le
08/01/2025 à
10h
13
Je pense que ça ne protège ni l'un ni l'autre, ça protège les commerçants et industriels de l'UE.
L'UE n'a pas vocation à être social, mais à être un marché unique. De là, la girouette suit le vent.
Recommandation que ne vaut pas grand chose je trouve, c'est plus une manière de pester contre Microsoft.
En entreprise que tu aies 50 ou 500 personnes, il faut former, trouver de l'équivalent, redéployer, migrer, tester un nombre de logiciels et salariés importants, il faudrait bien plus de 12 mois dans la plupart des cas.
En particulier, ca s'applique facilement pour nous qui allons nous en sortir tranquille. J'ai mis ma femme sous Ubuntu, elle s'en sort très bien parce qu'elle fait navigation/impression et parce que je m'occupe de tout. J'ai mis mal belle mère et ma sœur avec des PC tout configurés aussi, 1-2 ans après je les repassais sous Windows. Sachant que c'était sous Mint et Zorin, des distrib plutôt "user friendly" qui tournent bien et qui prennent une apparence proche Windows. Mais du moment ou tu veux aller un peu plus loin, tu branches ton appareil photo, un scanner, tu dois installer tel ou tel appli, ca pas forcément simple. Et le fractionnement de Linux devient pour le coup une complication pour les users lambda. Donc a forcé d'être appelé, j'ai lâché l'affaire.
Bref, c'est un débat interminable, mais ca a du bon sens, quand on en est capable.
Pour la partie entreprise, je suis presque d'accord avec toi. A ceci que quand tu travailles dans une entreprise, tu te dois de t'adapter aux nouveaux outils, logiciels ou autres. Ce travail d'évolution permanent n'est pas réservé qu'aux ingénieurs, informaticiens et autres personnels techniques. Il vaut aussi pour la compta, la direction financière et autres. Que de l'accompagnement soit fait, évidemment, de la pédagogie aussi pour les usagers. Mais à un moment donné, l'usager doit s'adapter. Ce qui ont des profils techs ici savent bien que nous sommes obligés de suivre les évolutions, les outils, les langages ... Alors pourquoi pas les autres ?
Quand aux logiciels, oui ça fait du boulot et ça a un coût et du temps. Mais la boîte a choisi Microsoft, et par conséquent à accepter de faire "lock-in". C'est pas comme si les stratégies commerciales des GAFAM (coucou le 3E) n'était pas connu. Et il n'y a pas d'excuses pour les boîtes de techs ni de commerce.
Pour le particulier, je pense que la question est la suivante : "Veut-il faire l'effort de quitter Microsoft ?" Si oui, ils acceptent (en connaissance de cause) de savoir qu'il va y avoir des soucis que tu décris... Si ça les insupportes, bah qu'il reste chez Microsoft ou vont chez Apple. Perso, j'ai la même expérience que toi. Sauf que j'ai posé la question avant en mentionnant tout les difficultés possibles avec Linux. Ma soeur a préféré prendre un crédit pour du Apple. Mon cousin a accepté les efforts (parfois changement de matériel pour être plus Linux-compatible) et finalement après 6 mois, je fais plus d'assistance.
Bon, alors je vais préciser mon propos, car je pense que dans le fond, on partage quand même pas mal la même idée.
L'usage d'algorithme cryptographique peu sûr est un leurre (comme le RC4, le MD5, etc.) L'usage de l'obscurité comme unique moyen de protection, est un leurre.
Par contre, et c'est là où nos avis diverges (peut être à cause des malentendus ce-dessus, mais peut être pas), ajouter de l'obscurité a un algorithme éprouvé comme AES ne peut qu'améliorer la sécurité de tout le système, en rajoutant une couche supplémentaire.
La seule chose que l'obscurité va changer, c'est la confiance que l'utilisateur va avoir dans le système, mais pas la sécurité du système lui-même.
Il n'empêche que je suis désolé mais un système cryptographique doit-être ouvert pour être plus sûr. Pas sans failles, mais au moins augmente la probabilité d'en voir une.
Absolument pas. Clamer haut et fort que tu utilises de l'AES GCM avec une clé de 128 bits ne va pas rendre ton système plus sécurisé que si tu ne le dis pas. C'est même le contraire.
Penser que le code est ouvert, donc auditable, est audité, c'est aussi se mettre de belles oeillères. C'est aussi un excellent moyen pour des pirates de venir trouver justement lesdites failles.
L'obfuscation ou l'ouverture du code (et là, je parle d'implémentation d'un algorithme de chiffrement, pas de l'algorithme en lui-même) ont chacun leurs avantages et leurs inconvénients. L'obfuscation rend plus difficile la découverte de faille pour tout le monde. L'ouverture rend plus facile la découverte de faille pour tout le monde.
Mais le monde cryptographique (je parle de la conception et l'implémentation des algorithmes, pas de leur utilisation) est un monde pointu avec peu de véritables experts sur le sujet. C'est bien pour ça que certaines failles, pourtant dans du code ouvert, ont perduré pendant 16 ans ! (cf. goto fail d'Apple).
De même que la faille heartbleed a été introduite malgré une relecture approfondie de la PR du développeur à l'origine involontaire de la faille par l'équipe d'OpenSSL.
L'ouverture en gage de qualité est tout autant un leurre que la sécurité reposant uniquement sur l'obscurité.
Maintenant, et je le répète une dernière fois pour qu'il n'y ait pas de malentendu, quand je parle d'obscurité, je dis bien que : 1) il ne faut pas que cela soit l'unique moyen de défense 2) que l'algorithme derrière soit un algorithme sûr et éprouvé.
L'usage d'un algo pas sûr comme RC4, même avec obscurité, ne change rien au fait que ton système ne sera pas sûr. L'obscurité ne doit pas être LE moyen de protection. Par contre, il peut être un moyen de renforcer une protection existante.
"Absolument pas. Clamer haut et fort que tu utilises de l'AES GCM avec une clé de 128 bits ne va pas rendre ton système plus sécurisé que si tu ne le dis pas. C'est même le contraire."
Pourtant c'est bien ce que fait Microsoft en disant AES-XTS avec les tailles de clés associées. Justement, ils le disent parce qu'ils savent que l'algorithme est robuste et que la seule faiblesse actuelle de l'algorithme c'est du brute-force. Tu ferais confiance à un éditeur qui te dirait : "Faites-nous confiance, nous avons utilisé les meilleurs algorithmes du monde ?" et tu découvres plus tard que le cas à juste mis du RC4. Un exemple réel ? Juniper et sa rng backdooré.
Ne confonds pas la cryptographie "académique" dont les travaux portent sur la conception, l'analyse et l'étude des systèmes cryptographiques... Et leur implémentation en pratique. Les failles dans les codes (i.e., les implémentations cryptographiques) ne sont pas du fait de l'algorithme. AES n'est pas, par design vulnérable à une attaque temporelle. Par contre, et comme tu le mentionnais, s'il est mal implémenté il le devient.
Concernant la protection des codes, un code visible est plus susceptible de se voir découvrir des failles plus tôt qu'un code obscur. Ma phrase était de dire "un code ouvert augmente la probabilité de détection d'une faille" et non "ça permet de détecter une faille". Par chance (ou pas), la faille du root sous Linux (le signe = au == dans une condition) a été vu par relecture (et parce que le compilateur a gueulé). La même faille chez Microsoft serait passé, peut-être, inaperçue. Mais ce qui manque en vrai sur cette question de failles closed vs open source, c'est des expérimentations pour évaluer correctement les choses.
Dans le fond, je pense que nous sommes sur de nombreux points sauf sur celui, d'utiliser l'obscurité pour protéger un système cryptographique. Alors que par conception, celui doit pouvoir résister à ça car L'ennemi connaît le système. (cf. Maxime de Shannon).
Le
07/01/2025 à
22h
29
Si Microsoft refuse cet accès à un client, alors c'est de la sécurité par l'obscurité et dès lors c'est contraire au standard de cryptographie moderne
Non. Ce qui est contraire au "standard moderne", c'est de n'avoir une sécurité qui repose uniquement sur l'obscurité. Rajouter une couche d'obscurité ne fait absolument rien de mal, bien au contraire. Et au passage, le refus peut simplement être aussi l'absence de droit pour le faire, si la brique utilisée n'a pas été développée par Microsoft même (cf. l'ouverture des sources de Winamp sur du code dont ils n'avaient pas légalement le droit de rendre disponible).
L'algo utilisé ici est connu, et est réputé comme sûr aujourd'hui. Donc l'algo n'est plus inconnu, seule l'implémentation l'est.
Masquer l'implémentation permet de rendre très difficile Wikipedia, où l'implémentation est fonctionnellement juste, mais les différences de temps de traitement permet une fuite d'information permettant une attaque par statistique de la clé de chiffrement.
La sécurité par l'obscurantisme est un leurre. En crypto tu as RC4, KeeLog et d'autres encore qui montre que c'est une erreur. On peut aussi parler des backdoors dans les systèmes crytographiques de Juniper (qui équipe certains labo du CNRS à une époque...). Rien que ça, si le code avait était ouvert sur cette partie on aurait pu peut-être voir quelque chose. Et visiblement les autorités françaises de l'époque (pourtant en période post-Snowden) ne se sont pas donnée cette peine, et là on parle pas d'un particulier.
Tu peux aussi étendre à d'autres failles. Microsoft est l'implémentation de la faille de la backdoor NSA dual_ecb_drgb (tiens Cisco aussi). Microsoft l'a implementé dans ses produits. Si le code avait été ouvert, ça n'aurait jamais pu se passer ainsi. Que Microsoft protège Recall par l'obscurantisme (ou plus exactement en révélant pas les différentes techniques utilisés) c'est ok. Mais la cryptographie c'et la sécurité des données, c'est autre chose. Et ce n'est pas comme s'il y a pas eu des précédents sur le sujet.
AES c'est bon. XTS a des soucis avec l'authentification des données, mais ce n'est pas le sujet. Pour l'implémentation de l'algorithme, il n'y a pas que les attaques par canaux axillaires temporels. Tu les variantes avec les caches. Dans les deux cas, l'usage de l'AES-NI permet d'atténuer fortement la première faille et possiblement la seconde.
Il n'empêche que je suis désolé mais un système cryptographique doit-être ouvert pour être plus sûr. Pas sans failles, mais au moins augmente la probabilité d'en voir une.
Le
07/01/2025 à
21h
49
Il n'y a aucune raison valable à rendre opaque un système cryptographique quand on prétend concevoir/utiliser un tel système pour protéger des données, que ce soit pour des civils, des militaires ou des industriels.
Vraie question, tu as des noms de fournisseurs de tels systèmes propriétaires qui publient publiquement l'IP associée ?
La raison que je vois : cela ne fait pas parti de la licence que tu as acheté, l'accès au code source se paye dans d'autres niveaux de licences / programmes.
Est-ce que BoringSSL de Google rentre dans cette catégorie pour toi ? Idem avec NSS et s2n (Amazon) ? Pour moi, oui ce sont des systèmes cryptographiques développés par des boites privées et rendu accessible. Le principe de Kerckhoffs est respecté.
Que tu payes avec des licences de l'accès privilégiés oui bien sûr ça me va. Mais ça ne devrait pas être le cas pour la partie crypto uniquement. Encore une fois, c'est une question de sécurité.
Le
07/01/2025 à
19h
13
pourquoi, moi client de Microsoft ayant une licence MS, je me fais rejeter par le service client quand je demande ?
Directed by Quentin Inventino
Si MS n'a rien à cacher pourquoi il ne montre pas le code en faisant une simple demande ?
Dans le monde entier, la pratique courante est bien entendu de livrer son IP à n'importe qui, juste parce qu'un "client" le demande, c'est bien connu...
Sinon, comme tu l'indiques, tu as une licence, et elle ne te permet tout simplement pas l'accès au code. Il existe des programmes qui permettent d'avoir accès au code, dans des cas spécifiques : intégrateurs, états, cross-development ...
On parle pas du kernel, de Recall ou autres. On parle d'un système cryptographique. Si Microsoft refuse cet accès à un client, alors c'est de la sécurité par l'obscurité et dès lors c'est contraire au standard de cryptographie moderne (Schneier a publié à ce sujet à de nombreuses reprises), et par conséquent la sécurité du système peut-être légitimement questionné.
Que la licence m'interdise des choses (code source de Recall, insertion de clé TPM...) oui me parait logique au regard de la stratégie lock-in de Microsoft. Mais pour un système cryptographique qui visent à sécuriser mes données, c'est exactement le contraire que ça fait.
Il n'y a aucune raison valable à rendre opaque un système cryptographique quand on prétend concevoir/utiliser un tel système pour protéger des données, que ce soit pour des civils, des militaires ou des industriels.
Le
06/01/2025 à
14h
40
Ms ne le rend pas public parce que ses clients ne le demandent pas en masse. La plupart des clients s'en moquent: ils ne règlent pas les problèmes via une revue de code mais via des pénalités et des avocats. Et ces clients pourraient voir d'un mauvais oeil que Ms publie le code source.
Les deux mondes opensource/closed source doivent cohabiter.
Par ailleurs, Ms a un avantage: la doc. Ms documente encore plutôt bien (je trouve moins bien qu'avant mais bon, c'est toujours plus facile à trouver que la doc linux utilisable et à jour).
Ms ne publie pas de code, mais ils sont transparents sur énormément de points y compris techniques. C'est une autre conception.
J'aimerais voir ses clients français qui règlent leur problème d'espionnage économique de Microsoft ou alors de défauts de sécurités en envoyant des avocats. Pour les US je suis d'accord. Mais en France j'ai des doutes... Entre le coup des avocats, le gain a obtenir, la durée des procédures, le ping-pong juridiques et voir pis, le politique qui rentre dans la danse je vois pas comment une boîte française peut s'en tirer avec un gain favorable.
De mon trou de serrure, ce genre de clauses contractuelles sont là pour les commerciaux pour rassurer leur client, mais en sachant parfaitement qu'elles ne seront jamais utilisés.
Et encore une fois, si ça ne pose pas de problèmes à Microsoft pourquoi, moi client de Microsoft ayant une licence MS, je me fais rejeter par le service client quand je demande ? Si MS n'a rien à cacher pourquoi il ne montre pas le code en faisant une simple demande ?
Quand aux clients qui n'apprécierait pas, ceci se règle avec du marketing & de la com'. Ce genre de clients n'a pas les notions requises (en interne) pour comprendre ce genre de choses techniques, donc qu'ils se contente de ce qu'ils peuvent comprendre : " la com' ".
Pour la doc MS je ne sais pas vraiment ne l'ayant pas pratiqué énormément. Celle de Linux est plus technique et a un ticket d'entrée plus haut. Mais au moins, on peut prendre une décision éclairé. Quand à l'utilisation de la doc, pas de soucis ni à trouver une version à jour. Mais je n'ai probablement pas les même usages et besoins de que toi.
Le
05/01/2025 à
22h
34
Wikipédia :
Le principe de Kerckhoffs n'implique pas que le système de chiffrement soit public, mais seulement que sa sécurité ne repose pas sur le secret de celui-ci.
Le principe du chiffrement de Bitlocker est connu, que le code ne soit pas publié est accessoire. C'est d'ailleurs pour cela que la démonstration utilise Linux pour une fois la clé trouvée monter le disque sous Linux et que celui-ci est lisible.
Je cite Wikipedia (version anglaise) : "The principle holds that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge."
Ce qui, selon moi, implique que même si je dérobe le code source de BitLocker et le publie ouverte, la sécurité de celui-ci ne sera pas comprise car il repose sur la clé. Par conséquent, pourquoi Microsoft ne le rend-t-il pas publique ? Le chiffrement est connu c'est de l'AES. Le Cipher block, de l'XTS et la taille de la clé est connu (mais si à cette égard j'ignore si la taille de la clé donnée est avant ou après application de l'XTS).
J'ignore la citation original de Kerckhoffs, et de fait quelle page wiki est correct. En revanche, l'évolution des conflits et le role de la cryptographique a évolué depuis Kerckhoffs. Et je pense que la version "moderne" formulée par Shannon (celui de l'entropie de l'information) : "The ennemy knows the system" est plus approprié (non pas parce qu'elle appuie mon argument, mais parce qu'elle se trouve plus réaliste de nos conflits modernes).
Le
05/01/2025 à
16h
49
Soupir..... Déjà des failles, il y en a partout. Y compris dans l'open source. Ensuite pour la faille en question, déjà il faut un accès physique au pc,et il faut certaines connaissances. Et si tu ne travailles pas pour une agence de contre espionnage ou dans le nucléaire, tu peux dormir tranquille. C'est pas cette news qui me fera remplacer bitlocker par autre chose.
Au delà de la faille, on ne peut pas faire confiance à BitLocker ! Non pas parce que c'est du Microsoft mais simplement parce qu'il existe un principe fondamental en cryptographique que l'on nomme le principe de Kerckhoffs, principe qui consiste à dire que la sécurité d'un système crytographique doit reposer uniquement sur sa clé. Et par corollaire, offuscation de l’algorithme eet de son implémentation n'ajoute pas une sécurité supplémentaire. Pis, et a été déjà démontré à mainte reprises que ça finit toujours pas être cracké.
Si Microsoft (mais d'autres) veulent un système de chiffrement sécurisée, le code source doit pouvoir être librement accessible et reproductible.
Ca depend pas mal du type de calculs j’imagine. Dans notre cas on calcule beaucoup d’images au cpu, et avoir des xeon de generations différentes se gère très bien.
Ok. J'imagine que donc que les Xeons datent de plus de 2013 (AVX256) et qu'il y a une absence de conflits en terme de support dans les codes utilisés.
Merci pour les infos.
Le
03/01/2025 à
11h
24
Peut-être que le coût du renouvellement est « rentable » par rapport au gain d’efficacité (puissance/watt), et que d’autres pouvant réutiliser ces calculateurs pourraient faire le calcul que le surcoût en électricité serait trop défavorable par rapport aux dernières générations (donc au neuf)… (j’en sais rien, je spécule)
Le ratio flops/watt n'est pas forcément le plus important (et je ne vois pas de volonté de Météo-France à vouloir jouer à la plus grosse au Top500 Green).
En revanche, ce qui est plus intéressant dans du calculs scientifiques c'est l'augmentation du nombres de FLOPS, de la bande passante de la mémoire, de la capacité mémoire que peut adresser un CPU. A ça tu rajoutes la dimension GPU (je sais pas si Météo France a porté une partie de ses codes sous GPU, je me souviens d'avoir vu passé des offres de post-doc en ce sens) et de meilleurs systèmes d'interconnectivité pour les calculs distribués.
Le critère de puissance/watt n'est pas forcément dominant sachant qu'à chaque nouvelle génération de puce tu as toujours des gains positif sur ce ratio (gravure plus fine, design plus performant...)
Le
03/01/2025 à
11h
17
Pour être proche du game, si on parle de CPU, c’est assez difficile de rentabiliser l’acquisition d’un CPU récent et puissant de classe serveur uniquement avec les économies d’énergie réalisées. Il faut en plus que le footprint coûte très cher, ce qui ne doit pas être trop le cas sur des DC exploités en propre de Météo France. Si les calculs sont massivement parallèles, parfois c’est plus intéressant d’ajouter juste de nouvelles machines à la ferme (plus récentes ou non). Sur le GPU c’est un peu différent, la vRAM n’est pas évolutive ce qui interdit des calculs plus exigeants, et les chips ont beaucoup évolué ces 7 dernières années, mais là encore le coût de l’énergie risque de ne pas être déterminant.
"Ajouter des machines récentes ou non à la ferme de calcul ?" Pour mon info, tu ne mélanges pas les µ-arch CPU quand même ?
Le smartphone le plus vert, c'est celui qu'on le peut continuer d'utiliser sans obsolescence programmé, la merdification de l'OS et le verrouillage du bootloader.
Je change de téléphone tout les 8 ans environ, mais ça me fait suer d'avoir un téléphone déjà obsolète supplément car les MaJ de sécurité ne sont plus assuré, et sans raison technologique valable.
oui effectivement je dis que il y en toujours eu et il dis que il y en aura de plus en plus mais je ne suis quand même pas d'accord avec ça. Il fait un lien de causalité entre la complexité des systèmes et le nombre de faille matérielles connue qu'il y aura dans le futur. Je suis d'accord que plus un système est complexe plus il y a de chance d'avoir une faille, mais cela peut être compensé par le fait qu'on peut mettre plus de moyen pour les trouver et les corriger avant release. Donc pour moi le lien de causalité n'est pas avec la complexité d'un système mais avec l'étendu des tests fait (test coverage en anglais)
Je n'ai pas de chiffre mais je n'ai pas l'impression qu'il y en ait plus qu'avant au contraire je dirais que il y en a autant et qu'elles sont moins évidente, les failles deviennent ultra complexe à trouver alors qu'avant sur des systèmes moins complexe il y avait des failles pas si dure à trouver. En plus vu que plus de monde s'intéressent à ce genre de faille et leur conséquence on en entends plus parler aussi.
Les GPU sont un bon exemple ils sont aussi complexe que les CPU et ont des failles et pourtant on en entends pas ou presque pas parlé. Next par exemple n'en as pas parlé ou le moteur de recherche de next ne les trouvent pas et pourtant il y en a aussi. https://www.01net.com/actualites/les-cartes-graphiques-dapple-amd-et-qualcomm-sont-victimes-dune-faille-de-securite.html https://www.hardwarecooking.fr/nvidia-corrige-8-importantes-failles-de-securite-sur-ses-gpu/
Je ne sais pas pour la corrélation. Je pense que le problème est multi-factoriel et non-linéaire. Au mieux une corrélation mais la causalité je ne sais pas.
Par contre, je pense qu'il y aussi deux biais : L'un d'observation lié aux fait que plus de gens s'intéresse maintenant qu'avant. Et l'autre que l'accès à ce genre d'informations est plus largement diffusable et diffusé qu'hier. C'est pour ces raisons que je ne m'avance pas pour la causalité.
Pour les GPU je pense qu'il y a autres choses en jeu. Je vois au moins deux facteurs: la vitesse d'évolution des GPU rendant rapidement une faille obsolète à l'usage, et la nature des données à récupérer. Un GPU ça sert concrètement à du calcul ou du jeux vidéos. Un CPU ça fait beaucoup de choses et surtout ils ont accès plus facilement à des données sensibles (clé de chiffrements, token d'ID...) ce qui fait que ce sont des cibles plus intéressantes.
Par exemple, un GPU chez un provider a très peu de chance de voir passer des clés cryptographiques. Il servira à du calcul numérique (CFD, deep learning...). En revanche un CPU va travailler avec les token d'ID, les clés SSH... rendent plus interessante cette cible. Et surtout le provider va conserver plus longtemps un processeur qu'un GPU. Par exemple chez OVH, on peut encore louer du Skylake.
Le
07/11/2024 à
14h
04
Tout va dépendre des utilisateurs finaux et du pouvoir de nuisance associé à la faille pour eux.
Si ton utilisateur final est Mme Michu, on peut en effet se poser la question. Si ton utilisateur final est un cloud provider (e.g., OVH), la correction est mettre en regard de son impact sur les performances et le service proposé.
Néanmoins, même si tu désactives les failles car tu considères que c'est ok. Tu peux avoir des softs qui inclus ces contre-mesures dans leur code. Et là, tu ne peux rien faire si le code n'est pas open-source.
Le
07/11/2024 à
13h
59
non rien à voir avec la complexité d'un matériel. Il y a toujours eu des bugs/failles hardware et il y a de plus en plus de gens qui s'intéressent de près à ces failles car cela contourne toutes les protections logicielles. Et statistiquement plus tu mets de personnes qui cherche quelque chose plus tu as de chance d'en trouver.
L'affirmation de @Gilbert_Gosseyn ne contredit pas la tienne. Plus un système devient complexe, plus la probabilité d'une faille/bug est prononcé. Il serait possible de supprimer Spectre et ses variantes des procs en supprimant le prédicat de branchement (en autres). Mais l'impact sur les performances seront cataclysmiques. Et c'est bien parce que le prédicat de branchement est complexe, qui est plus susceptible de contenir des failles.
Le financement vient du pourcentage du PIB que mette chaque état dans leur propre défense, les membres de l'OTAN s'était mis d'accord pour atteindre 2% on y arrive à peine mais il faut atteindre 2,5% voir 3% la Pologne est à plus de 4,5% et sont en train de prendre le lead de l'Europe à la place du couple Franco-Allemand. Vous croyez que les F22 ou F35 ils donnés gratuitement ?
Justement, j'aimerais bien que les F22 et F35 ne soient pas achetés. Mettre du PIB dans la défense, c'est bien et c'est souhaitable vu le contexte actuel et futur. Par contre, ça serait bien que cette argent de l'UE n'aille pas dans les poches de l'oncle Sam inutilement, et servent à faire tourner aussi nos industries d'armements. C'est juste mon point. On peut néanmoins toujours s'entendre sur des normes (e.g., calibre des armes à feu).
Le
06/11/2024 à
19h
26
Ce qui me fait le plus peur c'est plutôt le fait que Trump affirme haut et fort laisser tomber l'Europe concernant la défense, donc d'ouvrir la porte à des scénarios plus que probable qu'après l'Ukraine, ce soit les pays balte, la moldavie etc. Je ne pense pas qu'un seul pays Européen soit en mesure de mener une guerre actuellement, tout le monde se "repose" sur le parapluie Américain, donc Trump a raison, mais maintenant il faudrait que l'Europe se réveille rapidement...et pas pour acheter Américain (bonne chance pour construire une défense fiable sans financement).
On peut construire fiable et l'argent n'est pas le problème si on emprunte collectivement (cf. rapport Draghi).
Par contre, je ne sais pas si les allemands ou les polonais seront de cet avis pour construire une vrai défense européenne sans matériel et logiciel US... Et je suis aussi pessimiste sur la capacité des pays européens à s'accorder de manière intelligente sur qui fait quoi.
Par contre, je ne pense pas que Trump laisserait tombé l'UE. Notre marché est très important pour les US et une guerre ne serait pas bon pour leur business sur le sol européen. Et l'économie c'est important pour Trump.
Et pendant ce temps, nos politiques font des restrictions budgétaires pour satisfaire une note comme lorsqu'ils étaient à leur "grande école", note qui est attribuée par les agences américaines dont la mentalité sur le rôle de l'état (sécurité sociale, santé, éducation) est antagoniste du notre.
Le souci des notes attribuées par ces agences, c'est qu'elles servent aussi d'indicateurs pour les créanciers puisqu'elles correspondent à un indice de solvabilité. Si elle baisse, les taux d'intérêts de la dette d'augmentent parce que l'Etat emprunteur est considéré comme à risque. Voire, il n'arrive plus à emprunter et se voit déclaré en faillite.
Dans le cas où un Etat manque de cash, l'impact n'est pas neutre vu qu'il ne peut plus assurer ses fonctions régaliennes et perd l'accès aux marchés financiers permettant d'emprunter.
Je n'ai rien contre l'existence de ce genre d'agences. Mais... Elles ne sont pas européennes ! Et par conséquent une arme de soft-power. N'oublions pas que les US ne sont pas nos alliés et que ce genre d'agence est un moyen de pression sur la France (mais aussi l'Europe). A ma connaissance leur méthode de calculs ne semblent pas librement accessible. Donc, j'ai envie de dire comment je peux savoir si c'est rigoureusement fait ou bien en faisant un lancé de dés.
Ensuite, je critique la valeur de ces fameux 3% alors que des pays comme les US ou la Japon sont à 6% et s'en moque un peu. Ce que je ne pige pas, c'est pourquoi on embête la France sur ce point (qui est un peu un OVNI en terme de dépense à cause de son armée et son occupation géographique en autres). Surtout que c'est 3% sont sortis de nul part (et je ne considère pas l'économie comme une Science). Et nous savons parfaitement que la France a les moyens de rembourser, au besoin.
Pendant ce temps-là, les US investissent, le Japon investit et la France (et l'UE de manière générale) sont à la traine. Et dans un plan à 3 avec l'US, l'Europe et l'Asie, les US sont trop pudique pour inclure l'Europe dans leur galipettes.
Mais là, c'est un HS par rappport au sujet, je pense.
Le
06/11/2024 à
17h
00
En phase, quand on voit EELV et Sandrine Rousseau prof d'économie ... Mais ça va même plus loin que l'économie. Mettons au ban de la société ces sectes qui nous font régresser.
Même sans parler de Rousseau. Cette fumisterie des 3% quand on voit comment les américains produisent de la dette pour leur industries avec une dette > 6% du PIB, idem pour le Japon. La Chine qui investit dans son économie... Et pendant ce temps, nos politiques font des restrictions budgétaires pour satisfaire une note comme lorsqu'ils étaient à leur "grande école", note qui est attribuée par les agences américaines dont la mentalité sur le rôle de l'état (sécurité sociale, santé, éducation) est antagoniste du notre.
Le
06/11/2024 à
13h
54
Allez l'Europe ! Maintenant faut se sortir les doigts du * et commencer à penser au 21ème et arrêter de réfléchir avec des idéologies économistes digne d'un gourou de secte !
Je vais conclure là-dessus: - tout à fait d'accord, RISC ou cisc, ce n'est qu'une façade. Et même RISC-V n'est qu'un ensemble d'ISA, l'implémentation 'hardwired' d'un RISC-V est possible, mais ne permet pas les performances d'un CPU qui redécoupe/réorganise - en termes de langages, je connais fortran et ses extensions (MPI/OpenMP) que j'ai utilisé il y a plus de 20 ans sur du code matriciel et 64 CPU. Je n'ai pas compris que fortran ne soit pas utilisé avec le GPGPU et le SIMD. - pour les dev, c'est très variables. Mais j'estime que dans les outils bureautiques/internet, les CPU sont sollicités essentiellement pour de la comparaison de chaîne (indexation des colonnes, des attributs par nom, interprétation de scripts, de XML, de HTML...) +le chiffrement (donc multiplication et division entières). Tout soft de compta utilise une représentation parfaite des nombres (donc pas de virgule flottante) et ces opérations n'ont pas de bench généralement (bon, un peu avec les benchs bdd). Donc se poser la question de comment ma structure va tomber avec les pages mémoire ou si mes nombres sont alignés et si ma boucle passe en cache... C'est loin de 90% des dev. - est-ce que les Apple M ne ressembleraient pas un peu aux transmeta?
Je rebondis juste sur la partie Fortran car pour le reste je suis ok, et pour le coup on a une expérience assez proche dessus (peut-être pas en durée d'années, par contre).
Fortran fait du SIMD mais il délègue ceci aux compilateurs. Tu le peux faire un peu plus "nativement" via l'iso_c_binding sur les intrinsiques. Note que le C++ propose d'introduire le SIMD dans la norme C++26. A ma connaissance actuelle, seul Rust propose de faire du SIMD d'une façon naturelle. Dans tout les cas, il faut checker l'assembleur et parfois jouer avec les options du compilateurs et le code pour arriver à ses désirs.
Pour le GPGPU, tu peux regarder du coté d'OpenMP pour les calculs hétérogènes ou OpenACC. Certains compilateurs comme pg ce sont aussi associées avec Nvidia pour intégrer du CUDA en Fortran sous forme d'extension.
Le
05/11/2024 à
22h
29
Actuellement les cpu sont une jungle. Les ISA sont pleines d'extensions, certaines remplaçant les autres, d'autres à mi-chemin d'être un NPU. Mais les langages 'classiques' sont incapables de gérer correctement ces instructions. C'était d'ailleurs le constat dans les années 80 qui a amené le RISC et les 1er ARM: l'adoption de compilos haut niveau faisait disparaître l'usage des instructions cisc (par exemple, un x86 a des instructions de calcul en mode quasi texte ou de recherche qui ne correspondent à rien dans les langages).
Bref, je te donne raison sur l'intérêt de bien connaître son archi.
En même temps ces annonces ARM me rappellebt les années 90 quand IBM/Apple faisaient du Power PC (et les difficultés d'IBM à sortir le meilleur des power pc - ainsi que la difficulté de prédire comment allait se comporter le cpu ce qui gênait les dev en assembleur).
Bref, même si Apple a un excellent CPU, je n'enterrerait pas le x86 avant un moment. (Tout en remerciant AMD de montrer à Intel comment implémenter AVX512)
Oui les ISA sont devenus assez bordéliques, et je pense qu'une partie provient de la complexité croissante des processeurs qui deviennent de plus en plus "diversifié". Une autre partie provient des ballons d'essais, d'évolution (unités vectoriels passant de 128 -> 256 bits), de choix marketing...
Néanmoins tout les processeurs sont des risc à l'heure actuelle si on regarde dans les détails. Les x86 sont certes des CISC, mais dès le tout début du front-end du CPU, tu as une conversion des instructions en micro-opérations, qui ressemble furieusement à ce que tu as en risc. Est-ce une bonne chose ? Honnêtement je ne sais pas à l'heure actuelle. Les deux approches ont des avantages et inconvénients.
Mais néanmoins je pense que ce n'est pas nécessairement un problème de langage. Il existe un langage pour ça, et c'est l'assembleur. Les langages de haut-niveau s'appuie dessu via un interpréteur (compilateur, JIT...). Je pense que le soucis concerne la capacité du compilateur a comprendre un code ou une fonction dans sa globalité et comment l'optimiser avec les bonnes instructions. Il y a, selon moi, une responsabilité majeure des développeurs qui, pour la très grande majorité, ignore comment fonctionne un ordinateur, et par conséquent n'ont pas connaissance de ce genre de détails et son impact. Mais finalement, bien que non-idéal, on s'y retrouve sous la le bon outils pour la bonne tâche. VLC est en majorité codé en C++, et tu trouves de l'assembleur pour les fonctions les plus critiques (e.g., en/decoders).
Je n'ai malheureusement jamais joué avec l'architecture PowerPC :( Mais je ne perds pas espoir avec la possiblité d'en louer ou d'en acheter un). En revanche, de ce que j'ai vu de son fonctionnement, elle a des trucs sympathiques.
Je te rejoins à 100%, l'x86 n'est pas mort ni à court ou moyen terme. Et oui, merci à AMD pour le double pumping qui ouvre la voie à de possibles folies (AVX-2048 ? ). Apple ouvre une voix pour le particulier, mais c'est aussi la face visible d'un iceberg (Graviton, Ampère, Axion...).
Le
05/11/2024 à
18h
43
Petit complément pour illustrer un peu la situation actuelle, où le CISC (et cela touche aussi ARM avec les différentes extensions d'ISA) reste difficile à mettre en place dans les compilo: Twitter
(en espérant que ce x94 en perf n'équivaut pas à générer un film en noir et blanc :) )
Sympa, Peux-tu m'expliquer le lien entre CISC, la difficulté du compilo et les x97 de perf ? Je n'arrive pas à saisir ton point.
Le
04/11/2024 à
14h
52
"c'est les détails plus profonds comme l'IPC, la longueur du décodeur d'instruction, le TLB, l'organisation des unités flottantes, la longeur du data path"
Autant ce sont des informations précieuses quand on fait des compilateurs CPU, autant sur des machines ultra hétérogènes et des traitements répartis comme maintenant, ça a peu d'intérêt je trouve, sans compter que l'IPC ARM et l'IPC x64 sont non comparables, surtout si on parle d'IPC de type AVX ou autre.
Ce qui m'intéresserait, c'est de voir comment les Apple Mx réorganisent les instructions. Je penche depuis le début pour une réorganisation qui tant vers une exécution proche du VLIW, ce qui expliquerait en grande partie les perfs en émulation.
Mais c'est du pinaillage: si je développais des compilateurs ça m'intéresserait, mais pour de l'utilisation, ce qui m'intéresse c'est plus le confort (qui n'est pas totalement /uniquement lié aux perfs théorique d'un CPU)
"Autant ce sont des informations précieuses quand on fait des compilateurs CPU, autant sur des machines ultra hétérogènes et des traitements répartis comme maintenant, ça a peu d'intérêt je trouve, sans compter que l'IPC ARM et l'IPC x64 sont non comparables, surtout si on parle d'IPC de type AVX ou autre."
Tu es dans le vrai pour le compilateur. En revanche je ne suis pas en total accord pour la suite. Certaines de ces informations sont pertinentes pour des cas d'usages. Le TLB a une énorme importance pour les accès mémoires, sa profondeur et la taille des pages peut avoir une influence non-négligeable sur certains scénarios mais connaître aussi le nombre d'unités FPU sont des détails importants. Pas uniquement pour les compilateurs ou des applications spécifiques, mais aussi pour voir l'évolution d'une architecture et éviter le discours marketing.
Même si ton architecture est très hétérogènes au sein de ta puce (CPU, NPU, GPU...) il n'empêche que c'est intéressant en soi d'avoir les informations propres à chaque partie et à leur interconnexion, indépendamment du fait que tu réalises plus de calculs d'un type que d'un autres.
Bonne question pour VLIW, je ne sais pas pour le CPU. Par contre pour le GPU et le DSP c'est plus que probable car c'est plutôt répandu.
* "Mais c'est du pinaillage: si je développais des compilateurs ça m'intéresserait, mais pour de l'utilisation, ce qui m'intéresse c'est plus le confort (qui n'est pas totalement /uniquement lié aux perfs théorique d'un CPU)"*
Et moi ce qui m'intéresse, au delà du confort, c'est d'avoir un processeur adapté à mon usage. Si je dois acheter (ou louer) ce type de machine, j'aime savoir ce qu'il y a dedans à minima pour faire un choix éclairé.
Après je tiens à préciser: Mme Michu & co n'ont clairement rien à faire de ceci. La notion même de fréquence ou de coeur de calculs sont très loin dans leur critère d'achat. Elles préfèrent des arguments plus "marketing" que techniques. Et sur ce point, elles achèteront Apple pour ce qu'Apple représente et non ce qu'Apple a mis comme génie dans la puce.
Le
01/11/2024 à
11h
15
C'était assez superficiel quand même pour le M1.
Et les concours de com de Intel et AMD ne servent qu'à une partie des clients, une autre partie d'en moque. Cela contribue même à l'impression d'ultracomplexité de l'informatique. Plus on a d'infos, plus on a de comparaisons à faire, plus il y a de doutes...
Un peu comme vendre une voiture de série en indiquant jusqu'au 0 à 100 par défaut...
ça dépend de tes usages. De mémoire, les benchmarks génériques n'étaient pas forcément les plus impressionnants. Par contre, dès que tu passes en calculs flottants, le M1 était quand même impressionnant à son époque. Mais c'est quand même un usage assez spécifique je te l'accorde.
Je me sers pas de la com' de ces boîtes. Mais ce qui m’intéresse c'est les détails plus profonds comme l'IPC, la longueur du décodeur d'instruction, le TLB, l'organisation des unités flottantes, la longeur du data path.... Et c'est pour ça que je préfère les slides car ces informations sont parfois accessibles. Et je chérie ces informations car avec tu peux comprendre ce qui se passe dans le CPU mieux que les slides des marketeux sur les perfs du CPU lors de benchmark (dont on ne connait jamais les conditions de tests [OS, température ambiante...])
En ce qui concerne l'ultracomplexicité de l'informatique... Et bien oui l'informatique est une science et c'est très complexe. Rien de nouveaux sous le Soleil. Par contre, la quantité d'informations n'est pas un problème tant que ce n'est pas du bullshit de marketeux (parce que ça c'est vraiment cancérigène). Après, c'est à chacun de savoir ce qu'il intéresse dans les infos et ce qu'il considère comme utile à garder ou à ignorer pour son analyse. Ce n'est, cependant, pas propre à l'informatique ou même spécifique à ces histoires d'architectures CPU.
Le
31/10/2024 à
15h
43
"C'est un back-end Apple top moumoute encore mieux que le précédent "
Tu voulais quel genre de com de leur part ? Apple communique rarement sur la partie matériel, c'est "accessoire", le plus important c'est l'expérience utilisateur.
De mémoire Apple avait communiqué sur son archi pour les M1. Et comme ils développent leur propre puce, ils pourraient avoir des slides similaires à Intel et AMD histoire de jouer "qui à la plus grosse" (ils aiment ça les Ricains) ou bien de dire "Venez chez nous, l'x86 c'est pour les vieux".
Le
30/10/2024 à
21h
10
Est-ce qu'Apple a communiqué sur les détails du back-end de leur CPU ?
Je peux t’assurer qu’on sait faire du cloud efficace. C’est juste pas mis en avant parce que Cloud Avenue, le navire amiral (et FCA/FE/FCP en leur temps) sont des usines à gaz, avec trop d’intervenants et de commerciaux, chefs de projets et toute l’armée mexicaine. (Et probablement quelques décisions discutables dues à des tentatives de faire simple) Ça n’est pas tellement compatible avec une tentative de cost-killer tel que les GAFAM les ont construits…
Il y a des clients privés, qui ont leur cloud privé, qui sont très contents de ce qu’on leur a construit.
Autant pour moi. J'en étais resté à ces histoires d'usine à gaz avec d'autres ESN qui n'avaient pas vraiment eu du succès.
Mais néanmoins, si je comprends mieux la position d'Orange je vois pas le lien avec le HPC. L'infra est une chose, mais les outils derrières (toolchains, compilateurs), le portage des libs et l'optimisation des codes, etc.... C'est pour la partie HPE ? Parce qu'HPE, Eviden et co j'en ai entendu parlé sans soucis, mais je n'ai jamais vu ni eu un interlocuteur d'Orange dans ce domaine.
821 commentaires
Rust dans le noyau Linux : nouvelles bisbilles, Linus Torvalds s’en mêle
10/02/2025
Aujourd'hui à 18h 58
La dernière fois que j'ai du mettre du restrict, c'était parce que le code servait de doc en même temps et que donc il fallait préciser ce point.
Donc en gros Rust interdit aliasing de pointeur.
Hier à 18h 54
Le 10/02/2025 à 20h 44
Ce qui m'a le plus gêné en Rust, c'est la complexité inutile de sa syntaxe et, dans une moindre mesure, la difficulté à faire produire un code performant par le compilateur. Je trouve que pour un langage qui se dit concurrencer le C on est en deçà de ce point essentiel.
Le 10/02/2025 à 20h 42
Le 10/02/2025 à 18h 56
Et dès qu'on essaye du fonctionnel ça devient très vite illisible et la POO avec Rust est encore plus immonde qu'en Fortran.
#Brieflock : Macron nous parle IA avec amour
10/02/2025
Le 10/02/2025 à 20h 13
Pour l'inanité (merci j'ai appris un mot), c'est pas choquant. Macron ne peut plus véritablement gouverner. Une démission incomprise, un précédent gouvernement censuré, Bayrou qui s'impose à lui et qui fait le boulot (en bien ou en mal ce n'est pas mon propos ici), et une sorte de détestation franche de la majorité des français. Concrètement à part l'internationale et faire acte de représentation il n'a franchement plus la main. ça doit peut-être long à l'Elysée des fois...
Le 10/02/2025 à 19h 01
La seule chose qui m'attriste c'est de voir que malgré l'aspect comique des parodies, le président n'est pas un mot pour rappeler que si c'est drôle dans ce contexte, la manipulation de l'image par l'IA et par extension, de l'information, est dangereuse et qu'il faut garder un esprit critique.IA : Emmanuel Macron annonce une centaine de milliards pour la Porte des étoiles française
10/02/2025
Le 10/02/2025 à 18h 52
Regarde le nombre de boîtes françaises qui utilisent du MS, du GCP, AWS... Alors qu'on pourrait la même chose (bon ok MS est un peu à part) en utilisant des solutions d'OVH, ScaleWay et autres acteurs locaux et/ou européen.
Il en sera de même pour l'IA. Mistral est là et c'est français mais combien de boîte utilise ChatGPT et, O combien les geeks, DSI et XXSI, ne font rien pour inciter à utiliser Mistral.
Et même si on incite à passer sur des solutions françaises, la riposte américaine serait probablement des droits de douane sur les CPUs & GPUs rendent les entreprises françaises et européennes non-compétitives.
On a perdu la "guerre" de l'IA et de l'informatique. Mettre 100 G€ ne changera rien tant qu'on ne sera pas capable, nous Européen, de produire nos propres puces ou d'utiliser des puces provenant d'autres pays.
Datacenters en France : 35 sites identifiés et un projet pharaonique avec les Émirats
07/02/2025
Le 10/02/2025 à 18h 41
Le 08/02/2025 à 21h 40
L'Emirat investisse et blanchissement probablement de l'argent au pasage. S'il achète les terrains au passage, ils doivent pouvoir les revendre avec quelques exonérations d'impôts sur les plus-values.En outre, il s'achète un peu d'image internationale et de pays moderne, vert et bienfaiseur. Mais surtout, il récupère des savoirs-faire en IA voir même des cerveaux (autres que du MBA qui pullule aux émirats).
Pour la France, Macron s'offre une réussite (vu la page blanche de son CV, ça va l'aider) et un peu d'image internationale. J'imagine qu'il a aussi participer (mais ça fait parti de son rôle) au négociation, mais je serais curieuse d'en connaître les dessous comme pour d'autres affaires.
Edit: Modification pour reformuler un propos alambiqué (merci jgguitare).
FLOP et SLAP : les puces Apple vulnérables à deux nouvelles attaques
29/01/2025
Le 03/02/2025 à 19h 00
Concernant sa modification, elle est uniquement de l'ordre du reverse-engineering et assez limité. Le papier que tu cites ne fonctionne que Goldmont (en gros les Atoms). Et personnellement modifié un micro-code c'est prendre le risque de transformer son processeur en cale-porte si ce n'est pas fait officiellement.
Le 02/02/2025 à 21h 24
@Nozalys parle de l’exécution spéculative au sein du microprocesseur, utiliser -march=i386 ne changera en rien la capacité du CPU à essayer de prédire le futur. C'est une fonctionnalité intrinsèque aux microprocesseur sur lequl on n'a, à l'heure actuelle pas de contrôle direct, seulement de l'indirect.
Le -funroll-all-loops ne sert pas au prédicat de branchement. Il y a déjà des unités dans le CPU pour ce genre de choses (cf mon post du dessus). Cette option sert surtout à dérouler des boucles pour pouvoir 1. permettre au compilateur d'optimiser via les unités vectorielles du code, 2. de saturer les unités calculs 3. cacher la latence et maximiser le throughput. Mais ce n'est pas aussi simple en réalité à utiliser surtout sans aller lire & comprendre l'assembleur pour s'assurer que le compilateur ne fait pas n'importe quoi.
De manière générale, la seule façon possible de désactiver totalement l’exécution spéculative serait via le microcode. Mais j'avoue que pour le fun, ça serait sympa de pouvoir essayer.
Quand à GCC ne fera rien si le code source C inclus des optimisations assembleur, tout dépend de comment ça a été inclus. Si c'est via le linker, il ne fera rien car ce n'est pas de sa "juridiction".Si c'est du GAS (inline assembleur), alors oui GCC peut y mettre son nez si celui-ci n'a pas l'attribut volatile.
Le 30/01/2025 à 15h 41
De manière simple non. On peut désactiver les caches mais ça demande de bidouiller des registres processeurs en kernel mode.Pour l'execution spéculative, il y a certainement des bits pour ça dans le microcode...
Mais oui, désactiver la spéculation se verrait sans soucis, en particulier si tu as des interfaces graphiques.
Le 30/01/2025 à 15h 38
Ce que tu décris existe déjà si je m'abuse. De mémoire, depuis Sandy Bridge il y a une unité LSD (Loop Stream Detector) qui est en charge de ce que tu décris.Pour aider le processeur, ça peut se faire déjà au niveau du code mais ça dépend des langages et surtout du niveau des devs. Et comme dans un monde où on favorise le pissage de code à l'efficacité (sauf niches mais c'est l'exception que la norme), ce genre de choses n'arrivent pas très souvent ou manière fortuite.
Les États-Unis veulent empêcher le rachat à 14 milliards de dollars de Juniper par HPE
31/01/2025
Le 01/02/2025 à 11h 06
L’avion Boom XB-1 dépasse le mur du son pour la première fois
29/01/2025
Le 29/01/2025 à 12h 51
Il y a des grandeurs dites "adimensionnées" qui permettent d'étudier une même physique à différentes échelles. C'est aussi le but des maquettes qui sont réalisés en ce sens. Les dimensions sont ajustées de sorte à ce que certaines grandeurs physiques soit identiques que le modèle 1:1.
Et ce n'est pas forcément une règle de 3. En outre, ces grandeurs sont très souvent utilisés dans les modèles physiques afin d'avoir des nombres assez petits pour les calculs (et ceux indépendamment que tu résolves ton équation sur une maquette de 10 cm ou à l'échelle réelle), mais également pour d'autres propriétés plus numériques.
Un exemple avec le nombre de
Union européenne : les enquêtes contre Apple, Meta et X en pause
08/01/2025
Le 08/01/2025 à 18h 44
L'Italie, la Hongrie et possiblement prochainement et partiellement l'Allemagne sont déjà du coté de ce duo US.
La commission européenne en le nom d'Ursula vient de déposer les armes et, comme en parle @Fred42, il y a peu de chances d'une destitution.
La France aurait pu encore avoir un mot à dire, mais Macron nous a tellement affaiblit et, il est religieusement pro-US, que nous pouvons rien faire.
Tu rajoutes à ça que Trump & Musk font de la division au sein de l'UE et oui nous sommes faibles et incapables de lutter contre eux pour le moment. Ce qui va suivre, sauf surprise, ne sera que gesticulation.
Le 08/01/2025 à 10h 37
Tu y crois ?Le 08/01/2025 à 10h 13
Pas de compatibilité avec Windows 11 ? ESET recommande le passage à Linux
08/01/2025
Le 08/01/2025 à 10h 36
Que de l'accompagnement soit fait, évidemment, de la pédagogie aussi pour les usagers. Mais à un moment donné, l'usager doit s'adapter. Ce qui ont des profils techs ici savent bien que nous sommes obligés de suivre les évolutions, les outils, les langages ... Alors pourquoi pas les autres ?
Quand aux logiciels, oui ça fait du boulot et ça a un coût et du temps. Mais la boîte a choisi Microsoft, et par conséquent à accepter de faire "lock-in". C'est pas comme si les stratégies commerciales des GAFAM (coucou le 3E) n'était pas connu. Et il n'y a pas d'excuses pour les boîtes de techs ni de commerce.
Pour le particulier, je pense que la question est la suivante : "Veut-il faire l'effort de quitter Microsoft ?" Si oui, ils acceptent (en connaissance de cause) de savoir qu'il va y avoir des soucis que tu décris... Si ça les insupportes, bah qu'il reste chez Microsoft ou vont chez Apple.
Perso, j'ai la même expérience que toi. Sauf que j'ai posé la question avant en mentionnant tout les difficultés possibles avec Linux. Ma soeur a préféré prendre un crédit pour du Apple. Mon cousin a accepté les efforts (parfois changement de matériel pour être plus Linux-compatible) et finalement après 6 mois, je fais plus d'assistance.
Chiffrement : BitLocker contourné par un hacker grâce à une ancienne faille
03/01/2025
Le 08/01/2025 à 10h 11
Pourtant c'est bien ce que fait Microsoft en disant AES-XTS avec les tailles de clés associées. Justement, ils le disent parce qu'ils savent que l'algorithme est robuste et que la seule faiblesse actuelle de l'algorithme c'est du brute-force.
Tu ferais confiance à un éditeur qui te dirait : "Faites-nous confiance, nous avons utilisé les meilleurs algorithmes du monde ?" et tu découvres plus tard que le cas à juste mis du RC4. Un exemple réel ? Juniper et sa rng backdooré.
Ne confonds pas la cryptographie "académique" dont les travaux portent sur la conception, l'analyse et l'étude des systèmes cryptographiques... Et leur implémentation en pratique.
Les failles dans les codes (i.e., les implémentations cryptographiques) ne sont pas du fait de l'algorithme. AES n'est pas, par design vulnérable à une attaque temporelle. Par contre, et comme tu le mentionnais, s'il est mal implémenté il le devient.
Concernant la protection des codes, un code visible est plus susceptible de se voir découvrir des failles plus tôt qu'un code obscur. Ma phrase était de dire "un code ouvert augmente la probabilité de détection d'une faille" et non "ça permet de détecter une faille".
Par chance (ou pas), la faille du root sous Linux (le signe = au == dans une condition) a été vu par relecture (et parce que le compilateur a gueulé).
La même faille chez Microsoft serait passé, peut-être, inaperçue.
Mais ce qui manque en vrai sur cette question de failles closed vs open source, c'est des expérimentations pour évaluer correctement les choses.
Dans le fond, je pense que nous sommes sur de nombreux points sauf sur celui, d'utiliser l'obscurité pour protéger un système cryptographique. Alors que par conception, celui doit pouvoir résister à ça car L'ennemi connaît le système. (cf. Maxime de Shannon).
Le 07/01/2025 à 22h 29
On peut aussi parler des backdoors dans les systèmes crytographiques de Juniper (qui équipe certains labo du CNRS à une époque...).
Rien que ça, si le code avait était ouvert sur cette partie on aurait pu peut-être voir quelque chose. Et visiblement les autorités françaises de l'époque (pourtant en période post-Snowden) ne se sont pas donnée cette peine, et là on parle pas d'un particulier.
Tu peux aussi étendre à d'autres failles. Microsoft est l'implémentation de la faille de la backdoor NSA dual_ecb_drgb (tiens Cisco aussi). Microsoft l'a implementé dans ses produits. Si le code avait été ouvert, ça n'aurait jamais pu se passer ainsi.
Que Microsoft protège Recall par l'obscurantisme (ou plus exactement en révélant pas les différentes techniques utilisés) c'est ok. Mais la cryptographie c'et la sécurité des données, c'est autre chose. Et ce n'est pas comme s'il y a pas eu des précédents sur le sujet.
AES c'est bon. XTS a des soucis avec l'authentification des données, mais ce n'est pas le sujet.
Pour l'implémentation de l'algorithme, il n'y a pas que les attaques par canaux axillaires temporels. Tu les variantes avec les caches. Dans les deux cas, l'usage de l'AES-NI permet d'atténuer fortement la première faille et possiblement la seconde.
Il n'empêche que je suis désolé mais un système cryptographique doit-être ouvert pour être plus sûr. Pas sans failles, mais au moins augmente la probabilité d'en voir une.
Le 07/01/2025 à 21h 49
Pour moi, oui ce sont des systèmes cryptographiques développés par des boites privées et rendu accessible. Le principe de Kerckhoffs est respecté.
Que tu payes avec des licences de l'accès privilégiés oui bien sûr ça me va. Mais ça ne devrait pas être le cas pour la partie crypto uniquement. Encore une fois, c'est une question de sécurité.
Le 07/01/2025 à 19h 13
Que la licence m'interdise des choses (code source de Recall, insertion de clé TPM...) oui me parait logique au regard de la stratégie lock-in de Microsoft. Mais pour un système cryptographique qui visent à sécuriser mes données, c'est exactement le contraire que ça fait.
Il n'y a aucune raison valable à rendre opaque un système cryptographique quand on prétend concevoir/utiliser un tel système pour protéger des données, que ce soit pour des civils, des militaires ou des industriels.
Le 06/01/2025 à 14h 40
De mon trou de serrure, ce genre de clauses contractuelles sont là pour les commerciaux pour rassurer leur client, mais en sachant parfaitement qu'elles ne seront jamais utilisés.
Et encore une fois, si ça ne pose pas de problèmes à Microsoft pourquoi, moi client de Microsoft ayant une licence MS, je me fais rejeter par le service client quand je demande ? Si MS n'a rien à cacher pourquoi il ne montre pas le code en faisant une simple demande ?
Quand aux clients qui n'apprécierait pas, ceci se règle avec du marketing & de la com'. Ce genre de clients n'a pas les notions requises (en interne) pour comprendre ce genre de choses techniques, donc qu'ils se contente de ce qu'ils peuvent comprendre : " la com' ".
Pour la doc MS je ne sais pas vraiment ne l'ayant pas pratiqué énormément. Celle de Linux est plus technique et a un ticket d'entrée plus haut. Mais au moins, on peut prendre une décision éclairé. Quand à l'utilisation de la doc, pas de soucis ni à trouver une version à jour. Mais je n'ai probablement pas les même usages et besoins de que toi.
Le 05/01/2025 à 22h 34
Ce qui, selon moi, implique que même si je dérobe le code source de BitLocker et le publie ouverte, la sécurité de celui-ci ne sera pas comprise car il repose sur la clé. Par conséquent, pourquoi Microsoft ne le rend-t-il pas publique ? Le chiffrement est connu c'est de l'AES. Le Cipher block, de l'XTS et la taille de la clé est connu (mais si à cette égard j'ignore si la taille de la clé donnée est avant ou après application de l'XTS).
J'ignore la citation original de Kerckhoffs, et de fait quelle page wiki est correct. En revanche, l'évolution des conflits et le role de la cryptographique a évolué depuis Kerckhoffs.
Et je pense que la version "moderne" formulée par Shannon (celui de l'entropie de l'information) : "The ennemy knows the system" est plus approprié (non pas parce qu'elle appuie mon argument, mais parce qu'elle se trouve plus réaliste de nos conflits modernes).
Le 05/01/2025 à 16h 49
Si Microsoft (mais d'autres) veulent un système de chiffrement sécurisée, le code source doit pouvoir être librement accessible et reproductible.
Core (Ultra) 200, Twin Lake : Intel lance des dizaines de nouveaux processeurs
07/01/2025
Le 07/01/2025 à 22h 33
Au-delà du marketing d'Intel (Pat aurait du tailler dans le gras sur cette activité) qui est dopé au champignon,est-ce que les différents supportent le même d'instruction ? Et si oui, l'AVX-512 est-il présent ou bien Intel y a renoncé ?
Météo-France engage 185 millions d’euros pour renouveler ses supercalculateurs
02/01/2025
Le 03/01/2025 à 11h 35
Merci pour les infos.
Le 03/01/2025 à 11h 24
En revanche, ce qui est plus intéressant dans du calculs scientifiques c'est l'augmentation du nombres de FLOPS, de la bande passante de la mémoire, de la capacité mémoire que peut adresser un CPU. A ça tu rajoutes la dimension GPU (je sais pas si Météo France a porté une partie de ses codes sous GPU, je me souviens d'avoir vu passé des offres de post-doc en ce sens) et de meilleurs systèmes d'interconnectivité pour les calculs distribués.
Le critère de puissance/watt n'est pas forcément dominant sachant qu'à chaque nouvelle génération de puce tu as toujours des gains positif sur ce ratio (gravure plus fine, design plus performant...)
Le 03/01/2025 à 11h 17
Pour mon info, tu ne mélanges pas les µ-arch CPU quand même ?
Delphine Gross, Commown : « le smartphone le plus vert, c’est celui que vous possédez déjà »
13/12/2024
Le 14/12/2024 à 13h 50
Le smartphone le plus vert, c'est celui qu'on le peut continuer d'utiliser sans obsolescence programmé, la merdification de l'OS et le verrouillage du bootloader.Je change de téléphone tout les 8 ans environ, mais ça me fait suer d'avoir un téléphone déjà obsolète supplément car les MaJ de sécurité ne sont plus assuré, et sans raison technologique valable.
Protocoles réseaux « next-gen » : Ultra Ethernet et UALink en approche chez Synopsys
12/12/2024
Le 12/12/2024 à 20h 27
Et niveau latence on sait quelque chose de plus concernant ce nouveau protocole ?Sept ans plus tard, la faille Spectre continue de hanter les processeurs AMD et Intel
07/11/2024
Le 07/11/2024 à 18h 35
Par contre, je pense qu'il y aussi deux biais : L'un d'observation lié aux fait que plus de gens s'intéresse maintenant qu'avant. Et l'autre que l'accès à ce genre d'informations est plus largement diffusable et diffusé qu'hier. C'est pour ces raisons que je ne m'avance pas pour la causalité.
Pour les GPU je pense qu'il y a autres choses en jeu. Je vois au moins deux facteurs: la vitesse d'évolution des GPU rendant rapidement une faille obsolète à l'usage, et la nature des données à récupérer. Un GPU ça sert concrètement à du calcul ou du jeux vidéos. Un CPU ça fait beaucoup de choses et surtout ils ont accès plus facilement à des données sensibles (clé de chiffrements, token d'ID...) ce qui fait que ce sont des cibles plus intéressantes.
Par exemple, un GPU chez un provider a très peu de chance de voir passer des clés cryptographiques. Il servira à du calcul numérique (CFD, deep learning...). En revanche un CPU va travailler avec les token d'ID, les clés SSH... rendent plus interessante cette cible. Et surtout le provider va conserver plus longtemps un processeur qu'un GPU. Par exemple chez OVH, on peut encore louer du Skylake.
Le 07/11/2024 à 14h 04
Tout va dépendre des utilisateurs finaux et du pouvoir de nuisance associé à la faille pour eux.Si ton utilisateur final est Mme Michu, on peut en effet se poser la question.
Si ton utilisateur final est un cloud provider (e.g., OVH), la correction est mettre en regard de son impact sur les performances et le service proposé.
Néanmoins, même si tu désactives les failles car tu considères que c'est ok. Tu peux avoir des softs qui inclus ces contre-mesures dans leur code. Et là, tu ne peux rien faire si le code n'est pas open-source.
Le 07/11/2024 à 13h 59
Ce que la présidence de Trump présage pour la tech
06/11/2024
Le 06/11/2024 à 22h 59
On peut néanmoins toujours s'entendre sur des normes (e.g., calibre des armes à feu).
Le 06/11/2024 à 19h 26
Par contre, je ne sais pas si les allemands ou les polonais seront de cet avis pour construire une vrai défense européenne sans matériel et logiciel US... Et je suis aussi pessimiste sur la capacité des pays européens à s'accorder de manière intelligente sur qui fait quoi.
Par contre, je ne pense pas que Trump laisserait tombé l'UE. Notre marché est très important pour les US et une guerre ne serait pas bon pour leur business sur le sol européen. Et l'économie c'est important pour Trump.
#Flock : les USA se sont encore Trumpé de Président
06/11/2024
Le 06/11/2024 à 20h 09
Le 06/11/2024 à 19h 19
A ma connaissance leur méthode de calculs ne semblent pas librement accessible. Donc, j'ai envie de dire comment je peux savoir si c'est rigoureusement fait ou bien en faisant un lancé de dés.
Ensuite, je critique la valeur de ces fameux 3% alors que des pays comme les US ou la Japon sont à 6% et s'en moque un peu. Ce que je ne pige pas, c'est pourquoi on embête la France sur ce point (qui est un peu un OVNI en terme de dépense à cause de son armée et son occupation géographique en autres). Surtout que c'est 3% sont sortis de nul part (et je ne considère pas l'économie comme une Science). Et nous savons parfaitement que la France a les moyens de rembourser, au besoin.
Pendant ce temps-là, les US investissent, le Japon investit et la France (et l'UE de manière générale) sont à la traine. Et dans un plan à 3 avec l'US, l'Europe et l'Asie, les US sont trop pudique pour inclure l'Europe dans leur galipettes.
Mais là, c'est un HS par rappport au sujet, je pense.
Le 06/11/2024 à 17h 00
Le 06/11/2024 à 13h 54
Allez l'Europe ! Maintenant faut se sortir les doigts du * et commencer à penser au 21ème et arrêter de réfléchir avec des idéologies économistes digne d'un gourou de secte !Comparatif des SoC Apple : des M1 aux M4, M4 Pro et M4 Max
30/10/2024
Le 06/11/2024 à 13h 51
Fortran fait du SIMD mais il délègue ceci aux compilateurs. Tu le peux faire un peu plus "nativement" via l'iso_c_binding sur les intrinsiques. Note que le C++ propose d'introduire le SIMD dans la norme C++26. A ma connaissance actuelle, seul Rust propose de faire du SIMD d'une façon naturelle.
Dans tout les cas, il faut checker l'assembleur et parfois jouer avec les options du compilateurs et le code pour arriver à ses désirs.
Pour le GPGPU, tu peux regarder du coté d'OpenMP pour les calculs hétérogènes ou OpenACC. Certains compilateurs comme pg ce sont aussi associées avec Nvidia pour intégrer du CUDA en Fortran sous forme d'extension.
Le 05/11/2024 à 22h 29
Néanmoins tout les processeurs sont des risc à l'heure actuelle si on regarde dans les détails. Les x86 sont certes des CISC, mais dès le tout début du front-end du CPU, tu as une conversion des instructions en micro-opérations, qui ressemble furieusement à ce que tu as en risc. Est-ce une bonne chose ? Honnêtement je ne sais pas à l'heure actuelle. Les deux approches ont des avantages et inconvénients.
Mais néanmoins je pense que ce n'est pas nécessairement un problème de langage. Il existe un langage pour ça, et c'est l'assembleur. Les langages de haut-niveau s'appuie dessu via un interpréteur (compilateur, JIT...).
Je pense que le soucis concerne la capacité du compilateur a comprendre un code ou une fonction dans sa globalité et comment l'optimiser avec les bonnes instructions. Il y a, selon moi, une responsabilité majeure des développeurs qui, pour la très grande majorité, ignore comment fonctionne un ordinateur, et par conséquent n'ont pas connaissance de ce genre de détails et son impact.
Mais finalement, bien que non-idéal, on s'y retrouve sous la le bon outils pour la bonne tâche.
VLC est en majorité codé en C++, et tu trouves de l'assembleur pour les fonctions les plus critiques (e.g., en/decoders).
Je n'ai malheureusement jamais joué avec l'architecture PowerPC :( Mais je ne perds pas espoir avec la possiblité d'en louer ou d'en acheter un). En revanche, de ce que j'ai vu de son fonctionnement, elle a des trucs sympathiques.
Je te rejoins à 100%, l'x86 n'est pas mort ni à court ou moyen terme. Et oui, merci à AMD pour le double pumping qui ouvre la voie à de possibles folies (AVX-2048 ?
Le 05/11/2024 à 18h 43
Le 04/11/2024 à 14h 52
Tu es dans le vrai pour le compilateur. En revanche je ne suis pas en total accord pour la suite. Certaines de ces informations sont pertinentes pour des cas d'usages. Le TLB a une énorme importance pour les accès mémoires, sa profondeur et la taille des pages peut avoir une influence non-négligeable sur certains scénarios mais connaître aussi le nombre d'unités FPU sont des détails importants. Pas uniquement pour les compilateurs ou des applications spécifiques, mais aussi pour voir l'évolution d'une architecture et éviter le discours marketing.
Même si ton architecture est très hétérogènes au sein de ta puce (CPU, NPU, GPU...) il n'empêche que c'est intéressant en soi d'avoir les informations propres à chaque partie et à leur interconnexion, indépendamment du fait que tu réalises plus de calculs d'un type que d'un autres.
Bonne question pour VLIW, je ne sais pas pour le CPU. Par contre pour le GPU et le DSP c'est plus que probable car c'est plutôt répandu.
*
"Mais c'est du pinaillage: si je développais des compilateurs ça m'intéresserait, mais pour de l'utilisation, ce qui m'intéresse c'est plus le confort (qui n'est pas totalement /uniquement lié aux perfs théorique d'un CPU)"*
Et moi ce qui m'intéresse, au delà du confort, c'est d'avoir un processeur adapté à mon usage. Si je dois acheter (ou louer) ce type de machine, j'aime savoir ce qu'il y a dedans à minima pour faire un choix éclairé.
Après je tiens à préciser: Mme Michu & co n'ont clairement rien à faire de ceci. La notion même de fréquence ou de coeur de calculs sont très loin dans leur critère d'achat. Elles préfèrent des arguments plus "marketing" que techniques. Et sur ce point, elles achèteront Apple pour ce qu'Apple représente et non ce qu'Apple a mis comme génie dans la puce.
Le 01/11/2024 à 11h 15
Je me sers pas de la com' de ces boîtes. Mais ce qui m’intéresse c'est les détails plus profonds comme l'IPC, la longueur du décodeur d'instruction, le TLB, l'organisation des unités flottantes, la longeur du data path.... Et c'est pour ça que je préfère les slides car ces informations sont parfois accessibles. Et je chérie ces informations car avec tu peux comprendre ce qui se passe dans le CPU mieux que les slides des marketeux sur les perfs du CPU lors de benchmark (dont on ne connait jamais les conditions de tests [OS, température ambiante...])
En ce qui concerne l'ultracomplexicité de l'informatique... Et bien oui l'informatique est une science et c'est très complexe. Rien de nouveaux sous le Soleil. Par contre, la quantité d'informations n'est pas un problème tant que ce n'est pas du bullshit de marketeux (parce que ça c'est vraiment cancérigène).
Après, c'est à chacun de savoir ce qu'il intéresse dans les infos et ce qu'il considère comme utile à garder ou à ignorer pour son analyse. Ce n'est, cependant, pas propre à l'informatique ou même spécifique à ces histoires d'architectures CPU.
Le 31/10/2024 à 15h 43
Le 30/10/2024 à 21h 10
Est-ce qu'Apple a communiqué sur les détails du back-end de leur CPU ?Orange et HPE construiront le supercalculateur classifié dédié à l’IA de défense
25/10/2024
Le 28/10/2024 à 21h 38
Mais néanmoins, si je comprends mieux la position d'Orange je vois pas le lien avec le HPC. L'infra est une chose, mais les outils derrières (toolchains, compilateurs), le portage des libs et l'optimisation des codes, etc.... C'est pour la partie HPE ?
Parce qu'HPE, Eviden et co j'en ai entendu parlé sans soucis, mais je n'ai jamais vu ni eu un interlocuteur d'Orange dans ce domaine.