Ça dépend ce que tu regardes. Le processeur ne fait pas tout, il y a
l'architecture à regarder de près. En première approximation, un PC
fonctionne bien jusqu'à une charge équivalente au nombre de voies.
Lorsque tu dépasses cette limite, les performances peuvent se casser
la figure assez rapidement. Pour avoir fait des benchs, le temps de
réponse de l'architecture PC n'est pas linéaire en fonction de la
charge alors qu'elle l'est sur POWER et sur Sparc (c'est une
histoire d'interruptions et de bus système avec le goulot
d'étranglement qu'est la gestion de la mémoire. Sans compter que le
bus PCI est une m*rde.). Ce genre de chose compte beaucoup dans le
choix d'un serveur.
Ça dépend ce que tu regardes. Le processeur ne fait pas tout, il y a
l'architecture à regarder de près. En première approximation, un PC
fonctionne bien jusqu'à une charge équivalente au nombre de voies.
Lorsque tu dépasses cette limite, les performances peuvent se casser
la figure assez rapidement. Pour avoir fait des benchs, le temps de
réponse de l'architecture PC n'est pas linéaire en fonction de la
charge alors qu'elle l'est sur POWER et sur Sparc (c'est une
histoire d'interruptions et de bus système avec le goulot
d'étranglement qu'est la gestion de la mémoire. Sans compter que le
bus PCI est une m*rde.). Ce genre de chose compte beaucoup dans le
choix d'un serveur.
Ça dépend ce que tu regardes. Le processeur ne fait pas tout, il y a
l'architecture à regarder de près. En première approximation, un PC
fonctionne bien jusqu'à une charge équivalente au nombre de voies.
Lorsque tu dépasses cette limite, les performances peuvent se casser
la figure assez rapidement. Pour avoir fait des benchs, le temps de
réponse de l'architecture PC n'est pas linéaire en fonction de la
charge alors qu'elle l'est sur POWER et sur Sparc (c'est une
histoire d'interruptions et de bus système avec le goulot
d'étranglement qu'est la gestion de la mémoire. Sans compter que le
bus PCI est une m*rde.). Ce genre de chose compte beaucoup dans le
choix d'un serveur.
Le 24 Sep 2010 16:45:17 GMT,
Toxico Nimbus écrivait :JKB a écrit :et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Ghz_Quad-core
et pour répondre à ta question tous les fabricants proposent un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sans mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ sans MMU...
Ça dépend où tu place la limite de la sériosité. Sur mon Amiga je pouvais
même faire du temps réel...
Sérieux, ça veut dire sans se marcher sur les pieds en cas
d'explosion d'un processus. MacOS (classic) et AmigaOS (les
anciennes versions parce qu'il y a toujours des rucs développés)
n'entrent triviallement pas dans cette catégorie.
Le 24 Sep 2010 16:45:17 GMT,
Toxico Nimbus<ToxN@free.fr> écrivait :
JKB a écrit :
et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Ghz_Quad-core
et pour répondre à ta question tous les fabricants proposent un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sans mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ sans MMU...
Ça dépend où tu place la limite de la sériosité. Sur mon Amiga je pouvais
même faire du temps réel...
Sérieux, ça veut dire sans se marcher sur les pieds en cas
d'explosion d'un processus. MacOS (classic) et AmigaOS (les
anciennes versions parce qu'il y a toujours des rucs développés)
n'entrent triviallement pas dans cette catégorie.
Le 24 Sep 2010 16:45:17 GMT,
Toxico Nimbus écrivait :JKB a écrit :et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Ghz_Quad-core
et pour répondre à ta question tous les fabricants proposent un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sans mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ sans MMU...
Ça dépend où tu place la limite de la sériosité. Sur mon Amiga je pouvais
même faire du temps réel...
Sérieux, ça veut dire sans se marcher sur les pieds en cas
d'explosion d'un processus. MacOS (classic) et AmigaOS (les
anciennes versions parce qu'il y a toujours des rucs développés)
n'entrent triviallement pas dans cette catégorie.
Le Fri, 24 Sep 2010 14:22:20 +0200,
remy écrivait :Miod Vallat a écrit :Bon, à part cela, ARM me semble très bien décoller, a vec même
maintenant un double-coeur super basse consommation sur lesquel tour ne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le cholà ©ra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et les MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPad, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas de
snooping : faible consommation électrique mais obligation de vid er le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est vendu : MMU
type v9 ou v11, snooping, forte consommation électrique, éc onomie de
purge de caches... mais toujours pas de coprocesseur arithmétiqu e, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc san s mmu
est utilisé et fonctionne correctement voire même très correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Ghz_ Quad-core
et pour répondre à ta question tous les fabricants proposent un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sans mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ s ans
MMU...
Le Fri, 24 Sep 2010 14:22:20 +0200,
remy <remy@fctpas.fr> écrivait :
Miod Vallat a écrit :
Bon, à part cela, ARM me semble très bien décoller, a vec même
maintenant un double-coeur super basse consommation sur lesquel tour ne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le cholà ©ra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et les MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPad, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas de
snooping : faible consommation électrique mais obligation de vid er le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est vendu : MMU
type v9 ou v11, snooping, forte consommation électrique, éc onomie de
purge de caches... mais toujours pas de coprocesseur arithmétiqu e, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc san s mmu
est utilisé et fonctionne correctement voire même très correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Ghz_ Quad-core
et pour répondre à ta question tous les fabricants proposent un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sans mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ s ans
MMU...
Le Fri, 24 Sep 2010 14:22:20 +0200,
remy écrivait :Miod Vallat a écrit :Bon, à part cela, ARM me semble très bien décoller, a vec même
maintenant un double-coeur super basse consommation sur lesquel tour ne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le cholà ©ra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et les MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPad, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas de
snooping : faible consommation électrique mais obligation de vid er le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est vendu : MMU
type v9 ou v11, snooping, forte consommation électrique, éc onomie de
purge de caches... mais toujours pas de coprocesseur arithmétiqu e, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc san s mmu
est utilisé et fonctionne correctement voire même très correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Ghz_ Quad-core
et pour répondre à ta question tous les fabricants proposent un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sans mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ s ans
MMU...
Le 26/09/2010 20:04, JKB a écrit :Le Sun, 26 Sep 2010 18:41:43 +0200,
pipantal écrivait :Pourtant, par thread, c'est bien l'US VII FX qui mène la danse. En
terme de puissance par watt, on doit trouver des choses
intéressantes sur les T2+ et les POWER. En tout cas, ce n'est pas
sur les x86 qui ne gagnent qu'en raison de leur coût d'achat.
Donc Mips/W US et POWER gagne, mais Mips/€ c'est l'x86 ou plutôt l'x64 !
Mais au final, le vainqueur c'est qui ?
Pour l'utilisateur lambda ?
Pour le serveur ?
Sparc ou power.Pour le producteur de boule quies ?
Pour le producteur d'électricité ?
x86 sans aucune réserve.
on est bien d'accord la dessus mais c'est une abominationSi sur la pratique nous avons des ordinateurs puissants pour pas cher,
je reste frustré par le quasimonopole d'une seule technologie !
Ça dépend ce que tu regardes. Le processeur ne fait pas tout, il y a
l'architecture à regarder de près. En première approximation, un PC
fonctionne bien jusqu'à une charge équivalente au nombre de voies.
Lorsque tu dépasses cette limite, les performances peuvent se casser
la figure assez rapidement. Pour avoir fait des benchs, le temps de
réponse de l'architecture PC n'est pas linéaire en fonction de la
charge alors qu'elle l'est sur POWER et sur Sparc (c'est une
histoire d'interruptions et de bus système avec le goulot
d'étranglement qu'est la gestion de la mémoire. Sans compter que le
bus PCI est une m*rde.). Ce genre de chose compte beaucoup dans le
choix d'un serveur.
Si cela se traduit, par le fait que par moment mon PC ne répond
quasiment plus à rien, parce qu'il a les application dans tous les sens,
avec base de donnée entre-autre ouverte (pas la meilleure), etc. en mode
Windows, je suis d'accord.
Mais bon, le PCI n'est pas une obligation de l'x86, il suffit d'avoir le
chipset qui gère un autre type de bus, comme les SCSI-family ou autre
bus de périphérique par exemple, et ce défaut se règle non ?
Et tu penses accéder au SCSI comment si ce n'est au travers du bus
PCI. Tu n'es pas sur sparc où le SCSI est sur le bus système.
oui mais d'après ce que je comprend, accèder à un bus SCSI à travers une
carte PCI-SCSI est une montruosité, qui ne peut donner raison qu'à l'IDE
dans l'extrême non ? ou bien c'est pire ? Mais ça peut être mieux aussi
mais pas aussi significativement qu'un SCSI en natif.
Dit autrement, si tu sais par avance que ta machine ne sera pas
chargée ou que tu peux limiter sa charge, un bête PC suffira. Si tu
as une base de données avec 1000 connexions simultanées, la
puissance du x86 à l'intérieur suffira, mais l'architecture ne sera
pas adaptée.
Enfin bon, le consommateur aujourd'hui n'a plus de choix.
Pour une station de travail, c'est x86, et personne n'arrive à présenter
une alternative, et dès lors qu'on veut plus de puissance, on nous pond
un truc, plus puissant.
J'ai l'impression, que les autres architectures POWER ou US, était
capable de fournir des puissances qui ne sont pas dépassées aujourd'hui,
mais qui à l'époque ne correspondant pas à la demande, se sont tirés une
balle dans le pied pour la commercialisation en masse.
Ne jamais oublier que si NT4 était censé tourner sur mips, sparc et
quelques autres architectures (j'ai encore les CD de boot de tels
NT4), le x86 n'aurait peut-être pas gagné.
Certes, mais si finalement X86 peut s'adapter et être aussi efficace
pourquoi pas !!
Mais si c'est une histoire de marketing, ou bien d'erreur stratégique de
la part de MIPS ou SPARC ou autres c'est effreyant, car les conséquences
technologique fragilisent le développement.La puissance de l'x86 est aussi peut-être de fabriquer ce que le
consommateur attend, ou tout du moins ce qu'on lui fait attendre.
On consomme tout de suite, dans 3 ans, de tout façon je change ! Et
c'est pas cher.
Et on en a pour son argent.
On en avait déjà discuté, mais à ce prix là !
Tu prends souvent l'exemple de l'algorithme de recherche d'itinéraire.
Les bases de données existent depuis 5-10 ans maintenant, certes une
optimisation étaient des plus utiles en 2000, autant aujourd'hui, mêle
un algorithme à chier peut répondre à la demande.
C'est dommage pour la puissance utile, mais tout le monde le fait.
Quand on regarde la techno GSM par exemple, avec les exigences de
synchronisation et de timing d'émission, on se demande aujourd'hui
comment cela était possible il y a ... 20 ans ! heureusement qu'il y a
eu des processeurs spécialisés et optimisés pour que les réseaux
modernes sans fil emergent.
C'est intéressant ce que tu dis.
En gros, l'x86, a donc encore la possibilité de gagner sur les tableaux
de la consommation en généralisant l'alignement des instructions ?
Oui. Il suffirait de forcer le mode en question (en espérant qu'il
ne soit pas buggué, je ne me suis pas penché sur le problème
récemment).
C'est un argument en faveur de l'x86 çà.
Comme quoi, ils ne sont pas à la ramace, ou bien, c'est unen astuce
qu'ils gardent sous la main, pour accroitre leur puissance en temps
utiles (mode commerciale actived).En gros, facilement aussi, Intel pourrait au niveau exécution améliorer
le parallelisme d'exécution et devait multiscalaire à l'image des sparc ?
Là, il ne faut pas exagérer. Le RISC évite des prédictions de saut
avec cassage de gueule du pipe-line. C'est dû à deux choses : format
d'instruction fixe _et_ traitement en nombre fixe de tops d'horloge.
Sur x86, les instructions ne sont pas traitées en un nombre fixe
de cycle. Pire, elles peuvent (de mémoire) être exécutées dans le
désordre. Donc pour optimiser tout ça, ce n'est pas gagné. C'est
typiquement ce genre de choses qui a fait que le P4 était une bouse.
Oui mais finalement est-ce impossible ?
Je me souviens d'une phrase du président d'Intel à propos de la crise
des années 2000 qui disait, que s'il avait su il aurait investie
beaucoup plus que les 8-10 milliards de dollars !
Et cet alignement pourrait se faire _sans_ problème de compatibilité
puisque cet alignement peut être fait lors du chargement d'un
binaire ELF en mémoire. Il suffit de le vouloir.
Cad, une option de compilation simplement ?
Non, une modification du chargement du format binaire en mémoire par
l'OS.
oui donc pas forcément très compliqué. Ce qui ne se fait pas parce que
les processeurs "doivent" s'attendre à un chargement "ancien". (en gros
l'éternel problème de la rétro compatibilité mais qui pour un binaire ne
devrait pas avoir lieu d'être).
C'est un problème de code ouvert ou fermé, pas un problème
d'architecture.
oui, mais s'il est difficile (de moins en moins d'ailleurs) d'avoir un
périphérique ayant un pilote sous Linux développé sous x86, je ne parle
même pas d'ARM, POWER, SPARC ou autre MIPS, etc.
?
Lexmark développe par chance un driver sous Linux.
Si je suis sous léon4 ou bien Loongson je ne peux utiliser mon driver,
par contre soous ATOM pas de problème !!!
Par contre, c'est peut-être la possibilité pour Microsoft, de
s'installer vraiment partout, justement par trop de simplicité et de
portabilité sur des matériels finalement tous pareils !
Ma machine à laver tourne avec un i386EX. Je serai curieux
d'installer un Windows là-dessus...
Mais un petit Windows adapté ? ça doit pas être compliqué !!!!!
Il n'y a pas de lecteur de disquette pour booter.
lol
Le 26/09/2010 20:04, JKB a écrit :
Le Sun, 26 Sep 2010 18:41:43 +0200,
pipantal<000pipantal@free.fr000> écrivait :
Pourtant, par thread, c'est bien l'US VII FX qui mène la danse. En
terme de puissance par watt, on doit trouver des choses
intéressantes sur les T2+ et les POWER. En tout cas, ce n'est pas
sur les x86 qui ne gagnent qu'en raison de leur coût d'achat.
Donc Mips/W US et POWER gagne, mais Mips/€ c'est l'x86 ou plutôt l'x64 !
Mais au final, le vainqueur c'est qui ?
Pour l'utilisateur lambda ?
Pour le serveur ?
Sparc ou power.
Pour le producteur de boule quies ?
Pour le producteur d'électricité ?
x86 sans aucune réserve.
on est bien d'accord la dessus mais c'est une abomination
Si sur la pratique nous avons des ordinateurs puissants pour pas cher,
je reste frustré par le quasimonopole d'une seule technologie !
Ça dépend ce que tu regardes. Le processeur ne fait pas tout, il y a
l'architecture à regarder de près. En première approximation, un PC
fonctionne bien jusqu'à une charge équivalente au nombre de voies.
Lorsque tu dépasses cette limite, les performances peuvent se casser
la figure assez rapidement. Pour avoir fait des benchs, le temps de
réponse de l'architecture PC n'est pas linéaire en fonction de la
charge alors qu'elle l'est sur POWER et sur Sparc (c'est une
histoire d'interruptions et de bus système avec le goulot
d'étranglement qu'est la gestion de la mémoire. Sans compter que le
bus PCI est une m*rde.). Ce genre de chose compte beaucoup dans le
choix d'un serveur.
Si cela se traduit, par le fait que par moment mon PC ne répond
quasiment plus à rien, parce qu'il a les application dans tous les sens,
avec base de donnée entre-autre ouverte (pas la meilleure), etc. en mode
Windows, je suis d'accord.
Mais bon, le PCI n'est pas une obligation de l'x86, il suffit d'avoir le
chipset qui gère un autre type de bus, comme les SCSI-family ou autre
bus de périphérique par exemple, et ce défaut se règle non ?
Et tu penses accéder au SCSI comment si ce n'est au travers du bus
PCI. Tu n'es pas sur sparc où le SCSI est sur le bus système.
oui mais d'après ce que je comprend, accèder à un bus SCSI à travers une
carte PCI-SCSI est une montruosité, qui ne peut donner raison qu'à l'IDE
dans l'extrême non ? ou bien c'est pire ? Mais ça peut être mieux aussi
mais pas aussi significativement qu'un SCSI en natif.
Dit autrement, si tu sais par avance que ta machine ne sera pas
chargée ou que tu peux limiter sa charge, un bête PC suffira. Si tu
as une base de données avec 1000 connexions simultanées, la
puissance du x86 à l'intérieur suffira, mais l'architecture ne sera
pas adaptée.
Enfin bon, le consommateur aujourd'hui n'a plus de choix.
Pour une station de travail, c'est x86, et personne n'arrive à présenter
une alternative, et dès lors qu'on veut plus de puissance, on nous pond
un truc, plus puissant.
J'ai l'impression, que les autres architectures POWER ou US, était
capable de fournir des puissances qui ne sont pas dépassées aujourd'hui,
mais qui à l'époque ne correspondant pas à la demande, se sont tirés une
balle dans le pied pour la commercialisation en masse.
Ne jamais oublier que si NT4 était censé tourner sur mips, sparc et
quelques autres architectures (j'ai encore les CD de boot de tels
NT4), le x86 n'aurait peut-être pas gagné.
Certes, mais si finalement X86 peut s'adapter et être aussi efficace
pourquoi pas !!
Mais si c'est une histoire de marketing, ou bien d'erreur stratégique de
la part de MIPS ou SPARC ou autres c'est effreyant, car les conséquences
technologique fragilisent le développement.
La puissance de l'x86 est aussi peut-être de fabriquer ce que le
consommateur attend, ou tout du moins ce qu'on lui fait attendre.
On consomme tout de suite, dans 3 ans, de tout façon je change ! Et
c'est pas cher.
Et on en a pour son argent.
On en avait déjà discuté, mais à ce prix là !
Tu prends souvent l'exemple de l'algorithme de recherche d'itinéraire.
Les bases de données existent depuis 5-10 ans maintenant, certes une
optimisation étaient des plus utiles en 2000, autant aujourd'hui, mêle
un algorithme à chier peut répondre à la demande.
C'est dommage pour la puissance utile, mais tout le monde le fait.
Quand on regarde la techno GSM par exemple, avec les exigences de
synchronisation et de timing d'émission, on se demande aujourd'hui
comment cela était possible il y a ... 20 ans ! heureusement qu'il y a
eu des processeurs spécialisés et optimisés pour que les réseaux
modernes sans fil emergent.
C'est intéressant ce que tu dis.
En gros, l'x86, a donc encore la possibilité de gagner sur les tableaux
de la consommation en généralisant l'alignement des instructions ?
Oui. Il suffirait de forcer le mode en question (en espérant qu'il
ne soit pas buggué, je ne me suis pas penché sur le problème
récemment).
C'est un argument en faveur de l'x86 çà.
Comme quoi, ils ne sont pas à la ramace, ou bien, c'est unen astuce
qu'ils gardent sous la main, pour accroitre leur puissance en temps
utiles (mode commerciale actived).
En gros, facilement aussi, Intel pourrait au niveau exécution améliorer
le parallelisme d'exécution et devait multiscalaire à l'image des sparc ?
Là, il ne faut pas exagérer. Le RISC évite des prédictions de saut
avec cassage de gueule du pipe-line. C'est dû à deux choses : format
d'instruction fixe _et_ traitement en nombre fixe de tops d'horloge.
Sur x86, les instructions ne sont pas traitées en un nombre fixe
de cycle. Pire, elles peuvent (de mémoire) être exécutées dans le
désordre. Donc pour optimiser tout ça, ce n'est pas gagné. C'est
typiquement ce genre de choses qui a fait que le P4 était une bouse.
Oui mais finalement est-ce impossible ?
Je me souviens d'une phrase du président d'Intel à propos de la crise
des années 2000 qui disait, que s'il avait su il aurait investie
beaucoup plus que les 8-10 milliards de dollars !
Et cet alignement pourrait se faire _sans_ problème de compatibilité
puisque cet alignement peut être fait lors du chargement d'un
binaire ELF en mémoire. Il suffit de le vouloir.
Cad, une option de compilation simplement ?
Non, une modification du chargement du format binaire en mémoire par
l'OS.
oui donc pas forcément très compliqué. Ce qui ne se fait pas parce que
les processeurs "doivent" s'attendre à un chargement "ancien". (en gros
l'éternel problème de la rétro compatibilité mais qui pour un binaire ne
devrait pas avoir lieu d'être).
C'est un problème de code ouvert ou fermé, pas un problème
d'architecture.
oui, mais s'il est difficile (de moins en moins d'ailleurs) d'avoir un
périphérique ayant un pilote sous Linux développé sous x86, je ne parle
même pas d'ARM, POWER, SPARC ou autre MIPS, etc.
?
Lexmark développe par chance un driver sous Linux.
Si je suis sous léon4 ou bien Loongson je ne peux utiliser mon driver,
par contre soous ATOM pas de problème !!!
Par contre, c'est peut-être la possibilité pour Microsoft, de
s'installer vraiment partout, justement par trop de simplicité et de
portabilité sur des matériels finalement tous pareils !
Ma machine à laver tourne avec un i386EX. Je serai curieux
d'installer un Windows là-dessus...
Mais un petit Windows adapté ? ça doit pas être compliqué !!!!!
Il n'y a pas de lecteur de disquette pour booter.
lol
Le 26/09/2010 20:04, JKB a écrit :Le Sun, 26 Sep 2010 18:41:43 +0200,
pipantal écrivait :Pourtant, par thread, c'est bien l'US VII FX qui mène la danse. En
terme de puissance par watt, on doit trouver des choses
intéressantes sur les T2+ et les POWER. En tout cas, ce n'est pas
sur les x86 qui ne gagnent qu'en raison de leur coût d'achat.
Donc Mips/W US et POWER gagne, mais Mips/€ c'est l'x86 ou plutôt l'x64 !
Mais au final, le vainqueur c'est qui ?
Pour l'utilisateur lambda ?
Pour le serveur ?
Sparc ou power.Pour le producteur de boule quies ?
Pour le producteur d'électricité ?
x86 sans aucune réserve.
on est bien d'accord la dessus mais c'est une abominationSi sur la pratique nous avons des ordinateurs puissants pour pas cher,
je reste frustré par le quasimonopole d'une seule technologie !
Ça dépend ce que tu regardes. Le processeur ne fait pas tout, il y a
l'architecture à regarder de près. En première approximation, un PC
fonctionne bien jusqu'à une charge équivalente au nombre de voies.
Lorsque tu dépasses cette limite, les performances peuvent se casser
la figure assez rapidement. Pour avoir fait des benchs, le temps de
réponse de l'architecture PC n'est pas linéaire en fonction de la
charge alors qu'elle l'est sur POWER et sur Sparc (c'est une
histoire d'interruptions et de bus système avec le goulot
d'étranglement qu'est la gestion de la mémoire. Sans compter que le
bus PCI est une m*rde.). Ce genre de chose compte beaucoup dans le
choix d'un serveur.
Si cela se traduit, par le fait que par moment mon PC ne répond
quasiment plus à rien, parce qu'il a les application dans tous les sens,
avec base de donnée entre-autre ouverte (pas la meilleure), etc. en mode
Windows, je suis d'accord.
Mais bon, le PCI n'est pas une obligation de l'x86, il suffit d'avoir le
chipset qui gère un autre type de bus, comme les SCSI-family ou autre
bus de périphérique par exemple, et ce défaut se règle non ?
Et tu penses accéder au SCSI comment si ce n'est au travers du bus
PCI. Tu n'es pas sur sparc où le SCSI est sur le bus système.
oui mais d'après ce que je comprend, accèder à un bus SCSI à travers une
carte PCI-SCSI est une montruosité, qui ne peut donner raison qu'à l'IDE
dans l'extrême non ? ou bien c'est pire ? Mais ça peut être mieux aussi
mais pas aussi significativement qu'un SCSI en natif.
Dit autrement, si tu sais par avance que ta machine ne sera pas
chargée ou que tu peux limiter sa charge, un bête PC suffira. Si tu
as une base de données avec 1000 connexions simultanées, la
puissance du x86 à l'intérieur suffira, mais l'architecture ne sera
pas adaptée.
Enfin bon, le consommateur aujourd'hui n'a plus de choix.
Pour une station de travail, c'est x86, et personne n'arrive à présenter
une alternative, et dès lors qu'on veut plus de puissance, on nous pond
un truc, plus puissant.
J'ai l'impression, que les autres architectures POWER ou US, était
capable de fournir des puissances qui ne sont pas dépassées aujourd'hui,
mais qui à l'époque ne correspondant pas à la demande, se sont tirés une
balle dans le pied pour la commercialisation en masse.
Ne jamais oublier que si NT4 était censé tourner sur mips, sparc et
quelques autres architectures (j'ai encore les CD de boot de tels
NT4), le x86 n'aurait peut-être pas gagné.
Certes, mais si finalement X86 peut s'adapter et être aussi efficace
pourquoi pas !!
Mais si c'est une histoire de marketing, ou bien d'erreur stratégique de
la part de MIPS ou SPARC ou autres c'est effreyant, car les conséquences
technologique fragilisent le développement.La puissance de l'x86 est aussi peut-être de fabriquer ce que le
consommateur attend, ou tout du moins ce qu'on lui fait attendre.
On consomme tout de suite, dans 3 ans, de tout façon je change ! Et
c'est pas cher.
Et on en a pour son argent.
On en avait déjà discuté, mais à ce prix là !
Tu prends souvent l'exemple de l'algorithme de recherche d'itinéraire.
Les bases de données existent depuis 5-10 ans maintenant, certes une
optimisation étaient des plus utiles en 2000, autant aujourd'hui, mêle
un algorithme à chier peut répondre à la demande.
C'est dommage pour la puissance utile, mais tout le monde le fait.
Quand on regarde la techno GSM par exemple, avec les exigences de
synchronisation et de timing d'émission, on se demande aujourd'hui
comment cela était possible il y a ... 20 ans ! heureusement qu'il y a
eu des processeurs spécialisés et optimisés pour que les réseaux
modernes sans fil emergent.
C'est intéressant ce que tu dis.
En gros, l'x86, a donc encore la possibilité de gagner sur les tableaux
de la consommation en généralisant l'alignement des instructions ?
Oui. Il suffirait de forcer le mode en question (en espérant qu'il
ne soit pas buggué, je ne me suis pas penché sur le problème
récemment).
C'est un argument en faveur de l'x86 çà.
Comme quoi, ils ne sont pas à la ramace, ou bien, c'est unen astuce
qu'ils gardent sous la main, pour accroitre leur puissance en temps
utiles (mode commerciale actived).En gros, facilement aussi, Intel pourrait au niveau exécution améliorer
le parallelisme d'exécution et devait multiscalaire à l'image des sparc ?
Là, il ne faut pas exagérer. Le RISC évite des prédictions de saut
avec cassage de gueule du pipe-line. C'est dû à deux choses : format
d'instruction fixe _et_ traitement en nombre fixe de tops d'horloge.
Sur x86, les instructions ne sont pas traitées en un nombre fixe
de cycle. Pire, elles peuvent (de mémoire) être exécutées dans le
désordre. Donc pour optimiser tout ça, ce n'est pas gagné. C'est
typiquement ce genre de choses qui a fait que le P4 était une bouse.
Oui mais finalement est-ce impossible ?
Je me souviens d'une phrase du président d'Intel à propos de la crise
des années 2000 qui disait, que s'il avait su il aurait investie
beaucoup plus que les 8-10 milliards de dollars !
Et cet alignement pourrait se faire _sans_ problème de compatibilité
puisque cet alignement peut être fait lors du chargement d'un
binaire ELF en mémoire. Il suffit de le vouloir.
Cad, une option de compilation simplement ?
Non, une modification du chargement du format binaire en mémoire par
l'OS.
oui donc pas forcément très compliqué. Ce qui ne se fait pas parce que
les processeurs "doivent" s'attendre à un chargement "ancien". (en gros
l'éternel problème de la rétro compatibilité mais qui pour un binaire ne
devrait pas avoir lieu d'être).
C'est un problème de code ouvert ou fermé, pas un problème
d'architecture.
oui, mais s'il est difficile (de moins en moins d'ailleurs) d'avoir un
périphérique ayant un pilote sous Linux développé sous x86, je ne parle
même pas d'ARM, POWER, SPARC ou autre MIPS, etc.
?
Lexmark développe par chance un driver sous Linux.
Si je suis sous léon4 ou bien Loongson je ne peux utiliser mon driver,
par contre soous ATOM pas de problème !!!
Par contre, c'est peut-être la possibilité pour Microsoft, de
s'installer vraiment partout, justement par trop de simplicité et de
portabilité sur des matériels finalement tous pareils !
Ma machine à laver tourne avec un i386EX. Je serai curieux
d'installer un Windows là-dessus...
Mais un petit Windows adapté ? ça doit pas être compliqué !!!!!
Il n'y a pas de lecteur de disquette pour booter.
lol
JKB a écrit :Le Fri, 24 Sep 2010 14:22:20 +0200,
remy écrivait :Miod Vallat a écrit :Bon, à part cela, ARM me semble très bien décoller, avec même
maintenant un double-coeur super basse consommation sur lesquel tourne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le choléra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et les MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPad, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas de
snooping : faible consommation électrique mais obligation de vider le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est vendu : MMU
type v9 ou v11, snooping, forte consommation électrique, économie de
purge de caches... mais toujours pas de coprocesseur arithmétique, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc sans mmu
est utilisé et fonctionne correctement voire même très correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
non
http://www.google.fr/url?sa=t&source=web&cd=8&ved D0QFjAH&url=http%3A%2F%2Fwww.pragmatec.net%2FProduits%2FWhitePapers%2FuClinux_userguide_S3C44B0.pdf&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNFKqT5sFyaXuJx-EeGeDFCk-NU0BQ&cad=rja
http://www.google.fr/url?sa=t&source=web&cd=7&ved DkQFjAG&url=http%3A%2F%2Ffree-electrons.com%2Fdoc%2Fuclinux_introduction_fr.odp&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNG-yATUJl-oKqCZw9uFlabIFnSw6A&cad=rja
et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Ghz_Quad-core
et pour répondre à ta question tous les fabricants proposent un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sans mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ sans
MMU...
j'ai pas le temp
JKB a écrit :
Le Fri, 24 Sep 2010 14:22:20 +0200,
remy <remy@fctpas.fr> écrivait :
Miod Vallat a écrit :
Bon, à part cela, ARM me semble très bien décoller, avec même
maintenant un double-coeur super basse consommation sur lesquel tourne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le choléra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et les MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPad, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas de
snooping : faible consommation électrique mais obligation de vider le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est vendu : MMU
type v9 ou v11, snooping, forte consommation électrique, économie de
purge de caches... mais toujours pas de coprocesseur arithmétique, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc sans mmu
est utilisé et fonctionne correctement voire même très correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
non
http://www.google.fr/url?sa=t&source=web&cd=8&ved D0QFjAH&url=http%3A%2F%2Fwww.pragmatec.net%2FProduits%2FWhitePapers%2FuClinux_userguide_S3C44B0.pdf&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNFKqT5sFyaXuJx-EeGeDFCk-NU0BQ&cad=rja
http://www.google.fr/url?sa=t&source=web&cd=7&ved DkQFjAG&url=http%3A%2F%2Ffree-electrons.com%2Fdoc%2Fuclinux_introduction_fr.odp&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNG-yATUJl-oKqCZw9uFlabIFnSw6A&cad=rja
et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Ghz_Quad-core
et pour répondre à ta question tous les fabricants proposent un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sans mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ sans
MMU...
j'ai pas le temp
JKB a écrit :Le Fri, 24 Sep 2010 14:22:20 +0200,
remy écrivait :Miod Vallat a écrit :Bon, à part cela, ARM me semble très bien décoller, avec même
maintenant un double-coeur super basse consommation sur lesquel tourne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le choléra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et les MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPad, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas de
snooping : faible consommation électrique mais obligation de vider le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est vendu : MMU
type v9 ou v11, snooping, forte consommation électrique, économie de
purge de caches... mais toujours pas de coprocesseur arithmétique, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc sans mmu
est utilisé et fonctionne correctement voire même très correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
non
http://www.google.fr/url?sa=t&source=web&cd=8&ved D0QFjAH&url=http%3A%2F%2Fwww.pragmatec.net%2FProduits%2FWhitePapers%2FuClinux_userguide_S3C44B0.pdf&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNFKqT5sFyaXuJx-EeGeDFCk-NU0BQ&cad=rja
http://www.google.fr/url?sa=t&source=web&cd=7&ved DkQFjAG&url=http%3A%2F%2Ffree-electrons.com%2Fdoc%2Fuclinux_introduction_fr.odp&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNG-yATUJl-oKqCZw9uFlabIFnSw6A&cad=rja
et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Ghz_Quad-core
et pour répondre à ta question tous les fabricants proposent un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sans mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ sans
MMU...
j'ai pas le temp
Le Mon, 27 Sep 2010 09:38:29 +0200,
remy écrivait :JKB a écrit :Le Fri, 24 Sep 2010 14:22:20 +0200,
remy écrivait :Miod Vallat a écrit :Bon, à part cela, ARM me semble très bien décoller, avec même
maintenant un double-coeur super basse consommation sur lesquel to urne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le chol éra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et le s MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPa d, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas d e
snooping : faible consommation électrique mais obligation de v ider le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est ven du : MMU
type v9 ou v11, snooping, forte consommation électrique, é conomie de
purge de caches... mais toujours pas de coprocesseur arithméti que, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc s ans mmu
est utilisé et fonctionne correctement voire même trè s correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
non
http://www.google.fr/url?sa=t&source=web&cd=8&ved D0QFjAH&ur l=http%3A%2F%2Fwww.pragmatec.net%2FProduits%2FWhitePapers%2FuClinux_use rguide_S3C44B0.pdf&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe 57oz-DA&usg¯QjCNFKqT5sFyaXuJx-EeGeDFCk-NU0BQ&cad=rja
http://www.google.fr/url?sa=t&source=web&cd=7&ved DkQFjAG&ur l=http%3A%2F%2Ffree-electrons.com%2Fdoc%2Fuclinux_introduction_fr.odp&r ct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCN G-yATUJl-oKqCZw9uFlabIFnSw6A&cad=rja
Bon, on va repartir des concepts de base.
1/ il ne faut pas faire de fork.
Un fork crée une image de lui-même dans un processus fils av ec copie
du contexte donc den particulier es adresses.
2/ il n'y a pas de MMU.
Les deux processus ne sont pas physiquement distincts (en terme
d'adressage).
Tu as donc un système multitâche dans lequel tu ne peux pas faire de
fork() (corollaire, à mha, le execve() doit aussi être foireu x).
=> conséquence, ton système est tout sauf multitâche puisque tu ne
peux faire cohabiter que des tâches disjointes. Ça ressemble
beaucoup à MacOS Classic et les gens sérieux n'appellent pas ça un
système multitâche.
et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Gh z_Quad-core
et pour répondre à ta question tous les fabricants propose nt un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sa ns mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ sans
MMU...
j'ai pas le temp
C'est dommage, ça m'aurait amusé.
JKB
Le Mon, 27 Sep 2010 09:38:29 +0200,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
Le Fri, 24 Sep 2010 14:22:20 +0200,
remy <remy@fctpas.fr> écrivait :
Miod Vallat a écrit :
Bon, à part cela, ARM me semble très bien décoller, avec même
maintenant un double-coeur super basse consommation sur lesquel to urne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le chol éra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et le s MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPa d, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas d e
snooping : faible consommation électrique mais obligation de v ider le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est ven du : MMU
type v9 ou v11, snooping, forte consommation électrique, é conomie de
purge de caches... mais toujours pas de coprocesseur arithméti que, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc s ans mmu
est utilisé et fonctionne correctement voire même trè s correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
non
http://www.google.fr/url?sa=t&source=web&cd=8&ved=0CD0QFjAH&ur l=http%3A%2F%2Fwww.pragmatec.net%2FProduits%2FWhitePapers%2FuClinux_use rguide_S3C44B0.pdf&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe 57oz-DA&usg=AFQjCNFKqT5sFyaXuJx-EeGeDFCk-NU0BQ&cad=rja
http://www.google.fr/url?sa=t&source=web&cd=7&ved=0CDkQFjAG&ur l=http%3A%2F%2Ffree-electrons.com%2Fdoc%2Fuclinux_introduction_fr.odp&r ct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg=AFQjCN G-yATUJl-oKqCZw9uFlabIFnSw6A&cad=rja
Bon, on va repartir des concepts de base.
1/ il ne faut pas faire de fork.
Un fork crée une image de lui-même dans un processus fils av ec copie
du contexte donc den particulier es adresses.
2/ il n'y a pas de MMU.
Les deux processus ne sont pas physiquement distincts (en terme
d'adressage).
Tu as donc un système multitâche dans lequel tu ne peux pas faire de
fork() (corollaire, à mha, le execve() doit aussi être foireu x).
=> conséquence, ton système est tout sauf multitâche puisque tu ne
peux faire cohabiter que des tâches disjointes. Ça ressemble
beaucoup à MacOS Classic et les gens sérieux n'appellent pas ça un
système multitâche.
et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Gh z_Quad-core
et pour répondre à ta question tous les fabricants propose nt un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sa ns mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ sans
MMU...
j'ai pas le temp
C'est dommage, ça m'aurait amusé.
JKB
Le Mon, 27 Sep 2010 09:38:29 +0200,
remy écrivait :JKB a écrit :Le Fri, 24 Sep 2010 14:22:20 +0200,
remy écrivait :Miod Vallat a écrit :Bon, à part cela, ARM me semble très bien décoller, avec même
maintenant un double-coeur super basse consommation sur lesquel to urne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le chol éra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et le s MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPa d, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas d e
snooping : faible consommation électrique mais obligation de v ider le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est ven du : MMU
type v9 ou v11, snooping, forte consommation électrique, é conomie de
purge de caches... mais toujours pas de coprocesseur arithméti que, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc s ans mmu
est utilisé et fonctionne correctement voire même trè s correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
non
http://www.google.fr/url?sa=t&source=web&cd=8&ved D0QFjAH&ur l=http%3A%2F%2Fwww.pragmatec.net%2FProduits%2FWhitePapers%2FuClinux_use rguide_S3C44B0.pdf&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe 57oz-DA&usg¯QjCNFKqT5sFyaXuJx-EeGeDFCk-NU0BQ&cad=rja
http://www.google.fr/url?sa=t&source=web&cd=7&ved DkQFjAG&ur l=http%3A%2F%2Ffree-electrons.com%2Fdoc%2Fuclinux_introduction_fr.odp&r ct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCN G-yATUJl-oKqCZw9uFlabIFnSw6A&cad=rja
Bon, on va repartir des concepts de base.
1/ il ne faut pas faire de fork.
Un fork crée une image de lui-même dans un processus fils av ec copie
du contexte donc den particulier es adresses.
2/ il n'y a pas de MMU.
Les deux processus ne sont pas physiquement distincts (en terme
d'adressage).
Tu as donc un système multitâche dans lequel tu ne peux pas faire de
fork() (corollaire, à mha, le execve() doit aussi être foireu x).
=> conséquence, ton système est tout sauf multitâche puisque tu ne
peux faire cohabiter que des tâches disjointes. Ça ressemble
beaucoup à MacOS Classic et les gens sérieux n'appellent pas ça un
système multitâche.
et si tu veux de la puissance tu as le petit nouveau
http://www.osnews.com/story/23784/ARM_Unveils_Cortex-A15_Up_to_2_5Gh z_Quad-core
et pour répondre à ta question tous les fabricants propose nt un kit
d'éval à base d'arm et de linux ou uclinux pour les arm sa ns mmu
Et tu vas nous expliquer ce qu'est le multitâche _sérieux_ sans
MMU...
j'ai pas le temp
C'est dommage, ça m'aurait amusé.
JKB
Sur ma précédente machine (Intel 32bits) flash était le _seul_ truc
qui se gauffrait régulièrement plusieurs fois par jour.
En regardant des films X ?
Sur ma précédente machine (Intel 32bits) flash était le _seul_ truc
qui se gauffrait régulièrement plusieurs fois par jour.
En regardant des films X ?
Sur ma précédente machine (Intel 32bits) flash était le _seul_ truc
qui se gauffrait régulièrement plusieurs fois par jour.
En regardant des films X ?
peut important present web run on
peut important present web run on
peut important present web run on
http://pwet.fr/man/linux/appels_systemes/vfork
vfork() est conçu comme un cas particulier de clone(2). Il sert à créer
un nouveau processus sans effectuer de copie de la table des pages
mémoire du processus père
vfork() diffère aussi de fork() car le processus père reste suspendu
jusqu'à ce que le fils invoque execve(), ou _exit()
http://pwet.fr/man/linux/appels_systemes/vfork
vfork() est conçu comme un cas particulier de clone(2). Il sert à créer
un nouveau processus sans effectuer de copie de la table des pages
mémoire du processus père
vfork() diffère aussi de fork() car le processus père reste suspendu
jusqu'à ce que le fils invoque execve(), ou _exit()
http://pwet.fr/man/linux/appels_systemes/vfork
vfork() est conçu comme un cas particulier de clone(2). Il sert à créer
un nouveau processus sans effectuer de copie de la table des pages
mémoire du processus père
vfork() diffère aussi de fork() car le processus père reste suspendu
jusqu'à ce que le fils invoque execve(), ou _exit()
JKB a écrit :Le Mon, 27 Sep 2010 09:38:29 +0200,
remy écrivait :JKB a écrit :Le Fri, 24 Sep 2010 14:22:20 +0200,
remy écrivait :Miod Vallat a écrit :Bon, à part cela, ARM me semble très bien décoller, avec même
maintenant un double-coeur super basse consommation sur lesquel tourne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le choléra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et les MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPad, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas de
snooping : faible consommation électrique mais obligation de vider le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est vendu : MMU
type v9 ou v11, snooping, forte consommation électrique, économie de
purge de caches... mais toujours pas de coprocesseur arithmétique, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc sans mmu
est utilisé et fonctionne correctement voire même très correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
non
http://www.google.fr/url?sa=t&source=web&cd=8&ved D0QFjAH&url=http%3A%2F%2Fwww.pragmatec.net%2FProduits%2FWhitePapers%2FuClinux_userguide_S3C44B0.pdf&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNFKqT5sFyaXuJx-EeGeDFCk-NU0BQ&cad=rja
http://www.google.fr/url?sa=t&source=web&cd=7&ved DkQFjAG&url=http%3A%2F%2Ffree-electrons.com%2Fdoc%2Fuclinux_introduction_fr.odp&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNG-yATUJl-oKqCZw9uFlabIFnSw6A&cad=rja
Bon, on va repartir des concepts de base.
1/ il ne faut pas faire de fork.
Un fork crée une image de lui-même dans un processus fils avec copie
du contexte donc den particulier es adresses.
2/ il n'y a pas de MMU.
Les deux processus ne sont pas physiquement distincts (en terme
d'adressage).
Tu as donc un système multitâche dans lequel tu ne peux pas faire de
fork() (corollaire, àmha, le execve() doit aussi être foireux).
=> conséquence, ton système est tout sauf multitâche puisque tu ne
peux faire cohabiter que des tâches disjointes. Ça ressemble
beaucoup à MacOS Classic et les gens sérieux n'appellent pas ça un
système multitâche.
http://pwet.fr/man/linux/appels_systemes/vfork
vfork() est conçu comme un cas particulier de clone(2). Il sert à créer
un nouveau processus sans effectuer de copie de la table des pages
mémoire du processus père
vfork() diffère aussi de fork() car le processus père reste suspendu
jusqu'à ce que le fils invoque execve(), ou _exit()
la comunication inter porcessus et juste différence mais il est bien
multitache
JKB a écrit :
Le Mon, 27 Sep 2010 09:38:29 +0200,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
Le Fri, 24 Sep 2010 14:22:20 +0200,
remy <remy@fctpas.fr> écrivait :
Miod Vallat a écrit :
Bon, à part cela, ARM me semble très bien décoller, avec même
maintenant un double-coeur super basse consommation sur lesquel tourne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le choléra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et les MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPad, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas de
snooping : faible consommation électrique mais obligation de vider le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est vendu : MMU
type v9 ou v11, snooping, forte consommation électrique, économie de
purge de caches... mais toujours pas de coprocesseur arithmétique, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc sans mmu
est utilisé et fonctionne correctement voire même très correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
non
http://www.google.fr/url?sa=t&source=web&cd=8&ved D0QFjAH&url=http%3A%2F%2Fwww.pragmatec.net%2FProduits%2FWhitePapers%2FuClinux_userguide_S3C44B0.pdf&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNFKqT5sFyaXuJx-EeGeDFCk-NU0BQ&cad=rja
http://www.google.fr/url?sa=t&source=web&cd=7&ved DkQFjAG&url=http%3A%2F%2Ffree-electrons.com%2Fdoc%2Fuclinux_introduction_fr.odp&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNG-yATUJl-oKqCZw9uFlabIFnSw6A&cad=rja
Bon, on va repartir des concepts de base.
1/ il ne faut pas faire de fork.
Un fork crée une image de lui-même dans un processus fils avec copie
du contexte donc den particulier es adresses.
2/ il n'y a pas de MMU.
Les deux processus ne sont pas physiquement distincts (en terme
d'adressage).
Tu as donc un système multitâche dans lequel tu ne peux pas faire de
fork() (corollaire, àmha, le execve() doit aussi être foireux).
=> conséquence, ton système est tout sauf multitâche puisque tu ne
peux faire cohabiter que des tâches disjointes. Ça ressemble
beaucoup à MacOS Classic et les gens sérieux n'appellent pas ça un
système multitâche.
http://pwet.fr/man/linux/appels_systemes/vfork
vfork() est conçu comme un cas particulier de clone(2). Il sert à créer
un nouveau processus sans effectuer de copie de la table des pages
mémoire du processus père
vfork() diffère aussi de fork() car le processus père reste suspendu
jusqu'à ce que le fils invoque execve(), ou _exit()
la comunication inter porcessus et juste différence mais il est bien
multitache
JKB a écrit :Le Mon, 27 Sep 2010 09:38:29 +0200,
remy écrivait :JKB a écrit :Le Fri, 24 Sep 2010 14:22:20 +0200,
remy écrivait :Miod Vallat a écrit :Bon, à part cela, ARM me semble très bien décoller, avec même
maintenant un double-coeur super basse consommation sur lesquel tourne
déjà Linux et OS X
Donc, pas de souci à avoir, non ?
Ben si. Parce que x86, d'accord, c'est pire que la peste et le choléra,
d'accord. Mais arm, y'a pas de coprocesseur arithmétique et les MMU ont
été conçus par des ingénieurs qui ont abusé de substances hallucinogènes
prohibées.
Et en pratique, on a le choix entre de l'ARM de merde qui est
parfaitement adapté aux systèmes monotâches type iPad, soit de l'ARM
moins minable qui laisse le choix entre une faible consommation
électrique et des performances abominables (MMU type v7, pas de
snooping : faible consommation électrique mais obligation de vider le
cache à chaque changement de processue), soit une consommation
électrique affreuse aux antipodes de ce pourquoi l'ARM est vendu : MMU
type v9 ou v11, snooping, forte consommation électrique, économie de
purge de caches... mais toujours pas de coprocesseur arithmétique, donc
restant un jouet pour geeks.
je ne fais plus de développement bas niveau mais l'arm 7 donc sans mmu
est utilisé et fonctionne correctement voire même très correctement dans
un environnement multi taches avec http://www.uclinux.org/ports/
il faut juste, ne pas faire de fork dans l'applicatif
Il n'y a pas comme une petite contradiction, là ?
non
http://www.google.fr/url?sa=t&source=web&cd=8&ved D0QFjAH&url=http%3A%2F%2Fwww.pragmatec.net%2FProduits%2FWhitePapers%2FuClinux_userguide_S3C44B0.pdf&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNFKqT5sFyaXuJx-EeGeDFCk-NU0BQ&cad=rja
http://www.google.fr/url?sa=t&source=web&cd=7&ved DkQFjAG&url=http%3A%2F%2Ffree-electrons.com%2Fdoc%2Fuclinux_introduction_fr.odp&rct=j&q=application%20uclinux&ei=u0igTNajFNy4jAe57oz-DA&usg¯QjCNG-yATUJl-oKqCZw9uFlabIFnSw6A&cad=rja
Bon, on va repartir des concepts de base.
1/ il ne faut pas faire de fork.
Un fork crée une image de lui-même dans un processus fils avec copie
du contexte donc den particulier es adresses.
2/ il n'y a pas de MMU.
Les deux processus ne sont pas physiquement distincts (en terme
d'adressage).
Tu as donc un système multitâche dans lequel tu ne peux pas faire de
fork() (corollaire, àmha, le execve() doit aussi être foireux).
=> conséquence, ton système est tout sauf multitâche puisque tu ne
peux faire cohabiter que des tâches disjointes. Ça ressemble
beaucoup à MacOS Classic et les gens sérieux n'appellent pas ça un
système multitâche.
http://pwet.fr/man/linux/appels_systemes/vfork
vfork() est conçu comme un cas particulier de clone(2). Il sert à créer
un nouveau processus sans effectuer de copie de la table des pages
mémoire du processus père
vfork() diffère aussi de fork() car le processus père reste suspendu
jusqu'à ce que le fils invoque execve(), ou _exit()
la comunication inter porcessus et juste différence mais il est bien
multitache
