Discussion :

[Guillaume78fr]

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é...
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

[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.

[Guillaume78fr]

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

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...

- 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...

[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

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)

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

[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

[Guillaume78fr]

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

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

[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!

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...

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

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

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)

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, ...)

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...

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...

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