36 votes

Quand le parallélisme d'Erlang surmonte-t-il ses faiblesses en informatique numérique?

Avec tout le battage médiatique autour de l'informatique parallèle dernièrement, j'ai beaucoup réfléchi sur le parallélisme, les calculs, les clusters, etc...

J'ai commencé à lire Vous Apprendre Quelques Erlang. Comme plus de gens sont à l'apprentissage (moi y compris), Erlang poignées de la simultanéité dans un très impressionnant, élégant.

Ensuite, l'auteur affirme que Erlang est pas l'idéal pour de nombreux calculs. Je peux comprendre qu'une langue comme Erlang serait plus lent que le C, le modèle de la simultanéité semble parfaitement adapté à des choses comme le traitement d'image ou de multiplication de matrice, même si l'auteur dit spécifiquement de ses pas.

Est-il vraiment si mauvais? Est-il un point de basculement où Erlang est la force surpasse sa vitesse locale de la faiblesse? Sont/quelles sont les mesures prises pour faire face à la vitesse?

Pour être clair: je n'essaie pas de lancer un débat, je veux juste savoir.

47voto

Warren Young Points 16324

C'est une erreur de penser de parallélisme que seulement environ raw de nombreux calculs de puissance. Erlang est plus proche de la façon dont un cluster ordinateur fonctionne que, disons, un GPU classique ou d'un superordinateur.

Dans les Gpu modernes et vieux style de supercalculateurs, la performance est tout au sujet de vectorisé arithmétique, à des fins spéciales de calcul de matériel, à faible latence et la communication entre les unités de traitement. Parce que la communication de la latence est faible, et chaque unité de calcul est très rapide, l'idéal modèle d'utilisation est à la charge de la machine RAM avec des données et à les traiter tous à la fois. Ce traitement peut impliquer beaucoup de transmission de données entre les nœuds, comme il arrive dans le traitement de l'image ou de la 3D, là où il y a beaucoup de CPU des tâches à faire pour transformer les données de formulaire de saisie pour le format de sortie. Ce type de machine est un mauvais choix quand vous avez fréquemment à aller vers un disque réseau, ou certains autres lente canal d'e/S pour les données. Cela tourne au ralenti au moins un cher, processeur spécialisé, et probablement aussi étouffe les données pipeline de traitement si rien d'autre ne se fait, soit.

Si votre programme nécessite une utilisation intensive de la lenteur de canaux I/O, un meilleur type de machine est avec beaucoup de bon marché des processeurs indépendants, comme une grappe. Vous pouvez exécuter Erlang sur une seule machine, dans ce cas, vous obtenez quelque chose comme un cluster à l'intérieur de cette machine, ou vous pouvez facilement exécuter sur un matériel réel de cluster, dans ce cas, vous avez un groupe de clusters. Ici, la communication surcharge encore tourne au ralenti des unités de traitement, mais parce que vous avez de nombreuses unités de traitement en cours d'exécution sur chaque bit de matériel informatique, Erlang peut passer à l'un des autres processus instantanément. S'il arrive que l'ensemble de la machine est assis là à attendre sur les I/O, vous avez toujours les autres nœuds du matériel du cluster qui peuvent fonctionner indépendamment. Ce modèle se décompose lors de la communication de la surcharge est si élevé que chaque noeud est en attente sur une autre nœud, ou I/O, dans ce cas, vous avez besoin rapidement d'e/S ou plus de nœuds, qui Erlang naturellement prend avantage de la situation.

La Communication et les systèmes de contrôle sont les applications idéales de Erlang, car chaque individu tâche de traitement ne prend que peu de CPU et seulement de temps en temps besoin de communiquer avec les autres nœuds de traitement. La plupart du temps, chaque processus fonctionne de manière indépendante, chacun prenant une petite fraction de la puissance du PROCESSEUR. La chose la plus importante ici est la possibilité de gérer plusieurs milliers de ces efficacement.

Le cas classique où vous devez absolument classique supercalculateur est la prévision du temps. Ici, vous divisez l'atmosphère jusqu'en cubes et faire de la physique, des simulations pour savoir ce qui se passe dans chaque cube, mais vous ne pouvez pas utiliser un cluster parce que l'air se déplace entre chaque cube, de sorte que chaque cube est en constante communication avec ses 6 voisins adjacents. (L'Air ne passe pas par les bords ou les coins d'un cube, étant infiniment fine, afin de ne pas en parler à l'autre 20 voisins cubes.) L'exécuter sur un cluster, de savoir si l'exécution Erlang ou un autre système, et il devient instantanément I/O bound.

12voto

mwt Points 382

Y a-t-il un point de basculement où la force d'Erlang surmonte sa faiblesse de vitesse locale?

Eh bien, bien sûr. Par exemple, lorsque vous essayez de trouver la médiane d'un billion de nombres :):

http://matpalm.com/median/question.html

Juste avant de poster, j'ai remarqué que c'était le numéro 1 sur erlang.reddit.com.

10voto

jalf Points 142628

Presque n'importe quelle langue peut être parallélisée. Dans certaines langues, c'est simple, dans d'autres, c'est une douleur dans le cul, mais il peut être fait. Si vous voulez exécuter un programme C++ à travers 8000 CPU dans une grille, allez de l'avant! Vous pouvez le faire. Il a été fait avant.

Erlang n'est pas faire tout ce qui est impossible dans d'autres langues. Si un seul PROCESSEUR exécutant un Erlang programme est moins efficace que le même PROCESSEUR de l'exécution d'un programme C++, puis deux cent UC de course à Erlang sera également plus lent que deux cents CPU est en cours d'exécution C++.

Ce Erlang ne faire est de rendre ce type de parallélisme est facile de travailler avec. Il enregistre le temps du développeur et de réduire les risques de bugs.

Donc je vais dire non, il n'y a pas de point de basculement où Erlang du parallélisme permet de surpasser une autre langue numérique d'un nombre croquant de la force.

Où Erlang scores est en le rendant plus facile de faire évoluer et de le faire correctement. Mais il peut encore être fait dans d'autres langues qui sont de mieux en mieux arithmétique, si vous êtes prêt à payer le supplément de temps de développement.

Et bien sûr, n'oublions pas le bon vieux point que les langues n'ont pas une vitesse. Suffisamment bon Erlang compilateur donnerait parfaitement un code optimal. Suffisamment mauvais compilateur C rendement de code qui s'exécute plus lentement que n'importe quoi d'autre.

6voto

Christian Points 7253

Il y a une pression pour faire Erlang exécuter le code numérique est plus rapide. Le HiPe compilateur compile en code natif au lieu de la POUTRE du bytecode par exemple, et il a probablement le plus efficace d'optimisation du code, sur les points où il est possible d'éviter la boxe. Ceci est très bénéfique pour floating point de code, car il peut stocker des valeurs directement dans les registres FPU.

Pour la majorité d'Erlang d'utilisation, Erlang est beaucoup rapide comme il est. Ils utilisent Erlang pour écrire toujours les systèmes de contrôle où le plus important de mesure de la vitesse qui compte, c'est le faible temps de latence des réponses. Les performances sous charge a tendance à être IO-lié. Ces utilisateurs ont tendance à rester loin de la Hype, car il n'est pas aussi flexible/malléable dans le débogage des systèmes live.

Maintenant que les serveurs avec 128 go de RAM ne sont pas si rare, et il n'y a pas de raison qu'ils vont obtenir encore plus de mémoire, certains IO-des problèmes liés à la pourrait passer à être un peu en CPU. Qui pourrait être un pilote.

Vous devez suivre HiPe pour le développement.


Vos exemples de manipulations d'images et la matrice de multiplications me paraissent comme de très mauvais matchs pour Erlang bien. Ceux sont des exemples qui bénéficient de vecteur/SIMD opérations. Erlang n'est pas bonne à parallellism (où l'on fait la même chose à plusieurs valeurs à la fois).

Processus Erlang sont MIMD, de multiples instructions données multiples. Erlang fait beaucoup de ramification derrière le filtrage et boucles récursives. Qui tue CPU instruction de traitement en pipeline.

Le meilleur de l'architecture et fortement parallellised problèmes sont le Gpu. Pour la programmation des Gpu dans un langage fonctionnel, je vois le meilleur potentiel en utilisant Haskell pour la création de programmes en les ciblant. Un GPU est fondamentalement une pure fonction de données d'entrée en données de sortie. Voir la Lave projet en Haskell pour la création de circuits FPGA, si il est possible de créer des circuits si proprement en Haskell, il ne peut pas être plus difficile de créer des données de programme pour les Gpu.

La Cellule architecture est très agréable pour vectorizable problèmes.

1voto

Mike Dunlavey Points 25419

Je pense que le besoin plus large est de souligner que le parallélisme n'est pas nécessairement ni même typiquement une question de vitesse.

Il s'agit de savoir comment exprimer des algorithmes ou des programmes dans lesquels la séquence d'activités est partiellement ordonnée.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X