Re: [hpx-users] HPX and mvapich2

[Thomas Heller]

How did you invoke cmake? What was the output? How did you notice it's not
working as expected?

kniedzie  schrieb am Mi., 4. Sep. 2019, 21:45:

> Hi Thomas,
>
> thank you for your answer.
>
> I am using:
>
> cmake3 version 3.13.5
>
> mvapich2 version 2.3.2
>
> Best,
>
> Karol
> On 04/09/2019 21:19, Thomas Heller wrote:
>
> Hi Karol,
>
> As Hartmut said, CMake should be able to detect your mvapich2
> installation. Please check the following:
> Is the MPI compiler wrapper in your path?
>
> Another reason could be, that your cmake version is too old. Which cmake
> version, and which version of mvapich2 are you using?
>
> Regards,
> Thomas
>
> On Sat, Aug 24, 2019 at 4:25 AM Hartmut Kaiser 
> wrote:
>
>> Karol,
>>
>> I wouldn't know why a usual cmake configuration doesn't work. Cmake's
>> find_package(mpi) should find your installation of MVapich2. You may have
>> to
>> help it finding your files, though.
>>
>> Regards Hartmut
>> ---
>> http://stellar.cct.lsu.edu
>> https://github.com/STEllAR-GROUP/hpx
>>
>>
>> > -Original Message-
>> > From: hpx-users-boun...@stellar.cct.lsu.edu > > boun...@stellar.cct.lsu.edu> On Behalf Of kniedzie
>> > Sent: Thursday, August 22, 2019 9:20 AM
>> > To: hpx-users@stellar.cct.lsu.edu
>> > Subject: [hpx-users] HPX and mvapich2
>> >
>> > Hi all,
>> >
>> > is it possible to use HPX with mvapich2? If yes, how can I do that?
>> > Typical cmake configuration does not work in this case.
>> >
>> > Best,
>> >
>> > Karol Niedzielewski
>> >
>> > --
>> > Interdisciplinary Centre for Mathematical and Computational Modelling
>> > (ICM), University of Warsaw
>> >
>> > ul. Kupiecka 32, 03-046 Warsaw, Poland
>> >
>> > www.icm.edu.pl
>> >
>> > ___
>> > hpx-users mailing list
>> > hpx-users@stellar.cct.lsu.edu
>> > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>>
>>
>> ___
>> hpx-users mailing list
>> hpx-users@stellar.cct.lsu.edu
>> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>>
> --
> Interdisciplinary Centre for Mathematical and Computational Modelling
> (ICM), University of Warsaw
>
> ul. Kupiecka 32, 03-046 Warsaw, Poland
> www.icm.edu.pl
>
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] HPX and mvapich2

[Thomas Heller]

Hi Karol,

As Hartmut said, CMake should be able to detect your mvapich2 installation.
Please check the following:
Is the MPI compiler wrapper in your path?

Another reason could be, that your cmake version is too old. Which cmake
version, and which version of mvapich2 are you using?

Regards,
Thomas

On Sat, Aug 24, 2019 at 4:25 AM Hartmut Kaiser 
wrote:

> Karol,
>
> I wouldn't know why a usual cmake configuration doesn't work. Cmake's
> find_package(mpi) should find your installation of MVapich2. You may have
> to
> help it finding your files, though.
>
> Regards Hartmut
> ---
> http://stellar.cct.lsu.edu
> https://github.com/STEllAR-GROUP/hpx
>
>
> > -Original Message-
> > From: hpx-users-boun...@stellar.cct.lsu.edu  > boun...@stellar.cct.lsu.edu> On Behalf Of kniedzie
> > Sent: Thursday, August 22, 2019 9:20 AM
> > To: hpx-users@stellar.cct.lsu.edu
> > Subject: [hpx-users] HPX and mvapich2
> >
> > Hi all,
> >
> > is it possible to use HPX with mvapich2? If yes, how can I do that?
> > Typical cmake configuration does not work in this case.
> >
> > Best,
> >
> > Karol Niedzielewski
> >
> > --
> > Interdisciplinary Centre for Mathematical and Computational Modelling
> > (ICM), University of Warsaw
> >
> > ul. Kupiecka 32, 03-046 Warsaw, Poland
> >
> > www.icm.edu.pl
> >
> > ___
> > hpx-users mailing list
> > hpx-users@stellar.cct.lsu.edu
> > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Debugging bad locality number on MPI?

[Thomas Heller]

It sounds to me that the issue described is similar to
https://github.com/STEllAR-GROUP/hpx/pull/3948.
Something changed how we retrieve the number of localities (the issue with
alps was discovered on 1.3.0).

Hartmut Kaiser  schrieb am Fr., 5. Juli 2019
18:51:

> Andy,
>
> Could you please list your MPI env variables here? The number of localities
> should be picked up from them before the parcelport is initialized.
> Something goes wrong there, so it assumes that networking should not be
> enabled at all...
>
> Thanks!
> Regards Hartmut
> ---
> http://stellar.cct.lsu.edu
> https://github.com/STEllAR-GROUP/hpx
>
>
> > -Original Message-
> > From: hpx-users-boun...@stellar.cct.lsu.edu  > boun...@stellar.cct.lsu.edu> On Behalf Of Andreas Schäfer
> > Sent: Friday, July 5, 2019 5:14 AM
> > To: hpx-users@stellar.cct.lsu.edu
> > Subject: Re: [hpx-users] Debugging bad locality number on MPI?
> >
> > Thanks Thomas!
> >
> > The MPI environment variables are set up correctly. I dug a bit deeper
> and
> > figured out that HPX isn't even enabling networking. In
> > hpx/src/util/runtime_configuration.cpp the function
> > enable_networking() only enables networking if one of the following
> > conditions is true:
> >
> > a) the number of localities is > 1
> > b) the node number (is this the rank?) is > 0
> > c) the number of expected localities is != 0
> > d) the runtime mode is not console
> >
> > In my case the values are
> > a) 1
> > b) -1
> > c) 0
> > d) console
> >
> > These seem to be correct, since HPX can't know the number of localities
> > prior to initializing the MPI parcelport.
> > (enable_networking() is run when the parcelhandler is created, but before
> > the parcelports are instantiated.
> >
> > I'll be honest: I don't quite understand the logic there, but if I change
> > the code to enable networking in console mode, or if I enable networking
> > if the node number equals -1, then it works.
> >
> > Looks like the this was introduced with https://github.com/STEllAR-
> > GROUP/hpx/commit/ffb8470e6a1143e9e1c95c39eff58eec322148d3#diff-
> > 86850321552971332a5de979a34bd259
> >
> > Thoughts?
> >
> > Thanks!
> > -Andi
> >
> >
> > On 10:45 Fri 05 Jul , Thomas Heller wrote:
> > > The relevant parts in the codebase are here:
> > > Setting the env to check via cmake:
> > > https://github.com/STEllAR-GROUP/hpx/blob/master/plugins/parcelport/mp
> > > i/CMakeLists.txt#L42 Detecting if we run inside a MPI environment:
> > > https://github.com/STEllAR-GROUP/hpx/blob/master/plugins/parcelport/mp
> > > i/mpi_environment.cpp#L30-L52
> > >
> > > On Fri, Jul 5, 2019 at 10:41 AM Thomas Heller 
> > wrote:
> > >
> > > > The initialization of the MPI parcelport is done by checking
> > > > environment variables set by the most common MPI implementations.
> > > > Which MPI implementation do you use? Can you attach the output of
> > `mpirun env` maybe?
> > > >
> > > > Andreas Schäfer  schrieb am Fr., 5. Juli 2019 08:58:
> > > >
> > > >>
> > > >> On 01:11 Fri 05 Jul , Marcin Copik wrote:
> > > >> > I've seen such issue in pure MPI applications. The usual reason
> > > >> > is using an mpirun/mpiexec provided by an implementation
> > > >> > different than the one used for linking. Checking for a mismatch
> > there might help.
> > > >>
> > > >> There is only one MPI version installed on that machine. Also,
> > > >> running a simple MPI hello world works as expected. My assumption
> > > >> is that the MPI parcelport is not initialized correctly. Which part
> > > >> of the code loads/initialized all the parcelports?
> > > >>
> > > >> Thanks
> > > >> -Andi
> > > >>
> > > >>
> > > >> --
> > > >> ==
> > > >> Andreas Schäfer
> > > >>
> > > >> HPC and Supercomputing for Computer Simulations LibGeoDecomp
> > > >> project lead, http://www.libgeodecomp.org
> > > >>
> > > >> PGP/GPG key via keyserver
> > > >>
> > > >> I'm an SRE @ Google, this is a private account though.
> > > >> All mails are my own and not Google's.
> > > >> 

Re: [hpx-users] Debugging bad locality number on MPI?

[Thomas Heller]

The relevant parts in the codebase are here:
Setting the env to check via cmake:
https://github.com/STEllAR-GROUP/hpx/blob/master/plugins/parcelport/mpi/CMakeLists.txt#L42
Detecting if we run inside a MPI environment:
https://github.com/STEllAR-GROUP/hpx/blob/master/plugins/parcelport/mpi/mpi_environment.cpp#L30-L52

On Fri, Jul 5, 2019 at 10:41 AM Thomas Heller  wrote:

> The initialization of the MPI parcelport is done by checking environment
> variables set by the most common MPI implementations. Which MPI
> implementation do you use? Can you attach the output of `mpirun env` maybe?
>
> Andreas Schäfer  schrieb am Fr., 5. Juli 2019 08:58:
>
>>
>> On 01:11 Fri 05 Jul , Marcin Copik wrote:
>> > I've seen such issue in pure MPI applications. The usual reason is
>> > using an mpirun/mpiexec provided by an implementation different than
>> > the one used for linking. Checking for a mismatch there might help.
>>
>> There is only one MPI version installed on that machine. Also, running
>> a simple MPI hello world works as expected. My assumption is that the
>> MPI parcelport is not initialized correctly. Which part of the code
>> loads/initialized all the parcelports?
>>
>> Thanks
>> -Andi
>>
>>
>> --
>> ==
>> Andreas Schäfer
>>
>> HPC and Supercomputing for Computer Simulations
>> LibGeoDecomp project lead, http://www.libgeodecomp.org
>>
>> PGP/GPG key via keyserver
>>
>> I'm an SRE @ Google, this is a private account though.
>> All mails are my own and not Google's.
>> ==
>>
>> (\___/)
>> (+'.'+)
>> (")_(")
>> This is Bunny. Copy and paste Bunny into your
>> signature to help him gain world domination!
>> ___
>> hpx-users mailing list
>> hpx-users@stellar.cct.lsu.edu
>> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>>
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Debugging bad locality number on MPI?

[Thomas Heller]

The initialization of the MPI parcelport is done by checking environment
variables set by the most common MPI implementations. Which MPI
implementation do you use? Can you attach the output of `mpirun env` maybe?

Andreas Schäfer  schrieb am Fr., 5. Juli 2019 08:58:

>
> On 01:11 Fri 05 Jul , Marcin Copik wrote:
> > I've seen such issue in pure MPI applications. The usual reason is
> > using an mpirun/mpiexec provided by an implementation different than
> > the one used for linking. Checking for a mismatch there might help.
>
> There is only one MPI version installed on that machine. Also, running
> a simple MPI hello world works as expected. My assumption is that the
> MPI parcelport is not initialized correctly. Which part of the code
> loads/initialized all the parcelports?
>
> Thanks
> -Andi
>
>
> --
> ==
> Andreas Schäfer
>
> HPC and Supercomputing for Computer Simulations
> LibGeoDecomp project lead, http://www.libgeodecomp.org
>
> PGP/GPG key via keyserver
>
> I'm an SRE @ Google, this is a private account though.
> All mails are my own and not Google's.
> ==
>
> (\___/)
> (+'.'+)
> (")_(")
> This is Bunny. Copy and paste Bunny into your
> signature to help him gain world domination!
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Inquiry

[Thomas Heller]

Hi there and welcome,

There really is no specific background knowledge required in order to
contribute! Any help is highly appreciated. I suggest you come by at
out IRC channel #ste||ar on freenode to have a more interactive chat
and I am sure we can find a good project to get you started!

Regards,
Thomas

On Sun, Jun 30, 2019 at 11:32 PM LatticeQCDHolder
 wrote:
>
> Hello,
>
> I'm a journeyman C++ developer with a physics background. I'm looking for an 
> open source project involving high-performance computing to contribute to, 
> and I just recently discovered this: *really* cool stuff you've got going on! 
> I'd be interested in helping in whatever modest capacity I can, but I'm 
> worried I don't have the background needed to work on HPX due to being 
> self-taught: I'm constantly finding holes I need to fill up. Do you have a 
> general list of background knowledge that you need a contributor to have?
>
> I'm sorry if this is a dumb question, I just don't want to dive in blindly 
> and end up hitting concrete if you know what I mean.
>
> Best regards,
>
> Ian Robert George.
>
>
> Sent with ProtonMail Secure Email.
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Benchmarks

[Thomas Heller]

Hi Karol,

The below looks like you are on a Cray machine, forcing static linking
to off (it is off by default anyway) and using the Cray compiler
wrapper, which adds some special static linking flags by default.
This is the reason for the error you are seeing. CMake thinks it needs
to link dynamically, setting its own set of flags, the cray compiler
tries to link statically.
For compilation with the Cray compiler wrappers, I recommend using our
toolchain files linked here:
https://stellar-group.github.io/hpx/docs/sphinx/latest/html/manual/building_hpx.html#cmake-toolchains-shipped-with-hpx

I hope this helps. Please purge your build directory before trying.

On Mon, Apr 29, 2019 at 4:56 PM Adrian Serio  wrote:
>
> Forwarding your question to the list.
>
> On 4/29/2019 9:36 AM, kniedzie wrote:
>
> Adrian,
>
> thank you for you help. This information was helpful.
>
> Now I have problem building hpx with mpi. I receive this output:
>
> [ 54%] Linking CXX executable ../../../bin/test_client_1950
> /usr/bin/ld: ../../../lib/libtest_server_1950.a(server_1950.cpp.o): in 
> function `hpx::naming::gid_type::~gid_type()':
> /home/kn405499/tmp/hpx/hpx/runtime/actions/basic_action.hpp:171: multiple 
> definition of `hpx_exported_plugins_list_hpx_factory'; 
> ../../../lib/libhpx.a(runtime_support.cpp.o):/home/kn405499/tmp/hpx/src/runtime/components/runtime_support.cpp:13:
>  first defined here
> /usr/bin/ld: ../../../lib/libtest_server_1950.a(server_1950.cpp.o): in 
> function `hpx_exported_plugins_list_hpx_registry':
> /opt/gcc/7.3.0/snos/include/g++/bits/basic_ios.h:462: multiple definition of 
> `hpx_exported_plugins_list_hpx_registry'; 
> ../../../lib/libhpx.a(runtime_support.cpp.o):/home/kn405499/tmp/hpx/src/runtime/components/runtime_support.cpp:14:
>  first defined here
> /usr/bin/ld: ../../../lib/libtest_server_1950.a(server_1950.cpp.o): in 
> function `hpx_exported_plugins_force_load_hpx_factory':
> /opt/gcc/7.3.0/snos/include/g++/istream:607: multiple definition of 
> `hpx_exported_plugins_force_load_hpx_factory'; 
> ../../../lib/libhpx.a(runtime_support.cpp.o):/home/kn405499/tmp/hpx/src/runtime/components/runtime_support.cpp:13:
>  first defined here
> /usr/bin/ld: ../../../lib/libtest_server_1950.a(server_1950.cpp.o): in 
> function `hpx_exported_plugins_force_load_hpx_registry':
> /opt/gcc/7.3.0/snos/include/g++/istream:608: multiple definition of 
> `hpx_exported_plugins_force_load_hpx_registry'; 
> ../../../lib/libhpx.a(runtime_support.cpp.o):/home/kn405499/tmp/hpx/src/runtime/components/runtime_support.cpp:14:
>  first defined here
> /usr/bin/ld: ../../../lib/libhpx.a(runtime_support_server.cpp.o): in function 
> `hpx::util::plugin::dll::LoadLibrary(hpx::error_code&, bool)':
> /home/kn405499/tmp/hpx/hpx/util/plugin/detail/dll_dlopen.hpp:297: warning: 
> Using 'dlopen' in statically linked applications requires at runtime the 
> shared libraries from the glibc version used for linking
> /usr/bin/ld: ../../../lib/libhpx.a(asio_util.cpp.o): in function 
> `boost::asio::ip::basic_resolver::resolve(boost::asio::ip::basic_resolver_query
>  const&)':
> /home/kn405499/libs/boost_1_69_0/include/boost/asio/detail/impl/socket_ops.ipp:3344:
>  warning: Using 'getaddrinfo' in statically linked applications requires at 
> runtime the shared libraries from the glibc version used for linking
> collect2: error: ld returned 1 exit status
> tests/regressions/build/CMakeFiles/test_client_1950.dir/build.make:111: 
> recipe for target 'bin/test_client_1950' failed
> make[2]: *** [bin/test_client_1950] Error 1
> CMakeFiles/Makefile2:9348: recipe for target 
> 'tests/regressions/build/CMakeFiles/test_client_1950.dir/all' failed
> make[1]: *** [tests/regressions/build/CMakeFiles/test_client_1950.dir/all] 
> Error 2
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2
>
> My cmake configuration is:
>
> cmake -DBOOST_ROOT=/home/kn405499/libs/boost_1_69_0 \
>  -DHWLOC_ROOT=/home/kn405499/libs/hwloc-2.0.3/ \
>  -DCMAKE_INSTALL_PREFIX=/home/kn405499/libs/hpx_build_system_mpi \
>  -DCMAKE_BUILD_TYPE=RelWithDebInfo \
>  -DCMAKE_C_COMPILER=cc \
>  -DCMAKE_CXX_COMPILER=CC \
>  -DHPX_WITH_EXAMPLES=ON \
>  -DHPX_WITH_MALLOC=system \
>  -DHPX_WITH_STATIC_LINKING=OFF \
>  -DHPX_WITH_STATIC_EXE_LINKING=OFF \
>  -DHPX_WITH_PARCELPORT_MPI=ON \
>  -DMPI_C_COMPILER=cc \
>  -DMPI_CXX_COMPILER=CC \
>  -DHPX_WITH_TAU=OFF \
>  -DTAU_ROOT=/home/kn405499/libs/tau-2.25 \
>  -DTAU_ARCH=x86_64 \
>  -DTAU_OPTIONS=-mpi-pthread \
>  -DHPX_WITH_APEX=OFF \
>  -DAPEX_WITH_ACTIVEHARMONY=OFF \
>  -DAPEX_WITH_PAPI=OFF \
>  -DAPEX_WITH_MSR=OFF \
>  -DAPEX_WITH_OTF2=OFF \
>  -DACTIVEHARMONY_ROOT=/home/kn405499/libs/harmony-4.6.0/ \
>  /home/kn405499/tmp/hpx
>
> Do you now how to solve this issue?
>
> Best,
>
> Karol
>
> On 1/22/19 5:56 PM, Adrian Serio wrote:
>
> Karol,
>
> Our team did produce a paper on the inncabs benchmarks:
>
> http://stellar.cct.lsu.edu/pubs/hpcmaspa2016.pdf
>
> https://github.com/STEllAR-GROUP/inncabs
>
> Perhaps this is

Re: [hpx-users] performance study of HPX runtime

[Thomas Heller]

On Mon, Jan 28, 2019 at 8:27 AM yongkee kwon  wrote:
>
> Hartmut and Thomas,
>
> Thank you for the references. I will take a look at the benchmarks and the 
> publications. Hartmut's talks at CppCon brought me to HPX and I'm just done 
> with watching HPX tutorials in CSCS by Thomas and John. I do also thank you 
> for great lectures and tutorials about HPX.

Thanks!

>
> While I will be trying to learn more from the benchmarks and publications, 
> let me ask a bit more specific questions. First of all, is a coroutine 
> implemented in HPX is just about same as C++ coroutine discussed in TS, which 
> is stackless and relies solely on a compiler for transformations and 
> optimizations, or is there anything more in HPX than that?

They are more or less two different concepts. The C++ coroutine TS
deals with language and library extensions to allow for zero-cost
abstractions to write coroutines. By itself, the couroutine TS is
useless and specifies the basic concepts needed. This has been
explored by a number of people now. mostly focusing on asynchronous
I/O and related topics, not necessarily parallelism. See for example
here: https://github.com/lewissbaker/cppcoro or here:
http://ericniebler.com/2017/08/17/ranges-coroutines-and-react-early-musings-on-the-future-of-async-in-c/

>
> Also, could any of you point out if there is any example with coroutines and 
> active messages? I found a few with await but unfortunately fibonacci_await 
> failed, as commented in CMakeList, with an exception( what(): abandoning not 
> ready shared state: HPX(broken_promise) ). I also found transpose_await but 
> haven't had a chance to run it.

The await examples probably need some work to be adapted to the latest
state of the TS. We haven't updated it in a long time ... PRs are
welcome!

>
>  More examples are always better so please let me know if there is any more 
> example for coroutines and active message.

The nice thing about our abstractions build around hpx::future, is
that they work the same, regardless if you have local work or invoke
work remotely (through actions that is, which some refer to as active
messages).

I think there are lots of things which need to improved and worked on,
depending on our actual research goal.
Nevertheless, I think HPX is unique in offering a unified view (in
terms of syntax and semantics) to shared memory and distributed memory
parallelization which is hard to find in any other solution. So even
if there are initial hiccups, I'd like to invite you to work with us
to make your experience and HPX in general better.

>
> Thanks,
> Yongkee
>
> On Mon, Jan 28, 2019 at 12:26 AM Thomas Heller  wrote:
>>
>> Hi Yongkee,
>>
>> In addition to the performance tests, we published a wide range of
>> papers looking at the performance. Pleas have a look here:
>> http://stellar-group.org/publications/
>>
>> On Sun, Jan 27, 2019 at 6:16 PM Hartmut Kaiser  
>> wrote:
>> >
>> > Hey Yongkee,
>> >
>> > Thanks for your interest in HPX!
>> >
>> > > While I was looking for programming model and runtime system which 
>> > > support
>> > > both active messages and coroutines, I get to know HPX and now I am 
>> > > trying
>> > > to learn it with nice tutorials.
>> > >
>> > > I haven't (and can't) decided yet whether I am going for HPX for my
>> > > research yet since I am not so sure if HPX is competitive in terms of its
>> > > runtime performance (or overhead) as compared to others, if any.
>> > >
>> > > For example, I am wondering what differences are between HPX coroutines
>> > > and LLVM implementation with libc++, which is also getting to pretty a
>> > > stable stage I believe. For active messages I am not much aware of others
>> > > but I remember UPC or UPC++ is designed as PGAS language.
>> > >
>> > > HPX is still the best candidate for my research because it supports all
>> > > fun features within the single framework. But before going further, it
>> > > would be great for me to see any study about how much the runtime system
>> > > is comparatively lightweight and scalable especially in terms of both
>> > > features: active messages and coroutines.
>> > >
>> > > Please let me know if there is any prior study for me. Also any comment
>> > > with regard to my concerns above would be greatly appreciated!
>> >
>> > We have a couple of benchmarks here:
>> > https://github.com/STEllAR-GROUP/hpx/tree/master/tests/performance/local.
>> > That's where you might be

Re: [hpx-users] performance study of HPX runtime

[Thomas Heller]

Hi Yongkee,

In addition to the performance tests, we published a wide range of
papers looking at the performance. Pleas have a look here:
http://stellar-group.org/publications/

On Sun, Jan 27, 2019 at 6:16 PM Hartmut Kaiser  wrote:
>
> Hey Yongkee,
>
> Thanks for your interest in HPX!
>
> > While I was looking for programming model and runtime system which support
> > both active messages and coroutines, I get to know HPX and now I am trying
> > to learn it with nice tutorials.
> >
> > I haven't (and can't) decided yet whether I am going for HPX for my
> > research yet since I am not so sure if HPX is competitive in terms of its
> > runtime performance (or overhead) as compared to others, if any.
> >
> > For example, I am wondering what differences are between HPX coroutines
> > and LLVM implementation with libc++, which is also getting to pretty a
> > stable stage I believe. For active messages I am not much aware of others
> > but I remember UPC or UPC++ is designed as PGAS language.
> >
> > HPX is still the best candidate for my research because it supports all
> > fun features within the single framework. But before going further, it
> > would be great for me to see any study about how much the runtime system
> > is comparatively lightweight and scalable especially in terms of both
> > features: active messages and coroutines.
> >
> > Please let me know if there is any prior study for me. Also any comment
> > with regard to my concerns above would be greatly appreciated!
>
> We have a couple of benchmarks here:
> https://github.com/STEllAR-GROUP/hpx/tree/master/tests/performance/local.
> That's where you might be interested in starting your investigations.
>
> HTH
> Regards Hartmut
> ---
> http://stellar.cct.lsu.edu
> https://github.com/STEllAR-GROUP/hpx
>
>
>
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Contributing to HPX

[Thomas Heller]

On Wed, Oct 24, 2018 at 10:14 PM Biddiscombe, John A. 
wrote:

> Ahmed
>
> I'm a little bit frightened by the idea of you working on hwloc+hpx - the
> reason is the same as the one that caused problems in gsoc.
>

Something I have in mind, which would be a good fit with clear direction
and specification would be this here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0796r1.pdf


>
> * we don't have a well defined plan on what we want to do with hwloc yet.
> I would like to clean it up and make it better, but only because it is
> missing a couple of functions that I would like - but I don't really know
> hwloc that well either. (same as I didn't really know fflib)
>
> If you are working on a a problem and the tools you have don't quite solve
> the problem, then you can tweak the tools to work - for this reason I am
> looking at hwloc and asking myself - how do I find out which socket on the
> node is 'closest' to the gpu? Should I create a thread pool for GPU
> managment on socket 0, or socket 1 (or 2,3.4 ...). I will be working on a
> machine with 6 gpu's and 2 processors. it is probably safe to assume that
> gpu's 0,1,2 are closest to socket 0, and 3,4,5 to socket 1 - but maybe it's
> 0,2,4 and 1,3,5 - I'd like to be able to query hwloc and get this info and
> build it into our resource partitioned in such a way that the programmer
> can just say "which gpus should I use from this socket" or vice versa.
> So I know what I want - but I don't really have a plan yet, and usually,
> one knocks up a bit of code, get's something that half works and is good
> enough, then tries to make it fit into the existing framework and realize
> that something else needs to be tweaked to make it fit nicely with the rest
> of HPX. This requires a deal of understanding of the hpx internals and how
> it all fits together.
>
> So in summary, its better for you to find a project that already interests
> you (part of your coursework?) and use HPX for that project - this gives
> you time to learn how hpx works and use it a bit - then extend it gradually
> as your knowledge grows. hwloc/topology is quite a low level part of hpx
> and does require a bit of help. If you were here in the office next door to
> me, it'd be no problem - cos you could get help any time, but working on
> your own is going to be tough.
>
> I'm not saying do't do it (I did suggest it after all), but it will be
> hard to get going.
>
> I will try to think of some other less low level things we could use help
> with. (Ideas Thomas?)
>
> JB
>
> --
> *From:* hpx-users-boun...@stellar.cct.lsu.edu [
> hpx-users-boun...@stellar.cct.lsu.edu] on behalf of Ahmed Ali [
> ahmed.al...@eng-st.cu.edu.eg]
> *Sent:* 24 October 2018 14:12
> *To:* hartmut.kai...@gmail.com
> *Cc:* hpx-users@stellar.cct.lsu.edu
> *Subject:* Re: [hpx-users] Contributing to HPX
>
> John, Hartmut,
>
> Well I can go with that hwloc part. Where should I start? I think I
> should start by reading about hwloc from the open-mpi document. Is there
> any document about the HPX interface with hwloc?
>
> Best,
> Ahmed Samir
>
> On Tue, Oct 23, 2018 at 1:46 PM Hartmut Kaiser 
> wrote:
>
>>
>>
>> John, Ahmed,
>>
>>
>>
>> The hwloc integration sounds like a good idea to me. But anything else
>> would be fine as well.,,
>>
>>
>>
>> Regards Hartmut
>>
>> ---
>>
>> http://stellar.cct.lsu.edu
>>
>> https://github.com/STEllAR-GROUP/hpx
>>
>>
>>
>> *From:* hpx-users-boun...@stellar.cct.lsu.edu <
>> hpx-users-boun...@stellar.cct.lsu.edu> *On Behalf Of *Biddiscombe, John
>> A.
>> *Sent:* Tuesday, October 23, 2018 3:43 AM
>> *To:* hpx-users@stellar.cct.lsu.edu
>> *Subject:* Re: [hpx-users] Contributing to HPX
>>
>>
>>
>> Ahmed
>>
>>
>>
>> Good to hear from you again.
>>
>>
>>
>> >I was a participant in GSoC'18 in HPX but I've failed the program.
>>
>>
>>
>> I still feel bad about that.
>>
>>
>>
>> >However, I liked the project and the contribution to HPX. I wanted to
>> continue contributing to HPX so I want someone to guide me.
>>
>> Nice.
>>
>>
>>
>> >What part should I work on now? and where should I start?
>>
>> Well, there is the obvious option of continuing the parcelport work, but
>> I suspect you want to do something else since we didn’t help you enough
>> first time around. I’d certainly like to carry on with that and get it up
>> and running. It’s on my list, but I have a full plate already
>> unfortunately, so it has to wait if I’m doing it myself.
>>
>>
>>
>> There should still be a list of ‘projects’ that were compiled for GSoC
>> that you could look through and if something looks interesting, have a go
>> at it.
>>
>>
>>
>> If you have a project that you are already working on for your studies or
>> hobbies - why not try involving that somehow. Experience tells me that if
>> someone has a problem to solve and they use a library like HPX to solve it,
>> then they get much better results than if they just make up a project and
>> try to implement it. The 

Re: [hpx-users] Segmentation fault with mpi4py

[Thomas Heller]

Hi,

>From looking at the stacktrace, it is a segfault coming directly out of
MPI, which is then caught by our signal handlers.
In theory, there shouldn't be any problem with having multiple MPI
libraries running within HPX. The HPX parcelport tries to be a good citizen
and creates its own communicator. The problematic part however, might be
that you either have multiple calls to MPI_Init (HPX itself should handle
that correctly) or that the MPI implementation you are using is not thread
safe. HPX is driving MPI from all of its worker threads. For the purpose of
making MPI non thread implementations not crash, we use a lock to protect
each and every call into MPI (
https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/plugins/parcelport/mpi/mpi_environment.hpp#L42).
If you add a call to that around your pympi4 stuff, it might just work.

The suspension of the runtime should work as well. As soon as all worker
threads are suspended, there won't be any calls to MPI anymore. There still
might be incoming messages from other localities, but that shouldn't be a
problem.

I hope that scheds some light onto that problem.


On Tue, Oct 23, 2018 at 11:37 PM Simberg Mikael  wrote:

> Hi,
>
> hopefully someone else can chime in on the MPI and Python side of things,
> but thought I'd comment shortly on the runtime suspension since I
> implemented it.
>
> The reason for requiring a only a single locality for runtime suspension
> is simply that I never tested it with multiple localities. It may very well
> already work with multiple localities, but I didn't want users to get the
> impression that it's a well-tested feature. So if this is indeed useful for
> you you could try removing the check (you probably already found it, let me
> know if that's not the case) and rebuilding HPX.
>
> I suspect though that runtime suspension won't help you here since it
> doesn't actually disable MPI or anything else. All it does is put the HPX
> worker threads to sleep once all work is completed.
>
> In this case there might be a problem with our MPI parcelport interfering
> with mpi4py. It's not entirely clear to me if you want to use the
> networking features of HPX in addition to MPI. If not you can also build
> HPX with HPX_WITH_NETWORKING=OFF which will... disable networking. This
> branch is also meant to disable some networking related features at runtime
> if you're only using one locality:
> https://github.com/STEllAR-GROUP/hpx/pull/3486.
>
> Kind regards,
> Mikael
> --
> *From:* hpx-users-boun...@stellar.cct.lsu.edu [
> hpx-users-boun...@stellar.cct.lsu.edu] on behalf of Vance, James [
> va...@uni-mainz.de]
> *Sent:* Tuesday, October 23, 2018 4:38 PM
> *To:* hpx-users@stellar.cct.lsu.edu
> *Subject:* [hpx-users] Segmentation fault with mpi4py
>
> Hi everyone,
>
> I am trying to gradually port the molecular dynamics code Espresso++ from
> its current pure-MPI form to one that uses HPX for the critical parts of
> the code. It consists of a C++ and MPI-based shared library that can be
> imported in python using the boost.python library, a collection of python
> modules, and an mpi4py-based library for communication among the python
> processes.
>
> I was able to properly initialize and terminate the HPX runtime
> environment from python using the methods
> in hpx/examples/quickstart/init_globally.cpp
> and phylanx/python/src/init_hpx.cpp. However, when I use mpi4py to perform
> MPI-based communication from within a python script that also runs HPX, I
> encounter a segmentation fault with the following trace:
>
> -
> {stack-trace}: 21 frames:
> 0x2abc616b08f2  : ??? + 0x2abc616b08f2 in
> /lustre/miifs01/project/m2_zdvresearch/vance/hpx/builds/gcc-openmpi-bench/install/lib/libhpx.so.1
> 0x2abc616ad06c  : hpx::termination_handler(int) + 0x15c in
> /lustre/miifs01/project/m2_zdvresearch/vance/hpx/builds/gcc-openmpi-bench/install/lib/libhpx.so.1
> 0x2abc5979b370  : ??? + 0x2abc5979b370 in /lib64/libpthread.so.0
> 0x2abc62755a76  : mca_pml_cm_recv_request_completion + 0xb6 in
> /cluster/easybuild/broadwell/software/mpi/OpenMPI/2.0.2-GCC-6.3.0/lib/libmpi.so.20
> 0x2abc626f4ac9  : ompi_mtl_psm2_progress + 0x59 in
> /cluster/easybuild/broadwell/software/mpi/OpenMPI/2.0.2-GCC-6.3.0/lib/libmpi.so.20
> 0x2abc63383eec  : opal_progress + 0x3c in
> /cluster/easybuild/broadwell/software/mpi/OpenMPI/2.0.2-GCC-6.3.0/lib/libopen-pal.so.20
> 0x2abc62630a75  : ompi_request_default_wait + 0x105 in
> /cluster/easybuild/broadwell/software/mpi/OpenMPI/2.0.2-GCC-6.3.0/lib/libmpi.so.20
> 0x2abc6267be92  : ompi_coll_base_bcast_intra_generic + 0x5b2 in
> /cluster/easybuild/broadwell/software/mpi/OpenMPI/2.0.2-GCC-6.3.0/lib/libmpi.so.20
> 0x2abc6267c262  : ompi_coll_base_bcast_intra_binomial + 0xb2 in
> /cluster/easybuild/broadwell/software/mpi/OpenMPI/2.0.2-GCC-6.3.0/lib/libmpi.so.20
> 0x2abc6268803b  : ompi_coll_tuned_bcast_intra_dec_fixed + 0xcb in
> /cluster/easybuild/broadwell/software/mpi/Open

Re: [hpx-users] list of OS names

[Thomas Heller]

Patrick Welche  schrieb am Mo., 13. Aug. 2018 16:16:

> On Mon, Aug 13, 2018 at 08:06:25AM -0500, Hartmut Kaiser wrote:
> > FWIW, I have merged #3402 just now.
>
> Thanks!
>
> I have got as far as linking libhpx now - somehow there is a -ldl in
> link.txt (and in the generated pkg-config .pc files). I have been hunting
> through the cmake files where it comes from, but haven't found it. Any
> ideas? (dlopen and friends are in many OS's system library as opposed to
> libdl.)
>

If I'm not mistaken, this might even come out of the inner cmake core
itself.


> Cheers,
>
> Patrick
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] CMake Targets for HPX

[Thomas Heller]

On Sun, Aug 12, 2018 at 7:13 PM Jayesh Badwaik 
wrote:

> Is it possible to use HPX with CMake with Targets? For example, can I
> do `target_link_libraries(mylib INTERFACE/PUBLIC/PRIVATE HPX::HPX)`?
>

Please see my reply to your ticket here:
https://github.com/STEllAR-GROUP/hpx/issues/3408


>
> Thank you
>
> --
> Cheers
> Jayesh Badwaik
> https://jayeshbadwaik.gitlab.io
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] list of OS names

[Thomas Heller]

Hi Patrick,

Yes, it's hard to maintain. The problem is, that we have to rely on some OS
specific parts in very few places. From the top of my that includes:
 - User level context switching (that's the most crucial part)
 - Dynamic plugin loading (the one you stumbled over in your second mail)
 - OS thread handling (that should be handled by your C++ standard library
though)

We currently support (most) POSIX like systems (that should include OSX and
some BSD flavors) and Windows. For some *NIX flavors, we have some
workarounds. Most of it has grown over the years and could, probably
deserve a cleanup. Please also keep in mind that we don't run tests
regularly on those "exotic" platforms. However, if you want to dedicate
resources for testing, that would be awesome!

With that being said, we are totally open to suggestions to make this
handling of different OSes more maintainable. Do you have suggestions?

Regards,
Thomas


On Wed, Aug 8, 2018 at 10:06 PM Patrick Welche  wrote:

> I thought I would try out HPX, and hit:
>
> /tmp/pkgsrc/parallel/hpx/work.x86_64/hpx_1.1.0/src/exception.cpp:207:2:
> error: #error "Don't know, how to access the execution environment on this
> platform"
>  #error "Don't know, how to access the execution environment on this
> platform"
>
> I don't think a hand-coded list of operating systems is maintainable.
> Staring at it, I can't spot the difference between linux and __APPLE__
> for instance. Maybe linux, AIX, and __APPLE__ should just be the #else
> so that chances are, your code would compile on a not-listed OS, and
> you would only receive bug reports from the few that don't.
> (Is FreeBSD really different? I must check...)
>
> Cheers,
>
> Patrick
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Regarding GSoc 2018 Project

[Thomas Heller]

Hi,
Did you already approach me on IRC? I answered some questions there
already. If you haven't read them, I'll be happy to forward them again.

Please also use the public mailing list, so others can chime in and your
fellow students are aware of what's being discussed.

Am 17.02.2018 9:46 vorm. schrieb "ASHUTOSH KUMAR JATAV (B16CS004)" <
jata...@iitj.ac.in>:

hi,
  I am interested in one of the project of STE||ER group and that is
"Implement a Faster Associative Container for GIDs" can you please provide
me more guidance and explain the topic more and also can you tell me how
much is expected from us in this project .

Thank you
Regard
Ashutosh Kumar Jatav
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Performance Counter Data Interpretation

[Thomas Heller]

Hi Kilian,

The cumulative overhead counter indeed looks very odd. What it means is
the accumulated time *not* spend doing useful work.
Let's break it appart (For the single thread case):
 - The overall runtime of your application appears to be 2 seconds.
 - The number of total tasks run is 127704 with an average task length
   of about 15 micro seconds
 - The cumulative-overhead and the idle rate are closely related. about
   5.14% of the total runtime is spent in the scheduler. This is a good
   starting point

Now, when looking at the two core case, the overall number of tasks
doesn't significantly change, however, the average runtime increases
noticeably. What you observe in addition, is that the idle rate is
clocking in at 44%. This matches with the accumulated time spent in the
scheduler (the overhead) and the accumulated time spent doing useful
work. This trend is then followed by the 8 core run.

This could mean a variety of different things, the obvious one is this:
The average task duration is too little. That is, your granularity
appears to be too fine. IIRC, we recommend an average task length of
about 100 micro seconds (one magnitude different to your results).

What you see essentially is an increase of overhead due to the task
queues in the scheduler fighting for work.

To quickly test this hypothesis, you could artificially increase the
runtime of your tasks and see if that increases scalabilty. If that
helps, we have a winner and you need implement some kind of granularity
control, such that your tasks perform about 10 times more work, which
allows to mitigate the overheads more easily.

Hope that helps,
Thomas

On 01/09/2018 03:55 PM, Kilian Werner wrote:
> Dear Prof. Kaiser,
> 
> it is a new application we are building with hpx used for 
> parallelization (and a later distribution in mind).
> We have been working on it for the last two months and the 
> speedups have been this bad right from the start.
> However since the obvious, inherent bottlenecks were dealt 
> with one after the other we went to performance counters 
> for more detailed profiling.
> 
> Thanks,
> Kilian Werner
> 
> On Tue, 9 Jan 2018 08:47:12 -0600
>   "Hartmut Kaiser"  wrote:
>> Kilian,
>>
>> Was this slowdown happening always or did it just 
>> started to be bad
>> recently?
>>
>> Thanks!
>> Regards Hartmut
>> ---
>> http://boost-spirit.com
>> http://stellar.cct.lsu.edu
>>
>>
>>> -Original Message-
>>> From: hpx-users-boun...@stellar.cct.lsu.edu 
>>> [mailto:hpx-users-
>>> boun...@stellar.cct.lsu.edu] On Behalf Of Kilian Werner
>>> Sent: Tuesday, January 9, 2018 7:46 AM
>>> To: hpx-users@stellar.cct.lsu.edu
>>> Subject: [hpx-users] Performance Counter Data 
>>> Interpretation
>>>
>>> Dear hpx user list,
>>>
>>> one of our projects shows unexpectedly bad speedups when
>>> supplying additional OS-worker-threads to HPX.
>>> The project is run locally and in parallel on a machine
>>> with 8 cores, trying to pin down the parallelization
>>> bottleneck we printed the built in HPX Performance
>>> Counters as seen below.
>>> The parallelization is achieved by scheduling tasks with
>>> hpx::apply that themselves will schedule additional 
>>> tasks
>>> with hpx::apply.
>>> The program terminates after a final task (that can
>>> identify itself and will always finish last, independent
>>> of task scheduling order) fires an event.
>>> Synchronization is performed with some
>>> hpx::lcos::local::mutex locks.
>>>
>>> The problem seems to be apparent when looking at the
>>> harshly growing cumulative-overhead per worker-thread 
>>> when
>>> employing more OS threads.
>>> However we are a bit clueless as to interpret the 
>>> meaning
>>> of this cumulative-overhead counter.
>>> We were especially surprised to find, that the
>>> per-worker-thread overhead at some point came close to 
>>> and
>>> even surpassed the total cumulative runtime (see
>>> cumulative overhead of worker thread 0 when run with 8 
>>> os
>>> threads  vs. total cumulative runtime).
>>>
>>> What exactly does the performance counter
>>> /threads/time/cumulative-overhead measure? How can the
>>> overhead be larger than the total execution time?
>>> How could we narrow down the causes for the growing
>>> overhead? For example how could we measure how much time
>>> is spend waiting at (specific) mutexes  in total?
>>>
>>> Thanks in advance,
>>>
>>> Kilian Werner
>>>
>>>
>>>
>>> --hpx:threads 1:
>>>
>>> /threads{locality#0/total/total}/count/cumulative,1,2.015067,[s],127704
>>> /threads{locality#0/total/total}/time/average,1,2.015073,[s],14938,[ns]
>>> /threads{locality#0/total/total}/time/cumulative,1,2.015074,[s],1.90769e+0
>>> 9,[ns]
>>> /threads{locality#0/total/total}/time/cumulative-
>>> overhead,1,2.015076,[s],1.03483e+08,[ns]
>>> /threads{locality#0/pool#default/worker-thread#0}/time/cumulative-
>>> overhead,1,2.015076,[s],1.03483e+08,[ns]
>>> /threads{locality#0/total/total}/idle-rate,1,2.015078,[s],514,[0.01%]
>>>
>>> --hpx:threads 2:
>>

Re: [hpx-users] HPX - guidance regarding inter-locality communications

[Thomas Heller]

Hi Shmuel,

Am 07.12.2017 2:08 nachm. schrieb "Shmuel Levine" :

Hi All,

I’m looking for some help and guidance regarding passing along data between
localities.  I’ve got some ideas which I think would work, but I’d really
like some feedback, guidance and/or suggestions on this.



In general, all of the localities run the following conceptual loop:

a.   Test for convergence

b.   Run current iteration

c.   Migrate data / integrate data, if required



There are 3 communications scenarios I need to account for:

   1. Broadcasting some information to all other nodes.  For example, if
   the convergence tests succeed on one node, notify other nodes that they can
   stop processing.
   2. Send interim results to primary node for aggregation and reporting
   3. Migrate data conditionally



I am going to assume – for now, at least – that the **best** approach for
each scenario might be different, so I’ve separated the details / my
thoughts into separate sections below.



## Broadcasting information to other nodes



It seems to me that this could handled fairly simply if each component had:

   - Boolean flag
   - Action to set flag



This way, each node would test for convergence and if the test succeeds, I
can use broadcast to call this action on all of the other nodes, something
like: 
hpx::lcos::broadcast_apply(hpx::find_remote_localities()
);


That sounds like the best shot, yes. Some more suggestions here:
You can use your component ids directly here. One good approach would be to
register components with a basename and retrieve the vector using that same
basename. More information about that can be found here:
https://stellar-group.github.io/hpx/docs/html/header/hpx/runtime/basename_registration_hpp.html
The other suggestion is to use a direct action to set the flag in your
component, they don't spawn a separate thread when being invoked on the
remote end.



## Send interim results to primary node for aggregation and reporting



I spent a while typing up a rough proposal for an idea, and ended up with a
clumsy analog of receive_buffer ( I think -- I’m pretty sure that this is
what receive_buffer is intended to do, although that class isn’t documented
other than a regression test.)

Instead of using receive_buffer, you should use hpx::lcos::channel. It uses
receive_buffer internally and offers the abstractions you need.



## Migrate data conditionally between nodes



My expectations are that

   - I would like to send data based on some to-be-defined criteria which
   will likely be ‘data-centric’, not based on a fixed number of iterations.
   It is most likely that the receiving node will initiate the transfer (i.e.
   request data from one or more adjacent nodes).
   - I do not want the program to block waiting for data.  I am envisioning
   a test in the main control loop, which, if deemed necessary, would send a
   request to one or more adjacent nodes for data, and continue looping.  Once
   all of the new data has been received, then it can be incorporated at the
   beginning of the following iteration.  To be 100% clear, as an example: at
   iteration x, node N_d decides it needs new data from nodes N_c and N_e and
   executes an action on those 2 localities, then immediately starts iteration
   x+1.  Some time during x+1, the data from N_e arrives.  Then, the data from
   N_c arrives in the middle of iteration X+2.  The new data would be
   integrated into node N_d at the very beginning of iteration x+3.
   - Integrating received data cannot happen at an arbitrary time
   determined by the thread scheduler – this would cause major problems with
   the code execution.  In my mind, this means that the continuation for this
   future (or multiple futures)  causes the data to be staged into a temporary
   structure (e.g. a queue).



After mulling over this problem in my mind for hours, I think there are a
couple possibilities:



   1. Have the receiving node broadcast an action to the relevant nodes.
   For example:



Future > data_received = hpx::lcos::broadcast(adjacent_nodes,
migrate_data_action);

data_received.then([=](vector incoming_data){
incoming_data_stage.push_back(std::move(incoming_data)); }


This sounds good.



   1. I could probably also use receive_buffer: since the data transfer is
   initiated by the receiving node, I know which was the last index used for
   receiving data.  This time, I would not use broadcast, but rather iterate
   over the vector of localities, calling a remote action on each node and
   providing the index to use. Then, I could create a vector of futures from
   calling receive on those same indices, and use when_all to set up the
   continuation, as before.

I think that's overkill if you pull the data (instead of pushing).


   1.



   1. My first thought was to use channels; however, I don’t know how this
   could possibly work.  Among other things, I don’t know whether it is
   possible to che

Re: [hpx-users] Integration of HPX with GUI mainloop

[Thomas Heller]

Am 05.12.2017 2:13 nachm. schrieb "Andreas Buhr" :

On 12/04/2017 07:37 PM, Hartmut Kaiser wrote:
> There are several ways how to integrate Qt with HPX and let it run its
main
> loop.
>
> There is this example which explicitly drives Qt using HPX's
> main_pool_executor:
> https://github.com/STEllAR-GROUP/hpx/tree/master/examples/qt.

Wow, thanks a lot for your quick help and reply. But the example is
confusing me a bit.

The main problem when using a parallel system and Qt is that most member
functions of widgets must not be called from a thread other than the
main thread (GUI-thread). So when a thread other than the main thread
wants to trigger some GUI change, it has to communicate with the GUI
thread and the GUI thread then does the GUI change.

This principle is ignored in the example: In the example [1], an HPX
thread calls widget::add_label which in turn calls QListWidget::addItem.
I think this should not happen, even when protected with a mutex-lock.

I modified the code to be correct in my understanding: The widget has
now two threadsafe interface functions: threadsafe_add_label and
threadsafe_run_finished, both of which do not interact with GUI objects.
They might be called from any thread. They in turn schedule the
execution of corresponding functions within the GUI thread.

Would you agree? I am not a GUI expert, so I'm not sure about my solution.
I created a pull request [2]. Feel free to accept or reject...


You are most certainly correct. Thanks for catching this. Did you run into
any problems with what we have so far?


best regards,
Andreas


[1]
https://github.com/STEllAR-GROUP/hpx/blob/2ec00bc39b5d384aeda7cdb58a8936
80a057e2d2/examples/qt/widget.cpp#L53

[2]
https://github.com/STEllAR-GROUP/hpx/pull/3051


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Strong scalability of hpx dataflow and async

[Thomas Heller]

Hi Steve,

On Mittwoch, 11. Oktober 2017 18:24:36 CEST Steve Petruzza wrote:
> Going back to the channels discussion, how do you know if a channel has been
> already registered or not?
> 
> Look at the following code below (running with 2 localities):
> - they create or connect to the same channel name
> - if I introduce a delay in the receiver locality I get the following error:
> 
> Assertion failed: (buffer_map_.empty()), function ~receive_buffer, file
> hpx_install/include/hpx/lcos/local/receive_buffer.hpp, line 101.

I think this error can be solved by having something akin to that:
int hpx_main(boost::program_options::variables_map& vm){
std::vector localities =
hpx::find_all_localities();
auto cid = hpx::get_locality_id();
if(cid%2==0)
{
hpx::lcos::channel c(hpx::find_here());
c.register_as("name");
// Improve here with a custom neighbor barrier that only synchronizes 
with
// the localities that connect for better scalability
hpx::lcos::barrier::synchronize();

c.set(3);
}
else
{
usleep(100); // delay
hpx::lcos::channel c;
c.connect_to("name");

// Improve here with a custom neighbor barrier that only synchronizes 
with
// the localities that connect for better scalability
hpx::lcos::barrier::synchronize();
hpx::lcos::barrier::synchronize();

hpx::future p = c.get();
p.get();
}
}

When calling it with --hpx:run-hpx-main that scheme should scale reasonably 
well. To make it scale better, you should us a custom barrier instead of the 
global, system-wide one.

> 
> Here is the sample code:
> —
> 
> 
> void spmd_int(DataFlow::ShardId cid){
> if(cid%2==0){
> hpx::lcos::channel c(hpx::find_here());
> c.register_as(“name");
> c.set(3);
>   }
>   else{
> usleep(100); // delay
> hpx::lcos::channel c;
> c.connect_to("name");
> hpx::future p = c.get();
> p.get();
>   }
> }
> 
> 
> int hpx_main(boost::program_options::variables_map& vm){
> std::vector localities =
> hpx::find_all_localities();
> 
> int loc_count = 0;
>   for(auto loc: localities){
> 
> spmd_int_action act;
> hpx::async(act, loc, loc_count);
> 
> loc_count++;
>   }
> }
> 
> —
> 
> 
> What is happening here?
> If I add a
> c.connect_to("name");
> 
> to the the same task that does the registration (after
> c.register_as(“name");) it works, but I don’t like it (and in my actual
> application I still get this error).
> 
> More in general, when you have many of this channels at scale, do you think
> is better to use a register_as/connect_to mechanism or to pass alle the
> necessary channels to each locality at the beginning when I do the initial
> SPMD spawn?
> 
> Thanks,
> Steve
> 
> > On 11 Oct 2017, at 14:53, Steve Petruzza  wrote:
> > 
> > Thanks Hartmut, it all makes sense now.
> > 
> >> On 11 Oct 2017, at 14:51, Hartmut Kaiser  
wrote:
>  I think I’ve found a workaround.
>  
>  If I use a typedef as following:
>  
>  typedef std::vector vec_char;
>  
>  HPX_REGISTER_CHANNEL(vec_char);
>  
>  It works, but if I try to use directly:
>  HPX_REGISTER_CHANNEL(std::vector)
>  
>  this gives me the error I reported before.
>  The issue might be in the expansion of the macro HPX_REGISTER_CHANNEL.
> >>> 
> >>> Yes, that confirms my suspicion. I will have a looks what's going on.
> >> 
> >> Doh! The problem is that the (literal) parameter you give to the macro
> >> has to conform to the rules of a valid symbol name, i.e. no special
> >> characters are allowed (no '<', '>', etc.). Sorry, this has to be
> >> documented properly somewhere, and I forgot to mention it in the first
> >> place.
> >> 
> >> The 'workaround' you propose is the only way to circumvent problems.
> >> There is nothing we can do about it.
> >> 
> >> Also, wrt your comment that everything is working if you use
> >> hpx::lcos::local::channel instead - this is not surprising. The local
> >> channel type is representing a channel which can be used inside a given
> >> locality only (no remote operation, just inter-thread/inter-task
> >> communication), hence its name. Those channels don't require the use of
> >> the ugly macros, thus there is no problem.
> >> 
> >> HTH
> >> Regards Hartmut
> >> ---
> >> http://boost-spirit.com
> >> http://stellar.cct.lsu.edu
> >> 
> >>> Thanks!
> >>> Regards Hartmut
> >>> ---
> >>> http://boost-spirit.com
> >>> http://stellar.cct.lsu.edu
> >>> 
>  Steve
>  
>  
>  
>  
>  On 10 Oct 2017, at 18:38, Steve Petruzza 
>  wrote:
>  
>  Sorry, regarding the version that I am using it is the commit of your
>  
>  split_future for vector:
>    Adding split_future for std::vector
>    
>    - this fixes #2940
>  
>  commit 8ecf8197f9fc9d1cd45a7f9ee61a7be07ba26f46
>  
>  Steve
>  

Re: [hpx-users] Strong scalability of hpx dataflow and async

[Thomas Heller]

Am 13.10.2017 1:45 vorm. schrieb "Steve Petruzza" :

Yes, I got the things to work distributing the channels from the main task,
but I guess simply using hpx:async to spawn the tasks in an SPMD fashion is
not the best to scale, but it’s the only way I have now to pass all these
channels to each locality.


Right. It also leads to a congestion point for creating and registering the
channels.

One other option would be to use a barrier after you connected all channels:
https://stellar-group.github.io/hpx/docs/html/hpx/lcos/barrier.html

That way, you make sure that everyone is being kept alive.


Using the other executors that you mentioned how can I pass different
arguments to different localities (e.g., the channels)?

See below.


Is there any example of using tree-like spawning or bulk_async_execute
other then the tests?

You should really look into hpx::lcos:: broadcast. There is also a
_with_index one:
https://stellar-group.github.io/hpx/docs/html/header/hpx/lcos/broadcast_hpp.html

This should allow you to distribute work efficiently.


Thanks,
Steve







On 12 Oct 2017, at 09:53, Hartmut Kaiser  wrote:

Steve,

I see your point, but the problem is that I cannot know when the receiver
is going to be executes and so when it will receive the data.

Is there a way to wait on this channel until some task connects to and
make a get? This way I can keep the channel (and the task) alive until the
data has been consumed. I think there should be some mechanism to say
“wait for N tasks to connect”.


That's part of the deeper problem I hinted at. Let me think about this some
more before I respond.

I am reporting my other question:
More in general, when you have many channels at scale, do you
think is better to use a register_as/connect_to mechanism or to pass alle
the necessary channels to each locality at the beginning when I do the
initial SPMD spawn?


We usually use the register_as/connect_to mechanism as it separates
concerns nicely. But YMMV, so please try it out for yourself what works
best in your case. Sending a channel over the wire might overcome the
lifetime issues we're discussing as this would keep the channel alive no
matter what.

Regards Hartmut
---
http://boost-spirit.com
http://stellar.cct.lsu.edu



Thank you,
Steve





On 12 Oct 2017, at 09:28, Hartmut Kaiser  wrote:

Steve,


Going back to the channels discussion, how do you know if a channel has
been already registered or not?

Look at the following code below (running with 2 localities):
- they create or connect to the same channel name
- if I introduce a delay in the receiver locality I get the following
error:

Assertion failed: (buffer_map_.empty()), function ~receive_buffer,
file hpx_install/include/hpx/lcos/local/receive_buffer.hpp, line 101.

I think I understand what is going on. This assert says that you're trying
to destroy a channel with data sitting in the pipeline. This is caused by
your code:

  {
   hpx::lcos::channel c(hpx::find_here());
   c.register_as(“name");
   c.set(3);
  }

Which makes the channel go out of scope before the other locality had a
chance to connect and to extract the value.

There is also a deeper problem lurking behind the scenes, but that's
something I need to think about more before doing anything about it.

Regards Hartmut
---
http://boost-spirit.com
http://stellar.cct.lsu.edu



Here is the sample code:
—


void spmd_int(DataFlow::ShardId cid){
if(cid%2==0){
  hpx::lcos::channel c(hpx::find_here());
  c.register_as(“name");
  c.set(3);
}
else{
  usleep(100); // delay
  hpx::lcos::channel c;
  c.connect_to("name");
  hpx::future p = c.get();
  p.get();
}
}


int hpx_main(boost::program_options::variables_map& vm){
std::vector localities =
  hpx::find_all_localities();

int loc_count = 0;
for(auto loc: localities){

  spmd_int_action act;
  hpx::async(act, loc, loc_count);

  loc_count++;
}
}

—


What is happening here?
If I add a
c.connect_to("name");

to the the same task that does the registration (after
c.register_as(“name");) it works, but I don’t like it (and in my actual
application I still get this error).

More in general, when you have many of this channels at scale, do you
think is better to use a register_as/connect_to mechanism or to pass alle
the necessary channels to each locality at the beginning when I do the
initial SPMD spawn?

Thanks,
Steve


On 11 Oct 2017, at 14:53, Steve Petruzza  wrote:

Thanks Hartmut, it all makes sense now.



On 11 Oct 2017, at 14:51, Hartmut Kaiser  wrote:



I think I’ve found a workaround.

If I use a typedef as following:

typedef std::vector vec_char;

HPX_REGISTER_CHANNEL(vec_char);

It works, but if I try to use directly:
HPX_REGISTER_CHANNEL(std::vector)

this gives me the error I reported before.
The issue might be in the expansion of the macro HPX_REGISTER_CHANNEL.

Yes, that confirms my suspicion. I will have a looks what's going on.

Doh! The problem is that the (literal) par

Re: [hpx-users] Strong scalability of hpx dataflow and async

[Thomas Heller]

On Thu, Oct 12, 2017 at 2:24 AM, Steve Petruzza 
wrote:

> Going back to the channels discussion, how do you know if a channel has
> been already registered or not?
>
> Look at the following code below (running with 2 localities):
> - they create or connect to the same channel name
> - if I introduce a delay in the receiver locality I get the following
> error:
>
> 

>
> int hpx_main(boost::program_options::variables_map& vm){
> std::vector localities =
> hpx::find_all_localities();
>
> int loc_count = 0;
>   for(auto loc: localities){
>
> spmd_int_action act;
> hpx::async(act, loc, loc_count);
>
> loc_count++;
>   }
> }
>
> 

>
> More in general, when you have many of this channels at scale, do you
> think is better to use a register_as/connect_to mechanism or to pass alle
> the necessary channels to each locality at the beginning when I do the
> initial SPMD spawn?
>

Looking at the code as shown above, it will not scale. The bottleneck is
the linear spawn of `spmd_init_action`. If you operate in a SPMD fashio,
you should really use the "--hpx:run-hpx-main" command line parameter. This
runs hpx_main on each locality and avoids one extra broadcast. If you
indeed require such a startup code, that is spawning from a single, root
locality, you should use hpx::lcos::broadcast.

As of the initial question regarding connecting to vs. distributing GIDs
explicitly. I guess it is a question on how you want to distribute the GIDs
in the first place. By registering a name, you implicitly distribute this
information without explicit message passing. The symbol namespace (the
thing that resolves the name to a GID) does indeed scale. The strings are
usually constant and defined by the application (that is you). As a result,
you save those information distribution messages.

Of course, the problem with the channel going out of scope to early has to
be solved still. It is clearly a synchronization error, that is, the action
exits without waiting on the communicating partner. In your specific case,
connecting on the side of set and registering on the set side would solve
the issue you are seeing.


>
> Thanks,
> Steve
>
>
>
> On 11 Oct 2017, at 14:53, Steve Petruzza  wrote:
>
> Thanks Hartmut, it all makes sense now.
>
>
> On 11 Oct 2017, at 14:51, Hartmut Kaiser  wrote:
>
>
> I think I’ve found a workaround.
>
> If I use a typedef as following:
>
> typedef std::vector vec_char;
>
> HPX_REGISTER_CHANNEL(vec_char);
>
> It works, but if I try to use directly:
> HPX_REGISTER_CHANNEL(std::vector)
>
> this gives me the error I reported before.
> The issue might be in the expansion of the macro HPX_REGISTER_CHANNEL.
>
>
> Yes, that confirms my suspicion. I will have a looks what's going on.
>
>
> Doh! The problem is that the (literal) parameter you give to the macro has
> to conform to the rules of a valid symbol name, i.e. no special characters
> are allowed (no '<', '>', etc.). Sorry, this has to be documented properly
> somewhere, and I forgot to mention it in the first place.
>
> The 'workaround' you propose is the only way to circumvent problems. There
> is nothing we can do about it.
>
> Also, wrt your comment that everything is working if you use
> hpx::lcos::local::channel instead - this is not surprising. The local
> channel type is representing a channel which can be used inside a given
> locality only (no remote operation, just inter-thread/inter-task
> communication), hence its name. Those channels don't require the use of the
> ugly macros, thus there is no problem.
>
> HTH
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
>
> Thanks!
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
>
> Steve
>
>
>
>
> On 10 Oct 2017, at 18:38, Steve Petruzza  wrote:
>
> Sorry, regarding the version that I am using it is the commit of your
> split_future for vector:
>
>   Adding split_future for std::vector
>
>   - this fixes #2940
>
> commit 8ecf8197f9fc9d1cd45a7f9ee61a7be07ba26f46
>
> Steve
>
>
>
> On 10 Oct 2017, at 18:33, Steve Petruzza  wrote:
>
> hpx::find_here()
>
>
>
>
>
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] thread_stacksize_large for HPX_PLAIN_ACTION not working?

[Thomas Heller]

On 10/08/2017 08:14 PM, Hartmut Kaiser wrote:
> Steve,
> 
>> Thank you Harmut, I will report the bug.
> 
> 
> Thanks!
> 
>> But so this means that the only way to use my function remotely is to get
>> rid of all possible stack allocations?
>>
>> Or is there any setting/parameter of hpx to ask for more space in the
>> stack?
> 
> You can increase the stack-size globally. I'd suggest to change the code in 
> question to not allocate large chunks of memory on the stack, though.
> 
> You can pass -Ihpx.stacks.small_size=0x2 or similar on the command line 
> (0x8000 is the default).

With actions, you can also change the stack programmatically by using
the macro HPX_ACTION_USES_STACK. In your specific case, this would be:
HPX_ACTION_USES_STACK(testio_action, hpx::threads::thread_stacksize_large)
or short:
HPX_ACTION_USES_LARGE_STACK(testio_action)

see:
https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/runtime/actions/basic_action.hpp#L930-L951

The same can be done for the priority with HPX_ACTION_HAS_HIGH_PRIORITY
(and friends:
https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/runtime/actions/basic_action.hpp#L966-L992)

> 
> HTH
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
>>
>> Thank you,
>> Steve
>>
>>> On Oct 8, 2017, at 9:33 AM, Hartmut Kaiser 
>> wrote:
>>>
>>> Just making sure you receive this response, Steve...
>>>
>>> Regards Hartmut
>>> ---
>>> http://boost-spirit.com
>>> http://stellar.cct.lsu.edu
>>>
>>>
 -Original Message-
 From: Hartmut Kaiser [mailto:hartmut.kai...@gmail.com]
 Sent: Sunday, October 8, 2017 9:33 AM
 To: 'hpx-users@stellar.cct.lsu.edu' 
 Subject: RE: [hpx-users] thread_stacksize_large for HPX_PLAIN_ACTION
>> not
 working?

 Steve,

> After long debugging of my code I’ve found that calling hex::async on
>> an
> Actions that allocates some data in the stack results in SEG_FAULT.
>> The
> same is not true if I use simple (local) function calls.

 I think that we don't send the executor over the wire, they probably
>> will
 not work even for local invocations of actions.
 This is clearly a bug (i.e. missing implementation). Would you mind
 opening a ticket and attach a smallest possible self-contained test
>> case?

 Thanks!
 Regards Hartmut
 ---
 http://boost-spirit.com
 http://stellar.cct.lsu.edu


>
> Here is my code:
>
> ———
>
> int test(){
>  char filename[64*1024];
>
>  printf("DONE\n");
>  return 0;
>
> }
>
> HPX_PLAIN_ACTION(testio)
>
> int hpx_main(boost::program_options::variables_map& vm)
> {
>  hpx::parallel::execution::default_executor fancy_executor(
>hpx::threads::thread_priority_high,
>hpx::threads::thread_stacksize_large);
>
>  testio_action act;
>  hpx::future out = hpx::async(fancy_executor, act,
> hpx::find_here());
>
>  out.get();
>
>  return hpx::finalize();
> }
> ———
>
> This code results in a SEG_FAULT in test().
>
> Instead if I use the same function test() as a local call with:
>  hpx::future out = hpx::async(fancy_executor, &testio);
>
> Works correctly.
>
> What is going wrong using the Action? Should I add any settings to my
> executor or to HPX to tell that my actions require a bit more stack
> allocation?
>
> Thank you,
> Steve
>
>
>
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>>>
> 
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> 

___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Error on hpx_init on Cray XC40

[Thomas Heller]

Hi Steve,

this looks like some mismatch between build configurations indeed. Did you
pass the same CMAKE_CXX_COMPILER variable to your application? There might
also be a problem between debug and release builds. Could you share your
cmake configuration command for your application as well please?

On Wed, Oct 4, 2017 at 6:57 PM, Steve Petruzza 
wrote:

> Hi,
>
> I am trying to run my HPX application on a Cray XC40 machine.
>
> I built HPX with the following config:
> -DCMAKE_CXX_COMPILER=CC -DHPX_WITH_MALLOC=system
> -DHPX_WITH_PARCELPORT_MPI=ON -DHPX_WITH_STATIC_LINKING=ON
> -DHPX_WITH_HWLOC=OFF -DHPX_WITH_EXAMPLES=OFF
>
> When I simply try to run an example as following:
> srun ./1d_stencil_8 --hpx:threads 1
>
> I get the following error (apparently on the hpx::init()) call:
> terminate called after throwing an instance of 'std::length_error'
>   what():  vector::reserve
> srun: error: nid00753: task 0: Aborted
>
> Is there a problem in my build?
>
> Thank you,
> Steve
>
>
>
>
>
>
>
>
>
>
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] HPX concurrent queue ?

[Thomas Heller]

Hi Jean-Loup,

Am 24.08.2017 1:07 nachm. schrieb "Jean-Loup Tastet" <
jean-loup.tas...@epfl.ch>:

Hi all,

I am currently looking for a data structure that basically behaves like
TBB's `concurrent_queue`, except for the `pop()` operation which would
return a `hpx::future`, and would never fail. This way, `get()`-ting the
result would suspend the thread until the `pop()` has succeeded (possibly
never if the queue remains empty). Such a queue would be very useful to
manage tasks awaiting computing resources such as preallocated memory
buffers or CUDA streams.


hpx::lcos::local::channel is exactly what you need.


In my specific use case, the queue would only need to be local, and should
not be accessed from another locality (same NUMA domain should be okay,
though). Moreover, I will only need T = unsigned int.

I can certainly roll-out my own version of such a concurrent queue if
needed, but I would prefer to avoid reinventing the square wheel if
something similar already exists :-)

Is any of you aware of such a data structure or of a similar one ? Thanks
in advance for your suggestions.

Best regards,
Jean-Loup Tastet

___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Runtime error with simple class as component

[Thomas Heller]

Hi Tobias,

On Donnerstag, 1. Juni 2017 14:49:58 CEST Tobias Gauweiler wrote:
> Hello,
> 
 
> After compiling and running the code below i get the error message "***
> stack smashing detected ***".
> 
> I would highly appreciate it if you could help me.
> 
> Best regards
> Tobias Gauweiler
> 
> 
> hpx:version:
> 
> Versions:
>  HPX: V1.1.0 (AGAS: V3.0), Git: 73d25941cf
>  Boost: V1.62.0
>  Hwloc: V1.11.0
>  MPI: OpenMPI V2.0.2, MPI V3.1
> 
> Build:
>  Type: release
>  Date: May 16 2017 10:42:26
>  Platform: linux
>  Compiler: GNU C++ version 6.3.0 20170406
>  Standard Library: GNU libstdc++ version 20170406
>  Allocator: tcmalloc

I would like to know which OS (or Linux distribution) you are using. As 
Praveen pointed out correctly, this is due to the gcc stack protection. 
Unfortunately, it results in a false positive for HPX code. This is due to our 
user level context switch (which replaces the stack pointer) and gcc's stack 
protector feature just panics.
More unfortunately (at least for HPX) is that some Linux distributions ship 
with -fstack-protector enabled by default. You need to add -fno-stack-
protector to your CMAKE_CXX_COMPILE_FLAGS (at the first cmake invocation time, 
changing the compiler flags requires a completely fresh build directory).

This should fix your issue.

Cheers,
Thomas
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] partitioned_vectors questions

[Thomas Heller]

Hi Chris,

I hope I'll be able to answer your questions inline below...

On Dienstag, 25. April 2017 14:30:36 CEST ct clmsn wrote:
> thomas,
> 
> i'm in the midst of building a customized type to load histogram
> information from files into a partitioned_vector. ideally, an hpx parallel
> loop (for_each) should run over the partitioned_vector's elements in order
> to schedule execution of an hpx-action which tells the partitioned_vector's
> elements to load their respective data files (the parallel loop is a vector
> of file paths).

Alright ... in that case, I'd suggest to write an application which combines 
hpx::partitioned_vector and hpx::unordered_map 
(https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/components/containers/unordered/
unordered_map.hpp#L222).

Depending on how you get the list of files, you can create a partitioned_vector 
with a specific size, then use for_each to get the entries. The User-defined 
element function will then be executed exactly where the specific element 
resides. In this function (which needs to be serializable), you can then load 
your file and create the histogram updating the distributed unordered hash map 
with the file content (in parallel).

> 
> which parts of the hpx source tree (unit tests, examples) would you
> encourage me to review? i get the impression this should be a fairly
> straightforward bit of code.

The unit tests are always a good reference ... however not very condensed to 
get the message across:
https://github.com/STEllAR-GROUP/hpx/blob/master/tests/unit/component/
partitioned_vector_for_each.cpp
https://github.com/STEllAR-GROUP/hpx/blob/master/tests/unit/component/
unordered_map.cpp

There are also some examples featuring the distributed data structures:
https://github.com/STEllAR-GROUP/hpx/blob/master/examples/quickstart/
partitioned_vector_spmd_foreach.cpp

If you need to synchronize in between partitions, I suggest to use channel 
objects, featured here:
https://github.com/STEllAR-GROUP/hpx/blob/master/examples/quickstart/
local_channel.cpp

The same exists in a distributed manner, which is probably best explained 
here:
https://stellar-group.github.io/tutorials/hlrs2017/session5/#30

I hope that helps a bit... I know that our documentation needs major work... 
so best is to just ask here where to find the stuff you are looking for.

> 
> thanks in advance,
> 
> ct
> 
> On Mon, Apr 24, 2017 at 4:52 PM, Thomas Heller 
> 
> wrote:
> > Hi Chris,
> > 
> > Am 24.04.2017 7:30 nachm. schrieb "ct clmsn" :
> > 
> > two questions for the stellar community - if i'm writing a distributed
> > program that does not use the hpx spmd model, does hpx require the
> > partitioned_vector storing components to be registered into the agas? if
> > so, does hpx also require a call the connect function? several of the
> > non-spmd partitioned_vector unit tests do not require register/connect -
> > were those unit tests intended only to support single-node testing or is
> > distributed execution also supported?
> > 
> > 
> > I'm going to answer that later... Requires more writing...
> > 
> > 
> > on a separate issue, i'd like to access the contents of a distributed
> > vector that stores a component called 'dataset_t'  (the component inherits
> > from hpx::components::simple_component_base ; the client
> > interface for the component inherits from
> > hpx::components::client_base).
> > 
> > 
> > Just for future reference, this might not be what you want. For
> > hpx::partitioned_vector, T does not need to be a component. In fact,
> > the
> > vector stores any T and distributes it over the partitions.
> > 
> > 
> > currently, the following code compiles and produces a runtime exception.
> > 
> > std::vector pos = { static_cast(idx) };
> > std::vector svec = dataset_arr.get_values_sync(pos);
> > 
> > hpx::future fc = svec[0].create(args);
> > fc.wait();
> > hpx::future fv = dataset_arr.set_values(pos, svec);
> > fv.wait();
> > 
> > the program runs on 1 node/host without any runtime arguments applied. the
> > runtime exception reads:
> > 
> > "{what}: this client_base has no valid shared state: HPX(no_state)"
> > 
> > 
> > Makes sense, the client is default constructed, which doesn't create a
> > component. It might not need to after all (see comment above).
> > 
> > 
> > how should i comprehend this runtime exception?
> > 
> > 
> > The client did not allocate a component which it "points" to.
> > 
> > All in all it's difficult to say what the proper fix would be without
> > lookin

Re: [hpx-users] partitioned_vectors questions

[Thomas Heller]

Hi Chris,

Am 24.04.2017 7:30 nachm. schrieb "ct clmsn" :

two questions for the stellar community - if i'm writing a distributed
program that does not use the hpx spmd model, does hpx require the
partitioned_vector storing components to be registered into the agas? if
so, does hpx also require a call the connect function? several of the
non-spmd partitioned_vector unit tests do not require register/connect -
were those unit tests intended only to support single-node testing or is
distributed execution also supported?


I'm going to answer that later... Requires more writing...


on a separate issue, i'd like to access the contents of a distributed
vector that stores a component called 'dataset_t'  (the component inherits
from hpx::components::simple_component_base ; the client
interface for the component inherits from
hpx::components::client_base).


Just for future reference, this might not be what you want. For
hpx::partitioned_vector, T does not need to be a component. In fact, the
vector stores any T and distributes it over the partitions.


currently, the following code compiles and produces a runtime exception.

std::vector pos = { static_cast(idx) };
std::vector svec = dataset_arr.get_values_sync(pos);

hpx::future fc = svec[0].create(args);
fc.wait();
hpx::future fv = dataset_arr.set_values(pos, svec);
fv.wait();

the program runs on 1 node/host without any runtime arguments applied. the
runtime exception reads:

"{what}: this client_base has no valid shared state: HPX(no_state)"


Makes sense, the client is default constructed, which doesn't create a
component. It might not need to after all (see comment above).


how should i comprehend this runtime exception?


The client did not allocate a component which it "points" to.

All in all it's difficult to say what the proper fix would be without
looking at the code.


also, when the following, much simpler implementation, of sample code runs:

hpx::future fd = dataset_arr.get_value(static_
cast(idx));
fd.wait();

i had the following compile error:

"hpx/traits/get_remote_result.hpp:25:41: error: no matching function for
call to 'hpx::naming::id_type::id_type(std::remove_reference<
dataset_t&>::type"


any help, questions, or assistance would be appreciated!

chris

___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] [GSoC 2017] About progress of acceptance of proposal.

[Thomas Heller]

On Dienstag, 4. April 2017 02:01:16 CEST 권태국 wrote:
> In GSoC's official timeline, there is no another schedules until May 5.
> But, in github wiki of HPX, I find "Reviewing is basically done in two
> rounds". (
> https://github.com/STEllAR-GROUP/hpx/wiki/Hints-for-Successful-Proposals#rev
> iewing )
> Does it mean an additional progress for accepting proposal exist anymore?

That means, that if we have to decide between two proposals, because we can 
only take one, and might need to clarify one or two things with the student 
during reviewing and scoring our proposals, it might be good for you to be 
available to discuss things with us.
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] FW: build hpx as static lib?

[Thomas Heller]

Hi,

On 03/22/2017 07:40 AM, niXman wrote:
> Alexander писал 2017-03-22 00:03:
> 
>> can you create a minimal self-contained example (if possible without 
>> hpx)
>> which shows this problem, and post it here ?
> 
> Hi,
> 
> There is no need for any example, it's enought to build HPX with 'cmake 
> -DHPX_WITH_STATIC_LINKING=ON'

I just successfully completed a static build. What you might want to
consider is adding:
-DHPX_WITH_STATIC_EXE_LINKING=On

What I discovered during that build was that a cmake version 2.x was not
able to link correctly. cmake 3.3.2 did the job.

> 
> 


-- 
Thomas Heller
Friedrich-Alexander-Universität Erlangen-Nürnberg
Department Informatik - Lehrstuhl Rechnerarchitektur
Martensstr. 3
91058 Erlangen
Tel.: 09131/85-27018
Fax:  09131/85-27912
Email: thomas.hel...@cs.fau.de
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] [GSoC17] Am I write only backgrounds related in my proposal?

[Thomas Heller]

Am 24.03.2017 2:58 vorm. schrieb "권태국" :

Hi,
I have a question.
In educational and programming background, am I write only things related
in my proposal topic or not?


Whatever you think might be helpful for us to consider you a good
candidate...


Taeguk Kwon,
https://taeguk.github.io

___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] GSoC 2017 Proposal Work on Parallel Algorithms for HPX

[Thomas Heller]

Hi again

I've been through the full proposal now, and I think what I wrote below still 
holds.

On Dienstag, 21. März 2017 19:53:10 CET you wrote:
> On Dienstag, 21. März 2017 19:46:39 CET you wrote:
> > Hi Aja,
> > 
> > I think you should focus your proposal. As it stands right now, you will
> > not be able to complete everything. I strongly advice to pull together
> > some form of time plan on when you plan to have each part implemented,
> > given the vast number of algorithms you want to implement, it would be
> > great if you can in addition put in some references to already existing
> > solutions.
> > 
> > Please work on focusing your proposal.
> 
> Please ignore the previous email ... I only read the abstract on the mentors
> dashboard... I have to go through the full proposal again ;)
> 
> > On Samstag, 18. März 2017 15:20:28 CET Ajai George wrote:
> > > Hello,
> > > 
> > > I am Ajai V George, I had previously expressed my interest in doing a
> > > GSoC
> > > project with HPX. For the past week I was going through the hpx
> > > documentation and tutorial. I have been testing out examples and trying
> > > to
> > > write my own applications. I have also looked through the relevant
> > > codebase
> > > needed to resolve issues #1141 and #1338. I also read through the two
> > > papers on ParalleX for understanding the philosophy behind HPX. I
> > > believe
> > > that I can definitely complete this project and continue contributing
> > > further.
> > > 
> > > Please have a look at my GSoC application and help me make it better.
> > > Here
> > > is a link
> > >  > > 8Q
> > > KT BieY/edit?usp=sharing> to it.
> > > 
> > > Regards,
> > > 
> > > Ajai V George
> > > 
> > > On Mon, Mar 13, 2017 at 2:21 AM, Ajai George 
> > > 
> > > wrote:
> > > > Hello,
> > > > 
> > > > I am Ajai V George from BITS Pilani, Goa Campus, India. My major is
> > > > Electrical and Electronics Engineering. I currently work with
> > > > Professor
> > > > Santonu Sarkar from Centre for High Performance and Dependable Systems
> > > > (Department of Computer Science and Information Systems). My project
> > > > is
> > > > Building 2D Algorithms with shared memory in Thrust which is a CUDA
> > > > library. I am implementing Berkeley Structured Grid Dwarf by extending
> > > > Thrust.
> > > > 
> > > > Due to this project, I have significant experience with CUDA and with
> > > > implementing STL like data structures in CUDA. I have created a
> > > > block_2d
> > > > data
> > > > structure for Thrust for 2d data storage. I created a Thrust and thus
> > > > STL
> > > > compatible iterator for this. I also created an abstraction layer for
> > > > accessing windows (as described in structured grid dwarf) within this
> > > > data structure and an accompanying iterator which lazily generates
> > > > these
> > > > windows. I have created highly optimized for_each, transform, reduce,
> > > > and
> > > > transform_reduce functions for both the thrust 1D device vector and my
> > > > block_2d data structure. These algorithms use shared memory
> > > > efficiently
> > > > with proper memory access coalescence and no shared memory bank
> > > > conflicts. The reduction algorithm also uses a highly optimized tree
> > > > based approach. I have also created this framework such that it can be
> > > > extended to be used with cuFFT and cuBLAS libraries easily.
> > > > 
> > > > Due to the above background I believe, I can work on the Parallel
> > > > Algorithms for HPX project for GSoC 2017, specifically on extending
> > > > algorithms like scan, reduce, transform, for_each, fill, etc to work
> > > > with
> > > > hpx::vector. I have already cloned the repo and have built hpx and am
> > > > currently looking through the source code to see what would be
> > > > impacted
> > > > by
> > > > the project and what changes would be required.
> > > > 
> > > > I request help from the community in crafting my proposal, and in
> > > > understanding hpx codebase.
> > > > 
> > > > Regards,
> > > > 
> > > > Ajai V George


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] GSoC 2017 Proposal Work on Parallel Algorithms for HPX

[Thomas Heller]

On Dienstag, 21. März 2017 19:46:39 CET you wrote:
> Hi Aja,
> 
> I think you should focus your proposal. As it stands right now, you will not
> be able to complete everything. I strongly advice to pull together some
> form of time plan on when you plan to have each part implemented, given the
> vast number of algorithms you want to implement, it would be great if you
> can in addition put in some references to already existing solutions.
> 
> Please work on focusing your proposal.

Please ignore the previous email ... I only read the abstract on the mentors 
dashboard... I have to go through the full proposal again ;)

> 
> On Samstag, 18. März 2017 15:20:28 CET Ajai George wrote:
> > Hello,
> > 
> > I am Ajai V George, I had previously expressed my interest in doing a GSoC
> > project with HPX. For the past week I was going through the hpx
> > documentation and tutorial. I have been testing out examples and trying to
> > write my own applications. I have also looked through the relevant
> > codebase
> > needed to resolve issues #1141 and #1338. I also read through the two
> > papers on ParalleX for understanding the philosophy behind HPX. I believe
> > that I can definitely complete this project and continue contributing
> > further.
> > 
> > Please have a look at my GSoC application and help me make it better. Here
> > is a link
> >  > KT BieY/edit?usp=sharing> to it.
> > 
> > Regards,
> > 
> > Ajai V George
> > 
> > On Mon, Mar 13, 2017 at 2:21 AM, Ajai George 
> > 
> > wrote:
> > > Hello,
> > > 
> > > I am Ajai V George from BITS Pilani, Goa Campus, India. My major is
> > > Electrical and Electronics Engineering. I currently work with Professor
> > > Santonu Sarkar from Centre for High Performance and Dependable Systems
> > > (Department of Computer Science and Information Systems). My project is
> > > Building 2D Algorithms with shared memory in Thrust which is a CUDA
> > > library. I am implementing Berkeley Structured Grid Dwarf by extending
> > > Thrust.
> > > 
> > > Due to this project, I have significant experience with CUDA and with
> > > implementing STL like data structures in CUDA. I have created a block_2d
> > > data
> > > structure for Thrust for 2d data storage. I created a Thrust and thus
> > > STL
> > > compatible iterator for this. I also created an abstraction layer for
> > > accessing windows (as described in structured grid dwarf) within this
> > > data structure and an accompanying iterator which lazily generates these
> > > windows. I have created highly optimized for_each, transform, reduce,
> > > and
> > > transform_reduce functions for both the thrust 1D device vector and my
> > > block_2d data structure. These algorithms use shared memory efficiently
> > > with proper memory access coalescence and no shared memory bank
> > > conflicts. The reduction algorithm also uses a highly optimized tree
> > > based approach. I have also created this framework such that it can be
> > > extended to be used with cuFFT and cuBLAS libraries easily.
> > > 
> > > Due to the above background I believe, I can work on the Parallel
> > > Algorithms for HPX project for GSoC 2017, specifically on extending
> > > algorithms like scan, reduce, transform, for_each, fill, etc to work
> > > with
> > > hpx::vector. I have already cloned the repo and have built hpx and am
> > > currently looking through the source code to see what would be impacted
> > > by
> > > the project and what changes would be required.
> > > 
> > > I request help from the community in crafting my proposal, and in
> > > understanding hpx codebase.
> > > 
> > > Regards,
> > > 
> > > Ajai V George


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] GSoC 2017 Proposal Work on Parallel Algorithms for HPX

[Thomas Heller]

Hi Aja,

I think you should focus your proposal. As it stands right now, you will not 
be able to complete everything. I strongly advice to pull together some form 
of time plan on when you plan to have each part implemented, given the vast 
number of algorithms you want to implement, it would be great if you can in 
addition put in some references to already existing solutions.

Please work on focusing your proposal.

On Samstag, 18. März 2017 15:20:28 CET Ajai George wrote:
> Hello,
> 
> I am Ajai V George, I had previously expressed my interest in doing a GSoC
> project with HPX. For the past week I was going through the hpx
> documentation and tutorial. I have been testing out examples and trying to
> write my own applications. I have also looked through the relevant codebase
> needed to resolve issues #1141 and #1338. I also read through the two
> papers on ParalleX for understanding the philosophy behind HPX. I believe
> that I can definitely complete this project and continue contributing
> further.
> 
> Please have a look at my GSoC application and help me make it better. Here
> is a link
>  BieY/edit?usp=sharing> to it.
> 
> Regards,
> 
> Ajai V George
> 
> On Mon, Mar 13, 2017 at 2:21 AM, Ajai George 
> 
> wrote:
> > Hello,
> > 
> > I am Ajai V George from BITS Pilani, Goa Campus, India. My major is
> > Electrical and Electronics Engineering. I currently work with Professor
> > Santonu Sarkar from Centre for High Performance and Dependable Systems
> > (Department of Computer Science and Information Systems). My project is
> > Building 2D Algorithms with shared memory in Thrust which is a CUDA
> > library. I am implementing Berkeley Structured Grid Dwarf by extending
> > Thrust.
> > 
> > Due to this project, I have significant experience with CUDA and with
> > implementing STL like data structures in CUDA. I have created a block_2d
> > data
> > structure for Thrust for 2d data storage. I created a Thrust and thus STL
> > compatible iterator for this. I also created an abstraction layer for
> > accessing windows (as described in structured grid dwarf) within this
> > data structure and an accompanying iterator which lazily generates these
> > windows. I have created highly optimized for_each, transform, reduce, and
> > transform_reduce functions for both the thrust 1D device vector and my
> > block_2d data structure. These algorithms use shared memory efficiently
> > with proper memory access coalescence and no shared memory bank
> > conflicts. The reduction algorithm also uses a highly optimized tree
> > based approach. I have also created this framework such that it can be
> > extended to be used with cuFFT and cuBLAS libraries easily.
> > 
> > Due to the above background I believe, I can work on the Parallel
> > Algorithms for HPX project for GSoC 2017, specifically on extending
> > algorithms like scan, reduce, transform, for_each, fill, etc to work with
> > hpx::vector. I have already cloned the repo and have built hpx and am
> > currently looking through the source code to see what would be impacted by
> > the project and what changes would be required.
> > 
> > I request help from the community in crafting my proposal, and in
> > understanding hpx codebase.
> > 
> > Regards,
> > 
> > Ajai V George


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] linking/cmake problem

[Thomas Heller]

Hi Alex,

On Mittwoch, 15. März 2017 22:40:16 CET Alexander Neundorf wrote:
> Hi,
> 
> I'm building hpx without cuda, and in examples/qt/, tools/ and
> tools/inspect/ cmake errors out with the following error:
> 

This is embarrassing, please see inline for more discussion

> CMake Error at examples/qt/CMakeLists.txt:26 (target_link_libraries):
>   Policy CMP0023 is not set: Plain and keyword target_link_libraries
>   signatures cannot be mixed.  Run "cmake --help-policy CMP0023" for policy
>   details.  Use the cmake_policy command to set the policy and suppress this
> warning.
> 
>   The keyword signature for target_link_libraries has already been used with
> the target "qt_exe".  All uses of target_link_libraries with a target must
> be either all-keyword or all-plain.
> 
>   The uses of the keyword signature are here:
> 
>* cmake/HPX_SetupTarget.cmake:202 (target_link_libraries)
> 
> 
> This happens AFAICT because in HPX_SetupTarget.cmake there is the following
> code:
> if(NOT HPX_WITH_CUDA)  # Cuda needs plain target_link_libraries() signature
>   target_link_libraries(${target} PUBLIC ${hpx_libs} ${target_DEPENDENCIES})
> else()
>   target_link_libraries(${target} ${hpx_libs} ${target_DEPENDENCIES})
> endif()
> 
> i.e. without CUDA the "PUBLIC" signature of target_link_libraries() is used.
> Now in the mentioned directories target_link_libraries() is used without
> PUBLIC/PRIVATE/INTERFACE keywords.
> This is (by default) not allowed (see here
> https://cmake.org/cmake/help/v3.8/ policy/CMP0023.html ).
> 
> I could make it work for me by adding "PRIVATE" (or "PUBLIC") to the
> respective target_link_libraries() calls, e.g. in examples/qt/.
> But I guess this will break then in the other case, when building with CUDA.
> 
> The "PUBLIC" was added last November without much explanation:
> https://github.com/STEllAR-GROUP/hpx/commit/
> fb1fc68ea82a4623b5644f15f1d508fa9733f442

The commit introducing it was part of this PR:
https://github.com/STEllAR-GROUP/hpx/pull/2392

> 
> In src/CMakeLists.txt this is handled by duplicating the whole
> target_link_libraries()-calls in an if(WITH_CUDA) branch.
> 
> I see the following options to make it always work:
> 
> 1. add something like hpx_target_link_libraries(), which wraps
> target_link_libraries() and contains this if(WITH_CUDA) - maybe a bit
> overkill ?

Yes, I don't like it ... in the end, I would our cmake build system to work 
without too much hpx_XXX calls. hpx_setup_target is currently the only 
required call. hpx_add_executable and friends is essentially a convenience 
wrapper for add_executable (and friends) and hpx_setup_target.

> 
> 2. set a HPX_TLL_KEYWORD variable at the top level and use that then
> everywhere in the target_link_libraries() calls:
> set( HPX_TLL_KEYWORD)
> if (NOT HPX_WITH_CUDA)
>   set(HPX_TLL_KEYWORD PUBLIC)
> endif()

Sounds sensible to me...

> 
> 3. add the if(WITH_CUDA) in the three CMakeLists.txt which have a problem
> right now.

This is something we could do as well, as soon as third party applications run 
into that problem, we are back to square one.

> 
> 4. remove the "PUBLIC" from hpx_setup_target().
> But I guess there was a reason why it was added ?

Yes, see the PR I linked above

> 
> 5. add PUBLIC also with CUDA, but I guess there is a reason it is not there
> ?

Yes, the CUDA cmake wrappers are a PITA and use the plain signature.

> 
> I think my favourite is option 2, add a keyword-variable.

Yes, this could also be documented nicely.
What about explicitly setting CMP0023?

> 
> Alex
> 
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] First Time Installing, HWLOC Root?

[Thomas Heller]

Am 12.03.2017 12:40 schrieb "Hartmut Kaiser" :


> I'm very much into HPC and found out about this framework from cppcon
> videos on youtube. I want to take this for a spin on OpenSUSE, but the
> directions surrounding hwloc inclusion aren't very specific or seem to be
> distro-specific.

Welcome!

> In my /usr/bin folder are the hwloc-bind and other utilities, but the HPX
> installation instructions make it sound like a I need a library of some
> sort just like with Boost. Could I get some clarification on this? And
> then after that, if someone could clarify the installation instructions on
> Github, that would be very much appreciated.

You need a library, libhwloc.so (or somesuch). If your system has HWLOC
installed you should be able to find it in /usr/lib. Also, in this case the
HPX cmake build system should pick it up automatically.



And the headers, that means you need to install the development packages.


Regards Hartmut
---
http://boost-spirit.com
http://stellar.cct.lsu.edu



___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] SLURM: requesting a different number of localities than have been assigned

[Thomas Heller]

On Freitag, 24. Februar 2017 01:32:24 CET Tim Biedert wrote:
> Below you find the gdb thread infos for the single idling process (recall:
> all processes have 100% but one, which idles).  As you can see, there a
> quite a few threads stuck in some kind of TCMalloc spin lock.
> 
> Most backtraces in those threads contain a free(), but there are also
> allocs() (see thread 68 and 79 backtraces at end for examples).
> 
> In fact, in the phase of my program where the deadlock happens, all threads
> do perform many dynamic allocations and freeings (let’s say thousands).  I
> guess I could implement some manual pooling, but I thought TCMalloc would
> manage everything fast enough and transparently in the background.
> 
> Have you ever encountered something like this?

I have not encountered this error so far and this looks indeed like a deadlock 
inside of tcmalloc. I myself use jemalloc most of the time and didn't 
encounter this situation. Does changing the malloc implementation to system or 
jemalloc help here?

> 
> I am using gperftools-2.5 btw.
> 
> Thanks!
> Tim
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] SLURM: requesting a different number of localities than have been assigned

[Thomas Heller]

On 02/23/2017 02:49 PM, Tim Biedert wrote:
> Thanks for the hint.
> We're already getting deadlocks at 4 localities and we're not explicitly
> using any barriers.  Are there any internal barriers in HPX which might
> be affected by this just due to a high task count?

No. However, while attempting to fix #2516, I discovered something bad that
happens during parcel decoding.
The fix I came up with is in the following PR:
https://github.com/STEllAR-GROUP/hpx/pull/2518

This might also be the reason for the deadlock you are seeing. Could you
please try this patch
and see if that fixes your deadlocks?

> 
> Best,
> 
> Tim
> 
> 
> 
> On 02/22/2017 10:30 PM, Thomas Heller wrote:
>> If you are running with at least 256 localities (or are using
>> hpx::lcos::barrier with more than 256 participating threads), please
>> be aware
>> of:
>> https://github.com/STEllAR-GROUP/hpx/issues/2516
> 
> 
> 
> 
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> 


-- 
Thomas Heller
Friedrich-Alexander-Universität Erlangen-Nürnberg
Department Informatik - Lehrstuhl Rechnerarchitektur
Martensstr. 3
91058 Erlangen
Tel.: 09131/85-27018
Fax:  09131/85-27912
Email: thomas.hel...@cs.fau.de
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] SLURM: requesting a different number of localities than have been assigned

[Thomas Heller]

On Mittwoch, 22. Februar 2017 22:02:57 CET Tim Biedert wrote:
> > We were having troubles when running with multiple localities up until
> > recently. If you update to today's top of master, at least the problems
> > coming from HPX directly should go away.
> 
> Hi, thanks for the feedback!   Unfortunately, the deadlock remains.
> Any tips how to debug that?   (Admittedly, I haven't figured out yet how
> to interactively attach gdb to a running Slurm multi-node batch job.)

Please also make sure you are not affected by this:
https://github.com/STEllAR-GROUP/hpx/issues/2517
In order to check, run your code with -Ihpx.parcel.message_handlers=0
I got bit by this only at a scale of 256 recently.
If you are running with at least 256 localities (or are using 
hpx::lcos::barrier with more than 256 participating threads), please be aware 
of:
https://github.com/STEllAR-GROUP/hpx/issues/2516

> 
> Interestingly, the deadlock has never occurred when simulating multiple
> localities on a single machine by starting multiple processes using
> mpirun -np.  So it's probably a race condition influenced by additional
> network latency on the cluster, I guess.
> 
> However, I was wondering:  Are there any known issues which might cause
> a (remote) action invocation to stall/deadlock?I don't know if
> that's any special, but let's say we have a few hundred (or thousand)
> components per locality, which can all communicate
> wildly/asynchronously.  Are there any HPX implementation/concurrency
> limits we might reach?
> 
> 
> 
> On a side note:  When running on a single node, sometimes I get the
> following error for specific extreme cases in my benchmarks:
> 
> {what}: mmap() failed to allocate thread stack due to insufficient
> resources, increase /proc/sys/vm/max_map_count or add
> -Ihpx.stacks.use_guard_pages=0 to the command line: HPX(unhandled_exception)
> 
> I assume it means out of memory. I'm just wondering, because usually
> Slurm kills my job if I exceed the reserved memory amount.
> 
> 
> Best,
> Tim


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] SLURM: requesting a different number of localities than have been assigned

[Thomas Heller]

On Mittwoch, 22. Februar 2017 22:02:57 CET Tim Biedert wrote:
> > We were having troubles when running with multiple localities up until
> > recently. If you update to today's top of master, at least the problems
> > coming from HPX directly should go away.
> 
> Hi, thanks for the feedback!   Unfortunately, the deadlock remains.
> Any tips how to debug that?   (Admittedly, I haven't figured out yet how
> to interactively attach gdb to a running Slurm multi-node batch job.)

If you are able to log on to a node via ssh, then this should be trivial when 
using --hpx:attach-debugger=exception. Other options are gdbserver, or proper 
parallel debuggers like allinea ddt. I am nowadays using gdbserver + qtcreator 
on my small scale development system and mostly ddt for larger scale machines.
When your program hangs, you can look into the threadmanagers scheduler 
(accessible over the runtime ptr) and in the different pools there, where the 
thread_map_ will hold the different HPX threads that are alive. This probably 
sounds very confusing to you right now ... I really need to properly write 
that up once ...

> 
> Interestingly, the deadlock has never occurred when simulating multiple
> localities on a single machine by starting multiple processes using
> mpirun -np.  So it's probably a race condition influenced by additional
> network latency on the cluster, I guess.

Could be. Distributed, asynchronous communication is hard and very tricky to 
debug. First of all, you should try to figure out which part of your code 
blocks (cout debugging, outputting the necessary information like where am I, 
where did I come from etc.). 
Timing is usually very crucial for those deadlocks to appear ...

Sometimes, running with --hpx:debug-hpx-log helps as well.

> 
> However, I was wondering:  Are there any known issues which might cause
> a (remote) action invocation to stall/deadlock?I don't know if
> that's any special, but let's say we have a few hundred (or thousand)
> components per locality, which can all communicate
> wildly/asynchronously.  Are there any HPX implementation/concurrency
> limits we might reach?

Unlikely. It might mean that your code is very slow, that is eventually 
finishes (maybe let it run over night?).

> 
> 
> 
> On a side note:  When running on a single node, sometimes I get the
> following error for specific extreme cases in my benchmarks:
> 
> {what}: mmap() failed to allocate thread stack due to insufficient
> resources, increase /proc/sys/vm/max_map_count or add
> -Ihpx.stacks.use_guard_pages=0 to the command line: HPX(unhandled_exception)
> 
> I assume it means out of memory. I'm just wondering, because usually
> Slurm kills my job if I exceed the reserved memory amount.

It's not exactly out of memory. If you pass the suggested command line 
parameter you should be fine (note to self: add documentation about this).
It's mostly a limitation of the linux kernel not being able to have a rather 
small limit on available pages per process (or more precisely, page 
descriptors).

> 
> 
> Best,
> Tim


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] SLURM: requesting a different number of localities than have been assigned

[Thomas Heller]

Hi Tim,


On Mittwoch, 22. Februar 2017 17:03:45 CET Tim Biedert wrote:
> Hi,
> 
> when running my application on our (new) SLURM cluster, I receive the
> following warning (if using more than one node):
> 
> hpx::init: command line warning: --hpx:localities used when running with
> SLURM, requesting a different number of localities (2) than have been
> assigned by SLURM (1), the application might not run properly.

I guess you are using OpenMPI? If yes, than you can safely ignore this 
warning. The OpenMPI launcher modifies the SLURM environment in unexpected ways 
which leads to that warning.

> 
> In the program however HPX correctly reports two localities.
> 
> The warning is similar for other node counts (e.g. 4/3 or 16/15).
> 
> 
> My submit file basically looks like this:
> 
> #!/bin/bash
> 
> #SBATCH -t 20
> #SBATCH -N 2
> #SBATCH --ntasks-per-node=1
> #SBATCH --cpus-per-task=16
> #SBATCH --mem=62G
> 
> mpirun ./myapp --hpx:threads 16
> 
> 
> Is this a problem?The program seems to run ok  (I'm currently
> debugging a different deadlock issue, which is not related I guess).

We were having troubles when running with multiple localities up until 
recently. If you update to today's top of master, at least the problems coming 
from HPX directly should go away.

> 
> 
> Thanks!
> 
> Tim


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] HPX build fail

[Thomas Heller]

Hi Justs,

I am not exactly sure what's causing your issues. When looking at your script, 
I noticed that you don't use the CMake Toolchain file I strongly recommend to 
use when working on a cray (See here for more info: 
http://stellar-group.github.io/hpx/docs/html/hpx/manual/build_system/building_hpx/
cmake_toolchains.html).
The current name fo the file, Cray-Intel.cmake, might suggest that it is only 
really usable with the Intel compiler. However, it should really work with gcc 
just as fine. It sets all the necessary compiler options, like -dynamic etc.. 
So that cmake sets up the correct compiler flags. The PR #2440 (https://
github.com/STEllAR-GROUP/hpx/pull/2440) is going to rename that file to remedy 
that situation.

Your cmake invocation should then look like that:
cmake \
  -DBOOST_ROOT=$BOOSTDIR \
  -DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DHWLOC_ROOT=$HWLOCDIR \
  -DTCMALLOC_ROOT=$TCMALLOCDIR \
  -DHPX_WITH_MALLOC=tcmalloc \
  -DHPX_WITH_TESTS=OFF \
  -DHPX_WITH_EXAMPLES=OFF \
  -DCMAKE_INSTALL_PREFIX=$HPXDIR
  -DCMAKE_TOOLCHAIN_FILE=$WORKDIR/hpx-0.9.99/cmake/toolchains/Cray.cmake
  $WORKDIR/hpx-0.9.99/

Using that toolchain should fix your problem. John's instruction should work 
just as fine, he sets all the stuff manually.

Hope that helps,

Thomas

On Donnerstag, 29. Dezember 2016 15:40:45 CET Justs Zarins wrote:
> Hi Hartmut,
> 
> I’m attaching my build script, that has most of the relevant information.
> I’m using gcc 6.2.0
> 
> Regards,
> Justs
> 
> From: Hartmut Kaiser 
> Reply-To: "hartmut.kai...@gmail.com" 
> Date: Thursday, December 29, 2016 at 3:30 PM
> To: "hpx-users@stellar.cct.lsu.edu" 
> Cc: Justs Zarins 
> Subject: RE: [hpx-users] HPX build fail
> 
> Hey Justs,
> 
> Could you please give us a bit more information about how you built things?
> What compiler, what Boost version, what command lines, etc.?
 
> Thanks!
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> From: hpx-users-boun...@stellar.cct.lsu.edu
> [mailto:hpx-users-boun...@stellar.cct.lsu.edu] On Behalf Of Justs Zarins
> Sent: Thursday, December 29, 2016 9:10 AM
> To: hpx-users@stellar.cct.lsu.edu
> Subject: [hpx-users] HPX build fail
> 
> Hello,
> 
> I’m trying to build HPX on a Cray XC40 machine. The build is failing when
> linking:
 
> [100%] Built target iostreams_component
> Linking CXX executable ../bin/hpx_runtime
> /usr/bin/ld: attempted static link of dynamic object
> `../lib/libhpx.so.0.9.99'
 collect2: error: ld returned 1 exit status
> make[2]: *** [bin/hpx_runtime] Error 1
> make[1]: *** [runtime/CMakeFiles/hpx_runtime_exe.dir/all] Error 2
> 
> 
> Has cmake generated incorrect Makefiles?
> 
> I’ve tried to set –DHPX_WITH_STATIC_LINKING=ON but this results in a
> different linking error:
 
> [100%] Building CXX object
> runtime/CMakeFiles/hpx_runtime_exe.dir/hpx_runtime.cpp.o
 Linking CXX
> executable ../bin/hpx_runtime
> ../lib/libhpx.a(runtime_support_server.cpp.o): In function
> `hpx::util::plugin::dll::LoadLibrary(hpx::error_code&, bool) [clone
> .constprop.2162]':
 runtime_support_server.cpp:(.text+0x147a): warning:
> Using 'dlopen' in statically linked applications requires at runtime the
> shared libraries from the glibc version used for linking /usr/bin/ld:
> attempted static link of dynamic object
> `/lus/scratch/jzarins/lib/tcmalloc/lib/libtcmalloc_minimal.so' collect2:
> error: ld returned 1 exit status
> make[2]: *** [bin/hpx_runtime] Error 1
> make[1]: *** [runtime/CMakeFiles/hpx_runtime_exe.dir/all] Error 2
> make: *** [all] Error 2
> 
> 
> Any pointers?
> 
> Regards,
> Justs
> 
> 
> 


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] archive data bstream data chunk size mismatch: HPX(serialization_error)

[Thomas Heller]

On Montag, 12. Dezember 2016 10:12:11 CET Tim Biedert wrote:
> Thank you for the feedback!   Unfortunately, this hasn't solved the
> deserialization error.  However, I'm sure this has made the code more
> robust! ;-)
> 
> What do you suggest to localize the deserialization error?  Is it
> possible to determine which action would have been called with the
> deserialized data?

Yes, it is. start your application with --hpx:attach-debugger=exception.

Eventually you'll get a message that an exception has occured and the PID as 
well as the host where the exception occurred. Once you attached your 
debugger, for example gdb, you have to figure out which thread threw the 
exception (info threads). The thread that sits in the sleep function is the 
one you are looking for. Switch to it, and inspect the backtrace.

Does this help?

> 
> Best,
> 
> Tim
> 
> On 12/09/2016 04:20 PM, Hartmut Kaiser wrote:
> > Tim,
> > 
> > Sorry, this should have been:
> >  hpx::apply_cb(
> >  
> >  recipient,
> >  [this](boost::system::error_code const&, hpx::parcelset::parcel
> > 
> > const&) mutable
> > 
> >  { delete this; },
> >  
> >  this->image);
> > 
> > I.e. the callback needs to conform to this prototype:
> >  void callback(
> >  
> >  boost::system::error_code const&,
> >  hpx::parcelset::parcel const&);
> > 
> > HTH
> > Regards Hartmut
> > ---
> > http://boost-spirit.com
> > http://stellar.cct.lsu.edu
> > 
> >> -Original Message-
> >> From: Hartmut Kaiser [mailto:hartmut.kai...@gmail.com]
> >> Sent: Friday, December 9, 2016 9:09 AM
> >> To: 'hpx-users@stellar.cct.lsu.edu' 
> >> Subject: RE: [hpx-users] archive data bstream data chunk size mismatch:
> >> HPX(serialization_error)
> >> 
> >> Tim,
> >> 
> >>> could the following two lines cause the issue?
> >>> 
> >>> hpx::apply(recipient, this->image);
> >>> 
> >>>   delete this;
> >>> 
> >>> Basically, we're invoking a fire and forget action with a member
> >>> variable (which will be serialized) as parameter. Afterwards, the
> >>> instance is directly deleted.   I guess the serialization/parameter
> >>> transmission of the action does not happen right away and we're deleting
> >>> the send buffer too early.
> >>> 
> >>> How can we know - without using async() and waiting for the future -
> >>> that the "fire part" of fire and forget has been completed and we can
> >>> delete the send buffer?
> >> 
> >> You might want to do this instead:
> >>  hpx::apply_cb(
> >>  
> >>  recipient,
> >>  [this]() mutable { delete this; }
> >>  this->image);
> >> 
> >> instead.
> >> 
> >> hpx::apply_cb calls the supplied function whenever it's safe to release
> >> the data.
> >> 
> >> Regards Hartmut
> >> ---
> >> http://boost-spirit.com
> >> http://stellar.cct.lsu.edu
> > 
> > ___
> > hpx-users mailing list
> > hpx-users@stellar.cct.lsu.edu
> > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] archive data bstream data chunk size mismatch: HPX(serialization_error)

[Thomas Heller]

Am 09.12.2016 2:36 vorm. schrieb "Hartmut Kaiser" :

Tim,

> when running my HPX application on our cluster with multiple localities
> I SOMETIMES get a segmentation fault with error message: "archive data
> bstream data chunk size mismatch: HPX(serialization_error)".
>
> And when I rerun the same configuration, it either works or sometimes
> segfaults again.
>
> Any idea what could cause this or how to debug it?

I have not seen this problem before. Could you provide us with the code for
your application?

Thomas, is that a known issue with the MPI parcelport?



No it's not. I haven't seen this problem in a while. It's triggered in the
deserialization of the parcel. So it could be a corrupted parcel. Could you
inspect your serialization code for any lifetime issues? Do you maybe
serialize a temporary buffer with make_array?


Regards Hartmut
---
http://boost-spirit.com
http://stellar.cct.lsu.edu


>
> Thanks!
>
> Tim
>
> The full error output follows:
>
>
>
> {stack-trace}: 4 frames:
> 0x2b40ce84564c  : hpx::detail::backtrace[abi:cxx11](unsigned long) +
> 0x9c in /home/tbiedert/local/lib/libhpx.so.1
> 0x2b40ce8918fa  : boost::exception_ptr
> hpx::detail::get_exception(hpx::exception const&,
> std::__cxx11::basic_string,
> std::allocator > const&, std::__cxx11::basic_string std::char_traits, std::allocator > const&, long,
> std::__cxx11::basic_string,
> std::allocator > const&) + 0xaa in
> /home/tbiedert/local/lib/libhpx.so.1
> 0x2b40ce891e5e  : void
> hpx::detail::throw_exception(hpx::exception const&,
> std::__cxx11::basic_string,
> std::allocator > const&, std::__cxx11::basic_string std::char_traits, std::allocator > const&, long) + 0x4e in
> /home/tbiedert/local/lib/libhpx.so.1
> 0x2b40ce92049e  : hpx::detail::throw_exception(hpx::error,
> std::__cxx11::basic_string,
> std::allocator > const&, std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> std::__cxx11::basic_string,
> std::allocator > const&, long) + 0x4e in
> /home/tbiedert/local/lib/libhpx.so.1
> {env}: 177 entries:
>BASH_FUNC_module()=() {  eval `/usr/bin/modulecmd bash $*`
> }
>BINARY_TYPE_HPC=
>BSUB_BLOCK_EXEC_HOST=
>CFLAGS=-I/software/binutils/2.27/include -I/software/gcc/6.2.0/include
>CMAKE_PREFIX_PATH=/home/tbiedert/local
>CPATH=/home/tbiedert/local/opt/tbb2017-update3/include
> CPLUS_INCLUDE_PATH=/software/binutils/2.27/include:/software/gcc/6.2.0/inc
> lude:/home/tbiedert/local/include:
>CPPFLAGS=-I/software/binutils/2.27/include -
> I/software/gcc/6.2.0/include
>CPP_INCLUDE_PATH=/home/tbiedert/local/include:
>CVS_RSH=ssh
> C_INCLUDE_PATH=/software/binutils/2.27/include:/software/gcc/6.2.0/include
> :/home/tbiedert/local/include:
>G_BROKEN_FILENAMES=1
>HISTCONTROL=ignoreboth
>HISTSIZE=500
>HOME=/home/tbiedert
>HOSTNAME=node774
>HOSTTYPE=X86_64
>ITERM_ORIG_PS1=\[\033[7m\]\u@\h\[\033[m\] [\W]
>ITERM_PREV_PS1=\[\]\[\033[7m\]\u@\h\[\033[m\] [\W] \[\]
>JOB_TERMINATE_INTERVAL=300
>KDEDIRS=/usr
>KDE_IS_PRELINKED=1
>LANG=en_US.UTF-8
>LDFLAGS=-L/software/binutils/2.27/lib -L/software/gcc/6.2.0/lib64
> -L/software/gcc/6.2.0/lib
> LD_LIBRARY_PATH=/lsf/9.1/linux2.6-glibc2.3-
> x86_64/lib:/home/tbiedert/local/opt/tbb2017-
> update3/build/linux_intel64_gcc_cc6.2.0_libc2.12_kernel2.6.32_release:/sof
> tware/binutils/2.27/lib:/software/gcc/6.2.0/lib64:/software/gcc/6.2.0/lib:
> /home/tbiedert/local/lib:/home/tbiedert/local/usr/lib64:/home/tbiedert/loc
> al/lib64
>LESSOPEN=||/usr/bin/lesspipe.sh %s
> LIBRARY_PATH=/home/tbiedert/local/opt/tbb2017-
> update3/build/linux_intel64_gcc_cc6.2.0_libc2.12_kernel2.6.32_release
>LOADEDMODULES=gcc/6.2.0:binutils/latest
>LOGNAME=tbiedert
>LSB_ACCT_FILE=/tmp/5324709.tmpdir/.1481211361.5324709.acct
> LSB_AFFINITY_HOSTFILE=/home/tbiedert/.lsbatch/1481211361.5324709.hostAffin
> ityFile
>LSB_APPLICATION_NAME=hybrid_mpi_openmp
>LSB_BATCH_JID=5324709
>LSB_BIND_CPU_LIST=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
>LSB_CHKFILENAME=/home/tbiedert/.lsbatch/1481211361.5324709
> LSB_DJOB_HOSTFILE=/home/tbiedert/.lsbatch/1481211361.5324709.hostfile
>LSB_DJOB_NUMPROC=128
> LSB_DJOB_RANKFILE=/home/tbiedert/.lsbatch/1481211361.5324709.hostfile
>LSB_ECHKPNT_RSH_CMD=ssh
>LSB_EEXEC_REAL_GID=
>LSB_EEXEC_REAL_UID=
>LSB_EFFECTIVE_RSRCREQ=select[ ((( (model == XEON_E5_2640v3)) && type
> == any))] order[-slots:-maxslots] rusage[mem=6.00] span[ptile=16]
> same[model] cu[type=switch:maxcus=1:pref=config]
> affinity[core(1)*1:distribute=pack]
>LSB_ERRORFILE=5324709.err
>LSB_EXEC_CLUSTER=Elwetritsch
>LSB_EXEC_HOSTTYPE=X86_64
>LSB_EXIT_PRE_ABORT=99
>LSB_HOSTS=node790 node790 node790 node790 node790 node790 node790
> node790 node790 node790 node790 node790 node790 node790 node790 node790
> node792 node792 node792 node792 node792 node792 node792 node792 node792
> node792 node792 node792 node792 node792 node792 node792 node793 node793
> node793 node793 node793

Re: [hpx-users] Attempting to do sparse triangular solve

[Thomas Heller]

Hi Riccardo,

The problem seems to be that you capture everything by reference. You might
want to consider to capture some variables by value.

HTH,

Thomas

Am 08.12.2016 4:57 nachm. schrieb "Riccardo Rossi" :

> Dear List,
>
> this is a continuation of previous messages.
>
> I am trying to do a sparse triangular solve using a CSR matrix.
> the point is that some rows can be computed directly, while some others
> need to wait
>
> for the specific example i post
>
> lines 0 4 5 can be computed independelty
> while 1 must wait for 2
> 2 must wait for 1
> 3 must wait for 2
>
> in a more general case a line may have to wait for multiple other lines to
> be executed.
>
> essentially what i am trying to do is to say that a given line must wait
> for its dependencies before being processed.
> I have been trying to achieve this all day without success.
>
> My latest attempt is with a lambda, but the captured values at the moment
> of running (in particular i) are not the ones when i launch it, which
> essentially means that my usage must be wrong.
> (and it definitely is, as in the version i post the dependencies on the
> shared futures is not there)
>
> essentially the function to futurize is the one on line 65 of
>
> https://gist.github.com/RiccardoRossi/4adbdb29e1c94da8fefc4afdcf6b1e37
>
> my guess is that knowning how to actually do it, the change to my code for
> having it to run should be minimal ... but i am simply not able to do it
> succesfully
>
> any help would be great
> cheers
> Riccardo
>
>
>
>
> --
>
>
> *Riccardo Rossi*
>
> PhD, Civil Engineer
>
>
> member of the Kratos Team: www.cimne.com/kratos
>
> Tenure Track Lecturer at Universitat Politècnica de Catalunya,
> BarcelonaTech (UPC)
>
> Full Research Professor at International Center for Numerical Methods in
> Engineering (CIMNE)
>
>
> C/ Gran Capità, s/n, Campus Nord UPC, Ed. B0, Despatx 102
>
> (please deliver post to the porters of building C1)
>
> 08034 – Barcelona – Spain – www.cimne.com  -
>
> T.(+34) 93 401 56 96 skype: *rougered4*
>
>
>
> 
>
>  
>  
>  
>
> Les dades personals contingudes en aquest missatge són tractades amb la
> finalitat de mantenir el contacte professional entre CIMNE i voste. Podra
> exercir els drets d'accés, rectificació, cancel·lació i oposició,
> dirigint-se a ci...@cimne.upc.edu. La utilització de la seva adreça de
> correu electronic per part de CIMNE queda subjecte a les disposicions de la
> Llei 34/2002, de Serveis de la Societat de la Informació i el Comerç
> Electronic.
>
>  Imprimiu aquest missatge, només si és estrictament necessari.
> 
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] the simple code of previous message...

[Thomas Heller]

Hi Riccardo,

>From a first glance, the second parameter of do_work is a non-const
reference. We don't support non-const references here.

>From a first glance

Am 06.12.2016 5:51 nachm. schrieb "Riccardo Rossi" :

any help in understanding why this does not compile would be very welcome

regards
Riccardo

//[hello_world_client_getting_started
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

//compile with
//g++ -std=c++14 -fPIC coloring.cpp -o coloring.exe
-I/home/rrossi/scratch/hpx/build -I/home/rrossi/scratch/hpx/hpx
-I/home/rrossi/compiled_libraries/boost/include/
-L/home/rrossi/scratch/hpx/build/lib
-lhpx -L/home/rrossi/compiled_libraries/boost/lib/ -lboost_program_options
-lboost_system -lboost_thread


//this one would be the function to process a color, that is, a collection
of columns
hpx::lcos::shared_future do_work(unsigned int color,
std::vector >& dependencies)
{
std::cout << "i am " << color << std::endl;
return my_dependencies = hpx::lcos::shared_future(
hpx::when_all(dependencies.begin(), dependencies.end()) );
}




int hpx_main(boost::program_options::variables_map&)
{
int ncolors = 6;
std::vector< std::unordered_set > dependencies(ncolors);
dependencies[0]; //first has no dependencies
dependencies[1].insert({0}); //1 can be launched when 0 is completed
dependencies[2].insert({0,1}); //2 can be launched when 0 and 1 are
both completed
dependencies[3].insert({0,2});
dependencies[4].insert({1});
dependencies[5].insert({0});


//this is a set with all of the tasks i am spawning
std::unordered_map< unsigned int, hpx::lcos::shared_future >
work_items;

//here i actually spawn the threads
for(unsigned int i=0; i > item_dependencies;
auto& my_dependencies = dependencies[i];
for(unsigned int k=0; k > dependencies(ncolors);
// for(auto row = rows[0]; row < nrows; row++)
// {
// const auto row_color = colors[row];
//
// for(auto col = cols[row]; colhttp://www.cimne.com/>

 
 
 

Les dades personals contingudes en aquest missatge són tractades amb la
finalitat de mantenir el contacte professional entre CIMNE i voste. Podra
exercir els drets d'accés, rectificació, cancel·lació i oposició,
dirigint-se a ci...@cimne.upc.edu. La utilització de la seva adreça de
correu electronic per part de CIMNE queda subjecte a les disposicions de la
Llei 34/2002, de Serveis de la Societat de la Informació i el Comerç
Electronic.

 Imprimiu aquest missatge, només si és estrictament necessari.


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] On-the-fly (de)compression in serialization

[Thomas Heller]

Hi Tim,

Just a quick answer upfront, we support compression of action arguments
using snappy or bzip2 already. There is no need for you to do it yourself.
See here for an example on how to enable it for given actions (you can use
async/apply as usual, the parcel stuff is merely to unit test) :
https://github.com/STEllAR-GROUP/hpx/blob/master/tests/unit/parcelset/put_parcels_with_compression.cpp

You have to enable the respective options during cmake.

I will look at your specific problem later!

Am 17.11.2016 6:37 nachm. schrieb "Tim Biedert" :

> Hello,
>
> I’m trying to perform on-the-fly compression during serialization of my
> custom Image class using the Blosc library.
>
> While compression during save() seems to work fine, the decompression at
> load() randomly crashes or throws an exception due to corrupted source data.
> For verification I also included the same decompression routine directly
> after the compression step in save(), where it always produces correct
> results, as expected.
>
> See my code below.   Note, that serialization without compression works
> fine.   I’m using the MPI parcel port.
>
>
> --
>
> private:
>
> friend class hpx::serialization::access;
>
>
> /**
>
>  * Serialization.
>
>  */
>
> template 
>
> void save(Archive& ar, const unsigned int) const
>
> {
>
> ar << this->offset << this->size << this->scanlineBytes;
>
>
> int numBytes = this->size.y * this->scanlineBytes;
>
>
> if (compression)
>
> {
>
> byte* buffer = new byte[numBytes + BLOSC_MAX_OVERHEAD];
>
>
> // lz4 (level 4) - 4 threads
>
> int numBytesCompressed = blosc_compress_ctx(4, BLOSC_NOSHUFFLE, 
> sizeof(byte), numBytes, this->pixels, buffer, numBytes + BLOSC_MAX_OVERHEAD, 
> "lz4", 0, 4);
>
>
> if (numBytesCompressed <= 0)
>
> LogError() << "(save) Compressed size: " << 
> numBytesCompressed;
>
>
> ar << numBytesCompressed;
>
> ar << hpx::serialization::make_array(buffer, 
> numBytesCompressed);
>
>
>
> // For debugging only:  Verify that decompression works on 
> previously compressed data
>
> {
>
> byte* tmp = new byte[numBytes];
>
>
> int numBytesDecompressed = blosc_decompress_ctx(buffer, tmp, 
> numBytes, 4);
>
>
> // Check if decompression succeeded
>
> if (numBytesDecompressed <= 0)
>
> LogError() << "(save verification) Decompressed bytes: " 
> << numBytesDecompressed;
>
> else if (numBytesDecompressed != numBytes)
>
> LogWarning() << "(save verification) Decompress mismatch! 
> Pixel bytes: " << numBytes << ", Decompressed bytes: " << 
> numBytesDecompressed;
>
>
> delete[] tmp;
>
> }
>
>
> delete[] buffer;
>
> }
>
> else
>
> {
>
> ar << hpx::serialization::make_array(this->pixels, 
> numBytes);
>
> }
>
> }
>
>
> /**
>
>  * Deserialization.
>
>  */
>
> template 
>
> void load(Archive& ar, const unsigned int)
>
> {
>
> ar >> this->offset >> this->size >> this->scanlineBytes;
>
>
> int numBytes = this->size.y * this->scanlineBytes;
>
> this->pixels = (byte*) boost::alignment::aligned_alloc(32, numBytes);
>
>
> if (compression)
>
> {
>
> int numBytesCompressed;
>
> ar >> numBytesCompressed;
>
>
> byte* buffer = new byte[numBytesCompressed];
>
> ar >> hpx::serialization::make_array(buffer, 
> numBytesCompressed);
>
>
> int numBytesDecompressed = blosc_decompress_ctx(buffer, 
> this->pixels, numBytes, 4);
>
>
> // Check if decompression succeeded
>
> if (numBytesDecompressed <= 0)
>
> LogError() << "(load) Decompressed bytes: " << 
> numBytesDecompressed;
>
> else if (numBytesDecompressed != numBytes)
>
> LogWarning() << "(load) Decompress mismatch! Pixel bytes: " 
> << numBytes << ", Decompressed bytes: " << numBytesDecompressed;
>
>
> delete[] buffer;
>
> }
>
> else
>
> {
>
> ar >> hpx::serialization::make_array(this->pixels, 
> numBytes);
>
> }
>
> }
>
>
> HPX_SERIALIZATION_SPLIT_MEMBER();
>
>
> --
>
>
>
> Since I’m using a temporary buffer for the compressed results, what about
> the following theory:   Does "ar << 
> hpx::serialization::make_array(buffer,
> numBytesCompressed);”  directly copy the buffer contents?   Or is only the
> buffer address and size stored and its contents are transferred at a later
> stage  (after I have already deleted the temporary buffer)?  If so,
> what would be the ideal approach in this case?
>
>
> Another general issue I noted while tracking load()/save() calls:

Re: [hpx-users] hpx::util::verify_no_locks

[Thomas Heller]

Am 13.10.2016 4:56 nachm. schrieb "Kilian Werner" :
>
> Thank you for your quick replies.
>
> I am not 100% certain that the suspending thread is not
> holding any locks, trusting your check something seems to
> slip my attention.
> However I am not requesting that much locks and each of
> them with the  std::lock_guard
> l(mtx); syntax.
> This results in all held locks being requested in a method
> on the stack trace, since no intermediately called methods
> that already finished execution can omit any locks beyond
> their scope... right?
>
> >> Is there a way to query the number and or nature of
> >>locks
> >> currently held by the executing thread?
> >
> > Not at this point, at least not in the API. Do you need
> >this functionality?
>
> This conflict between my missing observation of any held
> locks and the check firing is the motivation for querying
> all locks held in the current context.
> I don't really need this functionality for functionality
> of the application, but it would come in handy during
> debugging, since I somehow lost track of my locks
> apparently.

The best way to debug this situation currently is to run the application
with --hpx:attach-debugger=exception. At some point, you'll see an output
that tells you which process threw an exception. You can then attach, for
example gdb to it, figure out which thread threw the exception: type "info
threads", the thread that sits in nanosleep is your victim. Switch to that
thread and inspect the backtrace to see where you held the lock.

>
> Thank you for explaining the decision to check for any
> locks before suspending. While I think the decision is
> very plausible, it's still a good thing it's so flexibly
> deactivatable.
>
> Thank you for making it clear, that no two hpx-threads can
> have any influence on each other regarding locks. I am
> therefore limiting my search for untracked locks to the
> methods on the stacktrace.
>
> Btw we compiled the used hpx version a few days ago from
> the master branch.
>
> Kind regards,
>
> Kilian Werner
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Debug with HPX

[Thomas Heller]

On Mittwoch, 5. Oktober 2016 13:20:39 CEST Hartmut Kaiser wrote:
> Uri,
> 
> > I skimmed the HPX manual and paper but didn't see any mention of support
> > for debug. Is there any easy way to attach a debugger in an HPX
> > application to reproduce a problem?
> 
> An HPX application is just another executable launched once per HPX locality
> on one of the nodes. Thus the same rules/possibilities apply as for any
> other distributed application. Use whatever debugger you're comfortable
> with.
> 
> We have recently started to work on extending gdb with HPX specific things
> (pretty printers, thread management, etc.) but this is in early alpha.
> Parsa Amini is the developer here, I will make sure he responds separately.

In addition to that, parallel debuggers like DDT tend to work just fine with 
HPX (it's just yet another executable after all). We are constantly improving 
the debugging experience for HPX. In general, there is a little steeper 
learning curve due to the user level threading.
Any feedback on the available debugging support we have is greatly 
appreciated. Or any directions you would like to see debugging support to move 
to.

> 
> HPX itself has a command line option
> --hpx:attach-debugger=[startup|exception] allowing to stop the process in
> either at startup or in case of an unhandled exception. This might be
> useful to get gdb attached to a life application.
> > Is there any support for logging
> > messages so that a process can be replayed later without bringing up the
> > whole system?
> 
> The command line option --hpx:debug-hpx-log= enables logging. While
> this is very verbose it will probably not be sufficient to 'fully replay'
> all of the activity post-mortem.

Core Dumps can be analyzed post mortem just as fine.

> 
> HTH
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> 
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Serializing type-erased classes

[Thomas Heller]

On Dienstag, 20. September 2016 13:44:21 CEST Michael Levine wrote:
> Thanks for getting back to me so quickly. It's great that the boilerplate is
> able to make polymorphic serialization so straightforward and effortless.
> 
> Likewise, thanks for the information about those macros.  Having gone
> through the Boost.Serialization documentation numerous times, I had assumed
> that there would be something like that, but I was having trouble with
> finding these details.

Sorry, about the state of the docs :/

> 
> However, I'm still having some further difficulties in getting my own code
> to successfully build.  As I noted in the example code at the bottom of my
> original message, there are 2 further complicating factors in my own code as
> compared with the sample code that you provided:
> - Firstly, the derived class is a template class.
> - Secondly, the derived template class does not have a default constructor
> (it would be meaningless in the context).

Alright. we support that.

> 
> I've spent a few hours now trying to make sense of the unit tests and code
> associated with intrusive and non-intrusive pointers, and I'm still
> extremely lost and confused.  I've tried understanding the different macros
> that are applicable in each different situation, but I just can't figure out
> the right combination of macros, plus the right way to write the
> serialization functions to suit my needs.

My appologies, we really need documentation for that.

> 
> Essentially, what I need to have happen is this:
> - the base class (detail::Model_Base) is an abstract base class.  I presume
> that the intrusive macro HPX_SERIALIZATION_POLYMORPHIC_ABSTRACT(Model_Base)
> can be added within the class declaration.
> - the derived class is a template class -- template 
> detail::Model_Impl
> - the constructor for the derived class requires the Model_Type model_ to be
> deserialized out of the archive.  model_  is the argument to the
> constructor.  Furthermore, as far as I understand, I cannot use
> type-deduction in the c-tor for the class template parameter.
> - unlike the unit test code, I cannot use the factory function to create a
> new pointer and then delegate back to the serialize(Archive, C, unsigned)
> function.  Does this mean I need separate save and load functions?   I'm
> just really, really confused here...

Please have a look here:
https://github.com/STEllAR-GROUP/hpx/blob/master/tests/unit/serialization/
polymorphic/polymorphic_nonintrusive.cpp#L104

This should do exactly what you want! You can use the archive to load the ctor 
arguments, and pass it to the ctor of your derived class. The tricky part here 
is to ensure that the save and load (in the custom factory) match.

> 
> >From what I can see, none of the examples / unit tests quite matches what
> 
> I'm trying to do, and I've been going in circles on my own.  Hopefully what
> I'm trying to do isn't that difficult and you could please give me some
> further direction on this.
> 
> Thanks again,
> Michael
> 
> > -Original Message-
> > From: hpx-users-boun...@stellar.cct.lsu.edu [mailto:hpx-users-
> > boun...@stellar.cct.lsu.edu] On Behalf Of Hartmut Kaiser
> > Sent: September-20-16 10:01 AM
> > To: hpx-users@stellar.cct.lsu.edu
> > Subject: Re: [hpx-users] Serializing type-erased classes
> > 
> > Sorry, I forgot to add macros to the classes, please see below:
> > > > Could someone please help me to better understand how to write
> > > > serialization functions for a class using type erasure?  Looking at
> > > > my code, and at the hpx/runtime/serialization/ code, I just can't
> > > > figure out how to handle this.  Even assuming that the boilerplate
> > > > code is able to correctly deal with pointers to a derived class, it
> > > > appears to me that only the serialize function for the base class
> > > > will be executed by the runtime system.
> > > 
> > > Polymorphic serialization is handled correctly by the boilerplate code.
> > > You serialize your object through a shared_ptr and write a normal
> > > 
> > > serialization function for your data:
> > > struct A
> > > {
> > > 
> > > virtual ~A() {}
> > > virtual void print_something() { cout << a << endl; }
> > > 
> > > A() : a(13) {}
> > > 
> > > int a;
> > > 
> > > template 
> > > void serialize(Archive& ar, unsigned)
> > > {
> > > 
> > > ar & a;
> > > 
> > > }
> > > 
> >   HPX_SERIALIZATION_POLYMORPHIC_ABSTRACT(A);
> > > 
> > > };
> > > 
> > > struct B : A
> > > {
> > > 
> > > B() : b(0) {}
> > > B(int v) : b(v) {}
> > > 
> > > int b;
> > > 
> > > virtual void print_something() { cout << b << endl; }
> > > 
> > > template 
> > > void serialize(Archive& ar, unsigned)
> > > {
> > > 
> > > ar & b;
> > > hpx::serial

Re: [hpx-users] Serializing type-erased classes

[Thomas Heller]

Am 20.09.2016 4:02 nachm. schrieb "Hartmut Kaiser" :
>
>
> Sorry, I forgot to add macros to the classes, please see below:

Just for completeness, serialization over unique_ptr works just as fine.
The important piece are the serialization boilerplate macros.

>
> > > Could someone please help me to better understand how to write
> > > serialization functions for a class using type erasure?  Looking at my
> > > code, and at the hpx/runtime/serialization/ code, I just can't figure
> > > out how to handle this.  Even assuming that the boilerplate code is
able
> > > to correctly deal with pointers to a derived class, it appears to me
> > > that only the serialize function for the base class will be executed
by
> > > the runtime system.
> >
> > Polymorphic serialization is handled correctly by the boilerplate code.
> > You serialize your object through a shared_ptr and write a normal
> > serialization function for your data:
> >
> > struct A
> > {
> > virtual ~A() {}
> > virtual void print_something() { cout << a << endl; }
> >
> > A() : a(13) {}
> >
> > int a;
> >
> > template 
> > void serialize(Archive& ar, unsigned)
> > {
> > ar & a;
> > }
>
>   HPX_SERIALIZATION_POLYMORPHIC_ABSTRACT(A);
> > };
> >
> > struct B : A
> > {
> > B() : b(0) {}
> > B(int v) : b(v) {}
> >
> > int b;
> >
> > virtual void print_something() { cout << b << endl; }
> >
> > template 
> > void serialize(Archive& ar, unsigned)
> > {
> > ar & b;
> > hpx::serialization::base_object(*this);
> > }
>
> HPX_SERIALIZATION_POLYMORPHIC(B)
>
> > }
>
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
> >
> > void foo(std::shared_ptr a)
> > {
> > a->print_something();   // prints 42
> > }
> >
> > HPX_PLAIN_ACTION(foo, foo_action);
> >
> > void bar()
> > {
> > std::shared_ptr b = new B(42);
> > async(foo_action, find_here(), b);
> > }
> >
> > HTH
> > Regards Hartmut
> > ---
> > http://boost-spirit.com
> > http://stellar.cct.lsu.edu
> >
> > >
> > > Perhaps I don't understand how the underlying serialization subsystem
> > > works in HPX, but it would seem to me that there should be *something*
> > > particular that needs to be done in my code to be able to properly
> > > handle this situation.  I suspect that this is the latest cause of
> > > segmentation faults that I'm having on my project...
> > >
> > > The classes in question look something like the following.  I think
that
> > > the code is fairly straightforward - the Model class is essentially a
> > > wrapper for a variety of concrete model types: first an object of
> > > concrete model type is created and then passed to
> > > Model::Construct(Model_Type) which returns a Model wrapper object.
This
> > > Model type is required as a parameter for some of my Components -- as
> > > such, these classes all need to support serialization.
> > >
> > > class Model{
> > >
> > > private:
> > >
> > >  std::unique_ptr impl_;
> > >
> > > public:
> > >
> > > Model(std::unique_ptr&& model_ptr ) :
> > > implex_(std::move(model_ptr>){}
> > > Model() = default;
> > > Model(Model&& other) = default;
> > > Model(Model const& other) : impl(other.impl_->Clone()){}
> > >
> > > template 
> > > static Model Construct(Model_Type const& model){
> > >
> > >  std::unique_ptr model_impl_ =
> > > std::make_unique>(model);
> > >  Model model_{std::move(model_impl_)};
> > >  return model_;
> > >
> > > /* ... */
> > >
> > >  private:
> > >
> > >  friend class hpx::serialization::access;
> > >
> > >  template 
> > >  void serialize(Archive& ar, const unsigned int version){ ar &
> > impl_;
> > > }
> > >
> > > };
> > >
> > > namespace detail{
> > >
> > > struct Model_Base {
> > >
> > >   virtual Matrix Model(Matrix const &inputdata, vector
> > > parameters);
> > >
> > > /* ... */
> > >
> > > virtual fx::modeling::detail::Model_Base *Clone();
> > >
> > > private:
> > >friend class hpx::serialization::access;
> > >
> > > protected:
> > >template 
> > >void serialize(Archive& ar, const unsigned int version){}
> > >
> > > }
> > >
> > >
> > > template  struct Model_Impl : public Model_Base {
> > > public:
> > >using model_type = Model_Type;
> > >Model_Impl(Model_Type model) : model_(model) {}
> > >Model_Impl(Model_Impl const &other) : model_(other.model_) {}
> > >Model_Impl(Model_Impl &&other) = default;
> > >
> > >Matrix Evaluate_Model(Matrix const &inputdata, vector
> > > parameters) override;
> > >
> > >/* ... */
> > >virtual fx::modeling::detail::Model_Base *Clone() override;
> > >
> > >
> > > private:
> > >Model_Type model_;
> > >
> > >friend class hpx::serialization::access;
> > >
> > >template 
> > >

Re: [hpx-users] Get raw address of component instance

[Thomas Heller]

On Mittwoch, 31. August 2016 07:05:42 CEST Hartmut Kaiser wrote:
> > given a server component's id_type, is it possible to retrieve the raw
> > address (pointer) of the instance (on the same locality of course) ?
> 
> Why do you think you need this?
> 
> While retrieving the (shared_)pointer to the component implementation is
> possible:
> 
> std::shared_ptr p = hpx::get_ptr(id);
> 
> it pins the object, i.e. the object can't be migrated anymore. Note also,
> that get_ptr<>() will fail if the object referred to with 'id' is not on
> the locality where the code is executed. The other caveat is that get_ptr()
> might impose some overhead.

If it is only ever called once (without migration), it certainly has its 
benefits in terms of code (no actions required) and overheads when calling 
actions on a component.

> 
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Get raw address of component instance

[Thomas Heller]

On Mittwoch, 31. August 2016 17:35:18 CEST Tim Biedert wrote:
> Hi,
> 
> on each locality I have several components, which directly interact
> (e.g. one "big" component has data which is read by lots of other
> components).
> 
> These components will never be migrated, so the pinning is alright.
> 
> Declaring and defining actions for all interaction methods (e.g.
> getters) seemed like a lot of messy/unnecessary code.

If you are not using them to get addressed over its client/id_type, does it 
make sense to have them be components in the first place?

> 
> But maybe a related question at this point:  Would there be a
> performance penalty when using synchronous action invocations on the
> same locality instead of direct member method invocation?

Yes, there are some overheads related to synchronous action invocation. 
Calling a member function directly will always be faster.

> 
> 
> I was also wondering if it would be possible to further simplify action
> declaration and definition?  I'm imagining something like this in the
> component's class declaration: /HPX_ACTION void foo();/   But that's
> just an idea. Or maybe a Java-like annotation.I assume this would
> require some kind of preprocessor which would be part of HPX.

Right. We currently do not require any special compiler or extensions or 
preprocessing and would like to keep it that way. Having a compiler 
automatically generating the action code would certainly be nice though ;)

> 
> 
> Best,
> 
> Tim
> 
> On 08/31/2016 02:05 PM, Hartmut Kaiser wrote:
> >> given a server component's id_type, is it possible to retrieve the raw
> >> address (pointer) of the instance (on the same locality of course) ?
> > 
> > Why do you think you need this?
> > 
> > While retrieving the (shared_)pointer to the component implementation is 
possible:
> >  std::shared_ptr p = hpx::get_ptr(id);
> > 
> > it pins the object, i.e. the object can't be migrated anymore. Note also,
> > that get_ptr<>() will fail if the object referred to with 'id' is not on
> > the locality where the code is executed. The other caveat is that
> > get_ptr() might impose some overhead.
> > 
> > Regards Hartmut
> > ---
> > http://boost-spirit.com
> > http://stellar.cct.lsu.edu
> > 
> > 
> > ___
> > hpx-users mailing list
> > hpx-users@stellar.cct.lsu.edu
> > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Get locality of component

[Thomas Heller]

Am 30.08.2016 6:16 nachm. schrieb "Tim Biedert" :
>
> Hi,
>
> what's the best way to determine the locality of a given (remote)
component?
>
> Actually, I want to create additional components on the same locality as
a given existing component, knowing only the component's id_type. The
existing component is usually remote, so find_here() is not suitable.
>
> Passing the component's id_type to _new yields "The id passed as the
first argument is not representing a locality: HPX(bad_parameter)".

You need to use the colocating facilities.
For new_, the best is to use the colocation distribution policy:
http://stellar-group.github.io/hpx/docs/html/hpx/components/colocated.html

See here for an example:
https://github.com/STEllAR-GROUP/hpx/blob/master/tests/unit/component/new_colocated.cpp

>
> Thank you!
>
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Memory management in a distributed app

[Thomas Heller]

Am 29.08.2016 10:04 nachm. schrieb "Michael Levine" :
>
> So, if I've finally understood what you're telling me-
>
> Class A{
> static int i_;
> };
>
> Class B{
> static A a_;
> /* various state */
> };
>
> Locality 0 keeps a version of B::a_ in the process's static variable
memory
> space.
> Locality 1 keeps a completely separate version of B::a_ in its own process
> static variable memory space.
>
> Any object of type B constructed on locality 0 - either in a
locally-called
> function or through a message deserialized on locality 0 - will always
refer
> to the same static object B::a_.
> Any object of type B constructed on locality 1 - either in a
locally-called
> function or through a message deserialized on locality 1 - will always
refer
> to the same static object B::a_.
>
> In other words, by default, any global object that is not explicitly
> synchronized somehow , will be locality-local.
>
> Does that sound about right?

Yes, exactly! Conceptually, the only difference between a regular global
and one in a class is the scope and potential access control (private,
public etc). So it doesn't really belong to a single object's state.

>
>
> > -Original Message-
> > From: hpx-users-boun...@stellar.cct.lsu.edu [mailto:hpx-users-
> > boun...@stellar.cct.lsu.edu] On Behalf Of Thomas Heller
> > Sent: August-29-16 3:32 PM
> > To: hpx-users@stellar.cct.lsu.edu
> > Subject: Re: [hpx-users] Memory management in a distributed app
> >
> > On Montag, 29. August 2016 14:29:32 CEST Michael Levine wrote:
> > > Hi Thomas,
> > >
> > > > -Original Message-
> > > > From: hpx-users-boun...@stellar.cct.lsu.edu [mailto:hpx-users-
> > > > boun...@stellar.cct.lsu.edu] On Behalf Of Thomas Heller
> > > > Sent: August-29-16 6:11 AM
> > > > To: hpx-users@stellar.cct.lsu.edu
> > > > Subject: Re: [hpx-users] Memory management in a distributed app
> > > >
> > > > Hi,
> > > >
> > > > On 08/28/2016 06:06 PM, Shmuel Levine wrote:
> > > > > Hi All,
> > > > >
> > > > > I've finally found a bit of time once again to work on my hobby
> > > > > project with HPX...  The long break actually gave me a fresh
> > > > > perspective on my own code, and it occurred to me that my code has
> > > > > some serious issues with memory management, and I'm hoping that
> > > > > someone can help to provide me with some better insight into how
> > > > > to best handle memory management while working in a distributed
> > > > > app.  In particular, I would greatly appreciate some specific
> > > > > guidance on how to address the issue in my own code, since I'm at
> > > > > a bit of a loss here
> > > >
> > > > Let me try to answer your question. I am not sure I understood
> > > > everything correctly though...
> > >
> > > Thanks for your thorough message.  I, as well, have a few questions on
> > > your message.
> > >
> > > However, let me preface two important points.  Firstly, I don't have
> > > either academic or professional background in CS - I'm basically
> > > self-taught.  So I might be somewhat naïve or unsophisticated in
> > understanding of some areas.
> > > I apologize if this leads to any confusion.  Secondly, I think it
> > > might be useful for me to start by clarifying the unstated
> > > assumption(s) in my last message about the potential problems that I
had
> > thought would be an issue.
> > >
> > > \begin {assumptions}
> > > Firstly - here's how I had visualized the concept of memory management
> > > in this distributed system:
> > >
> > > To start with, I considered the case of a single locality.  There are
> > > a few variables stored on the stack, a free_list and mutex in static
> > > variable storage space, and a number of pointers to memory chunks on
> > > the heap.  The pointers themselves are provided by the local machine's
> > > allocator and refer specifically to the process's address space.
> > > Given the list of pointers to allocated memory P = {p1, p2, ..., pn},
> > > every pointer in this case is valid and can be accessed freely.
> > > Incidentally, there shouldn't even be a segmentation fault associated
> > > with (mis-)using  memory that has already been allocated, since from
> > > the OS's point-of-view, the process is using a

Re: [hpx-users] Memory management in a distributed app

[Thomas Heller]

On Montag, 29. August 2016 14:29:32 CEST Michael Levine wrote:
> Hi Thomas,
> 
> > -Original Message-
> > From: hpx-users-boun...@stellar.cct.lsu.edu [mailto:hpx-users-
> > boun...@stellar.cct.lsu.edu] On Behalf Of Thomas Heller
> > Sent: August-29-16 6:11 AM
> > To: hpx-users@stellar.cct.lsu.edu
> > Subject: Re: [hpx-users] Memory management in a distributed app
> > 
> > Hi,
> > 
> > On 08/28/2016 06:06 PM, Shmuel Levine wrote:
> > > Hi All,
> > > 
> > > I've finally found a bit of time once again to work on my hobby
> > > project with HPX...  The long break actually gave me a fresh
> > > perspective on my own code, and it occurred to me that my code has
> > > some serious issues with memory management, and I'm hoping that
> > > someone can help to provide me with some better insight into how to
> > > best handle memory management while working in a distributed app.  In
> > > particular, I would greatly appreciate some specific guidance on how
> > > to address the issue in my own code, since I'm at a bit of a loss here
> > 
> > Let me try to answer your question. I am not sure I understood everything
> > correctly though...
> 
> Thanks for your thorough message.  I, as well, have a few questions on your
> message.
> 
> However, let me preface two important points.  Firstly, I don't have either
> academic or professional background in CS - I'm basically self-taught.  So I
> might be somewhat naïve or unsophisticated in understanding of some areas.
> I apologize if this leads to any confusion.  Secondly, I think it might be
> useful for me to start by clarifying the unstated assumption(s) in my last
> message about the potential problems that I had thought would be an issue.
> 
> \begin {assumptions}
> Firstly - here's how I had visualized the concept of memory management in
> this distributed system:
> 
> To start with, I considered the case of a single locality.  There are a few
> variables stored on the stack, a free_list and mutex in static variable
> storage space, and a number of pointers to memory chunks on the heap.  The
> pointers themselves are provided by the local machine's allocator and refer
> specifically to the process's address space.  Given the list of pointers to
> allocated memory P = {p1, p2, ..., pn}, every pointer in this case is valid
> and can be accessed freely.  Incidentally, there shouldn't even be a
> segmentation fault associated with (mis-)using  memory that has already been
> allocated, since from the OS's point-of-view, the process is using an
> allocated region of memory within the process's address space.
> 
> Next, I considered what would happen with separate processes, let's call
> them L0 and L1.  If I understand correctly, it wouldn't matter whether these
> are on separate machines or on a single machine.
> Let's say on process 0, I instantiate a bunch of Matrix objects.  These use
> allocated memory segments at P = {p1, p2, ..., pn}, as before.  For this
> hypothetical example, I've also finished with some of those Matrix objects
> so that my free list on process 0 -- call it F_0 -- contains P', which is a
> subset of P.  Next, I pass a Matrix to an action on a component residing on
> process 1.  Again, the main assumption here is:
> - I had assumed that the static free list would also be copied to locality
> 1, so that F_1 == F_0, and both contain the same list P'.
> 
> Now, the code running on L1 calls a Matrix constructor with the same static
> allocator containing list F_1.  As mentioned in my above assumptions, F_1
> contains pointers P' -- all of which are pointers to memory allocated within
> L0 process memory space.  Considering the first pointer p' on the
> free_list, on L1, the address pointed-to by p' was not allocated within
> L1's address space.  As such, I assume that any access of this space would
> cause a segmentation fault.
> 
> As a final underlying assumption -- following my earlier understanding that
> the runtime system handles the allocation of the new matrix when, when the
> matrix is de-serialized on L1 (let's call the Matrix on L1 - m1) : m1's data
> is deserialized into p'', which is a pointer allocated within L1's address
> space.  When m1 goes out of scope, p'' can be added to F_1 without a
> problem.  Another matrix on L1 -- say m1' can safely grab p''.
> 
> \end {assumptions}

please take a look at this pseudo code:
Please take a look here: 
template 
struct allocator
{
T *allocate(std::size_t count)
{
return free_list_.get(cou

Re: [hpx-users] Memory management in a distributed app

[Thomas Heller]

inclination is that 
> a Matrix class should not have knowledge of the [distributed] 
> architecture on which it runs, perhaps where dealing with a distributed 
> program architecture, it is necessary to create distributed-type classes 
> -- i.e. something like class Distributed_Matrix : public Matrix {..};
> explictly
> Having said that, those are merely some speculations which came to mind 
> while trying to organize my thoughts and present this question.  It is 
> still remains in mind, however, unclear.  Something tells me that there 
> must be a better way to deal with this. Hopefully, people with more 
> brains and experience can provide me with some insight and guidance.

I hope the description above sheds some light on it, the matrix class
doesn't need any
locality information, unless you want to create a truly distributed data
structure (as opposed to just a regular container that is sent over the
wire).

> 
> I would greatly appreciate any suggestions that you can offer.  If you 
> require further details of my code, please let me know and I'd be more 
> than happy to elaborate further. However, I think that the problem 
> itself is fairly generic and is relevant to most code which is written 
> for a distributed environment - especially where the parallelism isn't 
> handled explicitly in the code (as opposed to an MPI program, for 
> example, where this is far more straightforward).
> 
> Thanks and best regards,
> Shmuel Levine
> 
> 
> [1] The actual code is slightly more complicated than the above 
> description, although I don't think that it changes the nature of the 
> question or the appropriate solution signifcantly.  In particular, each 
> set of parameters is typically a std::vector, where each Matrix 
> is a different size. In other words, the code uses multiple matrix 
> sizes, although the number of different sizes is constrained to the 
> dimension of the parameter vector above.  The actual allocator 
> definition is as follows:
> 
> class Matrix_Allocator {
> public:
>using T = float;
>using data_type = T;
>static const int64_t alignment = 64;
> 
> private:
>using mutex_type = hpx::lcos::local::spinlock;
>using free_list_type = std::map>;
>using allocation_list_type = std::map;
> 
> public:
>Matrix_Allocator() {}
>~Matrix_Allocator();
>Matrix_Allocator(Matrix_Allocator const &) = delete;
>Matrix_Allocator(Matrix_Allocator &&) = delete;
> 
>static T *allocate(int64_t n);
>static void deallocate(T *p);
> 
> private:
>static mutex_type mtx_;
>static free_list_type free_list_;
>static allocation_list_type allocation_list_;
> 
> }; // class Matrix_Allocator
> 
> The allocation_list_ is used to track the allocated size of a given 
> pointer, to determine to which free_list should the pointer be added 
> upon destruction of a matrix.
> 
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> 


-- 
Thomas Heller
Friedrich-Alexander-Universität Erlangen-Nürnberg
Department Informatik - Lehrstuhl Rechnerarchitektur
Martensstr. 3
91058 Erlangen
Tel.: 09131/85-27018
Fax:  09131/85-27912
Email: thomas.hel...@cs.fau.de
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Iterative construction of dataflow graph

[Thomas Heller]

Am 17.08.2016 11:11 vorm. schrieb "Andreas Schäfer" :
>
> Hey guys,
>
> I've got a quick question on the creation of the dataflow graph in
> HPX. Zach reported yesterday that he can't run dgswem with a really
> large number of time steps on top of LGD/HPX, but the code works fine
> with just a couple of time steps. We create the complete dataflow
> graph before starting the simulation and my suspicion is that this
> simply fails for a couple million time steps. So my question is
> how/when should we fill the dataflow graph?
>
> I assume we should have some kind of iterative procedure for that, so
> that we add a certain number of timesteps with a certain look ahead
> distance to the graph, but I'm not sure which parameters make sense.
>
> For instance, if we assume a total of t timesteps, then right now our
> chunk size c is t and our look ahead distance l is 0. But we could
> also fill in 1000 timesteps up front and then add another step in each
> cycle (l = 1000, c = 1). Or some mixture of this, e.g. fill in 1000 up
> front and then add another 100 every 100 steps. I don't know. This
> already reeks of over engineering. Any ideas?

If you don't want to hardcode the limits, you could dynamically adjust the
look ahead using performance counters. That is, let it run until you hit
some limit like memory used or thread queue length or so.

>
> Thanks!
> -Andreas
>
>
> --
> ==
> Andreas Schäfer
> HPC and Supercomputing
> Institute for Multiscale Simulation
> Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany
> +49 9131 85-20866
> PGP/GPG key via keyserver
> http://www.libgeodecomp.org
> ==
>
> (\___/)
> (+'.'+)
> (")_(")
> This is Bunny. Copy and paste Bunny into your
> signature to help him gain world domination!
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Parallel reduce given vector of futures

[Thomas Heller]

On Donnerstag, 28. Juli 2016 12:45:09 CEST Hartmut Kaiser wrote:
> Daniel,
> 
> > > > > Suppose we have a vector of futures of type T and we want to reduce
> > > 
> > > the
> > > 
> > > > > values contained in the futures using T op(T, T), with initial value
> > > 
> > > of
> > > 
> > > > > init. What is the HPX recommended way of doing this? What should the
> > > > > implementation of "future myreduce(vector > fs, T init,
> > > 
> > > Op
> > > 
> > > > > op)" be?
> > > > > 
> > > > > hpx::parallel::reduce can't be used with a vector of futures.
> > > > > hpx::lcos::reduce isn't what we're looking for as this isn't a
> > > 
> > > distributed
> > > 
> > > > > operation. One option is to use hpx::when_any and accumulate the
> > > 
> > > values as
> > > 
> > > > > they are ready. But this serializes the accumulation of the futures,
> > > 
> > > which
> > > 
> > > > > may not be desirable.
> > > > 
> > > > How about:
> > > > 
> > > > vector> v = ...;
> > > > future f =
> > > > dataflow(unwrapped(
> > > > [](vector && data) -> T
> > > > {
> > > > return parallel::reduce(
> > > > par, data.begin(), data.end(), op);
> > > > }),
> > > > std::move(v)
> > > > );
> > > 
> > > This would work but wouldn't parallel::reduce not start until all of the
> > > futures in v are ready? I'd be concerned that waiting on all of v could
> > > take too long. Especially if this were the last task in an application
> > 
> > (no
> > 
> > > other asynchrony is available) and some elements in v may be ready much
> > > later than other elements in v.
> > 
> > Ahh! Yes, that would be the case. Reduce would run only once all input-
> > futures have become ready.
> > 
> > We don't have any way to work around that at this point short of re-
> > implementing reduce to start working on the input elements as they become
> > available.
> 
> Actually, if you assumed that the input futures will become ready one by one
> (not all at the same time) it might be beneficial to use when_each:

What we missed are "futurized" parallel algorithms, that are usable in the 
same sense as dataflow.

> 
> vector> v = ...;
> T reduced_result = 0;
> mutex mtx;
> future f =
> when_each(
> [&](future& f)
> {
> lock_guard l(mtx);
> reduced_result += f.get();
> },
> std::move(v)
> );
> 
> // do other things
> f.get();
> 
> as when_each calls the given function for each of the futures once they
> become ready. Alternatively you could use wait_each() which is equivalent,
> it just will return only after all futures have been processed.
> 
> If the locking/unlocking turns into a bottleneck you could also utilize
> something like a cilk hyperobject, for an example implementation see the
> file example/quickstart/safe_object.cpp.
> 
> HTH
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> 
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] HPX futures and random number generators

[Thomas Heller]

On Mittwoch, 22. Juni 2016 16:24:01 CEST Michael Levine wrote:
> I’m looking for some advice regarding creating an
> std::vector > > where the elements of the
> innermost vector use a random number generator.
> 
> 
> 
> Typically, if I were to use to generate this vector of random integers, I’d
> use either boost or standard library random functions (or possibly Intel MKL
> / VSL); however, all of these RNGs have a state.  As I understand, a naïve
> implementation, just passing a reference to the RNG state would lead to
> race conditions and will result in the RNG state ending up in some
> undefined-state.  If I understand correctly, that would be the reason that
> an action cannot have a non-const reference parameter.

The reason why actions can't take non-const references is because those don't 
make a lot of sense in a distributed context. const references are fine, but 
the parameters you pass to async will get decay-copied into the packaged task 
anyway.

> 
> 
> 
> In light of this, how could I use a future to represent this vector of
> future integer-vectors?  Is there any way to make this code concurrent?

One possibility would be to create a thread local random number generator as 
suggested here:
http://stackoverflow.com/questions/21237905/how-do-i-generate-thread-safe-uniform-random-numbers

The other is of course to really construct a fully parallel number generator.

> 
> As a rough reference:
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> using random_vec_t = std::vector;
> 
> constexpr int random_vec_size = 8;
> constexpr int vec_random_size = 30;
> 
> //template 
> std::vector Generate_Random_Vector(std::mt19937_64 &rng) {
>   std::vector random_vector_set;
>   static const int range_ = 100;
>  std::uniform_int_distribution dist_(0, range_);
>   random_vector_set.resize(vec_random_size);
> 
>   for (auto &vec : random_vector_set) {
> vec.reserve(random_vec_size);
> for (int i = 0; i < random_vec_size; ++i)
>   vec.push_back(dist_(rng));
>   }
>   return random_vector_set;
> }
> 
> HPX_PLAIN_ACTION(Generate_Random_Vector, generate_random_vector_action); //
> <= this line fails with message: static_assert failed "Using non-const
> references as arguments for actions is not supported."

Makes sense, as explained above.

> int main(int argc, char *argv[]) {
>   std::mt19937_64 rng_;
>   hpx::future> future_vectors_ =
> hpx::async(generate_random_vector_action, rng_);

Is there any reason to use an action here? async can just take any callable 
(including regular function pointers). You could express what you have like 
this:

async(&generate_random_vector, std::ref(rng_));

> 
>   auto vecs_ = future_vectors_.get();
> 
>   for (auto outer_vec : vecs_) {
> for (auto inner_vec : outer_vec)
>   std::cout << inner_vec << "\t";
> std::cout << std::endl;
>   }
> 
>   return 0;
> }
> 
> Thanks and regards,
> 
> Shmuel


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] clang-format

[Thomas Heller]

s which automatically
format the patches once you push them. pre commit hooks have the same
problem as the editor, they only run on the developers machine.
We could certainly have a bot though that goes through a pull request,
applies clang-format, and then issues a PR to the original PR that includes
the clang-format changes... resulting in a very convoluted setup ;)
However, such a technique might be quite cool as we could also leverage
clang-check, which is able to automatically rewrite code based on some
other static analysis results ...


> So the bottom line is, for me currently this adds more questions than it
> solves. More discussions are needed. Does anybody have any experience with
> code style/formatting tools from other projects?
>

I have no idea how other projects handle this.

However, I think the benefits outweigh the potential problems (turning off
developers how find it too cumbersome etc.).
It sometimes is really annoying to go through a PR which has flyby
formatting changes. Those are really getting in the way.


>
> Thanks!
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
> >
> > Cheers,
> > Thomas
> >
> > On 04/13/2016 11:48 AM, Hartmut Kaiser wrote:
> > > John,
> > >
> > >> I am working on multiple projects, each has different formatting
> styles
> > >> (annoying), but I recently discovered that one project uses a .clang-
> > >> format file in the root folder to control the style and there is an
> > >> eclipse plugin that searches the project path for the next-up .clang-
> > >> format file and uses that to reformat the code you want changed (there
> > are
> > >> also Xcode/vim/other? ones too!).
> > >>
> > >> If there was a .clang-format file for hpx at the root folder of hpx,
> > then
> > >> my dream of having each project I work on, formatted according to the
> > >> style of that project could be achieved.
> > >>
> > >> Does anyone have such a file for hpx, or can one convert easily one of
> > >> their existing style format control thingies, to the clang-format
> > format?
> > >> (I'm sure it's quite trivial, I just don't want to do it myself).
> > >
> > > Having this would be cool indeed. I'm not aware of anybody using
> > > clang-format for HPX, however.
> > >
> > > Regards Hartmut
> > > ---
> > > http://boost-spirit.com
> > > http://stellar.cct.lsu.edu
> > >
> > >
> > >
> > > ___
> > > hpx-users mailing list
> > > hpx-users@stellar.cct.lsu.edu
> > > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> > >
> >
> >
> > --
> > Thomas Heller
> > Friedrich-Alexander-Universität Erlangen-Nürnberg
> > Department Informatik - Lehrstuhl Rechnerarchitektur
> > Martensstr. 3
> > 91058 Erlangen
> > Tel.: 09131/85-27018
> > Fax:  09131/85-27912
> > Email: thomas.hel...@cs.fau.de
> > ___
> > hpx-users mailing list
> > hpx-users@stellar.cct.lsu.edu
> > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] clang-format

[Thomas Heller]

Hi all,

I tried to set up a .clang-format file which mostly matches our current
coding style (a few exceptions). I used clang-format from 3.8.
The file can be seen here:
https://gist.github.com/sithhell/5a0caa8b05a78c859390c2b7be174315
Is this something we can work with?

There is multitude of possibilities on how to integrate it in your
workflow. The first would be to integrate it into your IDE/editor as
described here:
http://clang.llvm.org/docs/ClangFormat.html (look through the page, the
editor setup comes at the end).
There is also a description on how to format the changes you made before
committing. I also found this little thingy here:
https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/git-clang-format

Would be great if we could start using that tool to finally get rid of
noisy reformatting changes in our commits.

Cheers,
Thomas

On 04/13/2016 11:48 AM, Hartmut Kaiser wrote:
> John,
> 
>> I am working on multiple projects, each has different formatting styles
>> (annoying), but I recently discovered that one project uses a .clang-
>> format file in the root folder to control the style and there is an
>> eclipse plugin that searches the project path for the next-up .clang-
>> format file and uses that to reformat the code you want changed (there are
>> also Xcode/vim/other? ones too!).
>>
>> If there was a .clang-format file for hpx at the root folder of hpx, then
>> my dream of having each project I work on, formatted according to the
>> style of that project could be achieved.
>>
>> Does anyone have such a file for hpx, or can one convert easily one of
>> their existing style format control thingies, to the clang-format format?
>> (I'm sure it's quite trivial, I just don't want to do it myself).
> 
> Having this would be cool indeed. I'm not aware of anybody using
> clang-format for HPX, however.
> 
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> 
> _______
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> 


-- 
Thomas Heller
Friedrich-Alexander-Universität Erlangen-Nürnberg
Department Informatik - Lehrstuhl Rechnerarchitektur
Martensstr. 3
91058 Erlangen
Tel.: 09131/85-27018
Fax:  09131/85-27912
Email: thomas.hel...@cs.fau.de
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

[hpx-users] GSoC - Websocket parcelport

[Thomas Heller]

Hi Egor,

I am very sorry that we couldn't have our skype meeting yet. I am 
currently still on travel ... Would you mind summarizing your current 
state and findings regarding the websocket parcelport?
What I am most interested in are answers to the following questions:
1) Which websocket implementation did you decide to use?
2) Is our current parcelport plugin system suitable for implementing a 
websockets backend?

If you are not sure how to answer any of those questions, please don't 
hesitate to point out your uncertainties so that we can discuss them and 
find a solution!

In the meantime, would next monday 15:00 work for you for a skype session?

Cheers,
Thomas
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

[hpx-users] GSoC - Prospective Students

[Thomas Heller]

Dear prospective Students,

This Friday, 19:00 UTC is the deadline for your GSoC Proposal! Time is 
running if you just start to write your proposal. If you haven't done 
so, please start now. Get in contact with us, discuss your ideas with 
us, we are looking forward to work with you!

Please also don't forget to submit your proof of enrollment in time! 
This has to happen right now as Google needs to approve you before you 
can submit anything! Also, share drafts as early as possible with us.

Cheers,
Thomas
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Fwd: GSoC hpx

[Thomas Heller]

Hi Ales,

Thanks for expressing interest! To answer your first question right away
(might be important for others as well):

We haven't received a lot proposals so far, unfortunately. Your chance
for a successful depends on a lot of factors, some of which we can't
influence.
However, what you should do right now (since time is limited) is the
following:
 - Make up your mind which project you want to apply for, NOW!
 - Discuss your ideas now and ask questions, NOW!
   The most interactive and productive source is our IRC channel
 - Start writing your proposal, NOW!

Sorry for the caps, but time is really limited ;)

The only project you listed directly dealing with parallelism is the
first. The other two are mainly "supporting" projects. However, I think
they are equally interesting and of high potential.
The second one would be particularly nice since having a separate
hpx_main is considered a hassle by some. The third one is at the heart
of HPX and a good outcome will have a huge impact on the performance of HPX!

Hope that helps, don't hesitate to ask further questions!

Cheers,
Thomas

On 03/23/2016 03:47 PM, Thomas Heller wrote:
> Forwarding to the ML for others to chime ...
> 
> 
>  Forwarded Message 
> Subject:  GSoC hpx
> Date: Wed, 23 Mar 2016 14:42:21 +0100
> From: Aleš Saska 
> To:   thom.hel...@gmail.com
> 
> 
> 
> Hello,
> it was about few days ago my friend told me about GSoC and I found it
> very interesting. After doing some research of organizations I find out
> that I'm most into you project. I am studying Programming (specially
> system programming - parallel systems and languages, and also data
> science) at the Czech Technical univensity in Prague .
> 
> My favourite language is C++ and I like parallel programming.
> 
> 
>  Could you please give me an answer, If I have any chance to pass this
> appliance (and also how many students are interested in these projects)?
> 
> I am focused in these projects (from the better to the worst):
> 
> Implement Map/Reduce
> A C++ Runtime Replacement
> Implement a faster associative container for GIDs
> 
> If you have another interesting tip for project, I could look to it.
> 
> 
> 
> 
> 
> I am sorry, that I am writing to you, but I don't have much time,
> because of deadline on Friday.
> 
> 
> 
> best regards,
> Aleš Saska
> 
> 


-- 
Thomas Heller
Friedrich-Alexander-Universität Erlangen-Nürnberg
Department Informatik - Lehrstuhl Rechnerarchitektur
Martensstr. 3
91058 Erlangen
Tel.: 09131/85-27018
Fax:  09131/85-27912
Email: thomas.hel...@cs.fau.de
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

[hpx-users] Fwd: GSoC hpx

[Thomas Heller]

Forwarding to the ML for others to chime ...


 Forwarded Message 
Subject:GSoC hpx
Date:   Wed, 23 Mar 2016 14:42:21 +0100
From:   Aleš Saska 
To: thom.hel...@gmail.com



Hello,
it was about few days ago my friend told me about GSoC and I found it
very interesting. After doing some research of organizations I find out
that I'm most into you project. I am studying Programming (specially
system programming - parallel systems and languages, and also data
science) at the Czech Technical univensity in Prague .

My favourite language is C++ and I like parallel programming.


 Could you please give me an answer, If I have any chance to pass this
appliance (and also how many students are interested in these projects)?

I am focused in these projects (from the better to the worst):

Implement Map/Reduce
A C++ Runtime Replacement
Implement a faster associative container for GIDs

If you have another interesting tip for project, I could look to it.





I am sorry, that I am writing to you, but I don't have much time,
because of deadline on Friday.



best regards,
Aleš Saska


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Filling a vector of futures

[Thomas Heller]

On 03/01/2016 03:31 PM, shmuel.lev...@gmail.com wrote:
> I came across an issue last night trying to initialize a vector of
> futures. I first tried std::fill but I (obviously - in retrospect)
> cant't assign ‎a float to future. hpx::fill also didn't work.

Yes, float to future directly doesn't work, hpx::make_ready_future(0.f);
should though. However, I believe that std::fill (and
hpx::parallel::fill) use the copy constructor. hpx::future is not
copyable though.

> 
> I also tried hpx::for_each and hpx::make_ready_future -- it surprised me
> that this also wouldn't compile. I've yet to fully decipher the compiler
> error, but I can say that it got stopped by the pseudo-concept /
> enable_if. I'm not sure which parameter(s) were problematic.

Not sure either, a testcase might help.

> 
> I expect that an explicit loop will work -- that is shown in the
> tutorials in the documentation - but was looking for an alternative
> using a high level algorithm. 
> 
> ‎It just occurred to me that std::generate might work, though I haven't
> tried it.

generate will work indeed, transform might be an option as well.

> 
> I suppose I have 2 questions:
> 1. Is there a canonical way to initialize a vector of futures? 

Depends on what you are after ... there is
hpx::parallel::executor_traits::execute which returns a vector
of futures if the Shape arguments has been passed to it:
http://stellar-group.github.io/hpx/docs/html/hpx/parallel/v3/executor_traits.html#idp33907472-bb


> 2. Is there any reason why hpx::fill cannot fill futures - other than
> lack of specialization? Is it semantically incorrect? If there are no
> fundamental objections, I'd like to attempt to contribute a patch for this. 

Do you mean hpx::parallel::fill? That's just the parallel version of
std::fill.

> 
> Thanks-
> Shmuel
> 
> 
> Sent from my BlackBerry 10 smartphone on the Rogers network.
> 
> 
> _______
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> 


-- 
Thomas Heller
Friedrich-Alexander-Universität Erlangen-Nürnberg
Department Informatik - Lehrstuhl Rechnerarchitektur
Martensstr. 3
91058 Erlangen
Tel.: 09131/85-27018
Fax:  09131/85-27912
Email: thomas.hel...@cs.fau.de
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Random Lockups

[Thomas Heller]

Am 18.02.2016 10:22 nachm. schrieb "Andreas Schäfer" :
>
> Heya,
>
> I've just seen my tests locking up again with HPX commit

Guess it is bisect time! Could you tell me which test and how frequently it
locks up?
I'm also interested in boost and compiler version!

>
>   0c3174572ef5d2c01043d9dd070023983ecb888a
>
> Backtrace:

P.S.: that backtrace is useless as it just shows the main (first thread) of
your process which is waiting on a CV for the application to end. In
general it is very difficult to "catch" the code that hangs when attaching
gdb.

>
> (gdb) bt
> #0  0x7f1715d2e00f in pthread_cond_wait () from /lib64/libpthread.so.0
> #1  0x7f1719afc416 in
boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock&,
boost::asio::detail::task_io_service_thread_info&,
boost::system::error_code const&) ()
>from
/home/gentryx/test_build_libgeodecomp_rei_clang++/install/lib/libhpx.so.0
> #2  0x7f1719afc120 in
boost::asio::detail::task_io_service::run(boost::system::error_code&) ()
from
/home/gentryx/test_build_libgeodecomp_rei_clang++/install/lib/libhpx.so.0
> #3  0x7f1719b355d4 in hpx::util::io_service_pool::thread_run(unsigned
long) () from
/home/gentryx/test_build_libgeodecomp_rei_clang++/install/lib/libhpx.so.0
> #4  0x7f1719576e4a in
hpx::runtime_impl >::wait() () from
/home/gentryx/test_build_libgeodecomp_rei_clang++/install/lib/libhpx.so.0
> #5  0x7f1719577ac5 in
hpx::runtime_impl >::run(hpx::util::function const&) () from
/home/gentryx/test_build_libgeodecomp_rei_clang++/install/lib/libhpx.so.0
> #6  0x7f17195b8d67 in hpx::detail::run(hpx::runtime&,
hpx::util::function
const&, boost::program_options::variables_map&, hpx::runtime_mode,
hpx::util::function const&, hpx::util::function const&) () from
/home/gentryx/test_build_libgeodecomp_rei_clang++/install/lib/libhpx.so.0
> #7  0x7f17195ba201 in
hpx::detail::run_priority_local(hpx::util::function const&,
hpx::util::function const&,
hpx::util::command_line_handling&, bool) ()
>from
/home/gentryx/test_build_libgeodecomp_rei_clang++/install/lib/libhpx.so.0
> #8  0x7f17195bb849 in
hpx::detail::run_or_start(hpx::util::function const&,
boost::program_options::options_description const&, int, char**,
std::vector >&&,
hpx::util::function const&, hpx::util::function const&, hpx::runtime_mode, bool) () from
/home/gentryx/test_build_libgeodecomp_rei_clang++/install/lib/libhpx.so.0
> #9  0x0077b5b6 in hpx::init(hpx::util::function const&,
boost::program_options::options_description const&, int, char**,
std::vector > const&,
hpx::util::function const&, hpx::util::function const&, hpx::runtime_mode) ()
> #10 0x0077b200 in hpx::init(int, char**, std::vector > const&, hpx::runtime_mode) ()
> #11 0x0077af1a in main ()
>
> QQ
> -Andi
>
>
> On 16:22 Tue 16 Feb , Hartmut Kaiser wrote:
> > Andy,
> >
> > You need at least use this: 8aac54113dccabcd29548cb3f764026d5ec7e696
(which
> > is the commit fixing the issue). Better yet, use top of master.
> >
> > Regards Hartmut
> > ---
> > http://boost-spirit.com
> > http://stellar.cct.lsu.edu
> >
> >
> > > -Original Message-
> > > From: Andreas Schäfer [mailto:gent...@gmx.de]
> > > Sent: Tuesday, February 16, 2016 2:03 PM
> > > To: hartmut.kai...@gmail.com; hpx-users@stellar.cct.lsu.edu
> > > Subject: Re: [hpx-users] Random Lockups
> > >
> > > Heya,
> > >
> > > it's still there. If it's of any help: I was running HPX commit
> > > e68952daf3eba2453c683cbef883a8132663c95d with four localities and four
> > > threads each.
> > >
> > > (gdb) bt
> > > #0  0x7f82b6ea600f in pthread_cond_wait () from
/lib64/libpthread.so.0
> > > #1  0x7f82b7b491ca in
> > > boost::asio::detail::task_io_service::run(boost::system::error_code&)
()
> > > from /home/gentryx/test_build_libgeodecomp_rei_g++-
> > > 4.9.3/install/lib/libhpx.so.0
> > > #2  0x7f82b7b7473b in
hpx::util::io_service_pool::thread_run(unsigned
> > > long) () from /home/gentryx/test_build_libgeodecomp_rei_g++-
> > > 4.9.3/install/lib/libhpx.so.0
> > > #3  0x7f82b7763b6b in
> > >
hpx::runtime_impl > > oost::mutex, hpx::threads::policies::lockfree_fifo,
> > > hpx::threads::policies::lockfree_fifo,
> > > hpx::threads::policies::lockfree_lifo> >::wait() () from
> > > /home/gentryx/test_build_libgeodecomp_rei_g++-
> > > 4.9.3/install/lib/libhpx.so.0
> > > #4  0x7f82b7748075 in
> > >
hpx::runtime_impl > > oost::mutex, hpx::threads::policies::lockfree_fifo,
> > > hpx::threads::policies::lockfree_fifo,
> > > hpx::threads::policies::lockfree_lifo> >::run(hpx::util::function > > false> const&) () from /home/gentryx/test_build_libgeodecomp_rei_g++-
> > > 4.9.3/install/lib/libhpx.so.0
> > > #5  0x7f82b778b581 in hpx::detail::run(hpx::runtime&,
> > > hpx::util::function
> > > const&, boost::program_options::variables_map&, hpx::runtime_mode,
> > > hpx::util::function const&, hpx::util::function > > false> const&) () from /home/gentryx/test_build_libgeodecomp_rei_g++-
> 

Re: [hpx-users] hpx 0.9.11 segmentation fault running on multiple localities

[Thomas Heller]

ot;nanosleep", which is part of libc. First thing to do is typing "info
threads". This will give you a list of all operating system threads
running. One (or more) is then sitting in nanosleep. Switch to that
thread with "thread I". Once you are in the correct frame, you can
navigate the frame up until it reaches your code. The variable i is in
the handle_attach_debugger function, which should be easily spottable in
the frame of that function.

Hope I could help

> 
> Thanks again for all your assistance,
> Michael
> 
> 
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> 


-- 
Thomas Heller
Friedrich-Alexander-Universität Erlangen-Nürnberg
Department Informatik - Lehrstuhl Rechnerarchitektur
Martensstr. 3
91058 Erlangen
Tel.: 09131/85-27018
Fax:  09131/85-27912
Email: thomas.hel...@cs.fau.de
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] hpx 0.9.11 segmentation fault running on multiple localities

[Thomas Heller]

Hi Michael,

>From your segfault, it seems that you're running into one of the problems
in the 0.9.11 release. We believe that those are fixed on the latest master
branch. As Hartmut noted, we plan to do a new release soon. Would you mind
checking with the latest master branch?

Regards,
Thomas
Am 08.01.2016 3:48 nachm. schrieb "Michael Levine" :

> Hi,
>
>
>
> I've been experimenting with hpx for a hobby project, with a small
> virtualized cluster of 3 debian 8.2 machines running on esxi server. When I
> run any hpx code on a single locality, it appears to be working; however,
> whenever I try to use more  than one locality, I invariably get a
> segmentation fault, regardless of which code I am using. I first
> encountered the trouble with my own code, but it also happens when running
> any of the example apps as well. I am somewhat new to all of this and I
> cannot figure out how to attach a debugger to try and identify the cause of
> these errors.
>
>
>
> I'm using hpx 0.9.11 on my small cluster using the latest version of slurm
> . (I chose slurm as it appears to provide support for Intel Phi nodes
> running applications in native mode).  To the best of my knowledge, slurm
> is configured correctly.  However, it is certainly possible that I have
> done something wrong configuring slurm.
>
>
>
> I have tried using boost 1.58, 1.59, and 1.60. I have tried with clang 3.7
> and with Intel C++ 16 and 16 update 1. In all cases, I get the same
> segmentation fault whenever I try and run on more than a single locality.
> I have played around with single vs. multiple network interfaces, single
> vs. multiple networks, etc.
>
>
>
> Lately, I have re-built boost using the Intel compiler to ensure that
> there was no issue caused by hpx and boost having been compiled with
> different compilers.   I have been trying to troubleshoot this only based
> on the example code, rather than my own code, so that I can be confident
> that the problems are not caused by my own code errors/bugs.
>
>
>
> I know there is a command-line option to attach a debugger but I cannot
> figure out how to use this.
>
>
>
> I’ve attached a copy of my slurm.conf for reference, and the output of
> --hpx:dump-config and --hpx:debug-clp
>
>
>
> HPX stack trace / complete error message is copied below.
>
>
>
> I’m really stuck here and honestly have no idea how to resolve this
> issue.  I greatly appreciate any help that you can offer.  Furthermore, I’d
> really appreciate some guidance as to how to use a debugger to debug my own
> hpx code to identify and resolve issues with that code.  Please let me know
> if there’s any additional information that I should provide.
>
>
>
> Thank you very much in advance,
>
> Shmuel
>
>
>
>
>
> shmuel@ssh01:/usr/local/lib
>
> > srun -n1 -N1 1d_stencil_7
>
>
> Localities,OS_Threads,Execution_Time_sec,Points_per_Partition,Partitions,Time_Steps
>
> 1, 1, 0.093138849, 10,   10,   45
>
>
>
> shmuel@ssh01:~
>
> > srun -n2 -N1 1d_stencil_7
>
>
>
> {stack-trace}: 4 frames:
>
> 0x7f09a45e9840  : hpx::detail::backtrace(unsigned long) + 0x80 in
> /usr/local/lib/libhpx.so.0
>
> 0x7f09a45eeced  : boost::exception_ptr
> hpx::detail::get_exception(hpx::exception const&,
> std::string const&, std::string const&, long, std::string const&) + 0x23d
> in /usr/local/lib/libhpx.so.0
>
> 0x7f09a45ee8bc  : void
> hpx::detail::throw_exception(hpx::exception const&,
> std::string const&, std::string const&, long) + 0x10c in
> /usr/local/lib/libhpx.so.0
>
> 0x7f09a4a0de3d  :
> hpx::agas::server::primary_namespace::resolve_free_list(boost::unique_lock&,
> std::list long> >,
> std::allocator const, long> > > > const&,
> std::list std::allocator >&,
> hpx::naming::gid_type const&, hpx::naming::gid_type const&,
> hpx::error_code&) + 0x137d in /usr/local/lib/libhpx.so.0
>
> {env}: 85 entries:
>
>   ALTERNATE_EDITOR=
>
>   CPATH=/opt/intel/compilers_and_libraries_2016.1.150/linux/mkl/include
>
>   CXX=clang++
>
>   DIRHISTORY_SIZE=30
>
>   DISPLAY=localhost:10.0
>
>   EDITOR=/usr/bin/vim
>
>
> FPATH=/home/shmuel/.oh-my-zsh/plugins/wd:/home/shmuel/.oh-my-zsh/plugins/tmux:/home/shmuel/.oh-my-zsh/plugins/dirhistory:/home/shmuel/.oh-my-zsh/plugins/colorize:/home/shmuel/.oh-my-zsh/plugins/history:/home/shmuel/.oh-my-zsh/plugins/sudo:/home/shmuel/.oh-my-zsh/plugins/command-not-found:/home/shmuel/.oh-my-zsh/plugins/tmux:/home/shmuel/.oh-my-zsh/plugins/mosh:/home/shmuel/.oh-my-zsh/plugins/git-extras:/home/shmuel/.oh-my-zsh/plugins/battery:/home/shmuel/.oh-my-zsh/plugins/git-flow-avh:/home/shmuel/.oh-my-zsh/plugins/git:/home/shmuel/.oh-my-zsh/functions:/home/shmuel/.oh-my-zsh/completions:/usr/local/share/zsh/site-functions:/usr/share/zsh/vendor-functions:/usr/share/zsh/vendor-completions:/usr/share/zsh/functions/Calendar:/usr/share/zsh/functions/Chpwd:/usr/share/zsh/functions/Completion:/usr/share/zsh/functions/Completion/AIX:/usr/share/zsh/functions/Completion/BSD:/usr/share/zsh/functions/Completion/Base:/usr/s

Re: [hpx-users] Action invocation problem on cluster

[Thomas Heller]

dless loop until my job times out.
>>
>> This same code runs completely if i take 8 localities on a single node,
>> or decrease my "vec"-size to 3000.
>> I need to send data of this size, because I'm trying to do image
>> compositing.
>> Thanks in advance for any tips.
>>
>> best,
>> Jan
>>
>>
>>
>> I'm currently learning and trying to use HPX on our uni-cluster in my
>> bachelor-thesis. I've come across a problem with big parameters in
>> actions.
>> My example setup (same problem with bigger setups) is 8 localities on 8
>> nodes of the cluster (one on each XEON E5 2670, I'm using intelMPI).
>> I'm calling method1 multiple times on each locality, here is the code:
>>
>> void out(std::vector vec)
>> {
>>hpx::cout << "out called " << hpx::find_here() << std::endl <<
>> hpx::flush;
>> }
>> HPX_PLAIN_ACTION(out, out_action);
>>
>> void method1()
>> {
>>std::vector locs =
>> hpx::find_all_localities();
>>std::vector > fut;
>>// create data
>>uint x = 300;
>>std::vector vec;
>>for (uint j=0; j < x; j++)
>>{
>>vec.push_back(1);
>>}
>>// send out my data
>>for (uint i = 0; i < locs.size(); i++)
>>{
>>typedef out_action act;
>>compFut.push_back(hpx::async(locs.at(i)), vec));
>>}
>>hpx::wait_all(fut);
>> }
>> HPX_PLAIN_ACTION(method1, method1_action);
>>
>>
>> Calling method1_action for the first time works just as expected, "out
>> called" gets printed 8 times per locality.
>> When called a second time, all out_action get scheduled, but only 2 or 3
>> get performed/produce output and I get stuck in an endless loop at
>> wait_all(fut).
>> If I increase my setup to eg. 64 localities on 4 nodes, the same problem
>> at the third or fourth time method1 is called.
>> This problem does not persist if I decrease the data-size x to 1 or
>> allocate the localities on a single node.
>> It seems to me like either a serialization problem or a buffer that runs
>> full. Since all data is forgot after each call of method1 I can't
>> explain it myself.
>> I would be grateful for any help regarding debugging, reconfiguring my
>> setup to bigger bounds or just where to search further.
>> Could you give us the full code to try? The code snippet you gave above
>> does
>> not compile ('compFut' is undefined).
>> Also, I see no place where you actually wait for all futures in 'compFut'
>> to
>> become ready - could that be that problem you're seeing?
>> Sorry, that was a mistake due to simplicity namechanges. "compFut" is
>> meant to be "fut", but that's not the problem.
>>
>> Regards Hartmut
>> ---
>> http://boost-spirit.com
>> http://stellar.cct.lsu.edu
>>
>>
>>
>>
>> Best,
>> Jan
>> ___
>> hpx-users mailing list
>> hpx-users@stellar.cct.lsu.edu
>> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>> ___
>> hpx-users mailing list
>> hpx-users@stellar.cct.lsu.edu
>> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>>
>>
>>
>>
>>
>> ___
>> hpx-users mailing list
>> hpx-users@stellar.cct.lsu.edu
>> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> 
> 
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> 


-- 
Thomas Heller
Friedrich-Alexander-Universität Erlangen-Nürnberg
Department Informatik - Lehrstuhl Rechnerarchitektur
Martensstr. 3
91058 Erlangen
Tel.: 09131/85-27018
Fax:  09131/85-27912
Email: thomas.hel...@cs.fau.de
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Program failing when not compiling with -O3

[Thomas Heller]

Am 17.11.2015 10:10 nachm. schrieb "Hartmut Kaiser" <
hartmut.kai...@gmail.com>:
>
>
> > So, Zach and I have hit the same error when interfacing dg-swem with
> > HPX+LGD, but here we weren't able to work around it via adding -O3.
> > Any ideas for another workaround?
> >
> > Thomas said he's suspecting a bug in HPX, but I can't really figure
> > out what's going wrong.
>
> As said, I don't understand what you're doing with that code. The
> component-registry stuff is very subtle to get right and I don't see any
> obvious reason you create your own.

Does it work when you use the HPX provided registration macros?

>
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
> >
> > Thanks!
> > -Andreas
> >
> >
> > On 23:49 Sun 15 Nov , Andreas Schäfer wrote:
> > > Heya,
> > >
> > > I've recently seen some of my HPX applications terminating right
> > > before hpx_init() is called. Strangely the build system did seem to
> > > determine whether the same code would either run flawlessly, or crash.
> > >
> > > Please find attached a (sort of) minimal example that reproduces the
> > > error. Below is a log of me compiling the code manually. The only
> > > difference here is that for the first run I did add -O3, for the
> > > second run that option was omitted. Any ideas what's going on here?
> > >
> > > > gentryx@neuromancer ~ $ time (rm -f test_hpx &&
> > /usr/lib64/ccache/bin/g++-4.9.3 -O3
-L/home/gentryx/local_install/lib -
> > lhpx test_hpx.cpp   -o test_hpx -std=c++11 -
> > I/home/gentryx/local_install/include -
> > I/home/gentryx/local_install/include/hpx/external -lboost_chrono -
> > lboost_date_time -lboost_filesystem -lboost_program_options
-lboost_system
> > -lboost_thread -lhpx_init -lhpx -ldl -lrt &&
> > LD_LIBRARY_PATH=/home/gentryx/local_install/lib  &&
> > LD_LIBRARY_PATH=/home/gentryx/local_install/lib  ./test_hpx)
> > > > ok
> > > >
> > > > real0m28.162s
> > > > user0m27.490s
> > > > sys 0m0.630s
> > > >
> > > > 23:43:58 - 0
> > > > gentryx@neuromancer ~ $ time (rm -f test_hpx &&
> > /usr/lib64/ccache/bin/g++-4.9.3-L/home/gentryx/local_install/lib
-lhpx
> > test_hpx.cpp   -o test_hpx -std=c++11 -
> > I/home/gentryx/local_install/include -
> > I/home/gentryx/local_install/include/hpx/external -lboost_chrono -
> > lboost_date_time -lboost_filesystem -lboost_program_options
-lboost_system
> > -lboost_thread -lhpx_init -lhpx -ldl -lrt &&
> > LD_LIBRARY_PATH=/home/gentryx/local_install/lib  &&
> > LD_LIBRARY_PATH=/home/gentryx/local_install/lib  ./test_hpx)
> > > > terminate called after throwing an instance of
> >
'boost::exception_detail::clone_impl > njector >'
> > > >   what():  attempt to insert a GVA with an invalid type,
> > gid({00010001, 0001}), gva(({0001,
> > } component_invalid[-1] 1 0xa41640 0)),
> > locality({0001, }): HPX(bad_parameter)
> > > >
> > > > real0m22.700s
> > > > user0m21.910s
> > > > sys 0m0.740s
> > > >
> > > > 23:44:41 - 134
> > >
> > > Thanks!
> > > -Andreas
> > >
> > >
> > > --
> > > ==
> > > Andreas Schäfer
> > > HPC and Grid Computing
> > > Department of Computer Science 3
> > > Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany
> > > +49 9131 85-27910
> > > PGP/GPG key via keyserver
> > > http://www.libgeodecomp.org
> > > ==
> > >
> > > (\___/)
> > > (+'.'+)
> > > (")_(")
> > > This is Bunny. Copy and paste Bunny into your
> > > signature to help him gain world domination!
> >
> > > #include 
> > > #include 
> > >
> > > #include 
> > > #include 
> > > #include 
> > > #include 
> > >
> > > namespace {
> > > template
> > > class hpx_plugin_exporter_factory;
> > >
> > > template
> > > class init_registry_factory_static;
> > >
> > > template
> > > class hpx_plugin_exporter_registry;
> > >
> > > }
> > >
> > > namespace LibGeoDecomp {
> > >
> > > /**
> > >  * Instantiate this template to ensure the instantiation of an HPX
> > >  * component template is actually registered. See HPXReceiver for an
> > >  * example on how to use this class and its assorted macros.
> > >  */
> > > template
> > > class HPXComponentRegistrator
> > > {
> > > public:
> > > virtual ~HPXComponentRegistrator()
> > > {}
> > >
> > > static
> >
hpx::components::component_factory > NENT> > *instanceA;
> > > static hpx::components::component_registry<
> > hpx::components::simple_component,
> > ::hpx::components::factory_check> *instanceB;
> > >
> > > virtual
> >
hpx::components::component_factory > NENT> > *foo1()
> > > {
> > > instanceA = new
> >
hpx::components::component_factory > NENT> >(0, 0, false);
> > > return instanceA;
> > > }
> > >
> > > virtual hpx::components::component_registry<
> > hpx::components::simple_component,
> > ::hpx::components::factory_check> *foo2()
> > > {
> > >   

Re: [hpx-users] Program failing when not compiling with -O3

[Thomas Heller]

Am 17.11.2015 11:39 nachm. schrieb "Andreas Schäfer" :
>
> On 15:08 Tue 17 Nov , Hartmut Kaiser wrote:
> > Why do you need your own component registry etc.?
>
> I can't use macros because a user would need to instantiate them
> manually. Users forget about that stuff, so we do it for them.

Did you try to explicitly call the macros for the components you use
instead of your auto registration of components?

>
> Cheers
> -Andi
>
>
> --
> ==
> Andreas Schäfer
> HPC and Grid Computing
> Department of Computer Science 3
> Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany
> +49 9131 85-27910
> PGP/GPG key via keyserver
> http://www.libgeodecomp.org
> ==
>
> (\___/)
> (+'.'+)
> (")_(")
> This is Bunny. Copy and paste Bunny into your
> signature to help him gain world domination!
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] use of HDF5 1.8.15-patch1 with HPX

[Thomas Heller]

Hi John,

On 09/22/2015 04:08 PM, John Donners wrote:
> Dear Sir, Madam,
>
> on the page with build prerequisites for HDF5,
>
> http://stellar.cct.lsu.edu/files/hpx-0.9.10/html/hpx/manual/build_system/prerequisites.html
>
> you write that HDF5 on linux needs to be compiled with
>
> export CFLAGS='-DHDatexit=""'
> export CPPFLAGS='-DHDatexit=""'
>
> which is presumably due to issues with parallel HDF5 when exiting the
> application.
> The most recent version of HDF5 (1.8.15-patch1) has some changes that
> seem to
> be related to these issues. At
> http://www.hdfgroup.org/HDF5/doc/ADGuide/Changes.html it says:
>
> *"*
> *For parallel applications*
> A fix for issues encountered upon calling |MPI_Finalize| without having
> closed everything in an HDF5 file
>
> An attribute destroy callback has been attached to |MPI_COMM_SELF|
> that shuts down the HDF5 Library when |MPI_COMM_SELF| is destroyed,
> that is, on |MPI_Finalize|. This should fix several issues that
> users see when they forget to close HDF5 objects before calling
> |MPI_Finalize()|.
> "
>
> Do I still need the special CFLAGS and CPPFLAGS for HDF5 1.8.15-patch1?

We are not using HDF5 inside of HPX at all. There were some older 
examples which used them. Due to that, I can't give you a good advice on 
whether you still need those special flags or not. Do you use HDF5 
yourself inside of one of your applications?

>
> With regards,
> John
>
>
> --
> SURFdrive: de persoonlijke cloudopslagdienst voor het Nederlandse hoger 
> onderwijs en onderzoek.
>
> | John Donners | Senior adviseur | Operations, Support & Development | 
> SURFsara | Science Park 140 | 1098 XG Amsterdam | Nederland |
> T (31)6 19039023 |john.donn...@surfsara.nl  |www.surfsara.nl  |
>
> Aanwezig op | ma | di | wo | do | vr
>
>
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>

___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

[hpx-users] Deprecating compiler toolchains

[Thomas Heller]

Hi all,

I would like to probe users/developers about the possibility to
deprecate compiler toolchains and drop support for those.

The toolchains I have in mind are:
 - GCC 4.6.x
 - Intel Compiler version 13
 - Intel Compilers with GCC 4.4.x as "base"

Rationale: We see more and compile errors only happening on those
toolchains as we continue to evolve our codebase towards more usage of
C++11. The continuous adaption of more and more C++11 is significantly
simplifying and improving our codebase.
Workarounds for those compilers become necessary which are sometimes
very time consuming and may even introduce slower code paths (for
example unique_ptr vs. shared_ptr).

Are there any objections? Does anybody absolutely rely on those toolchains?

Best regards,
Thomas

-- 
Thomas Heller
Friedrich-Alexander-Universität Erlangen-Nürnberg
Department Informatik - Lehrstuhl Rechnerarchitektur
Martensstr. 3
91058 Erlangen
Tel.: 09131/85-27018
Fax:  09131/85-27912
Email: thomas.hel...@cs.fau.de
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Infiniband support

[Thomas Heller]

Hi Helvi,

On 06/30/2015 04:20 PM, Helvi Hartmann wrote:
> Hi,
>
> I checked out the new version of HPX 0.9.11 and when I compile with
> -DHPX_WITH_PARCELPORT_IBVERBS=ON and run a program with:

First of, we haven't released 0.9.11 yet. However, the ibverbs 
parcelport was disabled for 0.9.10 because it was not properly 
maintained and contained some severe bugs. We are working on a new 
version of an infiniband based parcelport which should be ready soon. In 
the mean time, using the MPI based parcelport is your best shot.

Thanks for reporting this issue!

>
>>srun -N2 bin/pingpong--hpx:list-parcel-ports
> --hpx:ini=hpx.parcel.ibverbs.enable=1
>
> ***
> locality: 0
> parcel port: tcp, enabled, bootstrap, priority 1
>
> [hpx_pingpong]
> total_time(secs)=0.902558
> vsize=1048576 = 8388608 Bytes
> bandwidth(MiB/s)=88.637
> localities=1
> numiter=10
> ***
> locality: 1
> parcel port: tcp, enabled, bootstrap, priority 1
>
>
> and still no Infiniband is used. In contrast the old version yield with
> the same input:
>
>
>>srun -N2 bin/pingpong  --hpx:list-parcel-ports 
>>--hpx:ini=hpx.parcel.ibverbs.enable=1
>
> ***
> locality: 0
> parcel port: tcp (available), enabled, bootstrap
> parcel port: ipc (not available)
> parcel port: ibverbs (available), enabled
> parcel port: mpi (not available)
> [hpx_pingpong]
> total_time(secs)=0.239406
> vsize=1048576 = 8388608 Bytes
> bandwidth(MiB/s)=334.16
> localities=1
> numiter=10
> ***
> locality: 1
> parcel port: tcp (available), enabled, bootstrap
> parcel port: ipc (not available)
> parcel port: ibverbs (available), enabled
> parcel port: mpi (not available)
>
> sending via ibverbs.
> Is the new version even supposed to be able to use Infiniband?
>
> Regards
>
> Helvi Hartmann
>
>
>
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>

___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

Re: [hpx-users] Registering multiple gids with same global name

[Thomas Heller]

Hi Konstantin,

On Monday, June 08, 2015 18:35:18 Konstantin Kronfeldner wrote:
> Hello all,
> 
> I've run into some issues with the registration of global ids with global
> names.
> I'm working with the latest hpx trunk.
> 
> I have to create several instances of server component objects, which then
> have to be found by client objects.
> At the time of creation of the server components there are no client
> objects yet, as they are supposed to register while the simulation is
> running.
> In order to find the gids of the server components, I wanted to register
> them under a global base name using hpx::register_id_with_basename(), and
> retrieve them with hpx::find_all_ids_from_basename(). Looking at those
> functions, I thought that multiple ids with the same name should be
> possible. The registration of these gids seems to work fine, as the return
> value is always true.

I think this is a problem in the code. IMHO the registration should fail if 
there is an already registered id with that name. Could you create an issue 
for that please? That means that line 118 and 123 should return false in your 
minimal testcase. Not knowing the total amount of elements in your sequence is 
certainly a problem. I think the best way is, as you already described, is to 
have one "manager" per locality that is able to dispatch to the appropriate 
registered name of your dynamically allocated objects later on.

> 
> But when retrieving those objects, I ran into several problems.
> - I don't know the exact number of server objects that will be created but
> hpx::find_all_ids_from_basename() expects me to know the expected number
> (Though, this might be solvable in another way, as there *should* be as
> many of them as there are localities.)
> - When trying to use f.get() on anything but the first element in the
> vector returned by hpx::find_all_ids_from_basename() the thread doesn't
> return.

>From looking at your minimal testcase, you don't supply a sequence number 
(It's the last argument for register_with_basename: 
https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/hpx_fwd.hpp#L1133).
That means that you more or less overwrite the registration of A with B, and B 
with C. In the end, there is only one component registered. That's the reason 
why you only successfully get the first element.

> 
> I was hoping you could tell me what I'm doing wrong, or if there is a
> better solution to this problem.
> I've attached a minimal example of my code.
> 
> Thank you very much for your help.
> 
> Regards, Konstantin


HTH,
Thomas
___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users