Peut-être un moyen de retarder la fin programmée des processeurs à base de silicium, Réactions à la publication du 14/08/2017

[Lionel]

Comme vous le savez, les années des processeurs à base de silicium, tels qu'on les connaît, sont maintenant comptées. Les lois de la physique étant intangibles, il ne sera plus possible à un moment de graver plus finement sans se heurter à des lois quantiques.
Les fabricants de puces arrivent toutefois à reculer toujours plus ces limites. Actuellement, ils le font grâce à la technologie FinFET, qui permet en augmentant la hauteur des transistors de leur conserver une isolation suffisante pour éviter les courants de fuite malgré la diminution de leur épaisseur.
Des chercheurs de l'Université de Stanford ont annoncé avoir fait une découverte qui pourrait encore permettre aux fabricants de puces de retarder l'inéluctable.

Ils ont identifié deux semi-conducteurs, le diselénide au hafnium et le disélénure de zirconium qui permettent à eux deux de créer des transistors de seulement trois atomes d'épaisseur. Malgré cette épaisseur record, ils assurent une isolation suffisante pour éviter les fuites d'électrons. Ils permettraient de créer des transistors 10 fois plus petits que ce que permettra la gravure en 5nm qui est déjà en tests préliminaires chez quelques fondeurs de puces.

Si l'équipe est confiante dans sa découverte, elle n'a pas encore réglé tous les problèmes, à commencer par le renforcement du lien qui unira ces nouveaux matériaux avec le substrat qui restera en silicium.

Souhaitons pour eux et pour l'industrie des processeurs que cela soit rapide car les chercheurs et ingénieurs spécialisés dans ce domaine commencent à ne plus savoir quoi faire pour reculer la barrière qui obscurcit leur horizon tandis que les solutions alternatives aux procédés actuels de production de processeurs ne sont encore que des pistes très très éloignées d'une production de masse.

Lien vers le billet original

[ekami]

Merci pour l'info.
Par "chance" en attendant il reste encore une marge considérable "d'accélération" au niveau des temps d'accès entre le trio processeur / ram / espace de stockage.

[pmr115]

Faudrait aussi que les développeurs fassent un petit effort pour optimiser leurs programmes pour les multicoques actuels qui sont scandaleusement sous exploités.

excuser la coquille, il faut lire multicoeurs et non multicoques comme le correcteur orthographique a corrigé.

nb j'utilise un MacPro late 2013 trouvé neuf soldé a -50%. A ce prix c'est tout bon.

[Lionel]

Tu ne peux pas tout paraléliser, ou alors dans certains cas tu perdras du temps au lieu d'en gagner dès qu'une partie de tes calculs nécessite le résultat d'autres calculs. Le parallélisme massif c'est super pour un traitement photo ou vidéo car on découpe l'image en plissures morceaux et on laisse chaque coeur en traiter une partie. Dans d'autres cas c'est tout simplement impossible à découper une suite de calculs dont chaque nouveau dépend du résultat du précédent.
L'autre problème est le temps de développement. L'optimisation prend un temps considérable et plus le logiciel est complexe plus il faut de temps à le coder puis à l'optimiser.

[Jean-Jacques Cor...]

Si on commençait par réécrire les systèmes d'exploitation en codant proprement et si possible directement en assembleur, on gagnerait pas mal de puissance machine. Idem pour les applications.
Regardez ce que l'on arrivait à faire avec un Amstrad CPC et son Z80 à 4MHz ou avec l'Apple II et son 6502 à 1 MHz.

[Hebus]

Ce très intéressant papier de Jean-Louis Gassé au sujet de la transformation de macOS pour exploiter justement le peu de puissance disponible à l’epoque sur le processeur de l’iphone 1...

Comme dit Lionel, ça coûte cher d’écrire du code, il faut une motivation économique pour financer le temps passé.

https://mondaynote.com/the-operating-system...os-39bc1a3ce004

[Rorqual]

Ce très intéressant papier de Jean-Louis Gassé au sujet de la transformation de macOS pour exploiter justement le peu de puissance disponible à l’epoque sur le processeur de l’iphone 1...

Dans ce cas-ci, tel qu'exposé dans l'article, ce n'est pas de l'optimisation du code qui a été faite, mais le démembrement du logiciel pour ne garder que les parties vitales.

Ce message a été modifié par Rorqual - 14 Aug 2017, 07:39.

[Hebus]

Pas si simple de supprimer des morceaux, il faut enlever, simplifier, changer les logiques de connexion. Refactoring de grande envergure. Sans doute réécrire certaines parties trop gourmandes.
Réécrire l’assembleur.

L’optimisation c’est exactement ça. Simplifier, alléger...

Ce message a été modifié par Hebus - 14 Aug 2017, 08:01.

[marc_os]

[...]
Ils ont identifié deux semi-conducteurs, le diselénide au hafnium et le disélénure de zirconium qui permettent à eux deux de créer des transistors de seulement trois atomes d'épaisseur. Malgré cette épaisseur record, ils assurent une isolation suffisante pour éviter les fuites d'électrons. Ils permettraient de créer des transistors 10 fois plus petits que ce que permettra la gravure en 5nm qui est déjà en tests préliminaires chez quelques fondeurs de puces.

Si l'équipe est confiante dans sa découverte, elle n'a pas encore réglé tous les problèmes, à commencer par le renforcement du lien qui unira ces nouveaux matériaux avec le substrat qui restera en silicium.
[...]

Chouette ! Mais peut-être serait-il temps de tenir enfin compte des considérations environnementales et d'approvisionnement dès le début de telles recherches, ou au moins à partir du moment où elles semblent être prometteuses ?

Zirconium :

Il est trois fois plus abondant que le cuivre dans la croûte terrestre.
[Mais : ]
La production mondiale de zircon est d'environ 1,25 million de tonnes par an. La Chine a une production significative qui lui permet d'alimenter son marché intérieur. [...]
Les réserves sont estimées à 56 millions de tonnes, ce qui représente un peu plus de 40 ans de production au rythme de consommation actuel [qui ne tient donc pas compte de son utilisation éventuelle dans les processeurs]. Cependant, la consommation a crû en moyenne de 3,4 % par an sur la période 1990-2008, en raison notamment d'une forte croissance de la demande chinoise (17,2 % par an en moyenne). Deux pays, l'Australie et l'Afrique du Sud, se partagent les deux tiers de la production et des réserves. Les États-Unis, le Brésil, l'Inde et l'Ukraine ont aussi des réserves significatives. Le zirconium pose donc des problèmes d'une part dans le niveau des réserves, et d'autre part dans le déséquilibre de la répartition géographique des réserves.

Hafnium :

Comme la plupart des métaux rares, le hafnium est une ressource non renouvelable, la quasi-totalité de la ressource vient de l'épuration du zirconium.

Peut-être que je m'inquiète pour rien.
Mais je trouve quand même inquiétant le fait qu'il ne soit toujours pas "naturel" d'évoquer les questions environnementales liées aux découvertes. Quand l'humanité comprendra-t-elle que les ressources naturelles de la terre ne sont pas disponibles en quantité infinie ad vitam eternam ? Et que pour nombre d'entre elles l'humanité vit "à crédit", crédit que devront "payer" les générations futures ?

[marc_os]

Tu ne peux pas tout paraléliser, ou alors dans certains cas tu perdras du temps au lieu d'en gagner dès qu'une partie de tes calculs nécessite le résultat d'autres calculs. Le parallélisme massif c'est super pour un traitement photo ou vidéo car on découpe l'image en plissures morceaux et on laisse chaque coeur en traiter une partie. Dans d'autres cas c'est tout simplement impossible à découper une suite de calculs dont chaque nouveau dépend du résultat du précédent.
L'autre problème est le temps de développement. L'optimisation prend un temps considérable et plus le logiciel est complexe plus il faut de temps à le coder puis à l'optimiser.

Il n'y a pas que les gros algos bien jolis en traitement d'image qui peuvent profiter de traitements parallèles, car tout n'est pas "calcul" ! Car si tu codes "à l'ancienne", comme sous Mac OS 9 et antérieur (bien que), ton appli se fera jeter direct par ses utilisateurs. En effet, tout traitement gèlera ton application le temps qu'il finisse. Les traitements en parallèle, ça permet aussi d'avoir d'un côté la gestion de l'interface, et de l'autre côté, ou plutôt, "vu des autres côtés", on a les tâches à effectuer qui vivent leur vie indépendamment de l'interface, qui n'étant pas bloquée permet de les interrompre, tâches elles-même parallélisables ou pas. Et si le traitement en cours ne bloque pas toute l'interface, c'est bien grâce aux traitements en parallèle qui seront d'autant plus fluides les uns par rapport aux autres que le processeur dispose de plus de cœurs. Un autre domaine qui monte en puissance et profite du codage en parallèle et de la multiplication des cœurs, c'est tout ce qui est réalité virtuelle et surtout machine learning et réseaux de neurones. Et j'en remets une couche, c'est précisément à ça que sert GCD, gérer le parallélisme, la répartition transparente des tâches sur des threads, ainsi que la synchronisation des tâches, quelque soit leur nature.
Quant à l'optimisation, se serait déjà pas mal de ne pas penser dès le départ des trucs comme "vu la rapidité des processeurs de nos jours..." comme je peux parfois l'entendre, pensée qui n'incite pas vraiment le développeur à faire des efforts.
Dans le domaine du test des CI on parle de Design For Testability pour éviter dès la conception de produire des trucs intestables en prod et optimiser, càd minimiser les temps de test par exemple via du self-test, et bien en software prévoir le parallélisme un minimum dès la conception initiale est devenu de facto obligatoire pour l'interface sous OS X, et on pourrait parler de Design for Concurrency avec un outil formidable, GCD.
Amen.

[GregWar]

Si on commençait par réécrire les systèmes d'exploitation en codant proprement et si possible directement en assembleur, on gagnerait pas mal de puissance machine. Idem pour les applications.
Regardez ce que l'on arrivait à faire avec un Amstrad CPC et son Z80 à 4MHz ou avec l'Apple II et son 6502 à 1 MHz.

Note que l'on peut prendre ta phrase dans les 2 sens.

J'ai connu l'époque des démo makers 8/16 bit, c'était impressionnant d'avoir des images de 400 lignes de définition pour 4k couleurs (non pas 4K pixels… 4k couleurs)...
Et encore, c'est plutôt la fin, avec les Amiga 1000.
Avec un CPC, et son Z80 (même le 6128plus), c'est plus 200 lignes, soit une moins d'une demi-icône de OSX.


Vraiment impressionnant, oui ces démos, mais avec nos besoin d'aujourd'hui, c'est juste impossible de faire avec.
Juste un exemple, le RS232 montait sur le A1000 à 115kbps, en théorie. ThunderBolt, c'est 10G, on a un facteur 87000.
C'est environ le nombre de secondes dans une journée… donc 1 sec pour l'un, 1 journée pour l'autre.


On peut surement aller chercher quelques 50% d'augmentation, avec de l'optimisation un peu partout.
Allez disons même 500%… super, on aura juste comblé 3 ans de Loi de Moore.


Avec ce que l'on attend des ordis d'aujourd'hui, il faut pas trop rêver non plus, les développeurs ne sont pas que des mauvais, idiots… etc…


Quand à écrire un OS tel Windows 10 ou OSX en assembleur, tant que le code sera écrit par des humains, je ne pense pas que ce soit possible.
Les compilateurs C dispo optimisent déjà bien plus que le ferait un développeur non super-expert, c'est même pas sur que ce serait plus rapide... et ce serait truffé de bugs, par manque de lisibilité du code.
Sans parler d'une totale dépendance au CPU et des composants autour... oui c'est optimisé, mais plus du tout portable.

[Lionel]

Ouah, tu fais le pont ?
Pour commencer, on parle d'une utilisation pour fabriquer des processeurs, et même seulement les transistors, soit quelques nanogrammes par CPU à tout casser. Donc, on a de quoi voir venir s'il en faut quelques grammes ou même quelques dizaines de grammes pour produire des millions de processeurs.
Ensuite, on en reparlera le jour où les puces Ax seront aussi produites ainsi. Tu cesseras d'acheter des produits Apple pour autant ?

[Macintox]

Ce très intéressant papier de Jean-Louis Gassé au sujet de la transformation de macOS pour exploiter justement le peu de puissance disponible à l’epoque sur le processeur de l’iphone 1...

Comme dit Lionel, ça coûte cher d’écrire du code, il faut une motivation économique pour financer le temps passé.

https://mondaynote.com/the-operating-system...os-39bc1a3ce004

merci pour ce lien ...very interesting indeed ..

[linus]

Tu ne peux pas tout paraléliser, ou alors dans certains cas tu perdras du temps au lieu d'en gagner dès qu'une partie de tes calculs nécessite le résultat d'autres calculs. Le parallélisme massif c'est super pour un traitement photo ou vidéo car on découpe l'image en plissures morceaux et on laisse chaque coeur en traiter une partie. Dans d'autres cas c'est tout simplement impossible à découper une suite de calculs dont chaque nouveau dépend du résultat du précédent.
L'autre problème est le temps de développement. L'optimisation prend un temps considérable et plus le logiciel est complexe plus il faut de temps à le coder puis à l'optimiser.

De temps et de savoir faire mathématique. Décortiquer un algorithme pour la paralléliser et la Ve titiste (ah le fameux altivec de Motorola et Apple) n'est toujours trivial.

[otto87]

Si on commençait par réécrire les systèmes d'exploitation en codant proprement et si possible directement en assembleur, on gagnerait pas mal de puissance machine. Idem pour les applications.
Regardez ce que l'on arrivait à faire avec un Amstrad CPC et son Z80 à 4MHz ou avec l'Apple II et son 6502 à 1 MHz.

C'est as si simple que ça, il est impossible humainement de tout faire en assembleur vu le nombre de surcouche et lib qui trainent. Cependant il y a clairement un gâchis énorme de puissance : un chercheur français en 3D célèbre faisait une remarque équivalente ; depuis le début de carrière le gain de puissance se compte en millions ou centaines de millions... mais pour les performances pratique de rendu il y a quelques puissances de 10 qui manque...

On peut surement aller chercher quelques 50% d'augmentation, avec de l'optimisation un peu partout.
Allez disons même 500%… super, on aura juste comblé 3 ans de Loi de Moore.

3 ans de loi de Moore au moment ou en arrive au bout, c'est justement énorme...
Et 500%, c'est minimaliste... compare juste sur le même hardware l'exécution du javascript d'un naviguateur d'il y a 10 ans avec un navigateur actuel

Il y aussi la blague des soft comme je ne sais plus quel éditeur de code programmé avec NODE js (bordel ce correcteur orthographique me les brise menu) et co : 250 Mo de RAM pour ouvrir un fichier vide et du gâchis phénoménale de puissance... mais c'est facile a coder...

Ce message a été modifié par otto87 - 14 Aug 2017, 12:26.

[Anozer]

mais c'est facile a coder...

C'est bien là le cœur du problème. Le logiciel semble (c'est ce que tout le monde affirme, jamais été vérifié) coûter beaucoup plus cher à concevoir que le matériel. Donc on a tendance à développer des systèmes matériels toujours plus puissant pour proposer une "plateforme" au logiciel qui l'exploitera comme il l'entend.
Un collègue, concepteur logiciel, me disait un jour : chez nous, le soft, c'est comme un gaz parfait, il occupera tout l'espace disponible.
Dit autrement, c'est parce que la puissance matérielle a été décuplée que le logiciel est de moins en moins optimisé. Mais c'est pas forcément idiot. Le matériel n'est qu'une plateforme, au service du logiciel qui porte la fonction. Il n'est donc pas étonnant que le travail d'optimisation et de recherche de performance soit d'avantage porté par le matériel qui n'a finalement presque que ce rôle à jouer. Alors que les développeurs logiciels auront plutôt tendance à se focaliser sur le fonctionnel qui est vendu au client.

Ça c'est une vision certes pragmatique mais purement économique et que je ne défend pas forcément. D'un point de vue plus philosophique et politique, c'est un véritable gâchis.

[otto87]

Ça c'est une vision certes pragmatique mais purement économique et que je ne défend pas forcément. D'un point de vue plus philosophique et politique, c'est un véritable gâchis.

Je sais pour être dans le domaine que le temps d'optimisation peut être énorme : j'ai passé quelques mois sur quelques centaines de ligne de code et le résultat est le suivant : le temps de calcul est passé d'une seconde par image à 20 ms... un gain de 50000% mais faut-il encore avoir le temps... temps, argent et tout ça

[Anozer]

Peut-être que je m'inquiète pour rien.
Mais je trouve quand même inquiétant le fait qu'il ne soit toujours pas "naturel" d'évoquer les questions environnementales liées aux découvertes. Quand l'humanité comprendra-t-elle que les ressources naturelles de la terre ne sont pas disponibles en quantité infinie ad vitam eternam ? Et que pour nombre d'entre elles l'humanité vit "à crédit", crédit que devront "payer" les générations futures ?

Je suis plutôt d'accord avec toi. La fabrication de matériel/composant électronique a toujours été liée à l'exploitation des hommes et de l’environnement. Mais c'est un problème très politique, c'est à dire de société. Et ici, c'est un papier de recherche scientifique publique qui se concentre sur l'aspect technique de la microélectronique et des matériaux. Ce n'est donc l'objectif. Je ne sais pas si ça devrait.

[marc_os]

Ouah, tu fais le pont ?
Pour commencer, on parle d'une utilisation pour fabriquer des processeurs, et même seulement les transistors, soit quelques nanogrammes par CPU à tout casser. Donc, on a de quoi voir venir s'il en faut quelques grammes ou même quelques dizaines de grammes pour produire des millions de processeurs.
Ensuite, on en reparlera le jour où les puces Ax seront aussi produites ainsi. Tu cesseras d'acheter des produits Apple pour autant ?

Vivi c'est ça, ne nous posons surtout pas de questions, les politiques et les sociétés privées à but exclusivement lucratif qui rappellent encore et encore qu'elles ne font pas du mécénat, surtout pas, et appliquons la politique de l'autruche et taclons les emmerdeurs à coup d'attaques ad hominem pour changer, mais auxquelles je ne te ferai pas le plaisir de répondre.

Pour info, la microélectronique c'est un beau mix de physique et de chimie faisant appel à des produits pas toxiques du tout, et ce n'est pas parce qu'on a au final seulement quelques "nanogrammes" de zirconium dans un CPU qu'il n'aura fallu extraire que quelques microgrammes de minerai pour les obtenir !
Enfin bref, t'as raison, « après moi le déluge, rien à battre de l'environnement et des autres pourvu que j'en tire bénéfice ».

Ce message a été modifié par marc_os - 14 Aug 2017, 13:10.

[linus]

Si on commençait par réécrire les systèmes d'exploitation en codant proprement et si possible directement en assembleur, on gagnerait pas mal de puissance machine. Idem pour les applications.
Regardez ce que l'on arrivait à faire avec un Amstrad CPC et son Z80 à 4MHz ou avec l'Apple II et son 6502 à 1 MHz.

A l'époque des PowerPC, démonstrations à l'appui, il était prouvé que, contrairement au 68000 pour lequel un bon programmeur battait aisément les compilateurs, la programmation en assembleur d'un PPC était à coup sûr plus lente que l'assembleur produit par les compilateurs. Cela tenait à la complexité introduit par le RISC et la nécessité de consulteur des tables et ... j'ai oublié.
Donc l'assembleur n'est sans doute plus du tout la panacée que tu sembles croire.

[aka_mgr]

Quand les CPU arriveront à leur limite, les développeurs seront alors bien obligés de revoir leurs méthodes et outils. Il y a bien trop de couches empilées, de langages différents...Et si c'est l'optimisation est trop complexe parce que les logiciels sont complexes, c'est probablement qu'il faut peut-être faire des logiciels plus simples, non ?

Il y a énormément de gâchis du temps de développement. On n'a pas besoin de forker à tout va sur GitHub. Il suffit de contribuer sur le logiciel qui va bien pour le rendre encore meilleur et surtout plus efficace. Regardez le nombre de distributions linux qui sont créées chaque année... pourquoi se donner tant de mal ? Pour laisser tomber l'année suivante ?
Je trouve pourtant gratifiant d'optimiser un traitement de masse sur une base de données qui prennait 20 heures pour le passer à 30 minutes avec une réécriture de l'algo, quelques structures en mémoire et quelques bons index...

Finalement je suis très impatient que les CPU arrivent à leur limites. On va enfin voir arriver de vraies améliorations au niveau du logiciel !

[marc_os]

[...]
Je suis plutôt d'accord avec toi. La fabrication de matériel/composant électronique a toujours été liée à l'exploitation des hommes et de l’environnement. Mais c'est un problème très politique, c'est à dire de société. Et ici, c'est un papier de recherche scientifique publique qui se concentre sur l'aspect technique de la microélectronique et des matériaux. Ce n'est donc l'objectif. Je ne sais pas si ça devrait.

Pour info, Einstein ne s'est pas contenté d'être un génie, il s'est aussi exprimé contre la bombe nucléaire, déclarant que sa Lettre au Président Roosevelt en 1939 était une erreur.

Après la guerre, Einstein plaide en faveur du désarmement international mondial.
Avant sa mort, Einstein confesse à Linus Pauling : « J’ai fait une grande erreur dans ma vie, quand j’ai signé cette lettre. »

Ce message a été modifié par marc_os - 14 Aug 2017, 13:20.

[nicogala]

Souhaitons pour eux et pour l'industrie des processeurs que cela soit rapide car les chercheurs et ingénieurs spécialisés dans ce domaine commencent à ne plus savoir quoi faire pour reculer la barrière qui obscurcit leur horizon

Aïe...

Et... ça serait grave s'il y avait une "pause" de mettons une décennie ?
Le Monde s'arrêterait, le choléra se répandrait, les oiseaux se tairaient ?

Je me demande si ça aurait pas fait plus de bien que de mal que d'être confrontés à une stagnation d'une certaine durée, obligeant à développer d'autres solutions (voire se rendre compte que la fuite en avant n'est peut-être pas une fin en soi si globale et si vertueuse) comme lors du choc pétrolier de 73 par ex.

[otto87]

Je suis plutôt d'accord avec toi. La fabrication de matériel/composant électronique a toujours été liée à l'exploitation des hommes et de l’environnement. Mais c'est un problème très politique, c'est à dire de société. Et ici, c'est un papier de recherche scientifique publique qui se concentre sur l'aspect technique de la microélectronique et des matériaux. Ce n'est donc l'objectif. Je ne sais pas si ça devrait.

c'est pas grave le zirconium, c'est chez les pauvres qu'on l'exploite comme au sénégal avec je cite :

Néanmoins, cette décision du Sénégal « ne profite en rien aux populations qui risquent d’être la proie des maladies infectieuses dues à la pollution qu’entraîne l’extraction du zircon» a-t-il regretté. Selon toujours l’expert, ce zircon «contient des traces de thorium et d’uranium radioactifs, et les villages ciblés sont Diogo, Mboro, Fass Boye, Lompoul, Darou Khoudouss et Diokoul Diawrigne».

[iAPX]

Pas si simple de supprimer des morceaux, il faut enlever, simplifier, changer les logiques de connexion. Refactoring de grande envergure. Sans doute réécrire certaines parties trop gourmandes.
Réécrire l’assembleur.

L’optimisation c’est exactement ça. Simplifier, alléger...

+1 c'est exactement ça, aller à l'essentiel, revoir les interfaces, voire où elles sont situées dans un système, prendre des raccourcis, comme David Vincent

Avec le gâchis de cycles CPU que je vois aujourd'hui, il y a une marge de progression gigantesque et elle est coté logiciel, la balance revint en arrière, par rapport aux années 90, où j'ai vécu un abandon du craftmanship software pour passer à des modèles d'exécution et des frameworks de plus en plus lourds (et inefficaces), grâce au doublement des performances quasiment aux deux ans!

Et je suis très heureux de l'arrivée du mur

Ce message a été modifié par iAPX - 14 Aug 2017, 14:31.

[Alucard314159265]

Sans remplaçant pour prendre le relais, les CPU à base de silicium ont de beaux jours devant eux.
Qu'ils progressent ou pas n'y changera rien.

Ce message a été modifié par Alucard314159265 - 14 Aug 2017, 14:18.

[kwak-kwak]

Je ne suis pas convaincu qu'une optimisation Windows / Mac OS puisse accélérer le traitement de calculs lourds (genre accélérer significativement de la compression x264, du traitement d'image sous Photoshop, etc ... ).
Quand à optimiser les suites de logiciels bureautiques, la question ne se pose pas, ce n'est pas nécessaire : les processeurs actuels sont largement capable de faire fonctionner simultanément une suite bureautique et l'OS qui les supporte. (J'ai PC avec un core 2 duo à 3GHz de 2008 sous Windows 10 qui fonctionne à merveille pour cet usage). Les optimiser serait donc une perte de temps humain totale : optimiser un truc qui fonctionne déjà très bien sur de l'électronique vieille de 10 ans est un non sens absolu.

Et quand c'est nécessaire d'optimiser un OS, on sait déjà faire aussi : que ce soit par le fait d'une distribution Unix spécifique (par exemple conçu pour le calcul intensif) ou via un système embarqué conçu spécifiquement pour la machine.

On peut aussi prendre le problème à l'inverse et optimiser des puces voire des machines entières pour certaines tâches spécifiques... Cela dit on peut optimiser autant que souhaité, faire de la compression 4K, des simulations d'écoulement de fluide, de la crypto et autre, ça prendra toujours beaucoup de ressources informatiques.

L'optimisation est un faux débat : on optimise quand c'est nécessaire... et rentable.

[otto87]

Je ne suis pas convaincu qu'une optimisation Windows / Mac OS puisse accélérer le traitement de calculs lourds (genre accélérer significativement de la compression x264, du traitement d'image sous Photoshop, etc ... ).
Quand à optimiser les suites de logiciels bureautiques, la question ne se pose pas, ce n'est pas nécessaire : les processeurs actuels sont largement capable de faire fonctionner simultanément une suite bureautique et l'OS qui les supporte. (J'ai PC avec un core 2 duo à 3GHz de 2008 sous Windows 10 qui fonctionne à merveille pour cet usage). Les optimiser serait donc une perte de temps humain totale : optimiser un truc qui fonctionne déjà très bien sur de l'électronique vieille de 10 ans est un non sens absolu.

Et quand c'est nécessaire d'optimiser un OS, on sait déjà faire aussi : que ce soit par le fait d'une distribution Unix spécifique (par exemple conçu pour le calcul intensif) ou via un système embarqué conçu spécifiquement pour la machine.

On peut aussi prendre le problème à l'inverse et optimiser des puces voire des machines entières pour certaines tâches spécifiques... Cela dit on peut optimiser autant que souhaité, faire de la compression 4K, des simulations d'écoulement de fluide, de la crypto et autre, ça prendra toujours beaucoup de ressources informatiques.

L'optimisation est un faux débat : on optimise quand c'est nécessaire... et rentable.

Et bien compare la suite office sur mac et sous windows
Et ne parlons pas des performance 3D sous mac face a windows/linux!

Ce message a été modifié par otto87 - 14 Aug 2017, 15:41.

[kwak-kwak]

Et bien compare la suite office sur mac et sous windows
Et ne parlons pas des performance 3D sous mac face a windows/linux!

Ça fonctionne très bien sous Windows sur du matériel vieux de 10 ans... Si ça ne fonctionne pas avec un Mac récent, reste à vous d'utiliser un OS adapté à votre usage bureautique et 3D.

Pour la 3D, la question de "l'optimisation", n'est pas vraiment : il ne s'agit pas de code à alléger dans les pilotes des cartes graphiques, mais plutôt de code à ajouter pour utiliser des fonctions spécifiques aux cartes, et donc de savoir utiliser l'existant. (Après il est fort probable que ce ne soit pas rentable de faire des pilotes graphiques corrects sur Mac)

Maintenant si Office 20** vous fait saturer un CPU récent sous Mac, ce n'est ici plus une question d'optimisation, mais de débogage.

Ce message a été modifié par kwak-kwak - 14 Aug 2017, 15:58.

[otto87]

Maintenant si Office 20** vous fait saturer un CPU récent sous Mac, ce n'est ici plus une question d'optimisation, mais de débogage.

Quel écrin de mauvaise foi!