Les algorithmes dépendent-ils des architectures informatiques?

J'ai lu quelque part (j'ai oublié de quel livre il s'agit) que les algorithmes sont indépendants des architectures informatiques. Certains disent même que les algorithmes sont eux-mêmes du calcul (des machines?)?

D'un autre côté, les livres sur la programmation parallèle ont des chapitres sur les algorithmes parallèles. Il semble que les algorithmes parallèles dépendent d'architectures parallèles?

Je pense que je manque quelques grandes photos? Merci.

Les algorithmes sont la série d'étapes prises pour résoudre un problème particulier. La recette pour résoudre le problème, si vous voulez. Les «programmes» font les mêmes choses, bien sûr; nous utilisons "algorithme" pour suggérer des recettes "généralisées" ou "généralement applicables" qui sont indépendantes des conceptions de machines spécifiques, des langages de programmation, etc.

Les algorithmes sont censés être généraux, mais ils peuvent toujours dépendre de la présence de certaines fonctionnalités. «Les algorithmes simultanés», par exemple, peuvent dépendre de la présence d'un mécanisme permettant à différents programmes de s'exécuter simultanément. Les «algorithmes distribués» peuvent dépendre de la présence de plusieurs systèmes dans un groupe coopérant et d'un réseau ou d'un autre schéma de communication entre eux. De même, les «algorithmes parallèles» sont souvent ceux conçus pour s'exécuter lorsque vous disposez de plusieurs unités de traitement - potentiellement plusieurs, de nombreuses unités de traitement et le type d'installations de communication qui sont courantes lorsque vous disposez de grands ensembles d'unités de traitement. Vous pouvez peut-être exécuter un "algorithme parallèle" même si vous n'avez qu'un seul ordinateur ou un seul processeur - mais ce n'est pas très intéressant dans la façon dont les ingénieurs du trafic ne sont pas '

Les algorithmes sont indépendants de l'architecture informatique. En effet, les algorithmes définissent une série de processus qui résout un problème. Quelles que soient les architectures, les algorithmes de tri seront toujours triés. Il ne rendrait pas soudainement des dessins 3D sur certaines architectures.

Si vous y réfléchissez, c'est en fait intuitif. Google Chrome (qui n'est qu'un ensemble d'algorithmes) est un navigateur Web lorsqu'il est compilé pour n'importe quelle architecture. Il ne deviendrait pas soudainement un pilote de périphérique sur certaines architectures.

Mais la vitesse d'exécution des algorithmes dépend des architectures. Et certains algorithmes fonctionnent plus rapidement que d'autres en fonction des architectures.

Si vous y réfléchissez, c'est aussi réellement intuitif. Étant donné un algorithme, il est toujours possible pour le concepteur de matériel de concevoir une architecture qui accélère spécifiquement cet algorithme. C'est une des raisons pour lesquelles il y a des choses comme les cartes graphiques accélérées 3D et les accélérateurs de mineur Bitcoin.

Lorsque les gens parlent d'algorithmes parallèles, ils parlent d'une famille d'algorithmes qui peuvent fonctionner plus rapidement sur des architectures parallèles. Il existe de nombreux algorithmes qui ne sont pas améliorés par des architectures parallèles. L'identification de nouveaux algorithmes pour le même problème qui fonctionnent bien en parallèle est donc un domaine de recherche actif.

Mais ces algorithmes font toujours les mêmes choses. Les architectures ne changent pas ce qu'elles font.

"Il semble que les algorithmes parallèles dépendent d'architectures parallèles?"

À mon avis, la réponse est simplement: non. Général je n'obtiens que les propriétés

• parallélisme
• taille des mots (limites de ressources implicites)

quand on pense à l'architecture matérielle.

En vous référant au parallélisme, vous pouvez faire en sorte que tout algorithme parallèle soit calculé par lots et tout arc parallèle fonctionner en série, de sorte que l'algorithme ne dépend pas de cela. La taille des mots peut être un problème pour la stabilité numérique mais pas pour l'algorithme lui-même. Les limites de ressources comme 64 bits ne peuvent décrire que 2 ^ 64 nombres différents pourraient être un problème, mais de toute façon les éléments sont limités.

Bien sûr, il peut y avoir des algorithmes qui dépendent de certains jeux d'instructions étendus, mais au moins tout peut être décrit avec des mathématiques de base.

Par exemple, avec le calcul quantique, certaines valeurs Big-O peuvent changer et je dirais que

"les algorithmes sont indépendants des architectures informatiques"

n'est plus vrai.

Les algorithmes ne dépendent pas de l'architecture de l'ordinateur, mais l'efficacité de l'exécution d'un algorithme particulier dépend de l'architecture. Toutes les machines Turing Complete peuvent émuler n'importe quelle autre machine Turing Complete, bien que certaines machines soient meilleures que d'autres.

Ce que nous entendons par algorithmes simultanés, c'est que l'algorithme joue bien ou peut tirer parti de la concurrence dans la machine, peut-être parce qu'il nécessite moins de verrouillage qui aurait autrement été requis par des algorithmes qui ne sont pas spécifiquement conçus pour la machine simultanée ou peut-être parce que le L'algorithme utilise efficacement la division et la conquête pour utiliser toute la puissance de la machine. L'exécution de l'algorithme sur une machine non simultanée serait toujours possible mais pourrait ne pas être aussi efficace ou nécessiter un verrouillage supplémentaire pour fonctionner correctement.

Il existe également des algorithmes conçus pour tirer parti de la particularité d'une architecture particulière, comme les algorithmes compatibles avec le cache, qui optimisent la mise en cache. Ces algorithmes peuvent être moins efficaces sur les machines qui ne mettent pas en cache la façon dont l'algorithme le suppose.

En théorie, les algorithmes sont entièrement indépendants de l'architecture. Vous pouvez toujours émuler une architecture parallèle sur un système à tranche horaire unique. Vous pouvez raisonner sur les algorithmes sans architecture du tout. Le livre de Knuth utilise une architecture fictive.

En pratique, il existe des algorithmes qui tentent d'obtenir un meilleur temps d'exécution pour la même complexité "O" en optimisant l'utilisation du matériel de cache et des primitives de synchronisation.

Oui et non. Cela dépend des contraintes que vous souhaitez respecter et des conditions préalables nécessaires pour exécuter votre algorithme.

Idéalement, un algorithme est une recette abstraite qui définit étape par étape comment faire quelque chose. Les algorithmes ont été définis comme tels dans le but de reproductibilité, et d'automatisation ultérieure. Les algorithmes proviennent de lambda-calcul, vous pouvez donc facilement voir pourquoi ils sont créés de cette manière. Cette définition est la plus courante, mais les algorithmes modernes peuvent être non séquentiels (pas étape par étape, comme les algorithmes concurrents, ou logiques comme ceux utilisant l'unification), non linéaires (algorithmes stochastiques) ou tout simplement étranges (quantiques) algorithmes), mais je vais passer cela.

Ainsi, idéalement, un algorithme devrait être aussi abstrait que possible sans comptabiliser aucun matériel.

Mais, comme avec tout système, vous devez définir certains axiomes , non seulement pour obtenir un système cohérent, mais aussi pour gagner du temps. Par exemple, la plupart des algorithmes supposent, au moins implicitement, qu'ils sont définis sur une machine Von-Neumann. Si ce n'était pas le cas, ils devraient définir explicitement chaque partie du système sur laquelle ils doivent être exécutés (car cela est nécessaire pour reproduire la recette, c'est une sorte de condition préalable). De plus, les algorithmes s'appuient souvent sur des commandes courantes telles que write () sans les définir complètement.

Une autre raison pour laquelle les algorithmes ne sont pas si abstraits de l'architecture matérielle, c'est lorsque vous devez respecter certaines contraintes .

Supposons que vous travaillez sur des systèmes embarqués, alors vous ne pouvez probablement pas compter sur la même quantité de ressources que vous avez sur les postes de travail. L'une des ressources les plus restreintes est probablement la mémoire. Cependant, la plupart des algorithmes tendent à optimiser la complexité temporelle (vitesse d'exécution sur CPU), pas la complexité mémoire (quantité de mémoire nécessaire pour travailler sur les données). Pour ces systèmes, des algorithmes optimisés en mémoire ont été conçus où les algorithmes non optimisés en mémoire échoueraient ou fonctionneraient beaucoup plus lentement. En fait, les systèmes embarqués ne sont pas la seule cible des algorithmes efficaces en mémoire: par exemple, il existe des algorithmes sans cache qui adaptent leur traitement pour utiliser efficacement le cache CPU. Autre exemple: certains algorithmes d'apprentissage automatique pour les mégadonnées sont conçus pourapprentissage incrémentiel ou informatique hors cœur pour traiter une énorme quantité de données bien plus volumineuses que la mémoire disponible sur n'importe quel ordinateur, etc.

Il existe également des algorithmes qui n'optimisent pas une partie spécifique de l'ordinateur, mais une norme qui dépend de l'architecture matérielle. Par exemple, les données numériques qui nécessitent une précision sont stockées dans float ou double, qui sont par nature limitées en raison des limites matérielles. Le problème est que des calculs complexes peuvent conduire à des arrondis, et plus vous effectuez de calculs sur des nombres arrondis, plus vous dérivez. C'est ce qu'on appelle une interférence catastrophique . Certaines applications nécessitent une précision critique, même au prix d'une pire complexité. Pour ce type d'applications, des algorithmes qui optimisent leur calcul pour réduire ou supprimer les interférences catastrophiques ont été réalisés.

Ainsi, la conception d'un algorithme peut également être un compromis entre abstraction et contraintes.

En fin de compte, nous pouvons dire qu'un algorithme est aussi abstrait que sa cible et que ses besoins (architecturaux) préconditionnels . Plus l'objectif visé est précis, plus il s'appuiera probablement sur l'architecture matérielle.

Quelques mots clés associés qui pourraient vous intéresser:

• Localité de référence
• Optimisation de boucle
• Optimisation de l'imbrication de boucle
• Localité évolutive

Vous ne devez pas confondre un algorithme en général avec des algorithmes mathématiques ou informatiques. Si vous parlez d'algorithmes de calcul, oui, ils sont indépendants de l'architecture de la machine.

Définition de l'algorithme de Wikipedia:

En mathématiques et en informatique , un algorithme est un ensemble d'opérations pas à pas autonomes à effectuer. Il existe des algorithmes qui effectuent le calcul , le traitement des données et le raisonnement automatisé.

Cette définition est utilisée pour référencer certaines tâches de calcul ou de traitement de données fermées. En d'autres termes, des calculs qui peuvent être exécutés de manière abstraite sur Turing Machine . Cependant, récemment, il existe un concept en mathématiques appelé calcul interactif qui implique une communication d'entrée / sortie avec le monde extérieur pendant le calcul.

Dans une définition générale, l'algorithme n'est qu'une recette (séquence d'instructions). Je pense que vous ne pouvez pas penser à un algorithme sans connaître le jeu d'instructions ou les opérations que vous pouvez utiliser; Les opérations mathématiques concernent le calcul, puis un algorithme qui comprend une étape nommée `` chauffer le four '' n'est pas un algorithme mathématique mais vous pouvez le donner à un chef, car il sait comment l'exécuter.

Ensuite, vous pouvez créer une machine qui peut faire X, Y, Z ... chacune d'elles pourrait être utilisée dans votre algorithme comme instruction. Mais s'il s'agit uniquement de calcul fermé (en fait, de calculs numériques déterministes non interactifs à petite échelle), alors on peut prouver que votre machine est équivalente à Turing Machine . Mais si vous ciblez un autre type de calcul (valeurs continues ou calcul interactif [mais je ne suis pas sûr qu'il s'agisse vraiment d'un autre type de calcul]) ou même des tâches non informatiques, vous pouvez penser à des machines qui peuvent les exécuter.

Cette question et réponse est également intéressante pour obtenir une perspective plus large sur les algorithmes.

En général, les algorithmes sont conçus pour certains problèmes particuliers tout en minimisant une certaine mesure du «coût». Historiquement, de nombreux algorithmes ont été conçus en supposant que les coûts relatifs des opérations courantes seraient relativement similaires sur de nombreuses architectures, et donc certaines machines typiques exécuteraient un algorithme fonctionneraient mieux qu'un autre, puis sur la plupart des machines typiques, l'ancien algorithme, à pire, être légèrement inférieur à ce dernier. Au fil du temps, une telle hypothèse n'est plus aussi bonne qu'auparavant.

Par exemple, autrefois, le nombre de fois qu'un programme avait besoin de lire des choses de la mémoire était considéré comme plus important que les emplacements des choses à lire. Lire des choses qui étaient situées les unes à côté des autres en mémoire était un peu moins cher que de lire des choses qui étaient éloignées les unes des autres, mais pas outrageusement. Cependant, comme les vitesses du processeur principal ont augmenté à un rythme bien supérieur aux vitesses de la mémoire, l'importance de la séquence d'accès a considérablement augmenté. Il est possible qu'un programme exécute dix fois plus d'instructions qu'un autre et qu'il s'exécute toujours plus rapidement, si 95% des récupérations de mémoire de l'ancien programme génèrent des accès au cache L1 et une majorité des récupérations de mémoire de ce dernier programme génèrent des échecs de cache.

En outre, certains types d'algorithmes liés à la concurrence émettent diverses hypothèses sur le moment où les données écrites en mémoire par un cœur de processeur seront "vues" par d'autres cœurs. De nombreux processeurs peuvent lire et écrire de la mémoire de différentes manières, avec des coûts variables et des garanties de visibilité. Certains algorithmes fonctionneront très bien sur des architectures pouvant satisfaire "gratuitement" aux exigences de visibilité, mais mal sur d'autres où les instructions nécessaires à ces garanties sont coûteuses. En effet, sur certaines architectures, certains algorithmes liés à la concurrence ne pouvaient être garantis que s'ils fonctionnaient en limitant l'exécution à un seul cœur CPU partagé en temps (ce qui, bien sûr, irait à l'encontre de l'utilisation d'un algorithme simultané).

Beaucoup de réponses manquent du fait qu'un algorithme peut être défini en termes qui sont soit abstraits, soit en relation directe et littérale avec une architecture. Un algorithme doit être sans ambiguïté, mais il est toujours possible qu'il soit plus ou moins spécifique.

Un algorithme pour convertir une chaîne en majuscules peut être facilement décrit dans un pseudocode indépendant de l'architecture. Mais en même temps, rien ne vous empêche de décrire un algorithme pour convertir une chaîne en majuscules spécifiquement sur une architecture x86. Il suffit d'une tâche de devoirs d'assemblage x86. (Vous pouvez toujours le faire en pseudocode - juste un pseudocode relatif à cette architecture!) Le simple fait que le problème est spécifiquement lié à une telle opération sur une architecture x86 ne signifie pas que vous n'avez plus d'algorithme pour le résoudre.

Cela dépend du problème que l'algorithme est défini pour résoudre. L'algorithme est indépendant de l'architecture si le problème qu'il résout est indépendant de l'architecture (et en supposant que cela ne soit pas annulé par la façon dont l'algorithme est décrit ou assemblé). Le problème peut être soit théorique, soit un tableau noir, soit une architecture très spécifique. Dans ce dernier cas, l'algorithme, à son tour, se limiterait à travailler avec cette architecture.

Les algorithmes sont une séquence d'étapes. Ils ne dépendent pas de ce qui les exécute (ou non).

Cependant, la complexité temporelle d'un algorithme peut dépendre de ce qui l'exécute. C'est pourquoi l'analyse détaillée d'un algorithme nécessite un "modèle de calcul", tel qu'une machine à accès aléatoire .
Le fait que la mémoire soit ou non accessible au hasard affecte certainement la durée d'exécution de votre algorithme, et la plupart des algorithmes supposent que c'est le cas alors qu'en réalité la plupart des architectures ne remplissent pas cette condition.

Ils diffèrent selon le contexte différent des problèmes. L'algorithme est la collection d'étapes pour résoudre un problème. Le contexte de ce problème peut être théoriquement n'importe quoi. Par conséquent, l'algorithme de résolution du problème peut dépendre littéralement de tout ce que nous pouvons imaginer sur l'univers. Permettez-moi de clarifier avec un exemple. Imaginons qu'on vous confie une tâche,

Construisez un algorithme qui répartira les charges sur plusieurs cœurs lorsque le multicœur est disponible.

Pouvez-vous maintenant imaginer que votre algorithme dépendra de l'architecture ou non? Bien sûr que oui .