Récession mondiale sur la fin de la loi de Moore - page 7

 
Vladimir:

GPU = unité de traitement graphique (produite principalement par Nvidia)

CPU = unité centrale de traitement (fabriquée par Intel ou AMD)

Les deux sont des processeurs. Tu ne comprends pas ? Appelez le GPU une carte ou ce que vous voulez mais c'est un processeur avec 3000 cœurs si vous avez le dernier modèle. Si vous avez un ordinateur, c'est un GPU. Lisez dans votre documentation le modèle que vous avez et le nombre de cœurs qu'il possède.

CPU et GPU sont des CPU différents, je veux dire CPU.
 
Vladimir:

Pas de mélancolie, mais une peur de l'avenir, le mien et celui des autres...

Pourquoi cette peur ? Quel est le problème ?

Il n'y aura pas de nouveaux ordinateurs, et alors ? Tout sera comme avant et nous ne verrons pas un autre Windows avec une interface non plus transparente, mais brillante, qui dévore toutes les ressources nouvellement ajoutées.

 
Vladimir:

GPU = unité de traitement graphique (produite principalement par Nvidia)

CPU = unité centrale de traitement (fabriquée par Intel ou AMD)

Les deux sont des processeurs. Tu ne comprends pas ? Appelez le GPU une carte ou ce que vous voulez mais c'est un processeur avec 3000 cœurs si vous avez le dernier modèle. Si vous avez un ordinateur, c'est un GPU. Lisez dans votre documentation le modèle que vous avez et le nombre de cœurs qu'il possède.

En parlant de l'unité centrale. La carte peut être ceci, elle peut être une simple carte, et le CPU sera toujours là. Où sont les processeurs à 3000 cœurs ?
 
Dmitry Fedoseev:
La discussion porte sur l'unité centrale. Une carte peut être ceci, une simple carte peut être cela, et il y aura toujours un CPU. Où sont les processeurs à 3000 cœurs ?
Je suis également curieux de savoir ce qu'il en est.
 
Dmitry Fedoseev:
La discussion porte sur l'unité centrale. Une carte peut être ceci, une simple carte peut être cela, et il y aura toujours un CPU. Où sont les processeurs à 3000 cœurs ?
Je ne comprends pas le sens de l'argument. Vous avez fait valoir que les processeurs ont évolué pour avoir plus de cœurs. Je suis d'accord et j'ai donné l'exemple d'un GPU avec 3000 cœurs. Et vous voulez savoir pourquoi il n'existe pas de CPU avec le même nombre de cœurs, n'est-ce pas ? Et qu'est-ce que vous n'aimez pas dans les GPU ? L'unité centrale de traitement peut être identique ou différente. Si vous avez besoin de plusieurs cœurs, achetez un GPU correspondant et programmez dessus. Mais si vous n'avez pas besoin de beaucoup de cœurs, il est inutile d'en discuter. Mon point de vue est que le développement des processeurs sur la voie du multicore a commencé en 2004-2005. Il est donc peu probable que ce soit une nouveauté après la fin de la loi de Moore. Si vous n'avez pas besoin de cœurs maintenant, vous n'en aurez pas besoin non plus après 2020.
 
Vladimir:
Je ne comprends pas le sens de l'argument. Vous avez fait valoir que les processeurs ont évolué en augmentant le nombre de cœurs. Je suis d'accord et j'ai donné un exemple de GPU avec 3000 cœurs. Et vous voulez savoir pourquoi il n'y a pas de CPU avec le même nombre de cœurs, n'est-ce pas ? Et qu'est-ce que vous n'aimez pas dans les GPU ? L'unité centrale de traitement peut être identique ou différente. Si vous avez besoin de plusieurs cœurs, achetez un GPU correspondant et programmez dessus. Mais si vous n'avez pas besoin de beaucoup de cœurs, il est inutile d'en discuter. Mon point de vue est que le développement des processeurs sur la voie du multicore a commencé en 2004-2005. Il est donc peu probable que ce soit une nouveauté après la fin de la loi de Moore. Si vous n'avez pas besoin de cœurs maintenant, vous n'en aurez pas besoin non plus après 2020.
Ça me rappelle l'anecdote sur l'ablation des amygdales... ...avec un autogène... à travers un zp.
 
Dmitry Fedoseev:
Ça me rappelle l'anecdote sur l'ablation des amygdales... avec un autogénome... à travers un ZP.

Est-il plus facile d'écrire un programme pour des cœurs de CPU parallèles que pour un GPU ? Le problème est le même : le programmeur doit se creuser les méninges pour décider quelles parties d'un programme peuvent être mises en parallèle, écrire un code spécial de mise en parallèle, etc. La plupart des programmeurs ne souffrent pas et écrivent des programmes mono-cœur sans torsion. Quel est le problème ici : manque de cœurs ou programmes utilisant le multi-cœur ? Je pense que c'est la dernière. Même si je vous donne une unité centrale avec 3000 cœurs, vous écrirez toujours des programmes à un seul cœur puisqu'il n'y a pas de différence dans la difficulté d'écrire des programmes pour 3000 cœurs et pour 4 cœurs. Ce qu'il faut, c'est un nouveau compilateur capable de détecter automatiquement les morceaux de code qui peuvent être mis en parallèle. Mais là encore, les progrès réalisés dans la création d'un tel compilateur ne dépendent pas du matériel mais de la volonté des programmeurs d'écrire un tel compilateur. Tout au long de ce fil, j'affirme que la possibilité de créer du nouveau matériel après 2020 diminue en raison des progrès de la technologie des semi-conducteurs et de la réduction de la taille et de la consommation d'énergie des transistors. De nouveaux matériaux et transistors sont encore à l'horizon. Intel a essayé de créer la génération de processeurs Knight Hill sur la technologie 10nm en 2016 et a reporté cette génération à la fin 2017. Samsung aussi a des problèmes avec sa technologie 10nm pour ses processeurs d'application. Déjà à la taille de 10 nm, les transistors ne permettent qu'une faible réduction de la taille et de la puissance par rapport à la taille de 14 nm. La dissipation de la chaleur devient un gros problème. Un saut technologique est nécessaire. L'un des indicateurs de la technologie est le prix par transistor. Donc, ce prix baissait avant le 28nm, et après cela, il a commencé à augmenter de façon exponentielle. De nombreuses entreprises se sont arrêtées à 28 nm à cause du prix. Ainsi, le passage à la technologie 10 nm, puis à 7 nm et enfin à 5 nm s'accompagnera non seulement de problèmes de chaleur, mais aussi d'un prix élevé.

 
Maintenant, il n'y a pas de problème pour la mise en parallèle, mais seulement pour l'utilisation d'un CPU. En C#, cela se fait en 3 secondes. L'idée est plutôt qu'il n'est pas nécessaire d'avoir un grand nombre de cœurs. Un programme ordinaire, moyen, n'est pas un gros problème à paralléliser. Si nous utilisons plusieurs cœurs, le seul avantage sera de pouvoir exécuter de nombreux programmes différents, mais ce n'est pas vraiment nécessaire.
 
Vladimir:

Est-il plus facile d'écrire un programme pour des cœurs de CPU parallèles que pour un GPU ?

Il est vraiment difficile d'écrire des programmes efficaces sur les GPU.

En fait, il y a encore tout un domaine inexploité en termes d'interaction entre les appareils et entre les appareils et les humains.

Il y a le domaine des nuages, le fait d'y fourrer tout et tout le monde, la décentralisation...

Il y a le domaine des assistants intelligents et des dispositifs en général.

Il y a le domaine de la réalité augmentée et virtuelle.

En bref, en raison de la loi de Moore, il n'y aura pas de récession, mais une recherche de nouveaux modes de développement. Il y aura une récession pour une autre raison

 
Vladimir:

Est-il plus facile d'écrire un programme pour des cœurs de CPU parallèles que pour un GPU ? Le problème est le même : le programmeur doit se creuser les méninges pour décider quelles parties d'un programme peuvent être mises en parallèle, écrire un code spécial de mise en parallèle, etc. La plupart des programmeurs ne souffrent pas et écrivent des programmes mono-cœur sans torsion. Quel est le problème ici : manque de cœurs ou programmes utilisant le multi-cœur ? Je pense que c'est la dernière. Même si je vous donne une unité centrale avec 3000 cœurs, vous écrirez toujours des programmes à un seul cœur puisqu'il n'y a pas de différence dans la difficulté d'écrire des programmes pour 3000 cœurs et pour 4 cœurs. Ce qu'il faut, c'est un nouveau compilateur capable de détecter automatiquement les morceaux de code qui peuvent être mis en parallèle. Mais là encore, les progrès dans la création d'un tel compilateur ne dépendent pas du matériel mais de la volonté des programmeurs d'écrire ce compilateur.

R n'a pas les problèmes décrits.

1. Très probablement, il n'est pas nécessaire d'écrire des programmes pour les algorithmes complexes sur le plan informatique. Tout est écrit et si un algorithme complexe sur le plan informatique (par exemple, l'optimisation ou le boosting) admet le parallélisme, celui-ci est déjà mis en œuvre. Et vous n'avez pas besoin de le chercher quelque part. Un développeur part du contenu du problème et adapte l'outil à ce contenu, et tout est mis en œuvre dans l'outil au maximum. L'outil dispose d'un système d'aide très puissant destiné à rendre l'outil moins laborieux.

2. S'il vous est nécessaire, par exemple, d'exécuter des sections parallèles d'une boucle, il existe des outils de parallélisation. Pour décrire la syntaxe de ces constructions et les conditions de leur utilisation, il n'est pas nécessaire de perdre son temps.

3. Le programme peut charger non seulement le noyau de l'ordinateur donné, mais aussi les ordinateurs voisins. Et ce, sans aucun nuage, pour ainsi dire, de la part des ordinateurs disponibles.

Les problèmes que vous avez décrits sont dus au fait que vous partez du fer, passez par des langages algorithmiques universels et n'atteignez pas le problème. Si vous allez au contraire - du problème au choix de l'outil, vous ne devrez peut-être pas discuter du tout du matériel.

C'est pourquoi je répète la conclusion que j'ai tirée plus haut : tous ces gigahertz ont très peu de rapport avec l'efficacité d'exécution des programmes. Tout comme nous n'avons pas remarqué l'augmentation des gigahertz au cours des 15 dernières années, nous ne remarquerons pas que ces mêmes gigahertz ont cessé de croître.