Canard plus lent que Puma...

Au fait, vu que c'est à peu près le seul truc que j'attende réellement de la prochaine mise à jour de Mac OS X…
Une copie depuis une cartouche ZIP au format MS-DOS, ce sera aussi rapide que pour un format HFS+ ?
 
Tiens, moi aussi, je propose un test qui arrache tout…
grin.gif

On va y démontrer deux-trois trucs… (Sur un iMac G3/450 avec 512 Mo de RAM, donc.)

On lance donc un top dans le Terminal, puis iTunes à qui on demande de jouer un mp3, et Audion à qui on demande de faire de même (mais pas le même mp3, quand même, sinon, on a du mal à reconnaître qui joue quoi…). Jusque là, tout va bien, on entend distinctement un très beau mix…
grin.gif

Et maintenant, le clou du spectacle, on change le volume !!! Oui, vous avez bien lu ! Dans iTunes, je change le volume… Eh ben que se passe-t-il ? Je ne vous fais pas attendre plus longtemps : le volume change !!! Oui. Sans que le mp3 d'iTunes ne saute, ni celui d'Audion. Et le top nous indique qu'iTunes s'est contenté de 60% du CPU. Tout à fait…

Le test ayant été réalisé sous Mac OS X 10.1.4 — la version officielle la plus récente de Mac OS X, rappelons-le, et qui à ce titre est la seule à pouvoir être utilisée pour ce genre de test hautement révélateur —, tout me laisse à penser que les programmeurs d'Apple seront capables de réitérer cette prouesse pendant les 4 mois qu'il leur reste pour finaliser Jaquar.

Ce que ce test à démontré :
- C'est chaud d'écouter deux mp3s à la fois, même si on a deux oreilles,
- Les programmeurs d'Apple sont quand même capables de faire un logiciel qui tienne à peu près la route,
- Top — et on ne le répétera jamais assez — n'est pas représentatif de ce qui se passe réellement au niveau du CPU, tout simplement parce qu'au mieux, il n'affiche ses résultats que toutes les secondes.

(Pour faire bonne mesure, je viens de refaire le test en ajoutant une contrainte supplémentaire : la lecture d'un DVD. Ça ne sert toujours à rien, mais bon…
Aucun des deux mp3s n'a sauté, le film à peine, mais je dois admettre que les menus manquaient de réactivité, et que le top n'affichait plus rien. Au final, je suis confiant. Si 10.1.4 peut le faire, 10.2/5 le pourra aussi.)

Sans rancune, je veux bien la réponse à la question des cartouches Zip au format MS-DOS, quand même…

[J'oubliais… Pendant le premier test, locate a en plus mis à jour sa base de données…]

[02 juin 2002 : message édité par Gwenhiver]
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Gwenhiver:
Et maintenant, le clou du spectacle, on change le volume !!! Oui, vous avez bien lu ! Dans iTunes, je change le volume… Eh ben que se passe-t-il ? Je ne vous fais pas attendre plus longtemps : le volume change !!! Oui. Sans que le mp3 d'iTunes ne saute, ni celui d'Audion.<HR></BLOCKQUOTE>

Evidemment, vu que la décompression MP3 est prioritaire sur les interfaces utilisateurs des deux softs.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Et le top nous indique qu'iTunes s'est contenté de 60% du CPU. Tout à fait…<HR></BLOCKQUOTE>

Pareil chez moi sur 10.2, mais le Window manager prend 30% tandis que top en prend 10 environ. Donc il reste bien 0%.
Or quand il reste 0% de puissance dispo, c'est le truc le moins prioritaire qui saccade, en l'occurence, le feedback visuel du volume d'iTunes qui est très saccadé.

Enfin bon, si toi tu trouves que c'est un progrès d'avoir tout le mac qui s'arrête quand tu règles un petit bouton de volume ou la lecture DVD qui saute, alors qu'il y a plein de puissance dans la machine...

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>- Les programmeurs d'Apple sont quand même capables de faire un logiciel qui tienne à peu près la route,<HR></BLOCKQUOTE>

Là je t'arrête tout de suite: je ne crois pas que l'on puisse dire que les softs Apple soient dans les plus réactifs et légers d'OS X: iTunes, QuickTime Player (ha, ha, ha), Sherlock (mort de rire pour celui là)...
grin.gif


<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>- Top — et on ne le répétera jamais assez — n'est pas représentatif de ce qui se passe réellement au niveau du CPU, tout simplement parce qu'au mieux, il n'affiche ses résultats que toutes les secondes.<HR></BLOCKQUOTE>

Top est tout à fait représentatif dans le cas qui nous intéresse car on mesure une tâche continue.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Au final, je suis confiant. Si 10.1.4 peut le faire, 10.2/5 le pourra aussi.)<HR></BLOCKQUOTE>

Ah, perdu! Justement, si dans 10.2 le Window Manager se met à bouffer 20-30% de puissance en permanence, il reste moins de puissance pour les applis.
C'est pour ca que le DVD sautait dans 10.2 et pas dans 10.1 sur mon Pismo.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Sans rancune, je veux bien la réponse à la question des cartouches Zip au format MS-DOS, quand même…<HR></BLOCKQUOTE>

J'ai pas de zip USB
grin.gif
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par P O L:
J'ai pas de zip USB
grin.gif
<HR></BLOCKQUOTE>

Dommage…

Pour le reste, ça me rappelle les discussions d'un certain DG…
rolleyes.gif

Enfin bon, amuse-toi bien avec ton Jaguar et essaye quand même Key Xing, les commandes de pilotage d'iTunes y sont intégrées.
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par P O L:


Comment on fait pour faire ça de toute façon? J'ai jamais vraiment réussi la manip...
<HR></BLOCKQUOTE>

P O L : connecte ton pb éteint à un clavier/écran/souris externe, ouvre le capot, appuye sur le bouton d'allumage, referme immédiatement le capot, et 2 comportements possibles :
- tout baigne, il boote et fonctionne avec le clavier et l'écran externe
- soit il se remet en veille immédiatement à la fermeture du capot, sans même booter.

C'est un gros pb des possesseurs de Ti qui utilisent leurs portables en nomade et avec un écran/clavier externe en fixe.

J'ai fonctionné ainsi longtemps avec 2 pb G3 (Os 9), et avec mon actuel Ti 550 en Os 10.1.2.
Depuis le 10.1.3 ce n'est plus possible, la fermeture du capot le met en veille immédiatement, sans même booter.
Donc, comme de nombreux autres possesseurs de Ti avec écran externe je reste en 10.1.2.

D'où ma curiosité par rapport à "canard" :)

Pascal.
 
Difficile de donner un avis sur quelque chose qu on est pas sencé avoir sur sa machine et donc que je n ai pas testé.

Donc ma contribution sera plus celle d un lecteur de forum que celui d un faux beta testeur !

Alors c'était juste pour dire que j ai lu des réactions complètement inverses sur la 10.2 utilisé sur un pismo
beaucoup plus réactif plus rapide etc...

Donc je reviendrai vous donner mon avis en septembre
car j ai aussi un pismo et c'est vrai que te toutes mes bécannes y compris un imac dv c'est sur le pismo que la 10.1.4 est le moins réactif !
 
Pour info, j'ai testé les build 6C35 et 6C48 de Jaguar sur mon iBook 500/384Mb.

6C35 :

Finder + reactif. Par contre l'interface Aqua en general est PLUS LENTE que 10.1. Le temps de boot est aussi plus long que 10.1. Bref a choisir, je prends 10.1.

6C48:

Finder toujours + reactif. Les applis sont plus instables que sur 6C35 (bcp de crashs). Bcp de problemes d'affichage (avec QT par exemple). Par contre l'UI est maintenant + rapide que 10.1 ! (la difference n'est pas enorme par rapport a 10.1, mais significative par rapport a la lenteur du build 6C35.
Le SystemUIServer prend 0.9% de CPU et top prend entre 4 et 7% de CPU.

Je suppose que ca devrait s'amerliorer encore un peu d'ici la version finale... Donc je pense qu'on peut esperer une modeste acceleration d'Aqua meme sur les G3...

[02 juin 2002 : message édité par pat++]
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par P O L:
Mon Pismo doit à peine durer 1h1/2 et j'ai lu un test sur le dernier Titanium, et il disait que c'était pareil. <HR></BLOCKQUOTE>

Le vrai problème, c'est que même sur des données dont on pourrait croire qu'elles sont objectives, personne n'est d'accord...
Mon Titanium me permet de faire un trajet de TGV de 3 heures les doigts dans le nez, sous osX...

la dernière fois, j'ai eu le temps de mater un divx de 2 heures, et il me restait 30 minutes de batterie.
 
Pour le test iTunes, je n'ose pas trop commenter, de peur de passer pour un retardé fini, mais bon, je me lance quand même… Mon iMac n'était livré qu'avec une souris, et je n'ai que deux mains, donc quand je règle le volume dans Audion, je n'ai de toute façon pas besoin que le processeur puisse faire autre chose. Et quand bien même ce serait le cas, ça prend pas deux plombes pour régler le volume, donc je ne vois pas où est le problème.

Quant aux bugs inacceptables du Finder, je ne les rencontre jamais… Faut dire que je n'utilise pas le Finder, aussi…

Il n'y a que la réactivité de Project Builder qui me dérange en fait.

(Et puis la rengaine du lecteur MP3 sous Windows, c'est un peu de la mauvaise foi aussi, ça…
tongue.gif
De toute façon, chaque fois qu'il y a un problème sur Mac OS X, on nous sort le coup du MP3 sous Windows. A croire qu'un PC ne sait lire que des MP3s…
grin.gif
)
 
Et puis comme d'hab, il faut relativiser… Qu'est-ce que ça peut bien faire que le processeur soit utilisé à 100% par iTunes le temps de régler le volume, puisque de toute façon le temps que tu pousses le curseur de ta souris jusqu'au potentiomètre d'iTunes, tu as déjà perdu tes précieux centièmes de secondes.

(Ceci dit, j'ai fait le test sur 10.1.4 : si régler le volume dans Audion par le bouton idoine occupe 80% du CPU tant que le bouton de la souris est enfoncé, régler le volume par le biais d'AppleScript est invisible. Il suffit donc d'écrire un script et de l'associer à une touche de fonction avec Key Xing. Tu économises même le déplacement de la souris…
wink.gif
)
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR> J'ai fait un autre test et celui tu pourras pas dire que c'est tiré par les cheveux! Que top dans le terminal et iTunes sont lancés (iTunes est en mode fenêtre réduite). Le simple fait de faire glisser le bouton de volume dans iTunes consomme 100% de puissance processeur et son déplacement n'est pas fluide!!!! Tu ne va pas me dire que c'est normal ou pas important ça quand même...
On fait tout un cinéma avec Quarz Extreme qui permet de décharger le processeur, et à coté de ça, une simple opération comme ça le met par terre. D'accord, c'est pas un Titanium 800 avec 1Gb de RAM mon portable, mais faut pas pousser non plus: un G3/400 avec 384Mb de RAM et un disque neuf, ca reste très puissant. Un changement de volume ca devrait pas prendre plus de 50% à tout casser! Bon sang, il ne s'agit juste que de changer un volume et dessiner zone de 200pix par 20 à l'écran! Comment Apple fait pour mettre le processeur par terre avec un truc aussi basique?!
Montre ça à un utilisateur de PC en lui disant que ton OS est véloce, et il va être mort de rire <HR></BLOCKQUOTE>

je ne suis pas d'accord avec toi.
je ne conteste pas les 100% observe mais je serai un peu critique sur la maniere dont a ete mesuree ces 100%.
il faudrait savoir si ces 100% d'occupation sont le resultat d'une mesure ponctuelle a un instant T ou une moyenne sur par exemple, 500ms ou 1s.

parce qu'il est evident que lorsque tu fais faire qque chose au processeur, il est a "100%" quand il compute et si TOP vient rafraichir ces donnes a ce moment la ou fait une moyenne sur un temps tres court, il va mesurer 100% d'occupation.

il faudrait le mettre en rapport avec le temps d'inoccupation sur un intervale de temps plus long.

ceci dit je ne constest pas qui y a des ralentissements qui n'ont pas lieu d'etre en regard de ce qui est demande a la machine.

sur mon 667 DVI, lorsque j'ouvre une multitude de fenetres IE, il y a parfois - et ca n'est pas systematique- des ralentissement qui ressemblent bcp a un probleme d'optimisation
 
Si l'on compare l'évolution des beta de puma a celle de jaguar, jaguar devrait etre une belle petite bete qd meme.

Les premieres beta de puma tournait tres bien et était super fluide. Seulement il bouffait pas mal de cpu. Je suppose (je ne suis pas programmeur) que a partir d'un certain moment les prog d'apple vont commencer a épurer leur code, l'optimiser au maximum seulement dans les dernieres betas. Ici ils ont quand meme developpé une nouvelle technologie (quartz extreme) et ils vont sans doute surement la fignoler a la fin.

Je me tormpe peut etre tte facon tt ca ne rime a pas grand chose, on verra ce qu'on verra lors de la finale
wink.gif
(pas de foot, mais bien de jaguar)
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Gwenhiver:
[QB]Mais personne a parlé d'attendre…
Mac OS X est véloce sur mon système (un G3/450 à 512 Mo de RAM), et quoi que vous en pensiez, il n'y aurait pas de Jaquar que ça me serait égal.
<HR></BLOCKQUOTE>

Tout à fait bien dit, mon Imac dv400 avec aussi 512 mo de ram fonctionne à merveille sous X, même avec 10000 mp3 et un DD de 60 Go rempli à 85%.... alors il ne faut pas faire de catastrophisme.
wink.gif
 
Franchement je sais pas de quoi vous vous plaigneez j'ai installé Canard sur un disque externe FireWire, je démarre dessus avec l'iBook de Ma Puce (600Mhz, 128 Mo de RAM, et la carte graphique d'origine) et ben franchement cela va nettement mais alors nettement plus vite qu'avant, j'arrive enfin à utiliser des trucs bien lourds (du genre toshop, golive et illustrator en même temps) donc moi je vous dis qu'on est sur la bonne voix...

Il faut encore bien se dire qqch, le code de débug doit être hyper présent des ces versions de Jaguar alors cela doit pas mal ralentir la chose...quand à dire que les programmeurs d'Apple ne savent pas programmé je trouve cela un peu gonflé vu le travail fournit par cette équipe rien que pour OS X tu n'as pas le droit de dire qu'ils ne savent pas programmer (même s'il est pas hyper optimisé, l'exploit de coller un UNIX avec l'interface graphique et la simplicité du mac reste un exploit)
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Nicolas du Japon:
il faudrait savoir si ces 100% d'occupation sont le resultat d'une mesure ponctuelle a un instant T ou une moyenne sur par exemple, 500ms ou 1s.

parce qu'il est evident que lorsque tu fais faire qque chose au processeur, il est a "100%" quand il compute et si TOP vient rafraichir ces donnes a ce moment la ou fait une moyenne sur un temps tres court, il va mesurer 100% d'occupation.
<HR></BLOCKQUOTE>

Tu as tout à fait raison. En fait un processeur tourne toujours à 100%, puisqu'il exécute en permanence du code: il ne passe pas en veille. Par contre, soit il exécute du code d'une tâche d'une appli, soit d'une tâche d'attente (qui ne fait rien).
C'est pour ca que top mesure forcément des moyennes: il ne peut pas en être autrement - ca n'aurait aucun sens sinon. Et une moyenne est tout à fait représentative.

Dans le cas d'iTunes et de mes petits tests, l'occupation du processeur est donc bien représentative (en fait, ce n'est pas 100% pour iTunes bien sûr, car l'OS ne le permettrait pas, mais 60% + 30% pour le window server + 10% pour top). Mais toujours est-il que c'est anormal: quand le bouton n'est meme pas déplacé, iTunes ne devrait pas prendre plus de 20% et le window server quasi rien.

Enfin bon, pas mal d'entre vous disent que ca n'a aucune importance, mais ce que vous devez comprendre c'est que ce genre de petits détails multipliés par milliers dans l'OS, les applis... c'est ce qui fait qu'on as un OS lourd et poussif sur les petites configs.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>sur mon 667 DVI, lorsque j'ouvre une multitude de fenetres IE, il y a parfois - et ca n'est pas systematique- des ralentissement qui ressemblent bcp a un probleme d'optimisation<HR></BLOCKQUOTE>

Ca sous MacOS X, on ne peut malheureusement rien y faire, car contrairement à OS 9, chaque fenêtre à un buffer allouée en mémoire. Une fenêtre en 800x600 nécessite 1.8Mb minimum. Si tu ouvres 10 fenêtres dans IE, et que t'en as déjà 10 ouvertes à l'écran, que tu as peu de RAM, ca explique les lenteurs, car la mémoire virtuelle va devoir swapper.

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Simon:
quand à dire que les programmeurs d'Apple ne savent pas programmé je trouve cela un peu gonflé vu le travail fournit par cette équipe rien que pour OS X tu n'as pas le droit de dire qu'ils ne savent pas programmer<HR></BLOCKQUOTE>

Ce n'est à priori pas les mêmes équipes qui font l'OS et les applis. Dans le cas des applis, je maintiens ce que j'ai dit: la programmation est loin d'être bonne pour pas mal de softs.
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR> Tu as tout à fait raison. En fait un processeur tourne toujours à 100%, puisqu'il exécute en permanence du code: il ne passe pas en veille. <HR></BLOCKQUOTE>

la tu m'etonnes. comment expliquer alors l'echauffement d'un cpu en usage intensif si il est toujours en train de computer du code utilisateur ou systeme?
et aussi ce petit progamme PC CPU idle qque chose qui desactivait le cpu qd il n'est pas sollicite pour reduire l'echauffement et la conso
confused.gif


<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR> Dans le cas d'iTunes et de mes petits tests, l'occupation du processeur est donc bien représentativ <HR></BLOCKQUOTE>

j'ai fait l'essai, ca se bloque a 100% quand on maintient le clique. c'est effectivement idiot.
Est ce un bon exemple de ce qui fait la lourdeur X ou est ce une coquille sans rapport avec le reste?

<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR> pour ma part en ce moment je suis en train d'essayer MacAmp lite (demo)...

Alors la c'est clair qu'il est bien plus leger que iTunes ou Meme Audion !!!! <HR></BLOCKQUOTE>

ouais mais alors c'est pas un model de stabilite.
a fait son petit tour et puis est parti dans la corbeille.
wink.gif
 
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Nicolas du Japon:

j'ai fait l'essai, ca se bloque a 100% quand on maintient le clique. c'est effectivement idiot.
Est ce un bon exemple de ce qui fait la lourdeur X ou est ce une coquille sans rapport avec le reste?
<HR></BLOCKQUOTE>

les gens font une fixation sur le 100% mais au contraire : si vous faites une tache alors que le processeur est occupe a 60% et bien la logique veut qu'il utilise le reste pour accomplir ca tache (de toute facons vous ne faisiez rien avec le reste non?)! si vous avez 80% de pris et vous faite le coup du bouton de son et bien itune prendra les 20% restant pour accomplir sa tache. je ne vois la rien de choquant ! vous voulez quoi un processeur qui ne soit pas utilisé a 100%?
 
Juste une petite notion à propos du multitaches ...
Ce n'est pas parce qu'une application monopolise le processeur qu'il n'y a pas de multitaches ... Celà indique simplement qu'elle consomme du cpu et qu'aucune autre tache n'en avait besoin ...
Donc l'exemple d'iTunes prouve une chose et une seule. Le règlage du volume a été mal programmé, et consomme beaucoup trop d'UC ... celà ne prouve rien au niveau d'OsX. Pour démontrer un souci au niveau du gestionnaire de taches, il aurait fallu montrer (ce que Gwenhiver a fait dans son dernier post), qu'il y avait problème lorsque plusieurs programmes lancés simultanément réclamaient ensemble du cpu ... Et il n'en ai rien.

Remarque aussi : une version beta peut effectivement être 25% plus lente que la version finale ... et même plus ! Celà dépends de la quantité d'infos de déboguage traitée, et du niveau d'optimisation du code.