Je ne comprends pas trop tes réticences vis-à-vis des proc Intel, Bah si, moi je comprend très bien, pendant des années on lui a dit que
c'était de la merde, alors il a pas encore intégré le tournage de casaque ;-)
Mais je ne vois pas où est le problème; dans le temps (il y a 6 mois), les processeurs Intel ETAIENT de la merde, mais maintenant par la grâce de Steve ils savent fabriquer des processeur hypra géniaux alors qu'IBM privé de l'aura cosmique de St Jobs est retourné fabriquer des proc pour calculatrices 4 opérations.
-- arno
Nina Popravka <Nina@nospam> wrote:
On Sat, 5 Aug 2006 10:01:04 +0200, joly@facmed.u-nancy.fr (arno)
wrote:
Je ne comprends pas trop tes réticences vis-à-vis des proc Intel,
Bah si, moi je comprend très bien, pendant des années on lui a dit que
c'était de la merde, alors il a pas encore intégré le tournage de
casaque ;-)
Mais je ne vois pas où est le problème; dans le temps (il y a 6 mois),
les processeurs Intel ETAIENT de la merde, mais maintenant par la grâce
de Steve ils savent fabriquer des processeur hypra géniaux alors qu'IBM
privé de l'aura cosmique de St Jobs est retourné fabriquer des proc pour
calculatrices 4 opérations.
Je ne comprends pas trop tes réticences vis-à-vis des proc Intel, Bah si, moi je comprend très bien, pendant des années on lui a dit que
c'était de la merde, alors il a pas encore intégré le tournage de casaque ;-)
Mais je ne vois pas où est le problème; dans le temps (il y a 6 mois), les processeurs Intel ETAIENT de la merde, mais maintenant par la grâce de Steve ils savent fabriquer des processeur hypra géniaux alors qu'IBM privé de l'aura cosmique de St Jobs est retourné fabriquer des proc pour calculatrices 4 opérations.
-- arno
laurent.pertois
arno wrote:
Mais je ne vois pas où est le problème; dans le temps (il y a 6 mois), les processeurs Intel ETAIENT de la merde, mais maintenant par la grâce de Steve ils savent fabriquer des processeur hypra géniaux alors qu'IBM privé de l'aura cosmique de St Jobs est retourné fabriquer des proc pour calculatrices 4 opérations.
Tu as oublié un truc :
Allelluïa.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
arno <joly@facmed.u-nancy.fr> wrote:
Mais je ne vois pas où est le problème; dans le temps (il y a 6 mois),
les processeurs Intel ETAIENT de la merde, mais maintenant par la grâce
de Steve ils savent fabriquer des processeur hypra géniaux alors qu'IBM
privé de l'aura cosmique de St Jobs est retourné fabriquer des proc pour
calculatrices 4 opérations.
Tu as oublié un truc :
Allelluïa.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Mais je ne vois pas où est le problème; dans le temps (il y a 6 mois), les processeurs Intel ETAIENT de la merde, mais maintenant par la grâce de Steve ils savent fabriquer des processeur hypra géniaux alors qu'IBM privé de l'aura cosmique de St Jobs est retourné fabriquer des proc pour calculatrices 4 opérations.
Tu as oublié un truc :
Allelluïa.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nina Popravka
On Sat, 5 Aug 2006 10:41:24 +0200, (arno) wrote:
Mais je ne vois pas où est le problème; dans le temps (il y a 6 mois), les processeurs Intel ETAIENT de la merde, mais maintenant par la grâce de Steve ils savent fabriquer des processeur hypra géniaux alors qu'IBM privé de l'aura cosmique de St Jobs est retourné fabriquer des proc pour calculatrices 4 opérations. Mais non, c'est pas ça, on te l'a pourtant bien expliqué à la télé,
c'est parce que maintenant grâce à St Jobs, l'Intel il s'amuse, alors qu'avant il s'ennuyait. Intel joyeux, Intel rapide ;-) Bon, OK, j'arrête... -- Nina
On Sat, 5 Aug 2006 10:41:24 +0200, joly@facmed.u-nancy.fr (arno)
wrote:
Mais je ne vois pas où est le problème; dans le temps (il y a 6 mois),
les processeurs Intel ETAIENT de la merde, mais maintenant par la grâce
de Steve ils savent fabriquer des processeur hypra géniaux alors qu'IBM
privé de l'aura cosmique de St Jobs est retourné fabriquer des proc pour
calculatrices 4 opérations.
Mais non, c'est pas ça, on te l'a pourtant bien expliqué à la télé,
c'est parce que maintenant grâce à St Jobs, l'Intel il s'amuse, alors
qu'avant il s'ennuyait.
Intel joyeux, Intel rapide ;-)
Bon, OK, j'arrête...
--
Nina
Mais je ne vois pas où est le problème; dans le temps (il y a 6 mois), les processeurs Intel ETAIENT de la merde, mais maintenant par la grâce de Steve ils savent fabriquer des processeur hypra géniaux alors qu'IBM privé de l'aura cosmique de St Jobs est retourné fabriquer des proc pour calculatrices 4 opérations. Mais non, c'est pas ça, on te l'a pourtant bien expliqué à la télé,
c'est parce que maintenant grâce à St Jobs, l'Intel il s'amuse, alors qu'avant il s'ennuyait. Intel joyeux, Intel rapide ;-) Bon, OK, j'arrête... -- Nina
pmanet
arno wrote:
La seule application où j'ai vu une différence (très) sensible, c'est dnetc ou les PPC+Altivec atomisent les architectures x86 pais sinon...
c'est justement parce que j'utilise dnetc depuis longtemps que je sais que les G5 explosent les X86 quand le dev prend la peine de se mouiller la chemise.
maintenant, les devs optimisent pour X86, et adaptent ensuite pour >G5, ce qui donne généralement des résultats minables. C'est la faute des devs, pas du proc.
est-ce une raison pour accepter de travailler avec un proc merdique ?
-- Philippe Manet
arno <joly@facmed.u-nancy.fr> wrote:
La seule application où j'ai vu une différence (très) sensible, c'est
dnetc ou les PPC+Altivec atomisent les architectures x86 pais sinon...
c'est justement parce que j'utilise dnetc depuis longtemps que je sais
que les G5 explosent les X86 quand le dev prend la peine de se mouiller
la chemise.
maintenant, les devs optimisent pour X86, et adaptent ensuite pour >G5,
ce qui donne généralement des résultats minables. C'est la faute des
devs, pas du proc.
est-ce une raison pour accepter de travailler avec un proc merdique ?
La seule application où j'ai vu une différence (très) sensible, c'est dnetc ou les PPC+Altivec atomisent les architectures x86 pais sinon...
c'est justement parce que j'utilise dnetc depuis longtemps que je sais que les G5 explosent les X86 quand le dev prend la peine de se mouiller la chemise.
maintenant, les devs optimisent pour X86, et adaptent ensuite pour >G5, ce qui donne généralement des résultats minables. C'est la faute des devs, pas du proc.
est-ce une raison pour accepter de travailler avec un proc merdique ?
-- Philippe Manet
jc
David Remacle (Clampin) wrote:
Jean-Charles wrote:
Que pensez vous de Realbasic ?
Il est bien adapté à la programmation du Mac mais il n'est pas aussi performant que le Fortran pour les calculs scientifiques. Il a des lacunes que je pourrai vous préciser demain si vous voulez, après avoir demandé à mon père qui a fait la comparaison.
En effet, ce serait intéressant :)
Bon, alors voici : dans Realbasic (la version testée par mon mère mais ça a peut-être été arrangé depuis) on ne peut pas calculer la trace d'une matrice quelle que soit la taille de cette matrice.
-- JC
David Remacle (Clampin) <listes@clampin.com> wrote:
Jean-Charles <jc@qui.net> wrote:
Que pensez vous de Realbasic ?
Il est bien adapté à la programmation du Mac mais il n'est pas aussi
performant que le Fortran pour les calculs scientifiques. Il a des
lacunes que je pourrai vous préciser demain si vous voulez, après avoir
demandé à mon père qui a fait la comparaison.
En effet, ce serait intéressant :)
Bon, alors voici : dans Realbasic (la version testée par mon mère mais
ça a peut-être été arrangé depuis) on ne peut pas calculer la trace
d'une matrice quelle que soit la taille de cette matrice.
Il est bien adapté à la programmation du Mac mais il n'est pas aussi performant que le Fortran pour les calculs scientifiques. Il a des lacunes que je pourrai vous préciser demain si vous voulez, après avoir demandé à mon père qui a fait la comparaison.
En effet, ce serait intéressant :)
Bon, alors voici : dans Realbasic (la version testée par mon mère mais ça a peut-être été arrangé depuis) on ne peut pas calculer la trace d'une matrice quelle que soit la taille de cette matrice.
-- JC
Nina Popravka
On Sun, 6 Aug 2006 01:22:06 +0200, (Jean-Charles) wrote:
Bon, alors voici : dans Realbasic (la version testée par mon mère mais ça a peut-être été arrangé depuis) on ne peut pas calculer la trace d'une matrice quelle que soit la taille de cette matrice. Pour ceux qui auraient autant oublié leurs cours et seraient aussi
perplexes que moi : <http://fr.wikipedia.org/wiki/Trace_(matrice)> Pas de quoi :-) -- Nina
On Sun, 6 Aug 2006 01:22:06 +0200, jc@qui.net (Jean-Charles) wrote:
Bon, alors voici : dans Realbasic (la version testée par mon mère mais
ça a peut-être été arrangé depuis) on ne peut pas calculer la trace
d'une matrice quelle que soit la taille de cette matrice.
Pour ceux qui auraient autant oublié leurs cours et seraient aussi
perplexes que moi :
<http://fr.wikipedia.org/wiki/Trace_(matrice)>
Pas de quoi :-)
--
Nina
On Sun, 6 Aug 2006 01:22:06 +0200, (Jean-Charles) wrote:
Bon, alors voici : dans Realbasic (la version testée par mon mère mais ça a peut-être été arrangé depuis) on ne peut pas calculer la trace d'une matrice quelle que soit la taille de cette matrice. Pour ceux qui auraient autant oublié leurs cours et seraient aussi
perplexes que moi : <http://fr.wikipedia.org/wiki/Trace_(matrice)> Pas de quoi :-) -- Nina
ftestuz
Jean-Charles wrote:
David Remacle (Clampin) wrote:
Jean-Charles wrote:
Que pensez vous de Realbasic ?
Il est bien adapté à la programmation du Mac mais il n'est pas aussi performant que le Fortran pour les calculs scientifiques. Il a des lacunes que je pourrai vous préciser demain si vous voulez, après avoir demandé à mon père qui a fait la comparaison.
En effet, ce serait intéressant :)
Bon, alors voici : dans Realbasic (la version testée par mon mère mais ça a peut-être été arrangé depuis) on ne peut pas calculer la trace d'une matrice quelle que soit la taille de cette matrice.
Oui, bon. Mais d'un autre coté, RealBasic est un langage haut niveau. Je ne l'ai plus pratiqué depuis longtemps, mais il doit y avoir moyen de rajouter des fonctionnalités. Parce que après tout, la trace d'une matrice peut se calculer en une ligne en c avec les bibliothèques standards, mais si la matrice devient grosse et que l'on veut de l'efficacité, on devra aussi utiliser d'autres bibliothèques, du genre calcul vectoriel. Si je me rappelle bien, le Fortran est vraiment fait dès le départ pour le calcul scientifique. Ce n'est pas le cas de RealBasic, et même pas réellement le cas du c. Pour chaque application, il faut utiliser le langage adapté.
-- Frédéric Testuz <mailto:
Jean-Charles <jc@qui.net> wrote:
David Remacle (Clampin) <listes@clampin.com> wrote:
Jean-Charles <jc@qui.net> wrote:
Que pensez vous de Realbasic ?
Il est bien adapté à la programmation du Mac mais il n'est pas aussi
performant que le Fortran pour les calculs scientifiques. Il a des
lacunes que je pourrai vous préciser demain si vous voulez, après avoir
demandé à mon père qui a fait la comparaison.
En effet, ce serait intéressant :)
Bon, alors voici : dans Realbasic (la version testée par mon mère mais
ça a peut-être été arrangé depuis) on ne peut pas calculer la trace
d'une matrice quelle que soit la taille de cette matrice.
Oui, bon. Mais d'un autre coté, RealBasic est un langage haut niveau. Je
ne l'ai plus pratiqué depuis longtemps, mais il doit y avoir moyen de
rajouter des fonctionnalités.
Parce que après tout, la trace d'une matrice peut se calculer en une
ligne en c avec les bibliothèques standards, mais si la matrice devient
grosse et que l'on veut de l'efficacité, on devra aussi utiliser
d'autres bibliothèques, du genre calcul vectoriel.
Si je me rappelle bien, le Fortran est vraiment fait dès le départ pour
le calcul scientifique. Ce n'est pas le cas de RealBasic, et même pas
réellement le cas du c. Pour chaque application, il faut utiliser le
langage adapté.
Il est bien adapté à la programmation du Mac mais il n'est pas aussi performant que le Fortran pour les calculs scientifiques. Il a des lacunes que je pourrai vous préciser demain si vous voulez, après avoir demandé à mon père qui a fait la comparaison.
En effet, ce serait intéressant :)
Bon, alors voici : dans Realbasic (la version testée par mon mère mais ça a peut-être été arrangé depuis) on ne peut pas calculer la trace d'une matrice quelle que soit la taille de cette matrice.
Oui, bon. Mais d'un autre coté, RealBasic est un langage haut niveau. Je ne l'ai plus pratiqué depuis longtemps, mais il doit y avoir moyen de rajouter des fonctionnalités. Parce que après tout, la trace d'une matrice peut se calculer en une ligne en c avec les bibliothèques standards, mais si la matrice devient grosse et que l'on veut de l'efficacité, on devra aussi utiliser d'autres bibliothèques, du genre calcul vectoriel. Si je me rappelle bien, le Fortran est vraiment fait dès le départ pour le calcul scientifique. Ce n'est pas le cas de RealBasic, et même pas réellement le cas du c. Pour chaque application, il faut utiliser le langage adapté.
-- Frédéric Testuz <mailto:
joly
manet wrote:
arno wrote:
La seule application où j'ai vu une différence (très) sensible, c'est dnetc ou les PPC+Altivec atomisent les architectures x86 pais sinon...
c'est justement parce que j'utilise dnetc depuis longtemps que je sais que les G5 explosent les X86 quand le dev prend la peine de se mouiller la chemise.
Je ne pense pas que l'on puisse tirer de conclusions générales sur les performances d'un processeur vis-à-vis de son aptitude à mouliner un calcul très spécifique comme le RC5.
maintenant, les devs optimisent pour X86, et adaptent ensuite pour >G5, ce qui donne généralement des résultats minables. C'est la faute des devs, pas du proc.
est-ce une raison pour accepter de travailler avec un proc merdique ?
Euh, ça fait combien d'année qu'Apple nous dis "Le PPC est l'architecture ultime qui va tout pulvériser, il faut juste nous laisser le temps d'optimiser les soft" ?
En admettant que ce soit vrai, entre un processeur rapide sur le papier et un autre rapide dans la vrai vie j'ai vite choisi.
-- arno
manet <pmanet@invivo.edu> wrote:
arno <joly@facmed.u-nancy.fr> wrote:
La seule application où j'ai vu une différence (très) sensible, c'est
dnetc ou les PPC+Altivec atomisent les architectures x86 pais sinon...
c'est justement parce que j'utilise dnetc depuis longtemps que je sais
que les G5 explosent les X86 quand le dev prend la peine de se mouiller
la chemise.
Je ne pense pas que l'on puisse tirer de conclusions générales sur les
performances d'un processeur vis-à-vis de son aptitude à mouliner un
calcul très spécifique comme le RC5.
maintenant, les devs optimisent pour X86, et adaptent ensuite pour >G5,
ce qui donne généralement des résultats minables. C'est la faute des
devs, pas du proc.
est-ce une raison pour accepter de travailler avec un proc merdique ?
Euh, ça fait combien d'année qu'Apple nous dis "Le PPC est
l'architecture ultime qui va tout pulvériser, il faut juste nous laisser
le temps d'optimiser les soft" ?
En admettant que ce soit vrai, entre un processeur rapide sur le papier
et un autre rapide dans la vrai vie j'ai vite choisi.
La seule application où j'ai vu une différence (très) sensible, c'est dnetc ou les PPC+Altivec atomisent les architectures x86 pais sinon...
c'est justement parce que j'utilise dnetc depuis longtemps que je sais que les G5 explosent les X86 quand le dev prend la peine de se mouiller la chemise.
Je ne pense pas que l'on puisse tirer de conclusions générales sur les performances d'un processeur vis-à-vis de son aptitude à mouliner un calcul très spécifique comme le RC5.
maintenant, les devs optimisent pour X86, et adaptent ensuite pour >G5, ce qui donne généralement des résultats minables. C'est la faute des devs, pas du proc.
est-ce une raison pour accepter de travailler avec un proc merdique ?
Euh, ça fait combien d'année qu'Apple nous dis "Le PPC est l'architecture ultime qui va tout pulvériser, il faut juste nous laisser le temps d'optimiser les soft" ?
En admettant que ce soit vrai, entre un processeur rapide sur le papier et un autre rapide dans la vrai vie j'ai vite choisi.
-- arno
patpro ~ patrick proniewski
In article <1hjn8la.1fxyno4m7ipoN%, (arno) wrote:
manet wrote:
Euh, ça fait combien d'année qu'Apple nous dis "Le PPC est l'architecture ultime qui va tout pulvériser, il faut juste nous laisser le temps d'optimiser les soft" ?
En admettant que ce soit vrai, entre un processeur rapide sur le papier et un autre rapide dans la vrai vie j'ai vite choisi.
voilà, puis il n'y a pas que ça, il y a le rapport puissance de calcul sur puissance électrique. Quand je vois mon bi G5 2GHz avec son alim 600W que je suis obligé d'éteindre pendant les périodes de canicule, ça fait réfléchir sur le bien fondé de certains choix technologiques.
patpro
-- http://www.patpro.net/
In article <1hjn8la.1fxyno4m7ipoN%joly@facmed.u-nancy.fr>,
joly@facmed.u-nancy.fr (arno) wrote:
manet <pmanet@invivo.edu> wrote:
Euh, ça fait combien d'année qu'Apple nous dis "Le PPC est
l'architecture ultime qui va tout pulvériser, il faut juste nous laisser
le temps d'optimiser les soft" ?
En admettant que ce soit vrai, entre un processeur rapide sur le papier
et un autre rapide dans la vrai vie j'ai vite choisi.
voilà, puis il n'y a pas que ça, il y a le rapport puissance de calcul
sur puissance électrique. Quand je vois mon bi G5 2GHz avec son alim
600W que je suis obligé d'éteindre pendant les périodes de canicule, ça
fait réfléchir sur le bien fondé de certains choix technologiques.
Euh, ça fait combien d'année qu'Apple nous dis "Le PPC est l'architecture ultime qui va tout pulvériser, il faut juste nous laisser le temps d'optimiser les soft" ?
En admettant que ce soit vrai, entre un processeur rapide sur le papier et un autre rapide dans la vrai vie j'ai vite choisi.
voilà, puis il n'y a pas que ça, il y a le rapport puissance de calcul sur puissance électrique. Quand je vois mon bi G5 2GHz avec son alim 600W que je suis obligé d'éteindre pendant les périodes de canicule, ça fait réfléchir sur le bien fondé de certains choix technologiques.
patpro
-- http://www.patpro.net/
pas.de.spam
manet wrote:
arno wrote:
La seule application où j'ai vu une différence (très) sensible, c'est dnetc ou les PPC+Altivec atomisent les architectures x86 pais sinon...
c'est justement parce que j'utilise dnetc depuis longtemps que je sais que les G5 explosent les X86 quand le dev prend la peine de se mouiller la chemise.
concernant le dnetc, ce n'est pas strictement exact. C'est pour le proc
G4 que ça a été monstrueusement optimisé. Le G5 fait mmieux, uniquement par le jeu de l'augmentation de fréquence, sinon, à fréquence égale, il en fait même moins.
-- PO.
Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr
manet <pmanet@invivo.edu> wrote:
arno <joly@facmed.u-nancy.fr> wrote:
La seule application où j'ai vu une différence (très) sensible, c'est
dnetc ou les PPC+Altivec atomisent les architectures x86 pais sinon...
c'est justement parce que j'utilise dnetc depuis longtemps que je sais
que les G5 explosent les X86 quand le dev prend la peine de se mouiller
la chemise.
concernant le dnetc, ce n'est pas strictement exact. C'est pour le proc
G4 que ça a été monstrueusement optimisé. Le G5 fait mmieux, uniquement
par le jeu de l'augmentation de fréquence, sinon, à fréquence égale, il
en fait même moins.
--
PO.
Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr
La seule application où j'ai vu une différence (très) sensible, c'est dnetc ou les PPC+Altivec atomisent les architectures x86 pais sinon...
c'est justement parce que j'utilise dnetc depuis longtemps que je sais que les G5 explosent les X86 quand le dev prend la peine de se mouiller la chemise.
concernant le dnetc, ce n'est pas strictement exact. C'est pour le proc
G4 que ça a été monstrueusement optimisé. Le G5 fait mmieux, uniquement par le jeu de l'augmentation de fréquence, sinon, à fréquence égale, il en fait même moins.
-- PO.
Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr
