Compilation 64 Bits
chamine
-
dubcek Messages postés 19025 Date d'inscription Statut Contributeur Dernière intervention -
dubcek Messages postés 19025 Date d'inscription Statut Contributeur Dernière intervention -
Bonjour à tous,
J'ai un problème lorsque je fais tourner un programme fortran compilé en 64-Bits sur des machines 64-Bits. En fait
avant mon programe s'arretait en faisant apparaître des NaN, et je pensais que c'était parce que je le compilais sur une machine 32 Bit et le faisait tourner sur une 64 Bits.
Donc là je le compile avec mpich2 64 bits, et sur une machine 64 Bits mais le programme tourne très très lentement, 3 à 4 fois plus lent que d'habitude et voire même plus lent que sur une machine 64 Bits, et en plus il s'arrête au bout d'une petite dizaine d'heures sans aucun message d'erreur.
Je ne sais plus trop quoi faire, j'ai testé sur 3 machines 64 Bits différentes, et toujours aussi lent et il s'arrête toujours aussi subitement au bout du même temps.
Si quelqu'un a une idée cela me rendrait service!
Merci
PS : les machines 64 Bits sont des AMD64, j'utilise linux (système Debian version etch)
J'ai un problème lorsque je fais tourner un programme fortran compilé en 64-Bits sur des machines 64-Bits. En fait
avant mon programe s'arretait en faisant apparaître des NaN, et je pensais que c'était parce que je le compilais sur une machine 32 Bit et le faisait tourner sur une 64 Bits.
Donc là je le compile avec mpich2 64 bits, et sur une machine 64 Bits mais le programme tourne très très lentement, 3 à 4 fois plus lent que d'habitude et voire même plus lent que sur une machine 64 Bits, et en plus il s'arrête au bout d'une petite dizaine d'heures sans aucun message d'erreur.
Je ne sais plus trop quoi faire, j'ai testé sur 3 machines 64 Bits différentes, et toujours aussi lent et il s'arrête toujours aussi subitement au bout du même temps.
Si quelqu'un a une idée cela me rendrait service!
Merci
PS : les machines 64 Bits sont des AMD64, j'utilise linux (système Debian version etch)
A voir également:
- Compilation 64 Bits
- Winrar 64 bits - Télécharger - Compression & Décompression
- Clé windows 10 pro 64 bits gratuit - Guide
- 32 bits ou 64 bits - Guide
- Microsoft security essentials windows 7 64 bits - Télécharger - Antivirus & Antimalwares
- Format factory 64 bit - Télécharger - Conversion & Codecs
11 réponses
Bonjour
une piste : en 64 bits gcc utilise les instructions flottantes mmx, qui n'existent qu'en deux formats flottants 32 et 64 bits et n'ont pas les opérations trigonométriques et transcendantes, alors qu'en mode 32 bits gcc utilise les instructions x87 dont tous les résultats intermédiaires sont manipulés en format 80 bits.
J'ai rencontré des cas en 64 bits (X86_64) où les deux expressions a*d-b*c et b*c-a*d avaient le même signe sans être nulles (conduisant à des décisions incohérentes), alors que ça ne se produisait pas en 32 bits.
Manu
une piste : en 64 bits gcc utilise les instructions flottantes mmx, qui n'existent qu'en deux formats flottants 32 et 64 bits et n'ont pas les opérations trigonométriques et transcendantes, alors qu'en mode 32 bits gcc utilise les instructions x87 dont tous les résultats intermédiaires sont manipulés en format 80 bits.
J'ai rencontré des cas en 64 bits (X86_64) où les deux expressions a*d-b*c et b*c-a*d avaient le même signe sans être nulles (conduisant à des décisions incohérentes), alors que ça ne se produisait pas en 32 bits.
Manu
Bonjour,
Merci bcp pour ta réponse!!
J'ai testé en ajoutant par l'option -m64 à gcc, et c'est toujours aussi lent...
en fait je me demandais si ça ne pouvait pas être du à des librairies qui sont pas adaptées ou quelque chose comme ça... ptetre en le compilant en statique je sais pas...
et le problème aussi c'est que d'habitude je redirige vers un fichier de sortie où le programe écrit des paramètres quelconques, mais là le fichier de sortie est vide, mais le programme tourne quand même et crée des répertoires avec les "résultats".
J'avoue je commence à devenir folle ça fait plus de trois semaines que je suis dessus et mes travaux n'avancent pas.
J'utilisais avant ifort et il m'a posé des problèmes pour des programes en fortran ( typiquement des segmentation fault), et g95 est resté mon sauveur, donc je suis passée pour tous les programmes mpi de mpif90 à g95 (configuré avec mpich2)
Merci bcp pour ta réponse!!
J'ai testé en ajoutant par l'option -m64 à gcc, et c'est toujours aussi lent...
en fait je me demandais si ça ne pouvait pas être du à des librairies qui sont pas adaptées ou quelque chose comme ça... ptetre en le compilant en statique je sais pas...
et le problème aussi c'est que d'habitude je redirige vers un fichier de sortie où le programe écrit des paramètres quelconques, mais là le fichier de sortie est vide, mais le programme tourne quand même et crée des répertoires avec les "résultats".
J'avoue je commence à devenir folle ça fait plus de trois semaines que je suis dessus et mes travaux n'avancent pas.
J'utilisais avant ifort et il m'a posé des problèmes pour des programes en fortran ( typiquement des segmentation fault), et g95 est resté mon sauveur, donc je suis passée pour tous les programmes mpi de mpif90 à g95 (configuré avec mpich2)
Hello
est-ce que ces précisions changent qqchose ?
https://www.mpich.org/
A.2.5 Q: When I use the g95 Fortran compiler on a 64-bit platform, some of the tests fail
A: The g95 compiler incorrectly defines the default Fortran integer as a 64-
bit integer while defining Fortran reals as 32-bit values (the Fortran standard
requires that INTEGER and REAL be the same size). This was apparently
done to allow a Fortran INTEGER to hold the value of a pointer, rather
than requiring the programmer to select an INTEGER of a suitable KIND.
To force the g95 compiler to correctly implement the Fortran standard, use
the -i4 flag. For example, set the environment variable F90FLAGS before
configuring MPICH2:
setenv F90FLAGS "-i4"
G95 users should note that there (at this writing) are two distributions of
g95 for 64-bit Linux platforms. One uses 32-bit integers and reals (and
conforms to the Fortran standard) and one uses 32-bit integers and 64-bit
reals. We recommend using the one that conforms to the standard (note
that the standard specifies the ratio of sizes, not the absolute sizes, so a
Fortran 95 compiler that used 64 bits for both INTEGER and REAL would
also conform to the Fortran standard. However, such a compiler
est-ce que ces précisions changent qqchose ?
https://www.mpich.org/
A.2.5 Q: When I use the g95 Fortran compiler on a 64-bit platform, some of the tests fail
A: The g95 compiler incorrectly defines the default Fortran integer as a 64-
bit integer while defining Fortran reals as 32-bit values (the Fortran standard
requires that INTEGER and REAL be the same size). This was apparently
done to allow a Fortran INTEGER to hold the value of a pointer, rather
than requiring the programmer to select an INTEGER of a suitable KIND.
To force the g95 compiler to correctly implement the Fortran standard, use
the -i4 flag. For example, set the environment variable F90FLAGS before
configuring MPICH2:
setenv F90FLAGS "-i4"
G95 users should note that there (at this writing) are two distributions of
g95 for 64-bit Linux platforms. One uses 32-bit integers and reals (and
conforms to the Fortran standard) and one uses 32-bit integers and 64-bit
reals. We recommend using the one that conforms to the standard (note
that the standard specifies the ratio of sizes, not the absolute sizes, so a
Fortran 95 compiler that used 64 bits for both INTEGER and REAL would
also conform to the Fortran standard. However, such a compiler
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
J'ai essayé avec et sans, même résultat.
Par contre je suis repassé à ifort en mpi (donc mpif77 et 90) et là la vitesse est redevenue normale, mais il s'arrête toujours.
Une chose pendant la compilation qui apparaît, j'ai des remarques du type "remark: LOOP WAS VECTORIZED." J'essaie de voir ce que c'est exactement.
Merci encore pour les idées!
Par contre je suis repassé à ifort en mpi (donc mpif77 et 90) et là la vitesse est redevenue normale, mais il s'arrête toujours.
Une chose pendant la compilation qui apparaît, j'ai des remarques du type "remark: LOOP WAS VECTORIZED." J'essaie de voir ce que c'est exactement.
Merci encore pour les idées!
Ca veut dire que le compilateur optimise des boucles en fonction du cpu. essayer de trouver l'option pour éviter et tester.
C ok pour ne plus tester (option -vec_report0 si ça peut t'intéresser :) )
j'ai lancé un test pour voir ce que ça va donner
J'ai remarqué autre chose de différents concernant les librairies utilisées sur 32 et 64, en 32 il prends quelques librairies intel (notamment lapack), et sur les 64 il prend lapack chez atlas par exemple... Y'aurait-il une incompatibilité entre atlas et intel? et si oui pourquoi n'est-elle pas déclarée pendant la compilation?
j'ai lancé un test pour voir ce que ça va donner
J'ai remarqué autre chose de différents concernant les librairies utilisées sur 32 et 64, en 32 il prends quelques librairies intel (notamment lapack), et sur les 64 il prend lapack chez atlas par exemple... Y'aurait-il une incompatibilité entre atlas et intel? et si oui pourquoi n'est-elle pas déclarée pendant la compilation?
il serait bon, effectivement, pour tester d'utiliser les librairies 32 et 64 bits de la même origine.
ou avec les librairies AMD http://developer.amd.com/acml.jsp
ou avec les librairies AMD http://developer.amd.com/acml.jsp
Bonjour,
S'agissant du message "remark: LOOP WAS VECTORIZED.", il veut dire que le compilateur a utilisé les fonctions SIMD du mmx du X86_64. Ce processeur fait en une seule instruction deux opérations flottantes 64 bits ou quatre opérations flottantes 32 bits.
Cela ne double (ou quadruple) pas la vitesse, parce que dans un programme il y a beaucoup d'opérations non flottantes. Dans les meilleurs des cas j'ai pu gagner 30%, s'ajoutant au gain procuré par le dual-core (mais il faut "multithreader" pour cela).
Manu
S'agissant du message "remark: LOOP WAS VECTORIZED.", il veut dire que le compilateur a utilisé les fonctions SIMD du mmx du X86_64. Ce processeur fait en une seule instruction deux opérations flottantes 64 bits ou quatre opérations flottantes 32 bits.
Cela ne double (ou quadruple) pas la vitesse, parce que dans un programme il y a beaucoup d'opérations non flottantes. Dans les meilleurs des cas j'ai pu gagner 30%, s'ajoutant au gain procuré par le dual-core (mais il faut "multithreader" pour cela).
Manu
