Accroître l'utilisation du processeur pour une tâche

eric210766

Membre confirmé
5 Septembre 2007
47
1
Compiègne
j'ai un Dual Core 2 et j'aimerai réduire le temps de compression de mes sauvegardes effectuées à l'aide de DropStuff en faisant travailler les deux puces à fond ! Je n'ai rien trouvé au niveau du Moniteur d'activité. J'ai remarqué que le % du processeur plafonnait à 100. Il pourrait aller au moins à 190 !
Quelqu'un a-t-il une idée ?

Merci.
 
j'ai un Dual Core 2 et j'aimerai réduire le temps de compression de mes sauvegardes effectuées à l'aide de DropStuff en faisant travailler les deux puces à fond ! Je n'ai rien trouvé au niveau du Moniteur d'activité. J'ai remarqué que le % du processeur plafonnait à 100. Il pourrait aller au moins à 190 !
Quelqu'un a-t-il une idée ?

Merci.
100% ça doit include les deux procésseurs je pense non ?
En plus c'est plutôt possible parce que à priori compresser plusieurs fichiers doit pouvoir se faire fichier par fichier et donc facilement profiter de plusieurs core. Mais j'en suis pas certains. :)
 
alors mais vraiment n'importe quoi guigui :rolleyes:
tu sais tes procs ne travaillent pas en parallel...

bon je vais pas trop le casser:rolleyes: et juste un truc faut pas confondre avec le temps CPU...
 
alors mais vraiment n'importe quoi guigui :rolleyes:
tu sais tes procs ne travaillent pas en parallel...

bon je vais pas trop le casser:rolleyes: et juste un truc faut pas confondre avec le temps CPU...
C'est moi j'ai dis des bêtises ou c'est eric-codepostaletropgrand ? ^^
 
Les sauvegardes sont constituées de plusieurs fichiers. Ainsi, le parallélisme est possible sans problème.
En ce qui concerne le %, je viens de vérifier au niveau du moniteur, DropStuff est à 100 alors que le % inactif est à 38,78 %. J'ai d'autres applications ouvertes.
C'est d'autant plus bizarre qu'il dispose d'un Nombre de fils > 1.

Je ne comprend les propos de Tatouille. Expliques-toi ?
 
Les sauvegardes sont constituées de plusieurs fichiers. Ainsi, le parallélisme est possible sans problème.

J'aurais tendance à répondre que non, puisque tu n'as qu'un disque…
D'ailleurs, tu pars du principe que c'est ton processeur qui ralentit l'exécution. Je suis quasiment sûr que ce sont plutôt les lectures/écritures de fichiers. Tu pourrais faire un essai avec un RAM Disk pour voir.

Pour ce qui est du taux d'occupation CPU, d'après ce que j'ai vu en cours, il ne signifie pas grand chose.
Stuffit Expander existe sur Mac depuis des années. Je serais étonné qu'il n'utilise pas tous les noyaux de ton proc.
 
1- des procs ca ne marche pas en parallele on ne sait pas faire ou alors filer moi le design de votre puce et je depose une patente

2- c'est le system qui gere la premption
3- pour stuffit ou autre soft ils ont kenini a propos de la gestion des procs
4- l'acces disk plus c' est gros plus ca prend du temps cest pas tant une vitesse proc q,une mise en tampon (mem) et aussi la vitesse permise pour la lecture mais bon

les procs c'est comme des diodes qui s'allument et s'eteignent a leur possibilites de freq
le % CPU est le temps CPU alloue ca veut dire quelque chose mais rien en fonction de la premiere theorie fumeuse
 
1- des procs ca ne marche pas en parallele on ne sait pas faire ou alors filer moi le design de votre puce et je depose une patente

Ah bon, et à quoi sert le multiprocessing, alors ?
Le problème, c'est l'accès concurrentiel à la RAM, mais bien sûr que les proc travaillent en parallèle.
 
Je suis d'accord avec Céroce. Il y effectivement des ralentissements tant au niveau des accès disques que de la RAM. Ce dernier cas étant tout simplement lié au fait que les deux puces partagent les mêmes bus.
Bref, restons-en là. Et merci à tous ceux qui sont intervenus.
Joyeux Noël à tous.
 
Ah bon, et à quoi sert le multiprocessing, alors ?
Le problème, c'est l'accès concurrentiel à la RAM, mais bien sûr que les proc travaillent en parallèle.

le multi processing ca sert de passer de l'un a l'autre tres rapidemment
afin de deviser le calcul en aucun cas a T on a calcul1 et calcul2, c'est comme ca que l'on a regle
des barrieres impossible a franchir comme la sync totale (latency), c'est appele parallele parce que pour une Info ca divise,
mais ca ne le fait pas en meme temps donc electroniquement parlant c'est un abus de language, cest les memes problemes que les cylindres dun moteur, la gestion CPU et quelque choses d'assez touchi, a savoir quel proc est en train de travailler a T pour un thread, tu peux l'avoir avec un simple dtrace sur ton leo