" ...Cette réaction était la réponse du développeur à un ingénieur de
Novell citant une étude interne d'Intel selon laquelle la performance
de Linux reculait de 2% à chaque nouvelle version, portant ainsi à 12%
la baisse de performance globale depuis 10 ans.
-12% de performance en 10 ans..."
Je croyais que le système s'améliorait jour après jour, et bien en fait
il diminue
Dans une centaine d'année environ, il aura atteint une performance
générale de 0%, ce qui en fera le système le plus inutile du monde
Quand je pense que certains riaient, lorsque je disais que Linux allait
s'effondrer sur lui-même, tel un trou noir ;>))
Aujourd'hui, on ne cherche plus à faire le "processeur le plus puissant du monde"
Ah bon ? Figure-toi mon petit branli-branla qu'il y a des choses qui ne sont pas vraiment parallélisables (comme l'immense majorité des requêtes sur une base de données par exemple, ce qui est certainement un point anecdotique de l'utilisation de l'informatique).
On fait des clusters, et la plupart ont des x86 Intel ou AMD ;>)
Quand tu fais du calcul intensif et massivement parallèle, tu n'utilises pas forcément du PC ne serait-ce que pour des histoires indépendantes des processeurs.
1/ Il doit exister des choses à paralléliser dans le code. 2/ Le cluster (duquel parle-t-on : grappe de calcul ou SSI ?) doit pouvoir être maintenable à distance (donc processeur de service, tout ça, subtilement ignoré dans le monde du beurk). 3/ La consommation électrique doit être bornée (et on cause mips ou mflops par Watt et là, on se marre avec les PC). 4/ Le calcul intensif est souvent limité par le côté scalaire des processeurs du beurk et les alignements mémoire, mais tu ne vas pas comprendre. 5/ Les gens achètent du PC parce que c'est de la merde pas chère et que ça suffit pour le péquin moyen.
Il y a un dernier truc que tu sembles ignorer en parlant de calcul intensif. Je vais utiliser une métaphore pour esprit simple : lorsque tu as un tas de sable de plusieurs mètres cubes à bouger (tu sais, le truc dans lequel tu fais tes pâtés), tu peux utiliser deux choses. Tu peux utiliser une pelle et la faire bouger très vite (configuration du PC courant après les mégahertz) ou tu peux prendre un tractopelle qui bougera plus lentement (situation des PowerPC, des Alpha ou des Sparc, sans compter ceux que j'oublie.).
Que tu le veuilles ou non, le PC est _mauvais_ en calcul dès que le nombre de threads dépasse le nombre de voies du calculateur (en d'autres termes, le temps de réponse augmente exponentiellement en fonction du nombre de tâches parallèles sur architecture PC dès que le nombre de tâches dépasse le nombre de processeurs), alors que pour d'autres architectures, l'augmentation est _linéaire_. J'ai fait des benchs entre un serveur octo opteron à 2,2 GHz (8 coeurs) et un autre avec un T1 à 1 GHz (8 coeurs, 32 threads), les deux tournant avec les _mêmes_ disques SAS sur la _même_ base MySQL et avec le même OS. J'ai poussé le vice à essayer Solaris et Linux sur les deux machines (pas en même temps, hein !...). Jusqu'à huit requêtes simultanées, le beurk explosait largement le T1. À partir de 16 requêtes simultanées, le T1 était devant le beurk. À 100 requêtes simultanées, il fallait plus de deux minutes au beurk pour donner une réponse alors que le T1 renvoyait le résultat en moins de 10 secondes. J'ai fait le même genre de tests avec un AS800 muni d'un 21164A/500 et le gagnant est là-encore l'AS800 à partir d'une cinquantaine de requêtes simultanées. Pour brali-branla, l'AS800 n'est pas un double AS/400, c'est une machine sur laquelle il y a encore le logo 'DIGITAL', qui tourne présentement avec OpenVMS 8.3 (donc assez défavorisée en terme de rapidité d'accès aux disques en raison de la couche RMS), et qui fout encore la pâtée à un beurk de dix ans plus jeune sur des histoires de requêtes sur des bases de données (pour ton information encore, mon petit branli-branla, avant que tu ne retournes à l'école, c'est bientôt l'heure, un bloc Seti était calculé en un peu moins de trois heures sur un 21264/433 MHz alors qu'il fallait plus de six heures à un Athlon XP/900 MHz pour effectuer exactement le même boulot en 2001).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 24-09-2009, ? propos de
Re: Linux perd 2 % de performance par année,
P4nd1 - P4nd4 ?crivait dans fr.comp.os.linux.debats :
Thierry B a écrit :
On 2009-09-24, P4nd1 - P4nd4 <p4nd1-p4nd4@p4nd1-p4nd4.gov> wrote:
Bof, toutes ces vieilles technologies sont quasimment disparues
C'est pourtant un processeur UltraSparc qui est le plus puissant
du monde...
Aujourd'hui, on ne cherche plus à faire le "processeur le plus puissant
du monde"
Ah bon ? Figure-toi mon petit branli-branla qu'il y a des choses qui
ne sont pas vraiment parallélisables (comme l'immense majorité des
requêtes sur une base de données par exemple, ce qui est
certainement un point anecdotique de l'utilisation de l'informatique).
On fait des clusters, et la plupart ont des x86 Intel ou AMD ;>)
Quand tu fais du calcul intensif et massivement parallèle, tu
n'utilises pas forcément du PC ne serait-ce que pour des histoires
indépendantes des processeurs.
1/ Il doit exister des choses à paralléliser dans le code.
2/ Le cluster (duquel parle-t-on : grappe de calcul ou SSI ?) doit
pouvoir être maintenable à distance (donc processeur de service,
tout ça, subtilement ignoré dans le monde du beurk).
3/ La consommation électrique doit être bornée (et on cause mips ou
mflops par Watt et là, on se marre avec les PC).
4/ Le calcul intensif est souvent limité par le côté scalaire des
processeurs du beurk et les alignements mémoire, mais tu ne vas pas
comprendre.
5/ Les gens achètent du PC parce que c'est de la merde pas chère et
que ça suffit pour le péquin moyen.
Il y a un dernier truc que tu sembles ignorer en parlant de calcul
intensif. Je vais utiliser une métaphore pour esprit simple :
lorsque tu as un tas de sable de plusieurs mètres cubes à bouger (tu
sais, le truc dans lequel tu fais tes pâtés), tu peux utiliser deux
choses. Tu peux utiliser une pelle et la faire bouger très vite
(configuration du PC courant après les mégahertz) ou tu peux prendre
un tractopelle qui bougera plus lentement (situation des PowerPC,
des Alpha ou des Sparc, sans compter ceux que j'oublie.).
Que tu le veuilles ou non, le PC est _mauvais_ en calcul dès que
le nombre de threads dépasse le nombre de voies du calculateur
(en d'autres termes, le temps de réponse augmente exponentiellement
en fonction du nombre de tâches parallèles sur architecture PC dès
que le nombre de tâches dépasse le nombre de processeurs), alors que
pour d'autres architectures, l'augmentation est _linéaire_. J'ai
fait des benchs entre un serveur octo opteron à 2,2 GHz (8 coeurs)
et un autre avec un T1 à 1 GHz (8 coeurs, 32 threads), les deux tournant
avec les _mêmes_ disques SAS sur la _même_ base MySQL et avec le
même OS. J'ai poussé le vice à essayer Solaris et Linux sur les deux
machines (pas en même temps, hein !...). Jusqu'à huit
requêtes simultanées, le beurk explosait largement le T1. À partir
de 16 requêtes simultanées, le T1 était devant le beurk. À 100
requêtes simultanées, il fallait plus de deux minutes au beurk pour
donner une réponse alors que le T1 renvoyait le résultat en moins de
10 secondes. J'ai fait le même genre de tests avec un AS800 muni
d'un 21164A/500 et le gagnant est là-encore l'AS800 à partir d'une
cinquantaine de requêtes simultanées. Pour brali-branla, l'AS800
n'est pas un double AS/400, c'est une machine sur laquelle il y a
encore le logo 'DIGITAL', qui tourne présentement avec OpenVMS 8.3
(donc assez défavorisée en terme de rapidité d'accès aux disques en
raison de la couche RMS), et qui fout encore la pâtée à un beurk de
dix ans plus jeune sur des histoires de requêtes sur des bases de
données (pour ton information encore, mon petit branli-branla, avant
que tu ne retournes à l'école, c'est bientôt l'heure, un bloc Seti
était calculé en un peu moins de trois heures sur un 21264/433 MHz
alors qu'il fallait plus de six heures à un Athlon XP/900 MHz pour
effectuer exactement le même boulot en 2001).
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Aujourd'hui, on ne cherche plus à faire le "processeur le plus puissant du monde"
Ah bon ? Figure-toi mon petit branli-branla qu'il y a des choses qui ne sont pas vraiment parallélisables (comme l'immense majorité des requêtes sur une base de données par exemple, ce qui est certainement un point anecdotique de l'utilisation de l'informatique).
On fait des clusters, et la plupart ont des x86 Intel ou AMD ;>)
Quand tu fais du calcul intensif et massivement parallèle, tu n'utilises pas forcément du PC ne serait-ce que pour des histoires indépendantes des processeurs.
1/ Il doit exister des choses à paralléliser dans le code. 2/ Le cluster (duquel parle-t-on : grappe de calcul ou SSI ?) doit pouvoir être maintenable à distance (donc processeur de service, tout ça, subtilement ignoré dans le monde du beurk). 3/ La consommation électrique doit être bornée (et on cause mips ou mflops par Watt et là, on se marre avec les PC). 4/ Le calcul intensif est souvent limité par le côté scalaire des processeurs du beurk et les alignements mémoire, mais tu ne vas pas comprendre. 5/ Les gens achètent du PC parce que c'est de la merde pas chère et que ça suffit pour le péquin moyen.
Il y a un dernier truc que tu sembles ignorer en parlant de calcul intensif. Je vais utiliser une métaphore pour esprit simple : lorsque tu as un tas de sable de plusieurs mètres cubes à bouger (tu sais, le truc dans lequel tu fais tes pâtés), tu peux utiliser deux choses. Tu peux utiliser une pelle et la faire bouger très vite (configuration du PC courant après les mégahertz) ou tu peux prendre un tractopelle qui bougera plus lentement (situation des PowerPC, des Alpha ou des Sparc, sans compter ceux que j'oublie.).
Que tu le veuilles ou non, le PC est _mauvais_ en calcul dès que le nombre de threads dépasse le nombre de voies du calculateur (en d'autres termes, le temps de réponse augmente exponentiellement en fonction du nombre de tâches parallèles sur architecture PC dès que le nombre de tâches dépasse le nombre de processeurs), alors que pour d'autres architectures, l'augmentation est _linéaire_. J'ai fait des benchs entre un serveur octo opteron à 2,2 GHz (8 coeurs) et un autre avec un T1 à 1 GHz (8 coeurs, 32 threads), les deux tournant avec les _mêmes_ disques SAS sur la _même_ base MySQL et avec le même OS. J'ai poussé le vice à essayer Solaris et Linux sur les deux machines (pas en même temps, hein !...). Jusqu'à huit requêtes simultanées, le beurk explosait largement le T1. À partir de 16 requêtes simultanées, le T1 était devant le beurk. À 100 requêtes simultanées, il fallait plus de deux minutes au beurk pour donner une réponse alors que le T1 renvoyait le résultat en moins de 10 secondes. J'ai fait le même genre de tests avec un AS800 muni d'un 21164A/500 et le gagnant est là-encore l'AS800 à partir d'une cinquantaine de requêtes simultanées. Pour brali-branla, l'AS800 n'est pas un double AS/400, c'est une machine sur laquelle il y a encore le logo 'DIGITAL', qui tourne présentement avec OpenVMS 8.3 (donc assez défavorisée en terme de rapidité d'accès aux disques en raison de la couche RMS), et qui fout encore la pâtée à un beurk de dix ans plus jeune sur des histoires de requêtes sur des bases de données (pour ton information encore, mon petit branli-branla, avant que tu ne retournes à l'école, c'est bientôt l'heure, un bloc Seti était calculé en un peu moins de trois heures sur un 21264/433 MHz alors qu'il fallait plus de six heures à un Athlon XP/900 MHz pour effectuer exactement le même boulot en 2001).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
NiKo
Thierry B a écrit :
On 2009-09-23, NiKo wrote:
Faudra que Br4nl1 Br4nl4 m'explique comment il fait tourner la bouse avec seulement 96 Mo ... sans pouvoir l'installer ...
$ man dd $ man mkswap $ man swapon
_sans pouvoir l'installer_ ?
Thierry B a écrit :
On 2009-09-23, NiKo <NiKo@nomail.svp> wrote:
Faudra que Br4nl1 Br4nl4 m'explique comment il fait tourner la bouse
avec seulement 96 Mo ... sans pouvoir l'installer ...
