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
jc
Frédéric Testuz wrote:
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é.
Oui, mais c'est dommage de ne pas pouvoir avoir de Fortran sur Mac. Apple a vraiment loupé le coche des applications scientifiques. Tant pis. Mon père achète un PC dans quelques jours.
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é.
Oui, mais c'est dommage de ne pas pouvoir avoir de Fortran sur Mac.
Apple a vraiment loupé le coche des applications scientifiques.
Tant pis. Mon père achète un PC dans quelques jours.
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é.
Oui, mais c'est dommage de ne pas pouvoir avoir de Fortran sur Mac. Apple a vraiment loupé le coche des applications scientifiques. Tant pis. Mon père achète un PC dans quelques jours.
-- JC
listes
Jean-Charles wrote:
Oui, mais c'est dommage de ne pas pouvoir avoir de Fortran sur Mac. Apple a vraiment loupé le coche des applications scientifiques. Tant pis. Mon père achète un PC dans quelques jours.
Il aurait pu attendre quelque jour et prendre un macpro avec bootcamp.... :)
Jean-Charles <jc@qui.net> wrote:
Oui, mais c'est dommage de ne pas pouvoir avoir de Fortran sur Mac.
Apple a vraiment loupé le coche des applications scientifiques.
Tant pis. Mon père achète un PC dans quelques jours.
Il aurait pu attendre quelque jour et prendre un macpro avec
bootcamp.... :)
Oui, mais c'est dommage de ne pas pouvoir avoir de Fortran sur Mac. Apple a vraiment loupé le coche des applications scientifiques. Tant pis. Mon père achète un PC dans quelques jours.
Il aurait pu attendre quelque jour et prendre un macpro avec bootcamp.... :)
laurent.pertois
Xavier wrote:
Laurent Pertois wrote:
Tu sais, les x86 ont bien évolué. Quand je vois qu'avec un MacBook j'encode plus vite en MPEG-2 que sur un G5 Quad, ça fait bizarre...
Le back-end de gcc, optimisé uniquement pour x86, doit y être pour quelque chose, non ?
J'imagine, même si Apple a beaucoup fait pour optimiser les backends PPC ils n'ont jamais atteint la version x86.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Tu sais, les x86 ont bien évolué. Quand je vois qu'avec un MacBook
j'encode plus vite en MPEG-2 que sur un G5 Quad, ça fait bizarre...
Le back-end de gcc, optimisé uniquement pour x86, doit y être pour
quelque chose, non ?
J'imagine, même si Apple a beaucoup fait pour optimiser les backends PPC
ils n'ont jamais atteint la version x86.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Tu sais, les x86 ont bien évolué. Quand je vois qu'avec un MacBook j'encode plus vite en MPEG-2 que sur un G5 Quad, ça fait bizarre...
Le back-end de gcc, optimisé uniquement pour x86, doit y être pour quelque chose, non ?
J'imagine, même si Apple a beaucoup fait pour optimiser les backends PPC ils n'ont jamais atteint la version x86.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
