[Index Software] Coin des développeurs :]

[Bubu]

Je voulais juste parler de l'hyper-threading : aujourd'hui chaque coeur d'un CPU peut gérer deux threads...
En théorie.
Dans la réalité, c'est beaucoup moins glorieux.
C'est efficace seulement pour des tâches parallèles qui ont de longues boucles de pause, d'attente.
Car si on envoie 2 tâches de calcul intensif sur un seul cœur, c'est l’hécatombe au niveau performances.
Car l'hyper-threading permet seulement d'avoir 2 suites d'instructions (2 unités de commande) en parallèle, mais au final calculées par une seule ALU.
Après ce n'est pas pour rien que l'on a développé cette architecture. C'est très performant pour les OS multi-tâches, c'est indéniable.

Mais les architectures multi-cœurs sont la seule véritable solution. Et les algorithmes associés. Qui dispatchent les calculs sur plusieurs cœurs.
C'est une grosse difficulté algorithmique. On rêverait tous d'avoir un seul cœur cadencé à 20 Ghz.
Sauf que c'est impossible.
On est limité par la vitesse de propagation du courant. Pourtant proche de la vitesse de la lumière.
La vitesse du courant pour passer d'un coin à l'autre d'un chipset (tout droit vers le haut, tout droit vers la gauche en ligne droite), pour passer au point diagonalement opposé est trop basse pour respecter les échéances pour des fréquences de plusieurs giga-hertz....
Donc on parallélise les calculs.

[Tugdual]

Je voulais juste parler de l'hyper-threading [...]

Il n'est pas exclus qu'à cause des failles matérielles mises en évidences ces derniers temps, l'hyper-threading puisse être abandonné à l'avenir...

[Tugdual]

Sur Developpez.com :

• La compilation à la volée (just-in-time) ne serait pas ergonomique...

[Bubu]

Je rêverais d'un langage pour lequel le compilateur serait capable de paralléliser un code séquentiel en code parallèle de manière transparente....
Il y a OCAM, mais le parallélisme doit être précisé de manière explicite. C'est plus simple à coder, mais la difficulté reste toujours au développeur de préciser s'il s'agit de code séquentiel ou parallèle.

[Bubu]

Je voulais juste parler de l'hyper-threading [...]

Il n'est pas exclus qu'à cause des failles matérielles mises en évidences ces derniers temps, l'hyper-threading puisse être abandonné à l'avenir...

Ça ne m étonne pas, l'hyper-threading est une supercherie.
Mais il faut bien le dire, c'est une bonne solution pour des tâches qui ont de longs délais de pause, comme pour un OS multi-tâches qui gère plusieurs interfaces utilisateurs à la fois.

[Tugdual]

Créer des applis sans coder :

• Fantasme ou réalité ?

[Bubu]

Créer des applis sans coder :

• Fantasme ou réalité ?

Je pense que c'est plutôt un fantasme qu'une réalité.
Lego Technic utilise des sortes de graphsets pour programmer sans coder.
Mais je pense que c'est une limite vraiment rapidement limitative.

Et, je pense qu'il est plus abordable de coder directement avec les APIs adéquates, que d'utiliser des subterfuges opaques, et finalement, plus difficiles que ce que sont ces interfaces.

Pour développer, il faut un minimum de background mathématique notamment. (En général le BCPE suffit), mais si on se penche sur les applis graphiques, un Bac +1 est recommandé.
Que cela soit de la 2D, ou 3D, il faut un minimum avoir des compétences dans la manipulation des endomorphismes, représentés par des matrices.
Et ce n'est pas compliqué à calculer. Vous savez additionner et multiplier les nombres (réels), les matrices n'ont pas de secrets pour vous.

[Rána]

Je voulais juste parler de l'hyper-threading [...]

Il n'est pas exclus qu'à cause des failles matérielles mises en évidences ces derniers temps, l'hyper-threading puisse être abandonné à l'avenir...

Ça ne m étonne pas, l'hyper-threading est une supercherie.
Mais il faut bien le dire, c'est une bonne solution pour des tâches qui ont de longs délais de pause, comme pour un OS multi-tâches qui gère plusieurs interfaces utilisateurs à la fois.

C'est pour les serveurs qui ont font tourner en parallèle de nombreux processus.
Cela permet de faire travailler tous les composants du processeurs :
- soit en alimentant le pipeline de calcul (le calcul de l'instruction précédent n'est pas terminé mais il est déjà possible de commencer le calcul de l'instruction suivante)
- soit en utilisant des unités différentes de calcul

Je trouve donc que le terme "supercherie" un peu excessif

[Bubu]

Il n'est pas exclus qu'à cause des failles matérielles mises en évidences ces derniers temps, l'hyper-threading puisse être abandonné à l'avenir...

Ça ne m étonne pas, l'hyper-threading est une supercherie.
Mais il faut bien le dire, c'est une bonne solution pour des tâches qui ont de longs délais de pause, comme pour un OS multi-tâches qui gère plusieurs interfaces utilisateurs à la fois.

C'est pour les serveurs qui ont font tourner en parallèle de nombreux processus.
Cela permet de faire travailler tous les composants du processeurs :
- soit en alimentant le pipeline de calcul (le calcul de l'instruction précédent n'est pas terminé mais il est déjà possible de commencer le calcul de l'instruction suivante)
- soit en utilisant des unités différentes de calcul

Je trouve donc que le terme "supercherie" un peu excessif

Oui, sans aucun doute.
Ce que j'ai voulu dire, c'est que pour l'hyper-threading, on envoit 2 threads par cœurs.
Sauf que chaque cœur n'a qu'une seule UAL (unité arithmétique et logique), mais 2 unités de contrôle .
Donc on ne peut pas dire honnêtement qu'un cœur gère 2 threads.
Cependant, c'est très efficace pour bon nombre de tâches, de processus, qui utilisent l'instruction NOP à volonté.

[Rána]

Je trouve donc que le terme "supercherie" un peu excessif

Oui, sans aucun doute.
Ce que j'ai voulu dire, c'est que pour l'hyper-threading, on envoit 2 threads par cœurs.
Sauf que chaque cœur n'a qu'une seule UAL (unité arithmétique et logique), mais 2 unités de contrôle .
Donc on ne peut pas dire honnêtement qu'un cœur gère 2 threads.
Cependant, c'est très efficace pour bon nombre de tâches, de processus, qui utilisent l'instruction NOP à volonté.

L'hyperthreading optimise l'alimentation des pipelines. Il ne s'agit pas de profiter de processus inactifs (qui sont de toute façon mis en attente par le système d'exploitation) mais d'exécuter simultanément plusieurs instructions.

Au niveau du processeur, les instructions sont divisés en plusieurs étapes successives. Quand la première étape est effectuée, pendant que la seconde étape est effectuée, la première étape peut être effectué pour une autre instruction (même si la première instruction est toujours en cours) et ainsi de suite.
La profondeur du pipeline peut atteindre plusieurs dizaines d'étages.

[Tugdual]

On parlait il y a peu de temps du développement "sans code" :

• Un nouveau moteur de jeux vidéo, en alpha, ne nécessitant pas de code...

[Bubu]

Je trouve donc que le terme "supercherie" un peu excessif

Oui, sans aucun doute.
Ce que j'ai voulu dire, c'est que pour l'hyper-threading, on envoit 2 threads par cœurs.
Sauf que chaque cœur n'a qu'une seule UAL (unité arithmétique et logique), mais 2 unités de contrôle .
Donc on ne peut pas dire honnêtement qu'un cœur gère 2 threads.
Cependant, c'est très efficace pour bon nombre de tâches, de processus, qui utilisent l'instruction NOP à volonté.

L'hyperthreading optimise l'alimentation des pipelines. Il ne s'agit pas de profiter de processus inactifs (qui sont de toute façon mis en attente par le système d'exploitation) mais d'exécuter simultanément plusieurs instructions.

Au niveau du processeur, les instructions sont divisés en plusieurs étapes successives. Quand la première étape est effectuée, pendant que la seconde étape est effectuée, la première étape peut être effectué pour une autre instruction (même si la première instruction est toujours en cours) et ainsi de suite.
La profondeur du pipeline peut atteindre plusieurs dizaines d'étages.

C'est très juste, et donc je ne te contredirais pas.
Je sais bien que les CPUs modernes sont pipelinés. Jusqu’à une 20aine d'étages aujourd'hui. Même plus.
Cependant, il n'y a qu'une seule UAL par cœur, et pour des applications exigeantes en calcul comme les jeux, l'hyper-threading est inutile.

Pour des calculs intensifs, il vaut mieux dispatcher les calculs sur plusieurs cœurs et ne pas prendre en compte l'hyper-threading.
Sous Windows en C++, on peut assigner explicitement les tâches par coeur.
Mais en Java ce n'est pas possible.(On peut connaître le nombre de processeurs, mais c'est la machine virtuelle qui assigne les tâches aux coeurs).

Pour tout le monde :
C'est quoi un processeur pipeliné ?
Imaginez une usine de création de voiture.
Il y a plusieurs étapes. On n'attend pas qu'une voiture soit assemblée pour introduire la création d'une autre.
C'est la même chose.
Pour un processeur pipeliné, on exécute les instructions sans attendre que la précédente instruction soit gérée, finalement calculée.

C'est un concept plutôt génial car en gros on peut gérer presque une instruction par cycle d'horloge.

[Bubu]

Un algorithme simplissime, c'est l'addition avec retenues anticipées.
Pour calculer l'addition.
Et c'est génial.

En binaire :
0 + 0 = 0 (0 en retenue)
0 + 1 = 1 (0 en retenue)
1 + 0 = 1 (o en retenue)
1 + 1 = 0 (1 en retenue)
.

Pour ces unités de calcul, on calcule les 2 cas, avec et sans retenue. C'est le premier cycle.
Ensuite grâce à des multiplexeurs, on choisit le résultat conforme à la retenue. C'est le deuxième cycle.

Résultat : on peut calculer l'addition de deux entiers en 2 cycles, quelque soit leur taille.

(Sans cet algorithme, il faudrait autant de cycles que de bits...)

[Bubu]

En fait, concernant l'addition avec retenues anticipées, j'ai tellement simplifié qu'on n'y comprend plus rien.

Le premier cycle :
On calcule l'addition bit à bit, en binaire, mais dans les deux valeurs de retenue : 0 ou 1.
Donc le vrai tableau se compose plutôt de 2 colonnes de 3 valeurs de sorties : la valeur selon ou non une retenue, et la retenue.
Et on calcule l'addition en deux exemplaires, bit à bit, avec ou sans retenue. Donc on a deux résultats possibles par bit. Plus la retenue

Pour le deuxième cycle, on a les possibilités d'addition, et la valeur de la retenue. Il suffit de piocher la bonne addition selon le cas (avec ou sans retenue, "carry").
Grâce à des embranchements, on sélectionne le bon résultat via des multiplexeurs, guidés par les retenues.

Cet algorithme permet d'additionner des nombres entiers quelque soit leur taille en 2 cycles.
Si on utilise notre technique sur les nombres décimaux, il faut autant de cycles que de chiffres (digits). C'est un algorithme génial, l'addition par retenues anticipées. Mais impossible à utiliser pour les notations numériques différentes que le binaire.
On apprend cet algorithme en deuxième année d'info dans le cours intitulé "opérateurs de calcul".
En gros comment faire des calculs avec des transistors .
Ou de manière plus abstraite et moins pompeuse, avec des portes logiques.

[Tugdual]

Sur Developpez.com :

• Une IA de Microsoft différencie les bugs dans 99 % des cas...