Quelqu'un aurait-il une machine multi-pro ?
Chacha
Membre
Bonjour,
Je suis désolé d'ouvrir un thread parallèle à celui que j'ai déjà lancé pour le beta-test de MozoDojo
http://www.objective-cocoa.org/forum/index.php?topic=675.msg7481;topicseen#msg7481
Cependant, ce dernier est un peu en train d'enterrer un problème qui se pose toujours, puisque les GBT (gentils beta testeurs) ne disposent pas de biprocesseur.
Voilà : si quelqu'un avait une machine multi-pro, pourrait-il faire un essai, meme rapide, de MozoDojo ?
La dernière beta est ici :
http://ktd.club.fr/programmation/fichiers/MozoDojo.dmg
Il s'agirait de lancer un calcul d'abord en mode mono, puis en mode multi, avec à chaque fois un essai avec un "image cache" vierge (File > Clear image cache), et un deuxième essai (avec cache à jour).
Je voudrais juste savoir si des problèmes surviennent, et si, approximativement, ça va plus vite.
Pour que le test soit pertinent, il faudrait le lancer avec une grille assez fine (genre 70x70) et une banque d'images assez grande (>500). Et regarder les temps mis par les différentes étapes de calcul.
Pour activer/désactiver le mode multipro de l'appli, il y a le menu "Debug > Use Multiprocessing".
Merci d'avance à ceux qui peuvent et qui veulent bien !
+
Chacha
PS : minute culturelle; d'après le Grevisse, quand on écrit "multi-machin", on ne met pas "machin" au pluriel. Surprenant, non ?
Je suis désolé d'ouvrir un thread parallèle à celui que j'ai déjà lancé pour le beta-test de MozoDojo
http://www.objective-cocoa.org/forum/index.php?topic=675.msg7481;topicseen#msg7481
Cependant, ce dernier est un peu en train d'enterrer un problème qui se pose toujours, puisque les GBT (gentils beta testeurs) ne disposent pas de biprocesseur.
Voilà : si quelqu'un avait une machine multi-pro, pourrait-il faire un essai, meme rapide, de MozoDojo ?
La dernière beta est ici :
http://ktd.club.fr/programmation/fichiers/MozoDojo.dmg
Il s'agirait de lancer un calcul d'abord en mode mono, puis en mode multi, avec à chaque fois un essai avec un "image cache" vierge (File > Clear image cache), et un deuxième essai (avec cache à jour).
Je voudrais juste savoir si des problèmes surviennent, et si, approximativement, ça va plus vite.
Pour que le test soit pertinent, il faudrait le lancer avec une grille assez fine (genre 70x70) et une banque d'images assez grande (>500). Et regarder les temps mis par les différentes étapes de calcul.
Pour activer/désactiver le mode multipro de l'appli, il y a le menu "Debug > Use Multiprocessing".
Merci d'avance à ceux qui peuvent et qui veulent bien !
+
Chacha
PS : minute culturelle; d'après le Grevisse, quand on écrit "multi-machin", on ne met pas "machin" au pluriel. Surprenant, non ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
[edit]
bon, en mode normal environ 15 sec (grid 18x22, dossier avec 12 images)
en mode multiprocesseur, ça bloque quand le progress affiche "analyzing source image"... threadviewer m'indique qu'un seul thread est actif (le 3ème), les autres sont en attente... (je joins les copies d'écran)
[Fichier joint supprimé par l'administrateur]
Cool, merci
Il faudrait vraiment que ça dure plus longtemps, pour pouvoir relever les temps mis par les différentes phases
Analyzing Source Image
Analyzing Libary
Selecting Images
Rendering
Car en théorie, j'ai parallélisé chaque phase. Je voudrais savoir lesquels en bénéficient vraiment.
Au moins, ça ne marche pas, mais tout de suite. Je dois avoir un problème de partage de ressources. Je me penche sur ce problème.
Woah, l'autre, comment il peut mater mon code, avec les symboles de débuguage ! Heureusement j'ai pas des méthodes "toto" ni "onVerraCaPlusTard", ça n'aurait pas fait très sérieux.
Merci beaucoup, au fait
+
Chacha
[edit]
Heu, dis moi, dans les images que tu m'a données... c'est lequel, le thread 3 ?
[/edit]
ok, alors grid 30x38, dossier avec 68 photos:
(à la louche, j'ai pas chronométré)
analyzing source image: 15 sec
truc library: 42 sec
selecting images: 7 sec
rendering bidule: 5 sec
par ailleurs, il exploite déjà les deux processeurs, les deux jauges sont au taquet dans Activity Monitor...
ensuite j'ai recommencé (sans quitter l'appli, juste en recliquant sur "compute mozaic") ça a planté... (voir crashlog)
[Fichier joint supprimé par l'administrateur]
Es-tu sûr ? celui avec le sleepuUntilDate ? Parce que dans le débuggeur de XCode, l'ordre des thread est un peu aléatoire.
Ah bon ? Donc mon appli est multi-pro sans que je le sache ? En vérité, ce que j'appelle mode multi-pro, dans MozoDojo, c'est quand je décompose un calcul en autant de threads que de processeurs. Du coup, je m'attends à avoir un thread de calcul par proc. Je ne sais donc pas expliquer pourquoi dans ton cas, le mode multi-pro semble déjà bien exploité, à moins que OSX soit capable de gérer un thread unique avec deux procs à la fois !
(NB : il y a plusieurs threads dans MozoDojo, mais seuls les threads de calcul sont vraiment lourds, donc je ne pense pas que ces threads auxiliaires puissent mettre tes jauges "au taquet")
Drôle de CrashLog, c'est pas mon code qui plante, c'est celui de l'AppKit. Je ne comprends pas du tout l'origine de ce plantage. Quelqu'un a une idée ?
ils tous sont en attente, sauf le 3 qui se réveille de temps en temps... dans un sleepUntilDate... sinon les plus intéressants sont les 6 et 7, qui attendent quelque chose dans computeFeaturesForImage...
crash:
si par exemple tu fournis un pointeur pourri (ou qui devient pourri pour cause de release en tro, etc) à une NSView, au moment où elle veut s'afficher, alors... boum !
bon courage ! en tout cas le résultat est pas mal !
http://ktd.club.fr/programmation/fichiers/MozoDojo.dmg
Sinon, rassure-moi, ça ne marche pas que si tu actives le mode multi-pro ? En mode normal, ça marche ?
+
Chacha
en mode normal, 1er coup ok, et 2ème coup dans la foulée vrai plantage avec la log envoyée.
je regarde la nouvelle version....
EDIT:
ok, alors les résultats:
en mode multiprocesseur, ça se bloque pareil...
en mode normal, ça ne plante plus... (par contre j'obtiens un résultat différent à chaque fois, c'est normal docteur ?)
EDIT2:
on rejouant avec la 1ère version, finalement, ça ne plante plus... en tout il aura donc planté qu'une fois en fait...
et pour ce qui est de l'utilisation des processeurs, après un examen plus approfondi, je reviens sur ce que j'ia dit plus haut: il utilise 1 seul processeur à la fois, jusqu'à 99%, et en fait la charge de l'autre processeur vient des autres programmes qui tournent... il n'y a que vers la dernière seconde qu'il utilise environ 115% (donc les deux processeurs), mais c'est trop court pour être significatif...
Je ne suis pas trop surpris
Oui, c'est normal. Pour éviter d'avoir des mosaà¯ques trop uniformes, c'est-à -dire qui répètent toujours les mêmes carreaux dans les zones homogènes, il y a un random qui traà®ne, et qui permet de s'éloigner (un peu) de la solution algorithmique optimale. J'ai mis ça dans la doc. Mais il va me falloir un peu de temps pour ajuster ce paramètre (ni trop, ni trop peu).
Argh ! Un bug aléatoire non reproductible !
Ok, c'est plus cohérent.
Il faut donc que je cherche d'où peut venir le blocage quand on a vraiment deux threads qui causent en même temps ! Chez moi, je peux toujours activer le mode multi-pro, ça va pas changer grand chose, et ça marche tout aussi bien. Même quand je triche et que je fais croire au programme que j'ai deux processeurs. ça reste du faux multi-tâche.
Pfff, galère en perspective.
Merci encore
+
Chacha
par ex. si on considère le cas suivant: une fonction effectue simplement une addition:
eh bien si deux threads l'exécutent en même temps, la valeur de x ne va pas forcément augmenter de 2... donc il faut protéger la section critique avec des verrous:
attendreVerrouEtVerouiller () va attendre que le vérrou soit libre, puis va le vérouiller... et deverouiller () va simplement le déverouiller. comem ça les différents threads n'y accèdent pas tous en même temps. il faut placer judicieusement les verrous et ne pas tout verouiller en vrac, sinon un seul thread va travailler à un moment donné et les autres vont toujours être en attente du vérrou.
avec cocoa, c'est la class NSLock qui gère ça. bon courage...
T'inquiètes pas, je suis sensibilisé au partage de ressources. Des NSLock, NSConditionLock et des @synchronized, j'en ai mis dans mon programme. Et c'est justement parce que je pensais avoir fait les choses bien que je suis embêté de voir qu'en vrai mode bi-pro, ça ne va pas.
Si tu veux pas, pas de problème : je la remets dans ma culotte (mais tu sais pas c'que tu perds); si mon appli t'as pas plu, n'en parlons pluuuuuus
(y'a une dédicace, là ).
Tu peux m'envoyer un mail à mon adresse que tu trouveras dans l'appli (about box ou doc). (Non, cette partie n'est pas chantée, vous pouvez couper la musique)
+
Chacha
Fan de "Calvin et Hobbes" mais aussi de Renaud. Dis donc Chacha, t'as posté dans "Playlists de developpeurs" ??
Je suis sûr que sur le forum d'Objective-Cocoa, Renaud est content qu'on soit fan de lui.
on verra ça demain au bureau, tu peux m'envoyer un MP avec ton truc bien baveux (euh, verbeux)
Sympa! Tu m'enverras un mail pour que j'aie ton adresse ? Et à charge de revanche (par exemple sur le bridge iTunes)
+
Chacha
D'accord, mais attention, elle n'a l'aire qu'en surface ;-)
Et merci d'avance !
J'ai jamais dis que je ne faisais jamais de fautes d'ortogaf ::)
Excellent ;D
De la part d'un amateur: chapeau bas Chacha
P.S: et je suis un amateur averti
Sans vouloir tirer la couverture à moi, mais sans moi et mes fautes, la blague n'aurait jamais existé ;D
T'as raison ptit bras tout le mérite te revient en fin de compte
Après rapide test, je confirme que l'option bipro fait planter l'appli
Si t'as d'autre version à tester... je tenterai de trouver un peu plus de temps pour faire des tests plus utile pour toi.
@+
Oké.
Je pense qu'il est temps de refusionner ce thread avec le thread initial:
http://www.objective-cocoa.org/forum/index.php?topic=675.45
Car hier soir j'ai updaté MozoDojo en version qui est censée marché en mode bi-pro, et je pense que c'est la dernière beta.
Merci encore
+
Chacha