Building AMGCL on Windows 10 with VS2017/15/13

[C B]

Hello Denis and All,

First of all thank you so much for developing such a great library. I am currently using Petsc, but my target platform is the standard PC running Windows 10, therefore I am interested in the speed that you have indicated in the benchmarks with OpenMP.

I am trying to build AMGCL with VS2017 (2015/2013) to test the library just with OpenMP on multi-core shared memory / Windows 10.

I could not find in the documentation what dependencies/prerequisites are needed to build AMGCL, or under what environments has been successfully built,

but I found a previous email from Moises Berenguer who attempted to build on Windows, but run into similar issues as I have.

I downloaded the latest stable version of boost_1_75_0

Un7z-ipped and then using an x64 VS2017 command prompt, 

following the instructions from boost, I executed:

bootstrap
.\b2

...updated 3127 targets...


The Boost C++ Libraries were successfully built!

The following directory should be added to compiler include paths:

    D:\Software\Boost\boost_1_75_0

And then I tried configuring with CMake as the following snapshots show:

Please, let me know how to proceed. If you have some instructions on how to build on Windows, what are the minimum prerequisites, etc, this would be great for those like myself who are trying to test

this library.

Thank you so much in advance.

Regards,

Carl

[C B]

Reviewing old questions, I found this nice example from Denis:

https://gist.github.com/ddemidov/4656d9155744b167413885731fec776d

And I was able to compile/run it without any issues both using 

VS2017: 

cl /O2 /openmp -DNDEBUG   -I../amgcl-master   -Id:/Software/Boost/boost_1_75_0    amgcl.cpp

And g++/cygwin:

g++ -O3 -march=x86-64  -fopenmp -DNDEBUG -I../amgcl-master -Id:/Software/Boost/boost_1_75_0 -o amgcl.exe amgcl.cpp

This is very encouraging to me, gives me more confidence to continue :))

The g++ executable is marginally faster, and the reported memory used with g++ appears to be slightly less than with VS,

however there is a memory issue when running large cases:

$ amgcl.exe 190
Solver
======
Type:             BiCGStab
Unknowns:         6859000
Memory footprint: 366.31 M

Preconditioner
==============
Number of levels:    4
Operator complexity: 1.62
Grid complexity:     1.13
Memory footprint:    1.81 G

level     unknowns       nonzeros      memory
---------------------------------------------
    0      6859000       47796400      1.35 G (61.65%)
    1       830194       25941464    413.67 M (33.46%)
    2        49832        3622682     48.63 M ( 4.67%)
    3         2189         163833     15.02 M ( 0.21%)

Iterations: 9
Error     : 8.07738e-08

[Profile:    10.772 s] (100.00%)
[  setup:     4.041 s] ( 37.51%)
[  solve:     6.727 s] ( 62.45%)


$ amgcl.exe 200
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

  =============================================  

Whereas the VS2017 executable works w/o any problems:

VS2017: 

cl /O2 /openmp -DNDEBUG   -I../amgcl-master   -Id:/Software/Boost/boost_1_75_0    amgcl.cpp

$ amgcl.exe 190
Solver
======
Type:             BiCGStab
Unknowns:         6859000
Memory footprint: 366.31 M

Preconditioner
==============
Number of levels:    4
Operator complexity: 1.62
Grid complexity:     1.13
Memory footprint:    2.38 G

level     unknowns       nonzeros      memory
---------------------------------------------
    0      6859000       47796400      1.77 G (61.65%)
    1       830194       25941464    547.47 M (33.46%)
    2        49832        3622682     64.59 M ( 4.67%)
    3         2189         163833     15.02 M ( 0.21%)

Iterations: 9
Error     : 8.07724e-08

[Profile:    12.792 s] (100.00%)
[  setup:     4.511 s] ( 35.26%)
[  solve:     8.274 s] ( 64.68%)

$ amgcl.exe 256
Solver
======
Type:             BiCGStab
Unknowns:         16777216
Memory footprint: 896.00 M

Preconditioner
==============
Number of levels:    5
Operator complexity: 1.62
Grid complexity:     1.13
Memory footprint:    5.80 G

level     unknowns       nonzeros      memory
---------------------------------------------
    0     16777216      117047296      4.32 G (61.60%)
    1      2029083       63746807      1.31 G (33.55%)
    2       118853        8809677    156.79 M ( 4.64%)
    3         5000         399400      7.01 M ( 0.21%)
    4          206          11272    259.38 K ( 0.01%)

Iterations: 11
Error     : 9.93015e-07

[Profile:    34.092 s] (100.00%)
[  setup:     9.815 s] ( 28.79%)
[  solve:    24.269 s] ( 71.19%)

Thanks!

Carl

[Denis Demidov]

Hello Carl,

It looks like the reported memory in the VS case is higher than 4GB.

Could the reason for the g++ failure be that the executable (or the compiler itself) is built in 32bit mode (and thus is not able to allocate more than 4GB)?

I think on windows the limit is even lower than that (something like 3GB?).

Re boost configuration, it was a long time since I tried programming on windows, but I think you need to specify the exact toolkit and the address model when either bootstrapping or running ./b2.

This could be of help:
https://stackoverflow.com/questions/43946538/how-to-build-boost-1-64-in-64-bits/43950508

You may also need to run both bootstrap and b2 from the developer command prompt provided by the visual studio:

https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs

[C B]

Hello Denis! 

You are absolutely right, even when passing the flag -march=x86-64 the code was 32bits.

I installed the latest g++ and everything now work, and both memory and CPU/Wall from g++ and VS are very similar.

When I run ./b2  without arguments, and it appears that it created all version, including 32 and 64-bits, etc.

But I think that I might not have been totally successful, because even when the code is compiling, the basic example reading the .mtx matrix and rhs is not working.

However I am not too concerned about this for now, because I am learning how to work with the library by coding the matrices, and this is working well so far :).

About your not focusing on Windows. I see that most people doing HPC are mainly doing it on Linux, and a lot are just focusing on distributed memory.

And there are lots of applications which are built on Windows and could use hpc tools like your AMGCL to improve performance/reduce wall time.

And needless to say, you are the most knowledgeable on this library/subject, you could figure things out on Windows very quickly, and save your Win users a lot of time,

thereby facilitating the adoption of this amazing library !

Cheers!

Carl

--
You received this message because you are subscribed to the Google Groups "amgcl" group.
To unsubscribe from this group and stop receiving emails from it, send an email to amgcl+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/amgcl/d8e08124-a20f-4f0e-b903-fd68d9b42b85n%40googlegroups.com.