Dans le monde reel il y a aussi des logiciels proprios dispos sur HPC dont tu n'as pas le code qui fonctionne beaucoup plus vite si tu utilises l'hyperthreading.
Et si le code n'est pas vectorisable (plein de "if" qui se baladent, par exemple)?
Avec les masques SIMD et les instructions gather / scatter, même si ton code branche (pas trop excessivement), il peut se vectoriser correctement de nos jours.
C'est d'ailleurs l'astuce utilisé par CUDA / les backend OpenCL pour gérer correctement le branching sur des architectures SIMT.
Je me demande si c'est toujours vrai avec du code du monde réel. Car le cas que tu décris est celui ou le cache est toujours utilisé. Le moindre cache miss, c'est des centaines de cycle de perdu, qui peuvent être un peu récupéré par de l'hyperthreading (ex: un code d'IO qui n'utilise pas la FPU).
Dépend ce que tu appelles monde réel.
Sur un code serveur en Java bourré d'I/O, de branching et de context switch, c'est trés différent de ce que j'ai expliqué plus haut.
Sur un code HPC, on a actuellement un simulateur de réseau neuronaux biologique qui fonctionne de l'ordre de 5% plus lentement avec l'hyperthreading activé sur Skylake & Xeon Phi là où je travaille actuellement, dù à ce que j'ai expliqué plus haut.
Si tu prends un processeur Intel moderne haut de gamme (e.g Intel Skylake / Platinium Gold ), tu as généralement deux FPU par coeur avec des tailles de registre allant de jusqu'a 512bits par FPU (AVX-512, chez Intel, AMD c'est différent ).
Donc ton processeur peut au maximum exécuter deux instructions AVX-512 par coeur à un moment donné.
Les processeurs Intel étant super-scalaire depuis les années 90, ils peuvent tous exécuter bien plus (a shit-more) que deux instructions par cycle par thread…. Donc un seul et unique thread est largement suffisant pour saturer les deux unité SIMD de ton coeur ( si ton code est vectorisé correctement ) et obtenir la performance de crête de ton processeur avec nombre de coeur == nombre de thread ( sans hyperthreading ).
Si tu "forces" l'hyperthreading, quand tu as déja atteint ce peak, la seule chose que tu vas gagner est une petite pénalité au runtime lié au coût du scheduling associé à l'hyperthreading.
Tu peux reproduire ça assez facilement chez toi en utilisant un petit bench floating-point intensif (e.g mt-dgemm) and un backend BLAS proprement optimisé du genre OpenBLAS, BLIS ou l'Intel MKL.
Sur un HPC il y a des logiciels pour lesquel l'acceleration est vraiment impressionante et utile mais bon pas au point de la securite donc je soupconne que pas mal de serveurs vont redemarrer bientot et foutre ne l'air de beau uptime
Dans le monde HPC, tout logiciel qui a un gain significatif avec l'hyper-threading est un logiciel sous optimum, autrement dit mal codé. Un logiciel hautement optimisé à même tendance à avoir un gain négatif quand il est executé avec l'hyperthreading.
Cette décision devrait seulement sur ces critères et pas zut si je veux utiliser cette lib, je vais devoir comprendre son système de build puis soit tuner l'ajouter à ma chaîne de compilation en statique soit la packager pour tous les OS cibles… mmh bon finalement je vais réinventer les algos qui m'intéressent et hop.
Tout à fait d'accord sur ce point. Et oui les package manager des OS ne sont pas non plus des solutions à ces problèmes.
Ceci dit, réimplémenter la roue dans chaque langage et shipper ses propres libs systèmes dans chaque pseudo-build système / package manager langage spécifique n'est pas non-plus une solution.
Dans le monde idéal, je veux pouvoir déployer mon module C++ utilisé par un interpréteur python accompagné d'un petit service Java et d'un tool en Haskell sans avoir à :
jongler entre le pip de python qui n'aime pas les libs binaires car c'est pas son job
Conan de C++ qui n'aime pas JAVA car c'est pas son job
Maven qui n'aime pas python parce qu'il a été marié à Java
Et cabal de Haskell qui ne s'aime même pas lui même.
Et j'ai volontairement laissé npm en dehors de l'histoire d'eviter le troll trop facile.
C'est pas une philosophie: comme ajouter une dépendance demande un travail long et chiant, on préfère réinventer la roue :-)
Désolé, Mais ça c'est une réflexion stupide.
Ajouter une dépendance à un coût.
Et malheureusement, un coût bien souvent sous évalué par les développeurs inexpérimentés ce qui amène à des situations de non-sense complet comme avec npm ou certains devs ajoute même une dépendance pour faire un hello world ( j'exagère à peine ).
Ajouter une dépendance c'est lié la maintenabilité, donc le cout humain de son projet à une source externe ( souvent énormément de source externe récursivement) non contrôlée. Ce n'est JAMAIS une chose à prendre à la légère dans tout projet logiciel digne de ce nom.
Ajouter une dépendance doit toujours être une décision basée sur un compromis entre perte de contrôle, et de maintenabilité d'un ajout externe et coût humain d'une ré-implémentation.
Quand je vois des développeurs ajouter en dépendances des frameworks monstrueux de plusieurs centaines de milliers de lignes de code simplement pour utiliser 2-3 fonctions (utilitaires) de ces frameworks, c'est une absurdité, souvent du à l'inexpérience.
GNU Guix propose une abstraction au dessus de plusieurs « gestionnaires de paquets » spécifiques de différents langages. Je n’ai pas essayé, mais l’idée est intéressante. Ça n’enlève pas la dépendance à tous ces systèmes de construction, mais au moins ça ne demande d’interagir qu’avec un outil unique.
Et je pense que c'est une très bon pas dans la bonne direction. J'espère sincèrement qu'une solution du type GUIX/Nix, Spack ou EasyBuild prennent le dessus à l'avenir et mette un terme au zoo spécifique à chaque langage que nous avons actuellement.
Hein ? Tu build en prod ? On parle d'outil de build, non ? Si tu n'a pas de dépendance le fait d'utiliser un outil qui va télécharger des dépendances ne change rien (astuce: si tu ne liste aucune dépendances, il n'en télécharge pas !!!)
Dans les workflows scientifiques (HPC) , la notion de "prod" est toute relative.
Maven n'a pas besoin d'internet
Maven peut être. Il a un paquet de build système qui se prennent pour des packages manager qui ne te laissent pas le choix
le fait qu'on ai maven/pip/cpa/gem/npm/… Montre que c'est un besoin que les gens ont. On peut se dire que la population de développeurs de tous ses langages sont en dehors des réalités, mais c'est quand même un peu prétentieux, tu ne crois pas
Le fait qu'on ait maven/pip/cpa/gem/npm/conan/cabal/cargo/vcpkgs/gradle/goget illustre parfaitement le manque d'un package manager orienté développeur multi-language. Le résultat étant un zoo de tools redondant, souvent mal implémentés et faisant l'interopérabilité cross-language un cauchemar.
Oui tu demande à apt de les télécharger. Bien. Maintenant comment tu fais pour avoir plusieurs versions de libc diférentes ?
Tu as pas du comprendre ce que je dis.
Sur beaucoup de systèmes HPC / Banque, il n'y a PAS d'internet. Ni APT, ni quoi que ce soit d'autre en accés directe. Les noeuds en eux même sont souvent diskless et proviennent d'image statique déployées et controlées par les sys admins.
Tu as SSH et RIEN. Si tu veux déployer ton app, tu le fais toi même depuis les sources.
Et quand les OS cibles n'ont pas les paquets (ou seulement dans une version obsolète), tu pleures très fort.
Ben ce que tu as besoin c'est alors d'un package manager cross platform. Du genre Nix ou Spack.
Et non d'un enième build système langage spécifique qui se prend pour un package manager, en faisant mal le job, et en chiant sur tout ce qui n'est pas directement son langage.
Justement non. Et C'est une des raisons qui me font détester ces build systèmes qui se prennent pour des packages managers.
Il y a beaucoup de système dans ce monde qui n'ont pas accès et n'auront jamais accès à internet pour de très bonne raisons. ( sécurité, banque, réseau spécialisé, super-calculateurs … )
Pouvoir installer un soft juste en utilisant des dépendances locales spécifiées à la main est un pré-requirement de tout bon build système.
Pour ceux qui en doutent, je vous conseille fortement de voir le talk "How to make life of package manager miserables" de K Hoste de la dernière FOSDEM.
C'est bien de le défendre, mais pandoc est réellement un cauchemard de dépendences…. et c'est peu dire.
moins d'une soixantaine si on veut le binaire pandoc
Binaire oui peut être… mais compiler pandoc est une autre histoire.
C'est un cauchemar de dépendences digne des pire paquets d'Haskell, à tel point que j'ai des configuration spécifique pour le désactiver à la demande dans la stack que je déploie….. Car la simple compilation de pandoc et de toutes ses deps prends un peu prêt 2h from scratch.
Ben pour ARM il n'y a que ARM, non ? Là où Intel et AMD sont tous deux capables de proposer des évolutions.
Non, tu peux parfaitement acheter le droit d'utiliser uniquement le jeu d'instruction ARM et faire ton CPU toi même certifié compatible ARM. Là où avec x86 et Intel, c'est impossible, ou pratiquement impossible.
Il y a des tas d'acteurs qui font ça, aléatoirement :
- Qualcomm avec Centriq
- Cavium avec ses ThunderX
- Nvidia avec Tegra
- Apple avec ses A-Series
- Phythium avec Mars
- Applied Micro avec X-Genes
Fait quelquechose de similaire en x86 est théoriquement faisable, sauf qu'en pratique il faut une licence d'Intel qui n'en accorde pas ou plus. Nvidia a essayé, et s'est vite fait calmé.
AMD a toujours un temps de retard mais de là à ne pas le comptabiliser c'est un peu fort. Surtout qu'avec la dernière architecture AMD est pas mal revenu dans la course.
Loi de moi cette idée mais mon point peut se comprendre en deux questions :
Que représente AMD face à Intel ?
d
Combien d'acteurs il y a sur le marché x86 ? comparé à combien d'acteurs dans le monde ARM ? Est-ce que ça va s'améliorer ou s'empirer ?
Le marché du x86 et x86_64 a été en quasi monopole depuis 20 ans. Si on peut louer les performances technique d'Intel, fait est qu'en pratique Intel tue et tuera toute concurrence en dehors d'AMD en utilisant ses droits de propriété intellectuel, ils l'ont déja fait et le feront encore.
Mais il n'y a pas que ARM, je ne sais pas si MIPS ne pourrait pas venir le concurrencer sur les serveurs avec des puces gérant le SMT, ce que à ma connaissance ne fait pas ARM.
Le ARMv8.2 ThunderX2 est SMT avec 4 hardware threads par coeur.
C'est déjà le cas avec l'EABI, l'OABI, EABI-hf, les modes ARM et Thumb, le softfp/VFP/neon…
L'ARMv8 a balancé une bonne parti du bordel à la poubelle.
Le gros avantage de des processeurs ARM, le plus gros face à Intel, c'est justement qu'il y a plusieurs fondeurs, chacun avec ses propres designs, dans plusieurs pays, mais utilisant la même ISA… au lieu d'Intel et Intel uniquement pour le x86.
La chance que tous les puces soient ver-ollées made in NSA, alors qu'elles sont designées au quatre coin de la planète sont assez restreintes.
Ne JAMAIS au grand JAMAIS exprimer ses dépendances en requirement absolue sur une version particulière (==) mais toujours utiliser filtrage sur une version minimal compatible (>= ).
La dépendance sur une version absolue te garantie une explosion nucléaire dés que tu auras une dépendance en diamant quelque part. (e.g paquet A requiert C == 0.04 et paquet B requiert C == 0.05 )
C'est de mon expérience, une des plus mauvaise pratique et presque malédiction du packaging en python.
C'est vraiment un projet intéressant, merci beaucoup pour ça.
J'aime beaucoup le coté simple de l'interface.
Deux petites choses qui pourraient être sympa :
Pouvoir écrire des pages en markdown
La signature électronique des documents.
Et puis une petite idée pour vous :
Le CERN a un outil vraiment sympa appelé "EDH" qui permet de "signer" numériquement un document avant de le transmettre à une personne donnée. C'est vraiment exceptionnel comme outil pour la simple et bonne raison que ça rend numérique, simple et rapide, toutes les procédures papier habituelles d'une entreprise de moyenne / grande taille : demande de matériel, travel request, modification de contrat, etc..
À bon entendeur si vous voulez enrichir votre solution pour la vendre ;)
J'ai eu confirmation que c'est bien Linus qui a dévoilé la faille le premier en poussant les patchs avant terme.
C'est donc bien lui qui est mis en cause dans le communiqué Intel. Auquel il a répondu très hypocritement par ailleurs…
J'aurai tendance à dire que Linus a entièrement raison.
"""
I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.
… and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.
Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything?"""
La réponse d'Intel s'approche presque d'un foutage de gueule en choisissant bien sagement ses mots.
"Recent reports that these exploits are caused by a “bug” or a “flaw” […] are incorrect"
Un processeur qui autorise un programme parfaitement conforme à leaké ses données en violant complètement la protection mémoire, même indirectement, est un processeur buggé, n'en déplaise à Intel.
La pire faille du lot est bien Meltdown, et c'est principalement les processeurs Intel qui sont touchés, pas la concurrence.
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 1.
Tu as un nom particulier en tête ?
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 2. Dernière modification le 26 juin 2018 à 10:02.
Avec les masques SIMD et les instructions gather / scatter, même si ton code branche (pas trop excessivement), il peut se vectoriser correctement de nos jours.
C'est d'ailleurs l'astuce utilisé par CUDA / les backend OpenCL pour gérer correctement le branching sur des architectures SIMT.
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 3. Dernière modification le 26 juin 2018 à 09:58.
Dépend ce que tu appelles monde réel.
Sur un code serveur en Java bourré d'I/O, de branching et de context switch, c'est trés différent de ce que j'ai expliqué plus haut.
Sur un code HPC, on a actuellement un simulateur de réseau neuronaux biologique qui fonctionne de l'ordre de 5% plus lentement avec l'hyperthreading activé sur Skylake & Xeon Phi là où je travaille actuellement, dù à ce que j'ai expliqué plus haut.
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 3.
Si tu prends un processeur Intel moderne haut de gamme (e.g Intel Skylake / Platinium Gold ), tu as généralement deux FPU par coeur avec des tailles de registre allant de jusqu'a 512bits par FPU (AVX-512, chez Intel, AMD c'est différent ).
https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(client)#Front-end
Donc ton processeur peut au maximum exécuter deux instructions AVX-512 par coeur à un moment donné.
Les processeurs Intel étant super-scalaire depuis les années 90, ils peuvent tous exécuter bien plus (a shit-more) que deux instructions par cycle par thread…. Donc un seul et unique thread est largement suffisant pour saturer les deux unité SIMD de ton coeur ( si ton code est vectorisé correctement ) et obtenir la performance de crête de ton processeur avec nombre de coeur == nombre de thread ( sans hyperthreading ).
Si tu "forces" l'hyperthreading, quand tu as déja atteint ce peak, la seule chose que tu vas gagner est une petite pénalité au runtime lié au coût du scheduling associé à l'hyperthreading.
Tu peux reproduire ça assez facilement chez toi en utilisant un petit bench floating-point intensif (e.g mt-dgemm) and un backend BLAS proprement optimisé du genre OpenBLAS, BLIS ou l'Intel MKL.
[^] # Re: HT et performances...
Posté par Firwen (site web personnel) . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 1.
Dans le monde HPC, tout logiciel qui a un gain significatif avec l'hyper-threading est un logiciel sous optimum, autrement dit mal codé. Un logiciel hautement optimisé à même tendance à avoir un gain négatif quand il est executé avec l'hyperthreading.
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par Firwen (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 5. Dernière modification le 18 juin 2018 à 14:50.
Tout à fait d'accord sur ce point. Et oui les package manager des OS ne sont pas non plus des solutions à ces problèmes.
Ceci dit, réimplémenter la roue dans chaque langage et shipper ses propres libs systèmes dans chaque pseudo-build système / package manager langage spécifique n'est pas non-plus une solution.
Dans le monde idéal, je veux pouvoir déployer mon module C++ utilisé par un interpréteur python accompagné d'un petit service Java et d'un tool en Haskell sans avoir à :
Et j'ai volontairement laissé npm en dehors de l'histoire d'eviter le troll trop facile.
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par Firwen (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 6. Dernière modification le 18 juin 2018 à 11:54.
Désolé, Mais ça c'est une réflexion stupide.
Ajouter une dépendance à un coût.
Et malheureusement, un coût bien souvent sous évalué par les développeurs inexpérimentés ce qui amène à des situations de non-sense complet comme avec npm ou certains devs ajoute même une dépendance pour faire un hello world ( j'exagère à peine ).
Ajouter une dépendance c'est lié la maintenabilité, donc le cout humain de son projet à une source externe ( souvent énormément de source externe récursivement) non contrôlée. Ce n'est JAMAIS une chose à prendre à la légère dans tout projet logiciel digne de ce nom.
Ajouter une dépendance doit toujours être une décision basée sur un compromis entre perte de contrôle, et de maintenabilité d'un ajout externe et coût humain d'une ré-implémentation.
Quand je vois des développeurs ajouter en dépendances des frameworks monstrueux de plusieurs centaines de milliers de lignes de code simplement pour utiliser 2-3 fonctions (utilitaires) de ces frameworks, c'est une absurdité, souvent du à l'inexpérience.
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par Firwen (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 2.
Et je pense que c'est une très bon pas dans la bonne direction. J'espère sincèrement qu'une solution du type GUIX/Nix, Spack ou EasyBuild prennent le dessus à l'avenir et mette un terme au zoo spécifique à chaque langage que nous avons actuellement.
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par Firwen (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 5.
Dans les workflows scientifiques (HPC) , la notion de "prod" est toute relative.
Maven peut être. Il a un paquet de build système qui se prennent pour des packages manager qui ne te laissent pas le choix
Le fait qu'on ait maven/pip/cpa/gem/npm/conan/cabal/cargo/vcpkgs/gradle/goget illustre parfaitement le manque d'un package manager orienté développeur multi-language. Le résultat étant un zoo de tools redondant, souvent mal implémentés et faisant l'interopérabilité cross-language un cauchemar.
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par Firwen (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 1.
Tu as pas du comprendre ce que je dis.
Sur beaucoup de systèmes HPC / Banque, il n'y a PAS d'internet. Ni APT, ni quoi que ce soit d'autre en accés directe. Les noeuds en eux même sont souvent diskless et proviennent d'image statique déployées et controlées par les sys admins.
Tu as SSH et RIEN. Si tu veux déployer ton app, tu le fais toi même depuis les sources.
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par Firwen (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 2.
Ben ce que tu as besoin c'est alors d'un package manager cross platform. Du genre Nix ou Spack.
Et non d'un enième build système langage spécifique qui se prend pour un package manager, en faisant mal le job, et en chiant sur tout ce qui n'est pas directement son langage.
[^] # Re: Par Crom, il faut un maven pour C++ !
Posté par Firwen (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 2.
Justement non. Et C'est une des raisons qui me font détester ces build systèmes qui se prennent pour des packages managers.
Il y a beaucoup de système dans ce monde qui n'ont pas accès et n'auront jamais accès à internet pour de très bonne raisons. ( sécurité, banque, réseau spécialisé, super-calculateurs … )
Pouvoir installer un soft juste en utilisant des dépendances locales spécifiées à la main est un pré-requirement de tout bon build système.
Pour ceux qui en doutent, je vous conseille fortement de voir le talk "How to make life of package manager miserables" de K Hoste de la dernière FOSDEM.
https://mirror.as35701.net/video.fosdem.org/2018/K.3.201/how_to_make_package_managers_cry.webm
[^] # Re: Bazel
Posté par Firwen (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 4.
Horriblement bloaté ( e.g, requiert une JVM pour compiler un hello world en C )
Inflexible, hardcode compiler path et autre joyeusement
Ne suit pas le standard make / make install. Essaie de compiler tout dans un "workspace"
Je le rank assez haut au ranking des pires build systèmes available.
[^] # Re: LibreOffice Online est mort
Posté par Firwen (site web personnel) . En réponse à la dépêche Sortie de la suite bureautique en ligne ONLYOFFICE en version 5.1. Évalué à 2.
Sur les quelques tests que j'ai fait, Only Office exporte relativement bien en ODT.
[^] # Re: Pandoc
Posté par Firwen (site web personnel) . En réponse à la dépêche Trois outils pour développeur : MailHog, Tokei et Pandoc. Évalué à 3.
Nix retourne toujours toutes les dépendences jusqu'a la libc, donc oui.
A titre de comparaison voilà celui de doxygen, incluant aussi jusqu'a la libc
[^] # Re: Pandoc
Posté par Firwen (site web personnel) . En réponse à la dépêche Trois outils pour développeur : MailHog, Tokei et Pandoc. Évalué à 3. Dernière modification le 10 avril 2018 à 10:45.
C'est bien de le défendre, mais pandoc est réellement un cauchemard de dépendences…. et c'est peu dire.
Binaire oui peut être… mais compiler pandoc est une autre histoire.
C'est un cauchemar de dépendences digne des pire paquets d'Haskell, à tel point que j'ai des configuration spécifique pour le désactiver à la demande dans la stack que je déploie….. Car la simple compilation de pandoc et de toutes ses deps prends un peu prêt 2h from scratch.
un petit nix-store -q --graph sur pandoc me donne
Soit un graph de + de 6500 dependances.
A titre de comparaison, un serveur web complet comme nginx retourne environ ~2000. Incluant même perl, les autotools et GCC nécessaire à le compiler…
Ceci dit ça n’enlève rien au fait que ça soit un excellent tool.
Et qu'au passage, l'explosion des dépendance semble être une spécificité de beaucoup de documentation generator, Sphinx n'étant pas beaucoup mieux.
[^] # Re: Effet de mode?
Posté par Firwen (site web personnel) . En réponse au journal ARM vs Intel. Évalué à 3.
Non, tu peux parfaitement acheter le droit d'utiliser uniquement le jeu d'instruction ARM et faire ton CPU toi même certifié compatible ARM. Là où avec x86 et Intel, c'est impossible, ou pratiquement impossible.
Il y a des tas d'acteurs qui font ça, aléatoirement :
- Qualcomm avec Centriq
- Cavium avec ses ThunderX
- Nvidia avec Tegra
- Apple avec ses A-Series
- Phythium avec Mars
- Applied Micro avec X-Genes
Fait quelquechose de similaire en x86 est théoriquement faisable, sauf qu'en pratique il faut une licence d'Intel qui n'en accorde pas ou plus. Nvidia a essayé, et s'est vite fait calmé.
[^] # Re: Effet de mode?
Posté par Firwen (site web personnel) . En réponse au journal ARM vs Intel. Évalué à -1.
Loi de moi cette idée mais mon point peut se comprendre en deux questions :
Le marché du x86 et x86_64 a été en quasi monopole depuis 20 ans. Si on peut louer les performances technique d'Intel, fait est qu'en pratique Intel tue et tuera toute concurrence en dehors d'AMD en utilisant ses droits de propriété intellectuel, ils l'ont déja fait et le feront encore.
[^] # Re: la guerre du perf/watt ... et du perf/€
Posté par Firwen (site web personnel) . En réponse au journal ARM vs Intel. Évalué à 5.
Le ARMv8.2 ThunderX2 est SMT avec 4 hardware threads par coeur.
[^] # Re: Effet de mode?
Posté par Firwen (site web personnel) . En réponse au journal ARM vs Intel. Évalué à 1.
L'ARMv8 a balancé une bonne parti du bordel à la poubelle.
Le gros avantage de des processeurs ARM, le plus gros face à Intel, c'est justement qu'il y a plusieurs fondeurs, chacun avec ses propres designs, dans plusieurs pays, mais utilisant la même ISA… au lieu d'Intel et Intel uniquement pour le x86.
La chance que tous les puces soient ver-ollées made in NSA, alors qu'elles sont designées au quatre coin de la planète sont assez restreintes.
# Versionning absolue des dépendances considered harmful
Posté par Firwen (site web personnel) . En réponse au journal Envoyer des Python à roues. Évalué à 3.
Un petite note sur ça :
Ne JAMAIS au grand JAMAIS exprimer ses dépendances en requirement absolue sur une version particulière (==) mais toujours utiliser filtrage sur une version minimal compatible (>= ).
La dépendance sur une version absolue te garantie une explosion nucléaire dés que tu auras une dépendance en diamant quelque part. (e.g paquet A requiert C == 0.04 et paquet B requiert C == 0.05 )
C'est de mon expérience, une des plus mauvaise pratique et presque malédiction du packaging en python.
[^] # Re: qtcreator pour le c et c++
Posté par Firwen (site web personnel) . En réponse au journal Quel IDE pour quel langage. Évalué à 3.
J'ajouterai:
- Excellent support des projets CMake
- Integration avec GDB.
- Consommation mémoire résonnable
- Pas de JVM
# Signature electronique
Posté par Firwen (site web personnel) . En réponse à la dépêche Tracim, socle libre du travail en équipe, sort en v1.0. Évalué à 7.
C'est vraiment un projet intéressant, merci beaucoup pour ça.
J'aime beaucoup le coté simple de l'interface.
Deux petites choses qui pourraient être sympa :
Pouvoir écrire des pages en markdown
La signature électronique des documents.
Et puis une petite idée pour vous :
Le CERN a un outil vraiment sympa appelé "EDH" qui permet de "signer" numériquement un document avant de le transmettre à une personne donnée. C'est vraiment exceptionnel comme outil pour la simple et bonne raison que ça rend numérique, simple et rapide, toutes les procédures papier habituelles d'une entreprise de moyenne / grande taille : demande de matériel, travel request, modification de contrat, etc..
À bon entendeur si vous voulez enrichir votre solution pour la vendre ;)
[^] # Re: Précisions / corrections
Posté par Firwen (site web personnel) . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 2.
Et ça reste du C++…. Sur des languages fortement Objet ou les appels se font presque tous par vtables / déférencement, ça va être popcorn time.
[^] # Re: Et Linus ?
Posté par Firwen (site web personnel) . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10. Dernière modification le 05 janvier 2018 à 13:28.
J'aurai tendance à dire que Linus a entièrement raison.
"""
I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.
… and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.
Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything?"""
La réponse d'Intel s'approche presque d'un foutage de gueule en choisissant bien sagement ses mots.
Un processeur qui autorise un programme parfaitement conforme à leaké ses données en violant complètement la protection mémoire, même indirectement, est un processeur buggé, n'en déplaise à Intel.
La pire faille du lot est bien Meltdown, et c'est principalement les processeurs Intel qui sont touchés, pas la concurrence.