Comme tu dis : d'un point de vue theorique si on ne prend pas en compte les interactions des langages. En effet, tes processeurs touchent a une memoire globale. D'ou des interactions entres tes differents automates. Cela se traduit assez facilement : il n'y a un seul langage quelques que soit le nombre de processeurs de ta machine (et on ne parle pas de connection entre ordinateurs via des cables reseaux). D'un point de vue theorique le produit de tes n automates est different de l'automate prennant en compte directement tous les processeurs d'un seul coup.
Certain vont se poser la question de pourquoi il peut y avoir des interactions entre les processeurs. La reponse suppose un petit bagage theorique sur le fonctionnement des systemes d'exploitations. Le systeme d'exploitation gere les processus des programmes. Ces processus sont un ensemble d'element tel que le programme source (le programme charge en memoire), la memoire utilise, mais egalement un certain nombre de threads. Ces threads s'ils sont geres par le processeur peuvent tourner de facon parallele sur des processeurs differents. Comme chacun sait, des threads peuvent avoir un commun une memoire partage. Voici une des interactions que peuvent avoir les processeurs.
Les automates a pile ne sont pas beaucoup plus compliques quel les FSM. Tu as des operations sur chaque etat qui push ou qui pop l'etat courant dans la pile (donc globale) de l'automate. De meme, les transitions doivent supporter des testes sur l'etat de la pile (Est-elle vide ? Quel est le dernier etat ? Quels sont les n derniers etats ?). Ainsi tu peux reconnaitre des langages du type anbn alors que tu ne pouvais pas avec des automates finis.
L'automates pour ce dernier exemple est construit facilement. On lit des a en pushant l'etat dans la pile. Puis on lit que des b en poppant la pile. On acceptera le mot si la pile est vide et qu'il n'y a plus de lettre a lire.
On ne parle alors pas d'automates finis au sens de la theorie (si tu nous donnes pas plus d'information). Pour information, un automate a une memoire mais bornee.
Sans parler de la lisibilité, on veut au minimum un outils qui
n'est pas à la ramasse niveau performance. Regarde le lien suivant
pour voir que Perl, pour les grosses expressions rationnelles, ne
sert pas à grand chose mise à part réchauffer ton logis :
[^] # Re: Quote
Posté par Vash . En réponse à la dépêche Pourquoi les développeurs n'utilisent pas plus de machines à état ?. Évalué à 0.
Comme tu dis : d'un point de vue theorique si on ne prend pas en compte les interactions des langages. En effet, tes processeurs touchent a une memoire globale. D'ou des interactions entres tes differents automates. Cela se traduit assez facilement : il n'y a un seul langage quelques que soit le nombre de processeurs de ta machine (et on ne parle pas de connection entre ordinateurs via des cables reseaux). D'un point de vue theorique le produit de tes n automates est different de l'automate prennant en compte directement tous les processeurs d'un seul coup.
Certain vont se poser la question de pourquoi il peut y avoir des interactions entre les processeurs. La reponse suppose un petit bagage theorique sur le fonctionnement des systemes d'exploitations. Le systeme d'exploitation gere les processus des programmes. Ces processus sont un ensemble d'element tel que le programme source (le programme charge en memoire), la memoire utilise, mais egalement un certain nombre de threads. Ces threads s'ils sont geres par le processeur peuvent tourner de facon parallele sur des processeurs differents. Comme chacun sait, des threads peuvent avoir un commun une memoire partage. Voici une des interactions que peuvent avoir les processeurs.
[^] # Re: automates à pile
Posté par Vash . En réponse à la dépêche Pourquoi les développeurs n'utilisent pas plus de machines à état ?. Évalué à 3.
Les automates a pile ne sont pas beaucoup plus compliques quel les FSM. Tu as des operations sur chaque etat qui push ou qui pop l'etat courant dans la pile (donc globale) de l'automate. De meme, les transitions doivent supporter des testes sur l'etat de la pile (Est-elle vide ? Quel est le dernier etat ? Quels sont les n derniers etats ?). Ainsi tu peux reconnaitre des langages du type anbn alors que tu ne pouvais pas avec des automates finis.
L'automates pour ce dernier exemple est construit facilement. On lit des a en pushant l'etat dans la pile. Puis on lit que des b en poppant la pile. On acceptera le mot si la pile est vide et qu'il n'y a plus de lettre a lire.
[^] # Re: Historique
Posté par Vash . En réponse à la dépêche Pourquoi les développeurs n'utilisent pas plus de machines à état ?. Évalué à 2.
On ne parle alors pas d'automates finis au sens de la theorie (si tu nous donnes pas plus d'information). Pour information, un automate a une memoire mais bornee.
[^] # Re: Quote
Posté par Vash . En réponse à la dépêche Pourquoi les développeurs n'utilisent pas plus de machines à état ?. Évalué à 0.
Hmmm… Et le produit de ces automates donnent l'etat global de la machine.
[^] # Re: Mouais
Posté par Vash . En réponse à la dépêche Grabuge à la FSF : GnuTLS quitte le projet GNU et sed et grep perdent leur mainteneur. Évalué à 1.
Sans parler de la lisibilité, on veut au minimum un outils qui
n'est pas à la ramasse niveau performance. Regarde le lien suivant
pour voir que Perl, pour les grosses expressions rationnelles, ne
sert pas à grand chose mise à part réchauffer ton logis :
Russ Cox RegExp part 1