Problème avec mingw32-make multijob (make -jX)

Version imprimable

18/10/2010, 18h33
Guillaume78fr

Problème avec mingw32-make multijob (make -jX)

Bonsoir tout le monde,

Je me pose une petite question toute bête. Je suis retourné sous Windows pour faire quelques tests après avoir mis à jour mingw32 et Qt.

Conclusion, je ne sais pas pour quelle raison, mais lorsque j'execute un mingw32-make -j9, le -j9 n'est pas pris en compte. Le gestionnaire de tâche montre clairement que seul un processeur est utilisé... :(

Du coup, j'ai tenté de faire un tour sous MSYS et le problème est différent. un make -j9 lance bel et bien la compilation à 100% du processeur, mais pour une raison qui m'échappe, il bloque très souvent lors de la compilation...

Par bloquer, j'entends par là que la compilation n'avance plus même si le processeur reste occupé... 8O
Autre info, la compilation reste dans cet état plus longtemps que le make sans option avant que je ne shoote les processus... C'est bel et bien la preuve que ça coince quelque part...

Bref, je suis un peu déboussolé par ce comportement. Ca fonctionnait très bien auparavant, mais là je ne comprends plus rien. D'ailleurs, pour info, le make -j9 continue de bien fonctionner sous linux...

Quelqu'un aurait-il une idée, une piste?

D'avance merci. ;)

Guillaume
19/10/2010, 07h17
Firwen

le -j X n'est pas une instruction magique, elle se contente de séparer chaque tache différente de ton makefile sur un thread différent :

Ce qui veut dire :
- Si le makefile comporte des scripts graddy et que ce n'est pas parallèlisable : ça plante.

- Si tu as moins de 9 taches, le -j 9 est totalement ineffectif.
19/10/2010, 09h40
Guillaume78fr

En premier lieu, merci de prendre le temps de me lire et de me répondre.

Citation:

Envoyé par Firwen

le -j X n'est pas une instruction magique, elle se contente de séparer chaque tache différente de ton makefile sur un thread différent :

Ce qui veut dire :
- Si le makefile comporte des scripts graddy et que ce n'est pas parallèlisable : ça plante.

Merci pour l'info : je l'ignorai.
Je vais donc me documenter sur la question... ;)

Ceci dit, ce n'est pas le cas ici...

Citation:

Envoyé par Firwen

- Si tu as moins de 9 taches, le -j 9 est totalement ineffectif.

Le problème ne vient pas de là non plus... :-(

Pour un peu plus d'info, je cherche à compiler Qt 4.7.0 et postgresql 8.4.5.
Pour Qt, je l'avais déjà fait pour la 4.6.3 sans le moindre soucis et même chose pour PostgreSQL 8.3.8...

Pour le compilateur, j'utilise celui que j'ai téléchargé sur le site de Nokia auquel j'ai rajouté quelques options (gettext, gmp, libgmp, libiconv, libmpc, libmpfr, libpthread, mpc, mpfr, pthread, zlib, openssl)

La grosse différence qui me saute aux yeux entre cette fois-ci et l'autre fois, c'est que je n'ai pas pris le temps de recompiler minGW pour ma plateforme spécifiquement. C'est donc un target "i386-pc-mingw32". Est-ce que ça pourrait venir de là?

Pour rappel, j'ai retenté l'ensemble sous Linux sans le moindre souci. Je pense donc que le souci vient du compilateur....

Une petite idée?

Guillaume, qui te remercie encore de ta réponse...
19/10/2010, 11h42
koala01
Salut,

Il y a, en fait, plusieurs problèmes...

Le premier est que la gestion des threads, des processus et de la mémoire est différente sous windows que sous linux.

On arrive assez facilement à obtenir un processus zombie sous windows si, pour une raison ou une autre, il vient à y avoir une erreur mémoire trop importante :aie:

Le deuxième est que MSYS n'est pas à proprement parler une machine virtuelle: on est beaucoup plus proche d'une "collection de mini programme" que l'on essaye de faire fonctionner de concert pour nous donner l'occasion de travailler "comme sous linux" que d'une distribution linux réelle fonctionnant sur une machine virtuelle (faut il rappeler que MSYS est l'abréviation de Minimalist SYSTEM:question:)

Le troisième est que l'ensemble des outils fournis par MSYS en particulier (mais peut être aussi ta version de make!!!) est effectivement compilé sous la forme d'une application 32 bits, ce qui oblige, si tu dispose d'une version 64 bits de windows, à fonctionner dans un mode de compatibilité, avec tous les problèmes que cela peut occasionner, entre autres, en terme de disponibilité de mémoire.

Enfin, il faut savoir que, même sous linux, on conseille généralement de ne pas essayer de lancer plus de (nombre de coeur / processeurs) + 1 processus parallèles, histoire, justement, d'éviter que les différents processus n'en viennent à empiéter sur la mémoire les uns des autres.

En outre, si tu utilise une version 64bits de Gcc et de binutils, il faut veiller à ce que binutils ait été effectivement compilé avec une version de Gcc capable de fournir des exécutables 64bits.

Cela n'a l'air de rien, mais, lorsque tu compile toi même ces différents outils, binutils (et ld en particulier ;)) est compilé une première fois avec un compilateur qui, classiquement, ne fournit que des exécutables 32bits.

Tu te trouve donc avec une version 32bit de ld capable d'effectuer l'édition de liens d'applications 64 bits.

Mais, cette version de ld subit exactement les restrictions propres aux applications 32bits, dont, principalement, la restriction à une utilisation de maximum 2Gb de mémoire.

Si je t'en parle, c'est simplement par expérience: si tu ne dispose pas d'une version 64bits de ld, le processus "plantera" à un moment parce que ld ne pourra pas utiliser suffisamment de mémoire lors du processus de compilation de Qt.

Si tu compile toi-même les différents outils, tu dois donc veiller à compiler deux fois binutils:
- La première fois en début de processus, de manière à ce qu'il puisse gérer les fichiers objets 64 bits
- La seconde fois en fin de processus (après avoir compilé gcc) afin que ce soit effectivement une application 64 bits
Hope it helps ;)
19/10/2010, 11h50
koala01

Ah, au fait...

Il me semble que sous linux, tu peux écrire tout aussi ben -j9 (sans espaces) que -j 9 (avec un espace), mais qu'il n'y a qu'une seule écriture qui fonctionne effectivement sous windows...

Hé oui, make est un portage d'application, et ce portage pose parfois problème :D
19/10/2010, 12h54
Guillaume78fr
Pour commencer, merci pour tout ce lot d'information fort utiles. Pour information, j'avais suivi votre tutoriel pour compiler MinGW et comme il est clair et suffisamment détaillé, ce fut un "jeu d'enfant". Je profite donc de ce post pour vous en remercier et vous encourager à continuer! ;)

Citation:

Envoyé par koala01

Salut,

Il y a, en fait, plusieurs problèmes...

Le premier est que la gestion des threads, des processus et de la mémoire est différente sous windows que sous linux.

Ca, je le savais, mais c'est toujours une bonne chose de le rappeler... ;)

Citation:

Envoyé par koala01

On arrive assez facilement à obtenir un processus zombie sous windows si, pour une raison ou une autre, il vient à y avoir une erreur mémoire trop importante :aie:

C'est fort dommage et même fort dommageable... :?

Citation:

Envoyé par koala01

Le deuxième est que MSYS n'est pas à proprement parler une machine virtuelle: on est beaucoup plus proche d'une "collection de mini programme" que l'on essaye de faire fonctionner de concert pour nous donner l'occasion de travailler "comme sous linux" que d'une distribution linux réelle fonctionnant sur une machine virtuelle (faut il rappeler que MSYS est l'abréviation de Minimalist SYSTEM:question:)

Pour le côté un peu plus machine virtuelle, il y a Cygwin, mais personnellement je préfère l'approche "collection de mini-programme". Je viens de dotnet et si le côté machine virtuelle possède quelques avantages indéniables, il possède aussi des inconvénients non négligeables (dépendance de la MV, perfs déplorables si l'on se met à ne pas utiliser les objets fournis, ...)

Citation:

Envoyé par koala01

Le troisième est que l'ensemble des outils fournis par MSYS en particulier (mais peut être aussi ta version de make!!!) est effectivement compilé sous la forme d'une application 32 bits, ce qui oblige, si tu dispose d'une version 64 bits de windows, à fonctionner dans un mode de compatibilité, avec tous les problèmes que cela peut occasionner, entre autres, en terme de disponibilité de mémoire.

Tout cela est fort intéressant. Je compte à moyen terme passer au 64 bits : c'est donc encore un point qu'il faudra que je prévois avant de basculer...
Cependant, pour l'instant je ne suis qu'en 32bits... C'est d'ailleurs pour cette raison que je n'avais pas recompiler minGW. Comme il ne s'agissait que d'un test pour le moment...

Cependant, si je suis bien en 32, je dispose d'un processeur récent et peut-être y a-t-il un souci si l'un des jeux d'instructions type SSE et Cie n'est pas déclaré. Je vais donc refaire une compilation de minGW avant d'aller plus loin dans la réflexion...

Citation:

Envoyé par koala01

Enfin, il faut savoir que, même sous linux, on conseille généralement de ne pas essayer de lancer plus de (nombre de coeur / processeurs) + 1 processus parallèles, histoire, justement, d'éviter que les différents processus n'en viennent à empiéter sur la mémoire les uns des autres.

Effectivement, c'est un point que je connaissais déjà, mais j'ai la chance de posséder un processeur 4 coeurs / 8 threads et par conséquent m'autorise cette option.
D'ailleurs, c'est principalement la parallélisation de compilation qui a orienté mon choix de processeur... ;)
Citation:
Envoyé par koala01

En outre, si tu utilise une version 64bits de Gcc et de binutils, il faut veiller à ce que binutils ait été effectivement compilé avec une version de Gcc capable de fournir des exécutables 64bits.

Cela n'a l'air de rien, mais, lorsque tu compile toi même ces différents outils, binutils (et ld en particulier ;)) est compilé une première fois avec un compilateur qui, classiquement, ne fournit que des exécutables 32bits.

Tu te trouve donc avec une version 32bit de ld capable d'effectuer l'édition de liens d'applications 64 bits.

Mais, cette version de ld subit exactement les restrictions propres aux applications 32bits, dont, principalement, la restriction à une utilisation de maximum 2Gb de mémoire.

Si je t'en parle, c'est simplement par expérience: si tu ne dispose pas d'une version 64bits de ld, le processus "plantera" à un moment parce que ld ne pourra pas utiliser suffisamment de mémoire lors du processus de compilation de Qt.

Si tu compile toi-même les différents outils, tu dois donc veiller à compiler deux fois binutils:

La première fois en début de processus, de manière à ce qu'il puisse gérer les fichiers objets 64 bits
La seconde fois en fin de processus (après avoir compilé gcc) afin que ce soit effectivement une application 64 bits
Hope it helps ;)
Comme je le disais un poil plus haut, je ne suis pas en 64 bits (sous Windows) pour le moment, mais je conserve ces informations précieusement de côté.

Encore un grand merci pour toutes ces infos. Je reposterai lorsque j'aurai eu le temps de compiler minGW, histoire de dire si ça a changé ou non quelque chose.

Guillaume
19/10/2010, 12h56
Guillaume78fr

Citation:

Envoyé par koala01

Ah, au fait...

Il me semble que sous linux, tu peux écrire tout aussi ben -j9 (sans espaces) que -j 9 (avec un espace), mais qu'il n'y a qu'une seule écriture qui fonctionne effectivement sous windows...

Hé oui, make est un portage d'application, et ce portage pose parfois problème :D

Pour make dans msys, ça ne pose pas de problème en tout cas.
Pour mingw32-make, j'ai fait un rapide petit test et ça n'a absolument rien donné... :(

Tant pis, et merci tout de même pour le tuyau ;)
19/10/2010, 15h34
Guillaume78fr

Bon, je n'ai malheureusement pas le temps de pousser plus loin pour l'instant, mais ça n'est que partie remise.

Pour l'instant, tout ce que je peux affirmer, c'est que le problème vient bel et bien du MinGW.

En effet, j'ai retrouvé une de mes vieilles versions de MinGW avec le code source de mame. J'ai donc fait trois tests :
- compilation de mame avec mon minGW actuel (celui téléchargé du site de Nokia) et pas de prise en compte du -j9
- compilation de mame avec le minGW que l'on trouve sur developpez.com à la pages des binaires Qt (GCC 4.4.0 (32 bits)) ==> même problème
- compilation avec ma "vieille" version de minGW (4.2.1) ==> aucun problème, compilation à 100% du processeur...

Etant donné que seul mingw change dans ce cas, ça ne peut venir que de là. D'ailleurs, avant d'effectuer ces tests, j'ai désinstaller MSYS pour être sur à 100% de mon coup...

@koala01, ça a fonctionné avec un "mingw32-make -j9" et non "-j 9"... ;)

Quoiqu'il en soit, je compte bien trouver la solution ces prochains jours et en faire profiter ceux que ça pourrait intéresser...

à plus tard

Guillaume
21/10/2010, 07h53
koala01

Tiens, je viens de jeter un oeil à un script de compilation de make sous windows, et je constate que la configuration se fait (pour ce script particulier) en passant le paramètre --disable-job-server, qui, selon l'aide du script de configuration "disalow recursive make communication duing make -jN".

Cette option a-t-elle été passée pour la version de make dont tu dispose :question: aurait-elle du l'être :question:

J'ouvre une voie de réflexion, à toi de faire le reste ;)
21/10/2010, 09h41
Guillaume78fr

Citation:

Envoyé par koala01

Tiens, je viens de jeter un oeil à un script de compilation de make sous windows, et je constate que la configuration se fait (pour ce script particulier) en passant le paramètre --disable-job-server, qui, selon l'aide du script de configuration "disalow recursive make communication duing make -jN".

Cette option a-t-elle été passée pour la version de make dont tu dispose :question: aurait-elle du l'être :question:

Effectivement, c'est une piste fort intéressante! Je me pencherai sur la question avec le plus vif intérêt.

Cependant, j'ai une question qui peut sembler très bête... Je ne sais pas comment retrouver les options avec lesquelles a été compilé make. Autant pour gcc, on dispose de toutes les infos avec un "gcc -v", autant là je ne vois pas comment faire...

Citation:

Envoyé par koala01

J'ouvre une voie de réflexion, à toi de faire le reste ;)

C'est bel et bien mon intention. Il n'y a qu'en se prenant un peu la tête qu'on avance. ;)
Cependant, comme je l'avais précisé dans mon précédent post, j'ai d'autres petites choses à faire en priorité pour l'instant. Je pense que je pourrais me repencher sérieusement sur le sujet lundi.

Quoiqu'il en soit, merci pour ton observation, elle me permettra très certainement d'avancer beaucoup plus vite. ;)

Guillaume
21/10/2010, 13h00
koala01

Citation:

Envoyé par Guillaume78fr

Effectivement, c'est une piste fort intéressante! Je me pencherai sur la question avec le plus vif intérêt.

Cependant, j'ai une question qui peut sembler très bête... Je ne sais pas comment retrouver les options avec lesquelles a été compilé make. Autant pour gcc, on dispose de toutes les infos avec un "gcc -v", autant là je ne vois pas comment faire...

Je n'en ai strictement aucune idée...

Mais, ceci dit, make est encore le genre d'application qui se compile très rapidement.

Tu peux donc être relativement sur des options que tu passerais toi-même lors de sa compilation :D

Tu ferais un test avec, et un test sans cette option particulière, et tu aurais assez rapidement une réponse quant à l'intérêt / le besoin ou non de la passer :D

Citation:

C'est bel et bien mon intention. Il n'y a qu'en se prenant un peu la tête qu'on avance. ;)
Cependant, comme je l'avais précisé dans mon précédent post, j'ai d'autres petites choses à faire en priorité pour l'instant. Je pense que je pourrais me repencher sérieusement sur le sujet lundi.

Quoiqu'il en soit, merci pour ton observation, elle me permettra très certainement d'avancer beaucoup plus vite. ;)

Guillaume

Oh, tu sais, pour moi, ce n'est pas un problème ;)

Je me suis dit que l'information était peut être intéressante, je l'ai transmise... Le reste, "i don't care" ;)
16/11/2010, 15h52
Guillaume78fr

Citation:

Envoyé par koala01

Oh, tu sais, pour moi, ce n'est pas un problème ;)

Je me suis dit que l'information était peut être intéressante, je l'ai transmise... Le reste, "i don't care" ;)

Je m'en doute bien, mais je pense que je ne suis pas le seul à rencontrer le problème. Voilà pourquoi je voulais répondre au plus vite à mon problème (ce qui est raté, comme on a pu le voir).

Mon plus gros problème pour l'instant est de pouvoir dégager assez de temps pour compiler MinGW et résoudre le problème proprement.

Pour ceux que ça pourrait intéresser, j'ai une piste qui me semble prometteuse..
A l'heure actuelle, je n'ai qu'une version de MinGW qui exécute l'option -jX de make : c'est 4.2.1 avec les options de compilation suivantes :

Configured with: ../gcc-4.2.1/configure --with-gcc --enable-libgomp --host=mingw32 --build=mingw32 --target=mingw32 --program-suffix=-sjlj --with-arch=i486 --with-tune=generic --disable-werror --prefix=/mingw --with-local-prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-win32-registry --enable-sjlj-exceptions --enable-libstdcxx-debug --enable-cxx-flags=-fno-function-sections -fno-data-sections --enable-version-specific-runtime-libs --disable-bootstrap
Thread model: win32
gcc version 4.2.1-sjlj (mingw32 sjlj-unwind)

Par rapport à mes autres versions, les grosses différences sont :
--enable-sjlj-exceptions
et surtout :
--enable-threads

Pour SJLJ, j'ai vu que dwarf2 avait "pris le relais" car SJLJ posait des problèmes de stabilité. Quant à --enable-threads, le nom me semble suffisamment évocateur...
Voilou, si quelqu'un compile avant moi, n'hésitez pas à confirmer ou infirmer cette hypothèse. Autrement, je reviendrai plus tard (sans précision de date...) pour le faire moi-même.

Guillaume