OK le titre est un peu provoc ;-) mais en passant de "Alubook G4 1 GHz
- 2 Go de RAM - disque ATA 7200" =E0 "MacBook Pro Core 2 Duo 2,33 GHz -
2 Go de RAM - disque SATA 5400", je m'attendais =E0 ce que la nouvelle
machine soit au moins aussi rapide dans toutes ses utilisations. Je
n'ai pas encore tout test=E9, mais =E0 part un temps de d=E9marrage divis=
=E9
par deux, je constate que :
- les ouvertures de session des deux utilisateurs sont aussi longues,
- il y a un d=E9lai de plusieurs secondes lors de la permutation
"rapide" d'utilisateur sur le MBP, alors que c'=E9tait instantan=E9 sur le
PB G4 (les dossiers utilisateurs sont rigoureusement identiques,
transf=E9r=E9s avec Assistant Migration). C'est =E7a qui me g=EAne le plus =
au
quotidien, si vous avez des id=E9es je suis preneur.
- le lancement d'Excel et l'ouverture d'un fichier "basique" (une
vingtaine de colonnes, 200 lignes, et peu de formules) prend 25 s sur
le MBP contre 15 sur le vieux PB. Je sais bien que c'est une appli
Power PC et que Rosetta entre en jeu, mais quand m=EAme le processeur
est en principe 2,33 fois plus rapide et le bus deux fois plus.
- le d=E9lai d'extinction est identique.
personnellement, je me demande si il n'y aurais pas eu; lors de l'installation du MacBookPro une récupération des données.
Oui, il y a eu, comme précisé plus haut.
je n'avais pas lu, c'était à la fin du message.
J'ai lu, je ne sais plus où que certains utilisateurs ayant utilisé cette possibilité avaient rencontré des ralentissements de la machine. Ralentissements supprimés après une clean install SANS récupération données utilisateurs.
J'essaierai ça si l'éradication des mini-logiciels PowerPC ne donnent rien.
tu peux déjà créer un nouvel utilisateur vierge et voir si ça améliorerait pas les choses. -- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Herve <herve.nospam@tiscali.fr> wrote:
On 4 juil, 14:47, pas.de.s...@chez.moi (Pierre-Olivier TAUBATY) wrote:
personnellement, je me demande si il n'y aurais pas eu; lors de
l'installation du MacBookPro une récupération des données.
Oui, il y a eu, comme précisé plus haut.
je n'avais pas lu, c'était à la fin du message.
J'ai lu, je ne sais plus où que certains utilisateurs ayant utilisé
cette possibilité avaient rencontré des ralentissements de la machine.
Ralentissements supprimés après une clean install SANS récupération
données utilisateurs.
J'essaierai ça si l'éradication des mini-logiciels PowerPC ne donnent
rien.
tu peux déjà créer un nouvel utilisateur vierge et voir si ça
améliorerait pas les choses.
--
PO.
personnellement, je me demande si il n'y aurais pas eu; lors de l'installation du MacBookPro une récupération des données.
Oui, il y a eu, comme précisé plus haut.
je n'avais pas lu, c'était à la fin du message.
J'ai lu, je ne sais plus où que certains utilisateurs ayant utilisé cette possibilité avaient rencontré des ralentissements de la machine. Ralentissements supprimés après une clean install SANS récupération données utilisateurs.
J'essaierai ça si l'éradication des mini-logiciels PowerPC ne donnent rien.
tu peux déjà créer un nouvel utilisateur vierge et voir si ça améliorerait pas les choses. -- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Herve
On 4 juil, 16:20, (Pierre-Olivier TAUBATY) wrote:
tu peux déjà créer un nouvel utilisateur vierge et voir si ça améliorerait pas les choses.
J'ai : - supprimé toutes les applis PowerPC qui se lancent au démarrage, - créé un user3 tout neuf.
Et c'est toujours pareil : après avoir saisi le mot de passe de l'utilisateur vers lequel je veux permuter, la fenêtre de saisie disparaît, puis délai de plusieurs secondes avant que je débute la rotation du cube. Tout ceci alors qu'il n'y a aucune appli lancée chez les utilisateurs, ou alors au maxi Mail et Safari (et encore, pas pour tous). Et cerise sur le gâteau (ça je ne le constate que depuis aujourd'hui) : la rotation du cube est parfois saccadée, alors que le MBP a en principe une bien meilleure carte vidéo que le PB (ce qui est confirmé par les chiffres de Xbench). Autre précision : je constate ceci après redémarrage, alors qu'il n'y a aucun fichier de swap à part swapfile0 toujours présent.
Hervé
On 4 juil, 16:20, pas.de.s...@chez.moi (Pierre-Olivier TAUBATY) wrote:
tu peux déjà créer un nouvel utilisateur vierge et voir si ça
améliorerait pas les choses.
J'ai :
- supprimé toutes les applis PowerPC qui se lancent au démarrage,
- créé un user3 tout neuf.
Et c'est toujours pareil : après avoir saisi le mot de passe de
l'utilisateur vers lequel je veux permuter, la fenêtre de saisie
disparaît, puis délai de plusieurs secondes avant que je débute la
rotation du cube. Tout ceci alors qu'il n'y a aucune appli lancée chez
les utilisateurs, ou alors au maxi Mail et Safari (et encore, pas pour
tous). Et cerise sur le gâteau (ça je ne le constate que depuis
aujourd'hui) : la rotation du cube est parfois saccadée, alors que le
MBP a en principe une bien meilleure carte vidéo que le PB (ce qui est
confirmé par les chiffres de Xbench).
Autre précision : je constate ceci après redémarrage, alors qu'il n'y
a aucun fichier de swap à part swapfile0 toujours présent.
tu peux déjà créer un nouvel utilisateur vierge et voir si ça améliorerait pas les choses.
J'ai : - supprimé toutes les applis PowerPC qui se lancent au démarrage, - créé un user3 tout neuf.
Et c'est toujours pareil : après avoir saisi le mot de passe de l'utilisateur vers lequel je veux permuter, la fenêtre de saisie disparaît, puis délai de plusieurs secondes avant que je débute la rotation du cube. Tout ceci alors qu'il n'y a aucune appli lancée chez les utilisateurs, ou alors au maxi Mail et Safari (et encore, pas pour tous). Et cerise sur le gâteau (ça je ne le constate que depuis aujourd'hui) : la rotation du cube est parfois saccadée, alors que le MBP a en principe une bien meilleure carte vidéo que le PB (ce qui est confirmé par les chiffres de Xbench). Autre précision : je constate ceci après redémarrage, alors qu'il n'y a aucun fichier de swap à part swapfile0 toujours présent.
Hervé
gilbert.olivier
Herve wrote:
Autre précision : je constate ceci après redémarrage, alors qu'il n'y a aucun fichier de swap à part swapfile0 toujours présent.
Je ne sais plus si on a évoqué dans un précédent post l'utilisation du moniteur d'activité mais peut être pour voir si une tache occupe tout le temps processeur...
Dans le même genre, regarde avec soit via la palette soit via l'onglet "CPU" si les 2 coeurs travaillent, on ne sait jamais....
-- Gilbert
Herve <herve.nospam@tiscali.fr> wrote:
Autre précision : je constate ceci après redémarrage, alors qu'il n'y
a aucun fichier de swap à part swapfile0 toujours présent.
Je ne sais plus si on a évoqué dans un précédent post l'utilisation du
moniteur d'activité mais peut être pour voir si une tache occupe tout le
temps processeur...
Dans le même genre, regarde avec soit via la palette soit via l'onglet
"CPU" si les 2 coeurs travaillent, on ne sait jamais....
Autre précision : je constate ceci après redémarrage, alors qu'il n'y a aucun fichier de swap à part swapfile0 toujours présent.
Je ne sais plus si on a évoqué dans un précédent post l'utilisation du moniteur d'activité mais peut être pour voir si une tache occupe tout le temps processeur...
Dans le même genre, regarde avec soit via la palette soit via l'onglet "CPU" si les 2 coeurs travaillent, on ne sait jamais....
-- Gilbert
Herve
On 4 juil, 19:59, (Gilbert OLIVIER) wrote:
Je ne sais plus si on a évoqué dans un précédent post l'utilisati on du moniteur d'activité mais peut être pour voir si une tache occupe tout le temps processeur...
Non, rien de spécial.
Dans le même genre, regarde avec soit via la palette soit via l'onglet "CPU" si les 2 coeurs travaillent, on ne sait jamais....
Oui car quand j'ai utilisé Handbrake il travaillait à 176 %, preuve que plus d'un coeur était actif.
Dernier gag en date : quand j'essaie de lire un film en H264 avec VLC, il y a des sautes de son et d'image, et j'ai droit de temps en temps au message d'erreur suivant :
"ffmpeg: more than 5 seconds of late video -> dropping frame (computer too slow ?)"
On 4 juil, 19:59, gilbert.oliv...@wanadoo.fr (Gilbert OLIVIER) wrote:
Je ne sais plus si on a évoqué dans un précédent post l'utilisati on du
moniteur d'activité mais peut être pour voir si une tache occupe tout le
temps processeur...
Non, rien de spécial.
Dans le même genre, regarde avec soit via la palette soit via l'onglet
"CPU" si les 2 coeurs travaillent, on ne sait jamais....
Oui car quand j'ai utilisé Handbrake il travaillait à 176 %, preuve
que plus d'un coeur était actif.
Dernier gag en date : quand j'essaie de lire un film en H264 avec VLC,
il y a des sautes de son et d'image, et j'ai droit de temps en temps
au message d'erreur suivant :
"ffmpeg: more than 5 seconds of late video -> dropping frame (computer
too slow ?)"
Je ne sais plus si on a évoqué dans un précédent post l'utilisati on du moniteur d'activité mais peut être pour voir si une tache occupe tout le temps processeur...
Non, rien de spécial.
Dans le même genre, regarde avec soit via la palette soit via l'onglet "CPU" si les 2 coeurs travaillent, on ne sait jamais....
Oui car quand j'ai utilisé Handbrake il travaillait à 176 %, preuve que plus d'un coeur était actif.
Dernier gag en date : quand j'essaie de lire un film en H264 avec VLC, il y a des sautes de son et d'image, et j'ai droit de temps en temps au message d'erreur suivant :
"ffmpeg: more than 5 seconds of late video -> dropping frame (computer too slow ?)"
Herve
On 4 juil, 10:55, Herve wrote:
Mais une autre constatation m'inquiète : j'ai fait une comparaison sur la vitesse d'encodage d'un DVD en H264, avec Handbrake (dernière version, Intel) : - 4h23 sur le MBP 2,33 GHz 2 Go de RAM, - 1h50 sur un iMac 2,16 GHz 2 Go de RAM. Le tout avec les mêmes réglages de débit bien sur.
Bon je crois que pour ça j'ai trouvé l'explication : quand j'ai fait mon encodage sur le MBP, j'ai retiré la batterie (il est branché sur secteur) pour éviter qu'elle ne chauffe (ce qui n'est pas bon du tout pour la longévité d'icelle). Et il me semble avoir lu qq part (pas retrouvé dans les archives de fcomox ni fcsmm) que sur les MacBook Pro (contrairement aux Powerbooks) quand on retire la batterie la vitesse du proc diminue. Et c'est effectivement ce que je vérifie : avec la batterie, le temps d'encodage du même DVD n'est plus que de 1h40 environ, soit mieux que sur l'iMac (au passage, les histoires de disque plus rapide...;-) Si j'enlève la batterie pendant l'encodage, la vitesse d'encodage chute de manière visible, de 24 fps environ à 11 fps environ, soit à peine moitié moins. Et le ventilo qui tournait à plein régime s'arr ête au bout d'un moment. Même topo pour la lecture d'un fichier H264 avec VLC évoquée plus bas dans l'enfilade : saccadé sans batterie, tout à fait fluide avec. Par contre, ça ne change rien à l'histoire de la permutation d'utilisateurs, ça a l'air d'être un autre problème. Avez-vous entendu parler de cette histoire de fonctionnement à vitesse réduite quand le MBP est sur secteur sans batterie ? Je ne vois pas l'intérêt, par contre je vois bien l'inconvénient. Y a- t-il moyen de contourner ça ?
Hervé
On 4 juil, 10:55, Herve <herve.nos...@tiscali.fr> wrote:
Mais une autre constatation m'inquiète : j'ai fait une comparaison sur
la vitesse d'encodage d'un DVD en H264, avec Handbrake (dernière
version, Intel) :
- 4h23 sur le MBP 2,33 GHz 2 Go de RAM,
- 1h50 sur un iMac 2,16 GHz 2 Go de RAM.
Le tout avec les mêmes réglages de débit bien sur.
Bon je crois que pour ça j'ai trouvé l'explication : quand j'ai fait
mon encodage sur le MBP, j'ai retiré la batterie (il est branché sur
secteur) pour éviter qu'elle ne chauffe (ce qui n'est pas bon du tout
pour la longévité d'icelle).
Et il me semble avoir lu qq part (pas retrouvé dans les archives de
fcomox ni fcsmm) que sur les MacBook Pro (contrairement aux
Powerbooks) quand on retire la batterie la vitesse du proc diminue.
Et c'est effectivement ce que je vérifie : avec la batterie, le temps
d'encodage du même DVD n'est plus que de 1h40 environ, soit mieux que
sur l'iMac (au passage, les histoires de disque plus rapide...;-)
Si j'enlève la batterie pendant l'encodage, la vitesse d'encodage
chute de manière visible, de 24 fps environ à 11 fps environ, soit à
peine moitié moins. Et le ventilo qui tournait à plein régime s'arr ête
au bout d'un moment.
Même topo pour la lecture d'un fichier H264 avec VLC évoquée plus bas
dans l'enfilade : saccadé sans batterie, tout à fait fluide avec.
Par contre, ça ne change rien à l'histoire de la permutation
d'utilisateurs, ça a l'air d'être un autre problème.
Avez-vous entendu parler de cette histoire de fonctionnement à vitesse
réduite quand le MBP est sur secteur sans batterie ?
Je ne vois pas l'intérêt, par contre je vois bien l'inconvénient. Y a-
t-il moyen de contourner ça ?
Mais une autre constatation m'inquiète : j'ai fait une comparaison sur la vitesse d'encodage d'un DVD en H264, avec Handbrake (dernière version, Intel) : - 4h23 sur le MBP 2,33 GHz 2 Go de RAM, - 1h50 sur un iMac 2,16 GHz 2 Go de RAM. Le tout avec les mêmes réglages de débit bien sur.
Bon je crois que pour ça j'ai trouvé l'explication : quand j'ai fait mon encodage sur le MBP, j'ai retiré la batterie (il est branché sur secteur) pour éviter qu'elle ne chauffe (ce qui n'est pas bon du tout pour la longévité d'icelle). Et il me semble avoir lu qq part (pas retrouvé dans les archives de fcomox ni fcsmm) que sur les MacBook Pro (contrairement aux Powerbooks) quand on retire la batterie la vitesse du proc diminue. Et c'est effectivement ce que je vérifie : avec la batterie, le temps d'encodage du même DVD n'est plus que de 1h40 environ, soit mieux que sur l'iMac (au passage, les histoires de disque plus rapide...;-) Si j'enlève la batterie pendant l'encodage, la vitesse d'encodage chute de manière visible, de 24 fps environ à 11 fps environ, soit à peine moitié moins. Et le ventilo qui tournait à plein régime s'arr ête au bout d'un moment. Même topo pour la lecture d'un fichier H264 avec VLC évoquée plus bas dans l'enfilade : saccadé sans batterie, tout à fait fluide avec. Par contre, ça ne change rien à l'histoire de la permutation d'utilisateurs, ça a l'air d'être un autre problème. Avez-vous entendu parler de cette histoire de fonctionnement à vitesse réduite quand le MBP est sur secteur sans batterie ? Je ne vois pas l'intérêt, par contre je vois bien l'inconvénient. Y a- t-il moyen de contourner ça ?
Hervé
Eric Levenez
Le 4/07/07 21:31, dans , « Herve » a écrit :
Je ne vois pas l'intérêt, par contre je vois bien l'inconvénient. Y a- t-il moyen de contourner ça ?
As-tu regardé les réglages dans les Préférences système, onglet Économie d'énergie ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 4/07/07 21:31, dans
<1183577506.397919.164330@q75g2000hsh.googlegroups.com>, « Herve »
<herve.nospam@tiscali.fr> a écrit :
Je ne vois pas l'intérêt, par contre je vois bien l'inconvénient. Y a-
t-il moyen de contourner ça ?
As-tu regardé les réglages dans les Préférences système, onglet Économie
d'énergie ?
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Je ne vois pas l'intérêt, par contre je vois bien l'inconvénient. Y a- t-il moyen de contourner ça ?
As-tu regardé les réglages dans les Préférences système, onglet Économie d'énergie ?
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Herve
On 4 juil, 22:53, Eric Levenez wrote:
As-tu regardé les réglages dans les Préférences système, onglet Économie d'énergie ?
Ces réglages ne permettent que d'agir sur les délais de mise en vielle de l'écran et de la machine, pas sur les performances du processeur.
Après une petite recherche je m'aperçois qu'il s'agit là d'un bug connu mais hélas non résolu par Apple, qui est même allé jusqu'à clore le fil de discussion à ce sujet sur http://discussions.apple.com : <http://www.appledefects.com/?pD> <http://forums.macrumors.com/showpost.php?p854423&postcount> <http://www.macintouch.com/readerreports/macbook/ topic4267.html#07nov2006> (rechercher le mot "battery".
Je redirige le fil vers fcsmm, plus adapté.
Hervé
On 4 juil, 22:53, Eric Levenez <n...@levenez.com> wrote:
As-tu regardé les réglages dans les Préférences système, onglet Économie
d'énergie ?
Ces réglages ne permettent que d'agir sur les délais de mise en vielle
de l'écran et de la machine, pas sur les performances du processeur.
Après une petite recherche je m'aperçois qu'il s'agit là d'un bug
connu mais hélas non résolu par Apple, qui est même allé jusqu'à clore
le fil de discussion à ce sujet sur http://discussions.apple.com :
<http://www.appledefects.com/?p=44>
<http://forums.macrumors.com/showpost.php?p=3854423&postcount=14>
<http://www.macintouch.com/readerreports/macbook/
topic4267.html#07nov2006> (rechercher le mot "battery".
As-tu regardé les réglages dans les Préférences système, onglet Économie d'énergie ?
Ces réglages ne permettent que d'agir sur les délais de mise en vielle de l'écran et de la machine, pas sur les performances du processeur.
Après une petite recherche je m'aperçois qu'il s'agit là d'un bug connu mais hélas non résolu par Apple, qui est même allé jusqu'à clore le fil de discussion à ce sujet sur http://discussions.apple.com : <http://www.appledefects.com/?pD> <http://forums.macrumors.com/showpost.php?p854423&postcount> <http://www.macintouch.com/readerreports/macbook/ topic4267.html#07nov2006> (rechercher le mot "battery".
Je redirige le fil vers fcsmm, plus adapté.
Hervé
geeks
Laurent Pertois wrote:
Frédérique & Hervé Sainct wrote:
j'ai l'impression que les codes intel sont aussi un peu plus gourmands en mémoire...
Oui, je pense aussi. Je ne sais pas si c'est un signe mais quand on voit parfois les applis qui sont téléchargeables en PPC ou en Intel on voit cette dernière version plus lourde.
En théorie c'est l'inverse, les instructions PowerPC sont de taille fixe (32 bits) et normalement sont plus élémentaires (donc il en faut plus pour faire un truc compliqué), alors que les instructions x86 sont de taille variable et font potentiellement plus de choses.
C'est pour ça que les processeurs RISC ont souvent eu recours à de gros cache L1 de type instruction, car le code devrait être plus gros que sur x86.
Après c'est une question de qualité du compilateur, normalement GCC connait plus intimement les processeurs Intel et procède peut-être à plus d'optimisations qui allourdissent le code tout en le rendant plus rapide.
Concernant la taille des binaires, il arrive que les versions « Intel » soient en fait des Universal Binaries et donc logiquement plus lourdes.
j'ai l'impression que les codes intel sont aussi un peu plus gourmands
en mémoire...
Oui, je pense aussi. Je ne sais pas si c'est un signe mais quand on voit
parfois les applis qui sont téléchargeables en PPC ou en Intel on voit
cette dernière version plus lourde.
En théorie c'est l'inverse, les instructions PowerPC sont de taille fixe
(32 bits) et normalement sont plus élémentaires (donc il en faut plus
pour faire un truc compliqué), alors que les instructions x86 sont de
taille variable et font potentiellement plus de choses.
C'est pour ça que les processeurs RISC ont souvent eu recours à de gros
cache L1 de type instruction, car le code devrait être plus gros que sur
x86.
Après c'est une question de qualité du compilateur, normalement GCC
connait plus intimement les processeurs Intel et procède peut-être à
plus d'optimisations qui allourdissent le code tout en le rendant plus
rapide.
Concernant la taille des binaires, il arrive que les versions « Intel »
soient en fait des Universal Binaries et donc logiquement plus lourdes.
j'ai l'impression que les codes intel sont aussi un peu plus gourmands en mémoire...
Oui, je pense aussi. Je ne sais pas si c'est un signe mais quand on voit parfois les applis qui sont téléchargeables en PPC ou en Intel on voit cette dernière version plus lourde.
En théorie c'est l'inverse, les instructions PowerPC sont de taille fixe (32 bits) et normalement sont plus élémentaires (donc il en faut plus pour faire un truc compliqué), alors que les instructions x86 sont de taille variable et font potentiellement plus de choses.
C'est pour ça que les processeurs RISC ont souvent eu recours à de gros cache L1 de type instruction, car le code devrait être plus gros que sur x86.
Après c'est une question de qualité du compilateur, normalement GCC connait plus intimement les processeurs Intel et procède peut-être à plus d'optimisations qui allourdissent le code tout en le rendant plus rapide.
Concernant la taille des binaires, il arrive que les versions « Intel » soient en fait des Universal Binaries et donc logiquement plus lourdes.
-- F
laurent.pertois
Frédéric Kayser wrote:
Concernant la taille des binaires, il arrive que les versions « Intel » soient en fait des Universal Binaries et donc logiquement plus lourdes.
Je séparais bien ce cas, justement. Je ne parlais que de certains cas où l'on peut trouver une version Universa, une version PPC et une version Inel, cf, sjmsb, VLC.
Sinon, ça fait plaisir de te relire :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Frédéric Kayser <geeks@free.fr> wrote:
Concernant la taille des binaires, il arrive que les versions « Intel »
soient en fait des Universal Binaries et donc logiquement plus lourdes.
Je séparais bien ce cas, justement. Je ne parlais que de certains cas où
l'on peut trouver une version Universa, une version PPC et une version
Inel, cf, sjmsb, VLC.
Sinon, ça fait plaisir de te relire :-)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Concernant la taille des binaires, il arrive que les versions « Intel » soient en fait des Universal Binaries et donc logiquement plus lourdes.
Je séparais bien ce cas, justement. Je ne parlais que de certains cas où l'on peut trouver une version Universa, une version PPC et une version Inel, cf, sjmsb, VLC.
Sinon, ça fait plaisir de te relire :-)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
sebastienmarty
Olivier Marti wrote:
Une piste : Rosetta utilise pas mal de mémoire il me semble.
Je confirme (expérience ici avec Word et Excel).
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
Olivier Marti <olivier.marti@ensta.org> wrote:
Une piste : Rosetta utilise pas mal de mémoire il me semble.
Je confirme (expérience ici avec Word et Excel).
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
