Puissance des M1 et optimisation des applications

[hiwa]

Bonjour,

Je suis dans l'informatique et dans la programmation depuis le DOS, ça donne une idée de mon âge avancé 😉

J'ai développé principalement des didacticiels en Belgique, au temps des disquettes, des disque durs de 20 Mo, puis des cdrom. Sur PC, en Turbo Pascal, sous DOS, puis ensuite sous Windows. Je suis exclusivement sous MAC depuis 2013. Et je ne fais plus que du développement WEB.

Je me souviens avec nostalgie du temps de MS-DOS / Turbo Pascal, où, pour optimiser le développement, et accélérer l'affichage, j'utilisais des routines en assembleur. Puis l'augmentation de la puissance des PC a permis de se passer de ces routines de bas niveau (interdites ensuite par Windows).

Donc, l'augmentation de la puissance des machines a eu comme conséquence l'abandon de l'optimisation de la programmation ...

Ma question :

• Comme les nouveaux processeurs M1, puis M1 pro/max, puis M2 ... apportent un supplément de puissance fantastique par rapport aux processeurs Intel, ne risque-t-on pas d'avoir au niveau programmation un nivellement par le bas ... --> Je n'optimise pas mon code, car le processeur le fait pour moi ?
• Et donc, ne risque-t-on pas de se trouver avec un M1 "poussif" dans quelques années (avec l'évolution des logiciels), alors qu'aujourd'hui tout roule à la vitesse de l'éclair ?

Votre avis ?

Jean-Pol

[Mout]

Pour moi, sans aucun argument autre que ma petite cervelle, c'est le cas depuis une vingtaine d'années. 

Ya qu'à voir une chose toute bête : Les débits des réseaux en augmentation constante ont simplement permis au développeurs de se "lâcher" sur le code, sans optimisation, et on se retrouve avec des pages toujours plus lourdes à charger, et un Internet finalement jamais plus réactif que ca. Ce, depuis l'avènement de l'ADSL qui a effectivement mis un coup de fouet aux performances. Les pages internet de 2005 sur nos réseaux en VDSL et en fibre, c'est de l'instantanée. Les pages internet de 2021, c'est bien plus long à charger.

La nature a horreur du vide, c'est pareil dans l'informatique  puisque c'est puissant, rapide..., pourquoi m'embêter à faire de l'optimisation  

[hiwa]

Oui, c'est bien ce que je pensais ... Et ça contribue a l'obsolescence ... désespérant.

[Mout]

A la lointaine epoque de l'iPhone 5, Apple s'etait justement essayé à l'exercice de l'optimisation sur un iOS suppérieur qui, du coup, devenait plus (+) utilisable que l'iOS d'avant  comme quoi ^^

 

[Sethenès]

D'abord, augmentation "fantastique" ... il faut quand même raison garder. Au moment de la sortie, les perfs monocoeur de la plupart des Intel peinaient à s'approcher de 1600 au score de geekbench et le M1 a franchi la barre des 1700 pour s'établir vers 1750. Aujourd'hui les nouveaux processeurs d'Intel ont dépassé la barre des 1800 (pour les gros modèles déjà sortis).

De même en terme de puissance GPU, le M1 Max avoisine les 10 TFlops en FP32, ce qui est vraiment très bien mais une 3080, c'est 20 TFlops et encore avec de meilleure perf en FP16 car il semble que l'Apple M1 ne "scale" les perfs quand on passe en FP16.

De plus, Apple a renoncé aux instructions AVX d'Intel qui offrent d'intéressantes opportunités. Puisque tu as programmé en assembleur, le principe d'AVX est d'avoir un mot très très long (ex : 256 bits) structurés par exemple en 16 mots de 16 bits et en "une" instruction assembleur tu peux (par exemple) agir sur les 16 mots en même temps (ex : shl, décalage vers la gauche) ou encore opérer des opération bit à bit entre 2 "mots" de 256 bits. Par exemple, le calcul distribué de "repliage" des protéines n'est pas porté sur M1 pour cette absence.

Pour le reste, oui, clairement aujourd'hui les développeurs utilisent des frameworks de plus en plus éloignés du matériel et donc de moins en moins optimisés. Mais cela permet de développer des applications multiplateformes très facilement. Mais ces applis sont des gouffres à mémoire et à temps CPU.

Je serais très curieux de savoir lorsque qu'on code une division d'entier dans un tel programme, cb de vérification de non division par zéro sont effectuées en cascade. Je pars en gros de l'idée que chaque couche rajoute un test. Je ne dois avoir tout à fait raison, mais pas tout à fait tort non plus.

Ceci dit, le surcroit de performance est parfois utile. Si on dispose de correction orthographique en temps réel, c'est bien grâce à ces progrès.

[pehache]

Il y a 6 heures, hiwa a dit :

, j'utilisais des routines en assembleur. [...] (interdites ensuite par Windows).

What ?? Il est toujours "autorisé" de programmer en assembleur sous Windows...

 

Il y a 6 heures, Mout a dit :

Pour moi, sans aucun argument autre que ma petite cervelle, c'est le cas depuis une vingtaine d'années. 

Je plussoie. Les développeurs utilisent de plus en plus des briques logicielles haut niveau comme des boîtes noires.

[pehache]

il y a 15 minutes, Sethenès a dit :

De plus, Apple a renoncé aux instructions AVX d'Intel qui offrent d'intéressantes opportunités.

Par définition, les instructions vectorielles AVX font partie du jeu d'instruction x86, et forcément en passant à une architecture ARM il n'y a plus les instructions x86

Le jeu d'instructions ARM a un équivalent à AVX, qui s'appelle SVE : https://en.wikipedia.org/wiki/AArch64#Scalable_Vector_Extension_(SVE)

[Sethenès]

Je n'en disconviens pas mais la raison invoquée pour le non portage de folding@home sur les puces M1 est (à ce qu'on m'a dit, je n'ai pas vérifié) l'absence de cette technologie ou d'une concurrente.

[pehache]

il y a une heure, Sethenès a dit :

Je n'en disconviens pas mais la raison invoquée pour le non portage de folding@home sur les puces M1 est (à ce qu'on m'a dit, je n'ai pas vérifié) l'absence de cette technologie ou d'une concurrente.

Je suspecte plutôt des codes non portables faisant directement appel aux fonctions AVX au travers des API fournies par Intel. Ca pouvait paraître raisonnable alors que quasiment tous les ordis étaient basés sur du x86, mais quand on écrit non-portable on a toujours un risque de se faire rattraper par la patrouille.