Re: [ALPS-users] one solution to compilation issues with GCC (Jeff Hammond)
Thank you Jeff, now it works fine. I did not face above problem with older compiler. Tadeusz On Sun, 25 Jan 2009 12:00:03 +0100, comp-phys-alps-users-request wrote
What do you mean break? GCC 4.3.1 segfaulted on the compilation of spinmc_factory.C:
============================================== g++ -DHAVE_CONFIG_H -I. -I. -I../.. -DNDEBUG -I/software/alps/include -I/software/alps/boost_1_37_0 -I/software/alps/include -I/software/alps/lp_solve_4.0 -pthread -ftemplate-depth-150 -O3 -DBOOST_DISABLE_ASSERTS -fexceptions -w -MT spinmc_factory.o -MD -MP -MF .deps/spinmc_factory.Tpo -c -o spinmc_factory.o spinmc_factory.C spinmc_factory.C: In constructor 'AbstractSpinSim<MAT>::AbstractSpinSim(const alps::ProcessList&, const alps::Parameters&, int) [with MAT = DiagMatrix<double, 3>]': spinmc_factory.C:194: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.opensuse.org/> for instructions. make: *** [spinmc_factory.o] Error 1 ==============================================
but it compiled when I changed the "-O3" in CXXFLAGS "-O0" (both "- O2" and "-O1" failed as well for the same reasons) I was able to compile that file. I then stopped the build after the spinmc_factory.o was formed, restored optimization to the default, and the rest of ALPS compilation went fine.
I should have mentioned this the last time but I wasn't sure if it was just by distro that had this issue. I have 4 GB so the segfault is certainly a bug not the absence of sufficient memory.
I have not reported this bug to GCC because such things usually require posting the code that fails and I have no hope of doing this properly without including all of ALPS/Boost. It would be great it someone at ALPS who is closer to the GCC project could do so though.
Jeff
On Sat, Jan 24, 2009 at 4:52 AM, Tadeusz Wasiutynski <Tadeusz.Wasiutynski@ifj.edu.pl> wrote:
Indeed the compilation of ALPS-1.3.3 goes smoothly with gcc-4.3.1 and boost-1.37. Unfortunately alps-applications compilation breaks on spinmc.factory while was not the case with older gcc. All other prerequisities but lp_solve come in the system. Any suggestions? Shall we compare all the components incl kernel? Tadeusz
-- Jeff Hammond The University of Chicago http://home.uchicago.edu/~jhammond/
End of Comp-phys-alps-users Digest, Vol 34, Issue 9 ***************************************************
Unfortunately I fear that this trick will make the code very slow. Have you compared the execution speed of the spinmc code to that using -O3 and an older compiler? On 25 Jan 2009, at 09:12, Tadeusz Wasiutynski wrote:
Thank you Jeff, now it works fine. I did not face above problem with older compiler. Tadeusz
On Sun, 25 Jan 2009 12:00:03 +0100, comp-phys-alps-users-request wrote
What do you mean break? GCC 4.3.1 segfaulted on the compilation of spinmc_factory.C:
============================================== g++ -DHAVE_CONFIG_H -I. -I. -I../.. -DNDEBUG -I/software/alps/include -I/software/alps/boost_1_37_0 -I/software/alps/include -I/software/alps/lp_solve_4.0 -pthread -ftemplate-depth-150 -O3 -DBOOST_DISABLE_ASSERTS -fexceptions -w -MT spinmc_factory.o -MD -MP -MF .deps/spinmc_factory.Tpo -c -o spinmc_factory.o spinmc_factory.C spinmc_factory.C: In constructor 'AbstractSpinSim<MAT>::AbstractSpinSim(const alps::ProcessList&, const alps::Parameters&, int) [with MAT = DiagMatrix<double, 3>]': spinmc_factory.C:194: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.opensuse.org/> for instructions. make: *** [spinmc_factory.o] Error 1 ==============================================
but it compiled when I changed the "-O3" in CXXFLAGS "-O0" (both "- O2" and "-O1" failed as well for the same reasons) I was able to compile that file. I then stopped the build after the spinmc_factory.o was formed, restored optimization to the default, and the rest of ALPS compilation went fine.
I should have mentioned this the last time but I wasn't sure if it was just by distro that had this issue. I have 4 GB so the segfault is certainly a bug not the absence of sufficient memory.
I have not reported this bug to GCC because such things usually require posting the code that fails and I have no hope of doing this properly without including all of ALPS/Boost. It would be great it someone at ALPS who is closer to the GCC project could do so though.
Jeff
On Sat, Jan 24, 2009 at 4:52 AM, Tadeusz Wasiutynski <Tadeusz.Wasiutynski@ifj.edu.pl> wrote:
Indeed the compilation of ALPS-1.3.3 goes smoothly with gcc-4.3.1 and boost-1.37. Unfortunately alps-applications compilation breaks on spinmc.factory while was not the case with older gcc. All other prerequisities but lp_solve come in the system. Any suggestions? Shall we compare all the components incl kernel? Tadeusz
-- Jeff Hammond The University of Chicago http://home.uchicago.edu/~jhammond/
End of Comp-phys-alps-users Digest, Vol 34, Issue 9 ***************************************************
Using "-O0" to compile spinmc_factory.C indeed has a negative effect on performance: ==> test-4.2.4.log <== real 2m3.312s user 2m1.876s sys 0m0.524s ==> test-4.3.log <== real 5m11.542s user 5m9.495s sys 0m0.536s But, of course, without that compromise, the time to solution with GCC 4.3 is infinity, and the installation time for 4.2.4 is ~5 hours. I only use the ALPS DMRG and diagonalization codes so I don't have a lot of incentive to deduce what is wrong with GCC 4.3 in this case. However, GCC 4.3.3 dropped yesterday so I'll pull it and see if the problem has been fixed. Best, Jeff On Sun, Jan 25, 2009 at 11:28 AM, Matthias Troyer <troyer@phys.ethz.ch> wrote:
Unfortunately I fear that this trick will make the code very slow. Have you compared the execution speed of the spinmc code to that using -O3 and an older compiler?
On 25 Jan 2009, at 09:12, Tadeusz Wasiutynski wrote:
Thank you Jeff, now it works fine. I did not face above problem with older compiler. Tadeusz
On Sun, 25 Jan 2009 12:00:03 +0100, comp-phys-alps-users-request wrote
What do you mean break? GCC 4.3.1 segfaulted on the compilation of spinmc_factory.C:
============================================== g++ -DHAVE_CONFIG_H -I. -I. -I../.. -DNDEBUG -I/software/alps/include -I/software/alps/boost_1_37_0 -I/software/alps/include -I/software/alps/lp_solve_4.0 -pthread -ftemplate-depth-150 -O3 -DBOOST_DISABLE_ASSERTS -fexceptions -w -MT spinmc_factory.o -MD -MP -MF .deps/spinmc_factory.Tpo -c -o spinmc_factory.o spinmc_factory.C spinmc_factory.C: In constructor 'AbstractSpinSim<MAT>::AbstractSpinSim(const alps::ProcessList&, const alps::Parameters&, int) [with MAT = DiagMatrix<double, 3>]': spinmc_factory.C:194: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.opensuse.org/> for instructions. make: *** [spinmc_factory.o] Error 1 ==============================================
but it compiled when I changed the "-O3" in CXXFLAGS "-O0" (both "- O2" and "-O1" failed as well for the same reasons) I was able to compile that file. I then stopped the build after the spinmc_factory.o was formed, restored optimization to the default, and the rest of ALPS compilation went fine.
I should have mentioned this the last time but I wasn't sure if it was just by distro that had this issue. I have 4 GB so the segfault is certainly a bug not the absence of sufficient memory.
I have not reported this bug to GCC because such things usually require posting the code that fails and I have no hope of doing this properly without including all of ALPS/Boost. It would be great it someone at ALPS who is closer to the GCC project could do so though.
Jeff
On Sat, Jan 24, 2009 at 4:52 AM, Tadeusz Wasiutynski <Tadeusz.Wasiutynski@ifj.edu.pl> wrote:
Indeed the compilation of ALPS-1.3.3 goes smoothly with gcc-4.3.1 and boost-1.37. Unfortunately alps-applications compilation breaks on spinmc.factory while was not the case with older gcc. All other prerequisities but lp_solve come in the system. Any suggestions? Shall we compare all the components incl kernel? Tadeusz
-- Jeff Hammond The University of Chicago http://home.uchicago.edu/~jhammond/
End of Comp-phys-alps-users Digest, Vol 34, Issue 9 ***************************************************
-- Jeff Hammond The University of Chicago http://home.uchicago.edu/~jhammond/
The patch attached below seems to solve the problem (at least for gcc 4.3.2 on CentOS 5.2). I've already applied it to svn. Synge From: Jeff Hammond <jeff.science@gmail.com> Date: Sun, 25 Jan 2009 14:27:23 -0600
Using "-O0" to compile spinmc_factory.C indeed has a negative effect on performance:
==> test-4.2.4.log <== real 2m3.312s user 2m1.876s sys 0m0.524s
==> test-4.3.log <== real 5m11.542s user 5m9.495s sys 0m0.536s
But, of course, without that compromise, the time to solution with GCC 4.3 is infinity, and the installation time for 4.2.4 is ~5 hours.
I only use the ALPS DMRG and diagonalization codes so I don't have a lot of incentive to deduce what is wrong with GCC 4.3 in this case. However, GCC 4.3.3 dropped yesterday so I'll pull it and see if the problem has been fixed.
Best,
Jeff
On Sun, Jan 25, 2009 at 11:28 AM, Matthias Troyer <troyer@phys.ethz.ch> wrote:
Unfortunately I fear that this trick will make the code very slow. Have you compared the execution speed of the spinmc code to that using -O3 and an older compiler?
On 25 Jan 2009, at 09:12, Tadeusz Wasiutynski wrote:
Thank you Jeff, now it works fine. I did not face above problem with older compiler. Tadeusz
On Sun, 25 Jan 2009 12:00:03 +0100, comp-phys-alps-users-request wrote
What do you mean break? GCC 4.3.1 segfaulted on the compilation of spinmc_factory.C:
============================================== g++ -DHAVE_CONFIG_H -I. -I. -I../.. -DNDEBUG -I/software/alps/include -I/software/alps/boost_1_37_0 -I/software/alps/include -I/software/alps/lp_solve_4.0 -pthread -ftemplate-depth-150 -O3 -DBOOST_DISABLE_ASSERTS -fexceptions -w -MT spinmc_factory.o -MD -MP -MF .deps/spinmc_factory.Tpo -c -o spinmc_factory.o spinmc_factory.C spinmc_factory.C: In constructor 'AbstractSpinSim<MAT>::AbstractSpinSim(const alps::ProcessList&, const alps::Parameters&, int) [with MAT = DiagMatrix<double, 3>]': spinmc_factory.C:194: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.opensuse.org/> for instructions. make: *** [spinmc_factory.o] Error 1 ==============================================
but it compiled when I changed the "-O3" in CXXFLAGS "-O0" (both "- O2" and "-O1" failed as well for the same reasons) I was able to compile that file. I then stopped the build after the spinmc_factory.o was formed, restored optimization to the default, and the rest of ALPS compilation went fine.
I should have mentioned this the last time but I wasn't sure if it was just by distro that had this issue. I have 4 GB so the segfault is certainly a bug not the absence of sufficient memory.
I have not reported this bug to GCC because such things usually require posting the code that fails and I have no hope of doing this properly without including all of ALPS/Boost. It would be great it someone at ALPS who is closer to the GCC project could do so though.
Jeff
On Sat, Jan 24, 2009 at 4:52 AM, Tadeusz Wasiutynski <Tadeusz.Wasiutynski@ifj.edu.pl> wrote:
Indeed the compilation of ALPS-1.3.3 goes smoothly with gcc-4.3.1 and boost-1.37. Unfortunately alps-applications compilation breaks on spinmc.factory while was not the case with older gcc. All other prerequisities but lp_solve come in the system. Any suggestions? Shall we compare all the components incl kernel? Tadeusz
-- Jeff Hammond The University of Chicago http://home.uchicago.edu/~jhammond/
End of Comp-phys-alps-users Digest, Vol 34, Issue 9 ***************************************************
-- Jeff Hammond The University of Chicago http://home.uchicago.edu/~jhammond/
Index: abstractspinsim.h =================================================================== --- abstractspinsim.h (revision 3082) +++ abstractspinsim.h (working copy) @@ -99,8 +99,6 @@ sweeps_(static_cast<uint64_t>(parms["SWEEPS"])), h_(parms.defined("h") ? TinyVector<double,MAT::dim>(parms["h"],parms) : (parms.defined("H") ? TinyVector<double,MAT::dim>(parms["H"],parms) : TinyVector<double,MAT::dim>(0.0))), - h_normalized(h_*(1./std::sqrt(h_.get_length2()))), - has_magnetic_field_(h_normalized.get_length2()>1.e-10), sweeps_done_(0), thermalization_(parms.value_or_default("THERMALIZATION",sweeps_/10)), thermalization_fraction_(0.), @@ -117,6 +115,11 @@ g_(parms.defined("g") ? alps::evaluate<double>(parms["g"],parms) : 1.), print_sweeps_(parms.value_or_default("PRINT_SWEEPS",0)) { + // 2009-01-27: wistaria@comp-phys.org + // moved from the inilializaton list to avoid 'internal compiler error' in gcc 4.3.x + h_normalized = h_*(1./std::sqrt(h_.get_length2())); + has_magnetic_field_ = h_normalized.get_length2()>1.e-10; + if (inhomogeneous()) boost::throw_exception(std::runtime_error("Disordered lattices not supported by the classical Monte Carlo program.\n"));
Jeff, could you please test this and if it works we'll make a 1.3.4 release tomorrow? Matthias On 26 Jan 2009, at 19:40, Synge Todo wrote:
The patch attached below seems to solve the problem (at least for gcc 4.3.2 on CentOS 5.2). I've already applied it to svn.
Synge
Index: abstractspinsim.h =================================================================== --- abstractspinsim.h (revision 3082) +++ abstractspinsim.h (working copy) @@ -99,8 +99,6 @@ sweeps_(static_cast<uint64_t>(parms["SWEEPS"])), h_(parms.defined("h") ? TinyVector<double,MAT::dim>(parms["h"],parms) : (parms.defined("H") ? TinyVector<double,MAT::dim>(parms["H"],parms) : TinyVector<double,MAT::dim>(0.0))), - h_normalized(h_*(1./std::sqrt(h_.get_length2()))), - has_magnetic_field_(h_normalized.get_length2()>1.e-10), sweeps_done_(0), thermalization_(parms.value_or_default("THERMALIZATION",sweeps_/ 10)), thermalization_fraction_(0.), @@ -117,6 +115,11 @@ g_(parms.defined("g") ? alps::evaluate<double>(parms["g"],parms) : 1.), print_sweeps_(parms.value_or_default("PRINT_SWEEPS",0)) { + // 2009-01-27: wistaria@comp-phys.org + // moved from the inilializaton list to avoid 'internal compiler error' in gcc 4.3.x + h_normalized = h_*(1./std::sqrt(h_.get_length2())); + has_magnetic_field_ = h_normalized.get_length2()>1.e-10; + if (inhomogeneous()) boost::throw_exception(std::runtime_error("Disordered lattices not supported by the classical Monte Carlo program.\n"));
1. The patched version compiles with "-O3" with GCC-4.3.1 on openSUSE 11.0 so the patch appears portable. 2. The tests produce the same results as GCC-4.2.4 and GCC-4.3.1 (with "-O0" on spinmc_factory.C), ie one error which is ignored. I attached the log files of "make tests" in case anyone is curious. 3. The performance under 4.3.1 is equivalent to that of 4.2.4: ==> test-4.2.4.log <== real 2m3.312s user 2m1.876s sys 0m0.524s ==> test-4.3-1.log <== real 2m5.470s user 2m4.132s sys 0m0.840s My machine has been a little slower since I did a kernel update yesterday, to which I attribute the 2 second slowdown, if it is even reasonable to expect ALPS timings to be resolved on that scale. Jeff On Mon, Jan 26, 2009 at 9:54 PM, Matthias Troyer <troyer@phys.ethz.ch> wrote:
Jeff, could you please test this and if it works we'll make a 1.3.4 release tomorrow?
Matthias
On 26 Jan 2009, at 19:40, Synge Todo wrote:
The patch attached below seems to solve the problem (at least for gcc 4.3.2 on CentOS 5.2). I've already applied it to svn.
Synge
Index: abstractspinsim.h =================================================================== --- abstractspinsim.h (revision 3082) +++ abstractspinsim.h (working copy) @@ -99,8 +99,6 @@ sweeps_(static_cast<uint64_t>(parms["SWEEPS"])), h_(parms.defined("h") ? TinyVector<double,MAT::dim>(parms["h"],parms) : (parms.defined("H") ? TinyVector<double,MAT::dim>(parms["H"],parms) : TinyVector<double,MAT::dim>(0.0))), - h_normalized(h_*(1./std::sqrt(h_.get_length2()))), - has_magnetic_field_(h_normalized.get_length2()>1.e-10), sweeps_done_(0), thermalization_(parms.value_or_default("THERMALIZATION",sweeps_/10)), thermalization_fraction_(0.), @@ -117,6 +115,11 @@ g_(parms.defined("g") ? alps::evaluate<double>(parms["g"],parms) : 1.), print_sweeps_(parms.value_or_default("PRINT_SWEEPS",0)) { + // 2009-01-27: wistaria@comp-phys.org + // moved from the inilializaton list to avoid 'internal compiler error' in gcc 4.3.x + h_normalized = h_*(1./std::sqrt(h_.get_length2())); + has_magnetic_field_ = h_normalized.get_length2()>1.e-10; + if (inhomogeneous()) boost::throw_exception(std::runtime_error("Disordered lattices not supported by the classical Monte Carlo program.\n"));
-- Jeff Hammond The University of Chicago http://home.uchicago.edu/~jhammond/
Thanks! We'll prepare a new release tomorrow. Synge, is there any other patch from the trunk that we want to include in 1.3.4? Matthias On 26 Jan 2009, at 20:15, Jeff Hammond wrote:
1. The patched version compiles with "-O3" with GCC-4.3.1 on openSUSE 11.0 so the patch appears portable. 2. The tests produce the same results as GCC-4.2.4 and GCC-4.3.1 (with "-O0" on spinmc_factory.C), ie one error which is ignored. I attached the log files of "make tests" in case anyone is curious. 3. The performance under 4.3.1 is equivalent to that of 4.2.4:
==> test-4.2.4.log <== real 2m3.312s user 2m1.876s sys 0m0.524s
==> test-4.3-1.log <== real 2m5.470s user 2m4.132s sys 0m0.840s
My machine has been a little slower since I did a kernel update yesterday, to which I attribute the 2 second slowdown, if it is even reasonable to expect ALPS timings to be resolved on that scale.
Jeff
On Mon, Jan 26, 2009 at 9:54 PM, Matthias Troyer <troyer@phys.ethz.ch> wrote:
Jeff, could you please test this and if it works we'll make a 1.3.4 release tomorrow?
Matthias
On 26 Jan 2009, at 19:40, Synge Todo wrote:
The patch attached below seems to solve the problem (at least for gcc 4.3.2 on CentOS 5.2). I've already applied it to svn.
Synge
Index: abstractspinsim.h =================================================================== --- abstractspinsim.h (revision 3082) +++ abstractspinsim.h (working copy) @@ -99,8 +99,6 @@ sweeps_(static_cast<uint64_t>(parms["SWEEPS"])), h_(parms.defined("h") ? TinyVector<double,MAT::dim>(parms["h"],parms) : (parms.defined("H") ? TinyVector<double,MAT::dim>(parms["H"],parms) : TinyVector<double,MAT::dim>(0.0))), - h_normalized(h_*(1./std::sqrt(h_.get_length2()))), - has_magnetic_field_(h_normalized.get_length2()>1.e-10), sweeps_done_(0), thermalization_(parms.value_or_default("THERMALIZATION",sweeps_/ 10)), thermalization_fraction_(0.), @@ -117,6 +115,11 @@ g_(parms.defined("g") ? alps::evaluate<double>(parms["g"],parms) : 1.), print_sweeps_(parms.value_or_default("PRINT_SWEEPS",0)) { + // 2009-01-27: wistaria@comp-phys.org + // moved from the inilializaton list to avoid 'internal compiler error' in gcc 4.3.x + h_normalized = h_*(1./std::sqrt(h_.get_length2())); + has_magnetic_field_ = h_normalized.get_length2()>1.e-10; + if (inhomogeneous()) boost::throw_exception(std::runtime_error("Disordered lattices not supported by the classical Monte Carlo program.\n"));
-- Jeff Hammond The University of Chicago http://home.uchicago.edu/~jhammond/ <test-4.2.4.log><test-4.3.1.log><test-4.3.1_no-opt.log>
From: Matthias Troyer <troyer@phys.ethz.ch> Date: Mon, 26 Jan 2009 22:33:14 -0800
Thanks! We'll prepare a new release tomorrow.
Synge, is there any other patch from the trunk that we want to include in 1.3.4?
Not for now. Indeed there are too many changes after 1.3.3 and examining and applying each of them is not very practical. I think that we should start preparing 1.4 beta release just after 1.3.4. Thank you in advance for preparing release 1.3.4. Best, Synge
participants (4)
-
Jeff Hammond
-
Matthias Troyer
-
Synge Todo
-
Tadeusz Wasiutynski