[Index Software] Coin des développeurs :]

[Tugdual]

Question :

• Les programmeurs doivent-ils disposer d'un plan B avant leurs 40 ans ?

[Bubu]

Pour corriger, et recibler mon propos sur les GPUs.
On ne peut pas vraiment dire que leurs coeurs soient des processeurs.
Ils ont tous la même suite d'instructions, la même unité dont j'ai oublié le nom qui fournit le code de l'instruction à effectuer.
(Unité de contrôle je crois ? Je ne sais-plus )
Mais les unités de calcul des GPU comportent (et travaillent sur), des registres 128 bits. Et des palettes de matrices 4x4, de flottants 32 bits.
Elles ont des unités de calcul (ALU) phénoménales, on peut tout leur demander : + - / *, sinus cosinus racine carré exponentielle, logarithme, puissance (entre 2 flottants), etc etc.
Et elles font ces calculs sur des vecteurs. (Plusieurs valeurs (4) à la fois).
On peut aussi faire du calcul sur des flottants de 64 bits (double en C et C++) Mais que 2 par 2.

Ensuite des librairies comme Cuda et OpenCl ont permis de programmer pour des matrices et des vecteurs de taille quelconque, et de faire des merveilles.
Les réseaux neuronaux sont les parfaits candidats pour ces librairies. Il ne risque pas d'y avoir des tests divergents (il n'y a pas ce problème dans les calculs matriciels).
C'est pourquoi on utilise énormément les GPUs dans l'AI aujourd'hui.

Si on veut de nos jours faire du calcul matriciel intensif, c'est la meilleure solution.
Utiliser Cuda ou OpenCl.
Mais il semble exister des framework qui encapsulent encore mieux le processus. Programmables en Python.
Il y a un membre bcp plus qualifié que moi pour en parler.

Quand on compile un shader HLSL (DirectX) , on a le code en assembleur généré affiché en bonus. (En plus du code compilé sous forme de fichier binaire. Exécutable).
Cela est parfois indispensable pour optimiser son shader.
Car les shaders sont capricieux. Un seul mot de travers et on divise les performances par 10, si on l'avait codé autrement !
L'avantage des GPUs, c'est qu'ils ont tous le même jeu d'instructions. Même s'il s'enrichit avec les progrès, avec le temps.
Du coup un shader compilé est valable pour n'importe quel GPU.

J'avais parlé des tests incohérents (dont tous n'ont pas le même résultat), mais il y aussi les boucles.
Les boucles et les GPUs ne sont pas amis non plus. (Ils sont chiants les GPUs !)

Il faut préciser combien il y a d'itérations au max dans une boucle, via la directive [unroll x], où x est le nombre maximal d'itérations.
Et le compilateur déploie la boucle en une suite d'instructions, sans boucle.
Ce n'est pas obligatoire, mais si on ne le fait pas, on peut s'attendre à une baisse de performance phénoménale !
Pour la même raison que pour les tests incohérents : les unités de calculs ne sont plus synchrones et s'attendent les unes les autres avant de passer à la prochaine instruction....

Les GPUs sont une bénédiction pour le calcul parallèle, mais une malédiction pour le calcul séquentiel.
Et il ne faut pas grand-chose pour briser leur harmonie de calculs parallèles.


Autre chose, on pourrait se demander pourquoi les meilleurs GPUs ne sont cadencés qu'aux alentours de 1 GHz. Alors que les CPUs sont vers 5GHz.
Car ce qui compte, c'est le nombre d'unités de calcul, et pas l'horloge. C'est du calcul parallèle.
Quand on augmente sur la superficie de la puce le nombre d'unités de calcul, on progresse de manière quadratique. (au carré).
Si on progressait juste sur la cadence, cela serait linéaire.
Il vaut mieux passer de 4 à 9 unités de calculs que de doubler la fréquence d'horloge. (Exemple théorique).

[Tugdual]

Vu sur Developpez.com :

• Les informaticiens devraient prêter un équivalent du serment d'Hippocrate...

[lepton]

Fausse bonne idée...

Il choisit un terme informatique pour sa plaque d’immatriculation et sa vie devient un calvaire !

[Bubu]

Maintenant on ne parle plus de gpus, mais de gpgpus.(general purpose graphical processing unit)
Cette nouvelle generation de cartes graphiques sont prevues à la fois pour le calcul (matriciel) intensif, que pour le calcul graphique parallèle.
Pour l'ia, c'est une solution bon marché et parfaitement performante.
Qui reste aussi très puissante pour la 3d temps réel. (Pour les jeux mais non adapté pour le cinéma, qui utilise le ray tracing)

Ça peut sembler bizarre, mais il y a des gpgpus sans ports graphiques... De NVIDIA.
C'est destiné aux chercheurs qui sont spécialisés dans le calcul parallèle. Ils coûtent une fortune.

[Bubu]

Dans des vulgarisations un peu hâtives, on dit que le ray tracing(lancer de rayons) est une amélioration de la rasterisation.
C'est complètement faux, les 2 techniques n'ont rien à voir.

La rasterisation est utilisée dans les applications 3d temps réel car elles sont moins coûteuses.
Le lancer de rayon est utilisé pour les images où le photorealisme est la priorité. Comme pour le cinéma. Rarement, jamais en temps réel.

Les deux techniques sont opposées. Au niveau du pipeline graphique.

Pour la rasterisation, on part du pixel cible à coloriser, et on use d'approximations et de stratagèmes pour le faire. Ce qui peut s'avérer être très complexe, pour un résultat approximatif voire faux.

Pour le lancer de rayon, c'est tout l'inverse.
On lance un rayon partant de l'oeil et passant par un pixel de l'écran et on regarde où il atterrit.
Facile de savoir si on est dans l'ombre : on lance un rayon du point d'impact vers la lumière, et s'il y a un obstacle, on est dans l'obscurité.

Le lancer de rayon, une fois codé le calcul d'intersection, d'impact entre un rayon et une surface, est enfantin. C'est très intuitif.
Par contre ça coûte cher en performances.

(Imaginez, pour chaque pixel de l'écran, on lance plusieurs rayons le traversant pour calculer sa couleur. Et encore je suis gentil car on utilise de l'anti aliasing, et c'est pas un rayon lancé par pixel, mais 9 ou 16...)

[Siobhan]

Merci pour ces topos sur le calcul graphique Bubu, c'est très intéressant.

[Bubu]

Mettez-moi une perf de Valium si vous voulez que je me taise.
Obtenir une image grâce au ray-tracing... c'est un calvaire.
Cela peut aller du 1/4 d'heure à deux heures pour du simple HD. (Pas 4k, encore moins 8k, encore moins pour le cinéma).*
Après il y a des applications qui parviennent à utiliser du ray-tracing en temps réel avec un matos de fou, mais sur des formes géométriques.
NVidia utilise une technique hybride (rasterisation + ray tracing), mais loin d'être de nos jours utilisable dans la 3d temps réel.

Il ne reste que de 10 à 20 ans à la rasterisation, le ray tracing va vite finir par la remplacer. Mais on y est pas encore.

Gérer les ombres proprement et sans artifices, les réflexions, la réfraction (jusqu'à voir les couleurs de l'arc en ciel sur une bulle de savon, soit une réfraction dépendante des longueurs d'ondes de la lumière incidente), etc.
La rasterisation est inadaptée pour gérer la transparence. C'est feint. Le ray-tracing la gère très facilement. Pareil pour les réflexions (océan, carrosserie de voiture, etc), et c'est facile à implémenter.

Mais comme souvent, la frustration vient du fait que c'est, sauf exceptions, non gérable en temps réel. Les jeux : non. Le cinéma : oui.

Patience les gros et les grosses ! Parole de la brindille !

[Tugdual]

Il y a 28 ans :

• Linus Torvalds annonçait Linux...

[Bubu]

Il y a 28 ans :

• Linus Torvalds annonçait Linux...

Il y a Mac OS, et je suis plus concerné par Android, qui utilisent comme noyau Unix.

Sous Android, on utilise le système de fichier Unix, et l'ordonnanceur de tâches natif.
Evidemment, tout ce qui relève des interfaces graphiques et de la gestion haut niveau des applications est propriétaire (Google).

[Bubu]

Il y a un paradigme complètement bizarre dans les applis Android.
On ne peut pas décider de les fermer.
Dans les systèmes d'exploitations courants d'ordis, quand on ferme l'appli, le (ou les) processus sont shootés, après nettoyage des ressources.

C'est au moins exotique, mais quand on quitte une appli sous Android, elle n'est pas supprimée, elle se met en veille.
C'est l'effusion de sang sur les forums de développeurs : comment quitter une appli sous Android ?
La réponse : on ne peut pas et on ne doit même pas le vouloir.

(En fait c'est l'OS qui les shoote quand il est à cours de RAM, il met en veille le plus longtemps possible les appli avant de vraiment les shooter s'il n'a pas le choix. (Ressources insuffisantes) )
Comme dirait la grosse, c'est chelou...

[Tugdual]

Il y a un paradigme complètement bizarre dans les applis Android.
On ne peut pas décider de les fermer.

Vois-tu un intérêt à cette façon, de faire ?

[Bubu]

Il y a un paradigme complètement bizarre dans les applis Android.
On ne peut pas décider de les fermer.

Vois-tu un intérêt à cette façon, de faire ?

Bonsoir Tugdual !
Non, j'y vois pas d'intérêt.

Que l'appli soit en veille ou a relancer, ça prend le même temps.

[Tugdual]

Bon, le mystère persiste...

[Bubu]

une explication du cycle de vie d'une activité (fenêtre) Android

C'est en anglais, mais il y a un diagramme simplifié.
Tellement que la sortie du diagramme en est erronée : quand l'évènement OnDestroy() est appelé, l'activité n'est pas supprimée, mais signalée comme pouvant l'être à l'OS.
Et il le fait sans prévenir, donc il ne faut pas compter sur cet évènement pour supprimer ses ressources.

Perso, je charge mes ressources dans OnCreate() (et certaines dans OnResume() ) et les détruis dans OnStop() (et certaines dans OnPause()… )

Je ne vois pas l'intérêt d'un automate à états finis (finite states machine) si complexe (avec autant d'états différents) pour les activités. Création, Pause, Reprise, Destruction m'aurait semblé largement suffisant ….