Re: [hpx-users] Memory Usage depends on OS-Threadcount

[Hartmut Kaiser]

Hey,

> in our application, we observe that memory consumption is highly dependent
> on the supplied OS-Threads.
> Two otherwise identical runs of the application with "--hpx:threads 4" and
> "--hpx:threads 8" consume 40GB and above 90GB RAM respectively
> (reproducable on different hardware).
> It could be possible, that the additional threads alter the execution
> order and provoke a race condition that leaks crazy amounts of memory.
> But is there a possible explanation for the memory consumption within HPX
> itself?
>
> Regarding the application:
> We schedule a large number of tasks (approximately 16
> million) that have no dependencies on each other from a simple for loop.
> Some of them might schedule a continuing task when done, resulting in
> approximately 30 million tasks in total.
> Most data should be held on the heap, required stack sizes of tasks should
> not exceed a few hundred bytes. We do not supply a configuration or any
> command line parameters beyond hpx:threads. The application is run on a
> single node, without remote calls of any kind.

This could be explained by the fact, that all cores have their own
thread-local allocators that hold on to allocated stack segments and reuse
those as needed. In general, stack segments are created only if needed, but
will be reused as needed if previous threads have been terminated.

So, if you use one core, then only a few threads are actually run and
allocate stack segments. If you use more cores, then each of those will
allocate stack segments for the threads that have started running...

Given the large number of HPX threads you run, the high memory requirements
make sense to me.

A possible solution for you would be to limit the amount of threads that are
created (thus limit the number of created stack segments). We have several
options to do that:

- using John's limiting_executor, which is a special executor that holds
back scheduling tasks once a given limit is reached and automatically
resumes creating tasks once tasks have run to completion
- using the sliding_semaphore, which is more difficult to explain, but in
essence does a very similar thing (see the 1d_stencil examples to see how it
works)
- come up with your own means to limit the number of tasks to be created
simultaneously

HTH
Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx




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

Re: [hpx-users] STEllAR-GROUP, GSOC2020

[Hartmut Kaiser]

I’m forwarding this to the hpx-us...@stellar-group.org 
  ML for others to chime in for now.

 

Thanks for your interest!

Regards Hartmut

---

  http://stellar.cct.lsu.edu

  https://github.com/STEllAR-GROUP/hpx

 

From: Пилипeць Гліб  
Sent: Sunday, March 1, 2020 4:17 PM
To: hartmut.kai...@gmail.com
Subject: STEllAR-GROUP, GSOC2020

 

Hi, Hartmut

I had written a letter with the same message to Thomas Heller, but he hasn't 
replied yet. 

 

I am considering an opportunity to contribute to the Stellar Group 
"Courutine-like interface" problem within GSOC2020.   

 
https://github.com/STEllAR-GROUP/hpx/wiki/Google-Summer-of-Code-%28GSoC%29-2020#coroutine-like-interface

 

Having examined some other proposed projects, I could notice that you are 
moving the sources up to date with the latest C++ standard. Then why not to use 
C++20 coroutines?

I can see several reasons - indicate if I'm wrong.

1. You want C++20 coroutines in the earlier C++ standard(C++14,17, e.g)

2. You want to make usage of coroutines easier and/or niftier than in C++20. A 
good example can be "yield" in Python.

3. You want to adapt the usage of coroutines for HPX.

4. You don't need the full feature set of C++20 coroutines - rather have a 
generator like functions from Python in C++.

5. Your option.

Please let me know the answer.

 

Here are some more questions.

Should added coroutine functionality be thread-safe or consistent in a 
multi-threaded environment?

Which C++ standard can be used for the implementation?

"demonstrate on at least one example" - does it have to be an example using HPX 
or never mind?
Should the coroutine-like interface be integrated into HPX or provided as a 
separate library?


If there are some other details, not specified in the original proposal, I 
would be glad to know that.

Respectfully,
Hlib Pylypets

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

Re: [hpx-users] GSoC 20 proposal

[Hartmut Kaiser]

Afrin,

 

We’re certainly open for proposals that focus on tasks that are not listed on 
our ideas page. Those are possible ideas after all. 

 

I personally don’t know anything about PMDK. What would you suggest as a 
possible result of integrating it with HPX? What benefits would that give?

 

Thanks!

Regards Hartmut

---

 <http://stellar.cct.lsu.edu> http://stellar.cct.lsu.edu

 <https://github.com/STEllAR-GROUP/hpx> https://github.com/STEllAR-GROUP/hpx

 

From: Afrin Jaman  
Sent: Friday, February 28, 2020 7:35 PM
To: hartmut.kai...@gmail.com
Subject: Re: GSoC 20 proposal

 

Thanks a lot. 

 

On Sat, 29 Feb 2020, 12:07 am Hartmut Kaiser, mailto:hartmut.kai...@gmail.com> > wrote:

I’m forwarding this to hpx-us...@stellar-group.org 
<mailto:hpx-us...@stellar-group.org>  for others to be able to chime in.

 

Regards Hartmut

---

 <http://stellar.cct.lsu.edu> http://stellar.cct.lsu.edu

 <https://github.com/STEllAR-GROUP/hpx> https://github.com/STEllAR-GROUP/hpx

 

From: Afrin Jaman mailto:mailafrinja...@gmail.com> > 
Sent: Wednesday, February 26, 2020 10:18 AM
To: hartmut.kai...@gmail.com <mailto:hartmut.kai...@gmail.com> 
Cc: thom.hel...@gmail.com <mailto:thom.hel...@gmail.com> 
Subject: GSoC 20 proposal

 

Hello respective mentors,


I am Afrin Jaman and I am highly interested to work for HPX. I am a GSoC winner 
2019 and my previous project was on Persistent memory development kit. I am 
willing to propose my idea to HPX. I want to integrate non-volatile programming 
into HPX. PMDK also comes in C++ library, so I guess we can look forward to 
this idea.
As we know HPX is for parallel programming, if we can add non-volatile 
programming support into it then it will be more efficient. Please feel free to 
share your thoughts on this proposal (I really need your opinion).

I don't know where I can find a mentor or support to propose own idea. Will you 
please help me out with this?

Thank you in advance.

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

[hpx-users] Migrating email lists

[Hartmut Kaiser]

All,

In an effort to consolidate the domains used by various means of
communication for HPX, we plan to migrate the existing mailing lists
(hpx-users, hpx-commits, and hpx-devel) to the domain stellar-group.org.

We hope that this will not require any change on your end as the old domains
are kept around for a while (i.e. both, the old and the new domain should
work for the mailing lists for now). In fact, you are receiving this email
through the new domain.

Please start using the new mailing list addresses in any case:

Users list: hpx-us...@stellar-group.org
Developers list: hpx-de...@stellar-group.org
Commits list: hpx-comm...@stellar-group.org

We will update all existing references to the old domains as we go. Please
feel free to point out to us if you come across any of the old addresses
listed in any of the published documents.

Thanks!
Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx




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

Re: [hpx-users] Prospective Student for GSoC 2020 for project in Stellar under your guidance

[Hartmut Kaiser]

Forwarding this to hpx-users@stellar.cct.lsu.edu 
  for others to join the discussion…

 

Regards Hartmut

---

  http://stellar.cct.lsu.edu

  https://github.com/STEllAR-GROUP/hpx

 

From: GANDHI RONNIE  
Sent: Friday, February 21, 2020 2:47 PM
To: hartmutkai...@gmail.com; thom.hel...@gmail.com
Subject: Prospective Student for GSoC 2020 for project in Stellar under your 
guidance

 

Hello Sir,

 

I am Ronnie Gandhi(Krezhairo), a Computer Science Undergraduate from the Indian 
Institute of Technology Roorkee currently enrolled in my pre-final year.

 

I saw your project "Coroutine-Like Interface" in Stellar org under for GSoC 
2020. I am highly interested in working on this project under your supervision. 
I have previously done GSoC2019 last year in CGAL 
  
where I implemented a Demo over boolean operations package using C++ and QT.

 

Besides, I have previously interned at Microsoft Hyderabad as a Data and 
Applied Scientist Intern.

 

I have attached a full detailed resume hereby.

 

I am ready to learn any new thing needed for the project.

 

Regards,

Ronnie

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

Re: [hpx-users] static assertion failed

[Hartmut Kaiser]

> I have issue with serialization of my structure. Structure is following:
>
> struct point {
>float ig;
>std::size_t set;
> };
>
> When I am building my project I get errors typed below. I do not know how
> to fix this.

When compiling with -std=c++17 this should compile without change. For earlier 
versions of the standard, you will have to define a serialization function for 
your type explicitly:

template 
void serialize(Archive& ar, point& pt, unsigned)
{
ar & pt.ig & pt.set;
}

That should do the trick.

HTH
Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx


>
> Best,
>
> Karol
>
> --
> --
>
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/basic_a
> rchive.hpp:66:13:
> required from 'void
> hpx::serialization::basic_archive::invoke(T&) [with T = const
> hpx::util::tuple >
> >; Archive = hpx::serialization::output_archive]'
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/seriali
> ze.hpp:20:9:
> required from 'hpx::serialization::output_archive&
> hpx::serialization::operator<<(hpx::serialization::output_archive&,
> const T&) [with T = hpx::util::tuple std::allocator > >]'
> /home/user/libs/hpx_build_system/include/hpx/runtime/actions/transfer_base
> _action.hpp:306:16:
> required from 'void
> hpx::actions::transfer_base_action::save_base(hpx::serialization::
> output_archive&)
> [with Action = hpx::lcos::base_lco_with_value,
> std::vector,
> hpx::traits::detail::managed_component_tag>::set_value_action]'
> /home/user/libs/hpx_build_system/include/hpx/runtime/actions/transfer_cont
> inuation_action.hpp:211:9:
> required from 'void
> hpx::actions::transfer_continuation_action::save(hpx::serializatio
> n::output_archive&)
> [with Action = hpx::lcos::base_lco_with_value,
> std::vector,
> hpx::traits::detail::managed_component_tag>::set_value_action]'
> /home/user/workspace/Masters/mdfs_hpx/main.cc:200:1:   required from here
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/access.
> hpp:106:9:
> error: static assertion failed: No serialization method found
>   static_assert(dependent_false::value,
>   ^
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/access.
> hpp:
> In instantiation of 'static void
> hpx::serialization::access::serialize_dispatcher::non_intrusive::call(A
> rchive&,
> T&, unsigned int) [with Archive = hpx::serialization::output_archive; T =
> const mdfs::point]':
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/access.
> hpp:224:48:
> required from 'static void
> hpx::serialization::access::serialize(Archive&, T&, unsigned int) [with
> Archive = hpx::serialization::output_archive; T = const mdfs::point]'
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/output_
> archive.hpp:284:30:
> required from 'void
> hpx::serialization::output_archive::save_nonintrusively_polymorphic(const
> T&, std::false_type) [with T = mdfs::point; std::false_type =
> std::integral_constant]'
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/output_
> archive.hpp:260:13:
> required from 'void
> hpx::serialization::output_archive::save_bitwise(const T&,
> std::false_type) [with T = mdfs::point; std::false_type =
> std::integral_constant]'
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/output_
> archive.hpp:224:13:
> required from 'typename std::enable_if<((! std::is_integral<_Tp>::value)
> && (! std::is_enum<_Tp>::value))>::type
> hpx::serialization::output_archive::save(const T&) [with T = mdfs::point;
> typename std::enable_if<((! std::is_integral<_Tp>::value) && (!
> std::is_enum<_Tp>::value))>::type = void]'
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/output_
> archive.hpp:213:13:
> required from 'void
> hpx::serialization::output_archive::invoke_impl(const T&) [with T =
> mdfs::point]'
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/basic_a
> rchive.hpp:66:13:
> [ skipping 33 instantiation contexts, use -ftemplate-backtrace-limit=0 to
> disable ]
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/output_
> archive.hpp:213:13:
> required from 'void
> hpx::serialization::output_archive::invoke_impl(const T&) [with T =
> hpx::util::tuple >
> >]'
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/basic_a
> rchive.hpp:66:13:
> required from 'void
> hpx::serialization::basic_archive::invoke(T&) [with T = const
> hpx::util::tuple >
> >; Archive = hpx::serialization::output_archive]'
> /home/user/libs/hpx_build_system/include/hpx/runtime/serialization/seriali
> ze.hpp:20:9:
> required from 'hpx::serialization::output_archive&
> hpx::serialization::operator<<(hpx::serialization::output_archive&,
> const T&) [with T = hpx::util::tuple std::allocator > >]'
> 

Re: [hpx-users] Request for Experience

[Hartmut Kaiser]

Explicitly cc'ing Thomas and John to raise their awareness of this question.

 

Regards Hartmut

---

  http://stellar.cct.lsu.edu

  https://github.com/STEllAR-GROUP/hpx

 

From: hpx-users-boun...@stellar.cct.lsu.edu
 On Behalf Of Ohlerich, Martin
Sent: Tuesday, December 10, 2019 3:58 AM
To: hpx-users@stellar.cct.lsu.edu
Subject: [hpx-users] Request for Experience

 

Dear Colleagues,

 

my name is Martin Ohlerich. I'm working at the Leibniz Super-Computing
Center near Munich (LRZ), and test currently the capabilities of HPX. On our
Linux cluster with infinitband network, the tests were so far successful. On
SuperMUC-NG, we've an Intel OPA network, which seems to have some
peculiarities (that we also observed when trying to employ GPI (GASPI)). Is
there any experience with such a network type for HPX in the community?

I welcome any hint on where to find about the startup mechanism, and
debugging possibilities. I tried so far the easy approach to install HPX via
Spack. On SNG that might be not the correct way to go.

 

Many thanks in advance! Also in the name of our users!

Best regards,

Martin Ohlerich

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

Re: [hpx-users] HPX 1.4.0 release candidate 2

[Hartmut Kaiser]

Just cc'ing Kevin to make sure this gets the necessary attention...

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 Jong, K. de (Kor)
> Sent: Tuesday, December 10, 2019 4:23 AM
> To: hpx-users@stellar.cct.lsu.edu
> Subject: Re: [hpx-users] HPX 1.4.0 release candidate 2
>
> On 12/6/19 5:28 PM, Simberg Mikael wrote:
> > APEX integration has also
> > been updated and can be enabled with -DHPX_WITH_APEX=ON and
> > -DHPX_WITH_APEX_TAG=develop. The latter option will be unnecessary for
> > the final release.
>
> I am interested in generating traces in OTF2 format to load into Vampir.
> For that I am testing 1.4.0-rc2 with support for APEX and OTF2.
>
> Building HPX with support for APEX works fine, great! I have also built
> OTF2 (version 2.2) and passed in the APEX_WITH_OTF2 flag. I noticed that
> otf2_listener.cpp.o was being built. I have no reason to believe the
> resulting HPX does not have support for APEX+OTF2. Also:
>
> ./fibonacci --hpx:info | grep APEX
>HPX_WITH_APEX=ON
>HPX_WITH_APEX_NO_UPDATE=OFF
>
> When I try this, no trace is printed, though:
>
> APEX_SCREEN_OUTPUT=1 ./fibonacci
>
> When I try this, a trace is printed:
>
> APEX_SCREEN_OUTPUT=1 ./apex_fibonacci
>
> I expected the first command to also print a trace. Is automatic
> instrumentation of HPX with APEX maybe not working yet in 1.4.0-rc2?
>
> Kor
> ___
> 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] PAPI performance counters

[Hartmut Kaiser]

Kor,

 

Somebody mentioned to me today, that she had a similar problem with PAPI
counters when working with an installed version of HPX. It did however work
as expected if HPX was used from its build location. If this is the case it
might just be that the papi_counters shared library doesn't get properly
installed. Could you verify this, please?

 

Regards Hartmut

---

  http://stellar-group.org

 

 

 

From: hpx-users-boun...@stellar.cct.lsu.edu
[mailto:hpx-users-boun...@stellar.cct.lsu.edu] On Behalf Of Biddiscombe,
John A.
Sent: Friday, October 4, 2019 11:07 AM
To: hpx-users@stellar.cct.lsu.edu
Subject: Re: [hpx-users] PAPI performance counters

 

Kor

 

Could you please file an issue in github - I seem to recall I had a look at
this last time we did a tutorial and also noticed a problem with Papi but
forgot all about it. An issue would help us remember to look into it

 

JB

  _  

From: hpx-users-boun...@stellar.cct.lsu.edu

mailto:hpx-users-boun...@stellar.cct.lsu.edu> > on behalf of Jong, K. de
(Kor) mailto:k.dejo...@uu.nl> >
Sent: 04 October 2019 09:13:58
To: hpx-users@stellar.cct.lsu.edu  
Subject: [hpx-users] PAPI performance counters 

 

Hello HPX-ers,

I am looking into the HPX performance counters and have a question about 
the PAPI counters. I built HPX 1.3.0 with HPX_WITH_PAPI=ON and indeed 
the resulting collection of HPX libraries includes 
libhpx_papi_counters.so. According to the documentation:

---
For a full list of available PAPI events and their (short) description 
use the --hpx:list-counters and --papi-event-info=all command line options.
---

The latter option is not recognized though:

my_exe --hpx:list-counters --papi-event-info=all > out
runtime_support::load_components: command line processing: unrecognised 
option '--papi-event-info=all'

Looking at the source code, I think the documentation maybe contains a 
typo. The option should be named --hpx:papi-event-info (?), but this 
results in the same error message.

Can someone point me in the right direction in order to get the PAPI 
counters listed?

Thanks for any info on this.

Kor
___
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::find_locality use

[Hartmut Kaiser]

The use of component_type with find_locality and friends is obsolete and is no 
longer supported. We now assume that all localities support the same set of 
component types.

 

HTH

Regards Hartmut

---

  http://stellar.cct.lsu.edu

  https://github.com/STEllAR-GROUP/hpx

 

From: hpx-users-boun...@stellar.cct.lsu.edu 
 On Behalf Of Gleiry Agustín Serrano Wong
Sent: Thursday, September 5, 2019 1:53 PM
To: hpx-users@stellar.cct.lsu.edu
Subject: Re: [hpx-users] hpx::find_locality use

 

yes I have read the example you pointed to. I understand what you are saying, 
however the type created by HPX_PLAIN_ACTION macro contains a reference to a 
component_type. This suggested to me that HPX_PLAIN_ACTION wraps the supplied 
function and creates a document. Hello_world_distributed shows a similar case, 
however it makes use of std::find_all_localities . What I want is just any 
locality that can run my action. I could use find_all_localities and grab  any  
of the return id's. This is why I thought hpx::find_locality function would be 
a better fit.

 

Thanks.

 

Gleiry Agustin

 

El jue., 5 sept. 2019 a las 13:39, Parsa Amini () escribió:

Hello,

An example code like you described is available in the HPX documentation: 
https://stellar-group.github.io/hpx/docs/sphinx/branches/master/html/manual/creating_hpx_projects.html?highlight=find_here
You can also look at this code in the repository: 
https://github.com/STEllAR-GROUP/hpx/blob/master/examples/quickstart/hello_world_distributed.cpp
hpx::find_locality 

  works on components. You haven't passed a component (or declared a component 
anywhere in your code) to find_locality so it can't work.


- Parsa Amini

 

On Thu, Sep 5, 2019 at 1:17 PM Gleiry Agustín Serrano Wong 
mailto:gaswmskkory...@ciencias.unam.mx> > 
wrote:

All,

 

Basically I am asking for information on how to use hpx::find_locality. I am 
trying to write a simple program that runs an action on a random locality and 
then terminates. This seems to be simple but I am not getting this code to 
work. This is a small program to test what I want:

 

#include 
#include 

void sayhello(){
hpx::cout << "hello\n";
}

HPX_PLAIN_ACTION(sayhello,sayhello_action);

int main(){

hpx::async(hpx::find_locality(sayhello_action::get_component_type()));
return 0;
}

 

The previous code compiles however I get this error:

 

my_hpx_program: /usr/local/include/boost/smart_ptr/intrusive_ptr.hpp:193: T& 
boost::intrusive_ptr::operator*() const [with T = 
hpx::naming::detail::id_type_impl]: Assertion `px != 0' failed.

 

This tells me that maybe I need to register or instantiate a component 
implementing the plain action somewhere. However I cannot find any code, 
documentation or reference to the use of hpx::find_locality .Changing to 
hpx::find_here works normally which makes it more confusing to me.

 

Thanks.

 

Gleiry Agustin

 

___
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] HPX broadcast examples

[Hartmut Kaiser]

Kiril,

I have added a small test that demonstrates the use of broadcast with 
component actions. Please see https://github.com/STEllAR-GROUP/hpx/pull/3930 
for details.

Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx


> -Original Message-
> From: Hartmut Kaiser 
> Sent: Friday, June 14, 2019 7:38 AM
> To: 'hpx-users@stellar.cct.lsu.edu' 
> Cc: 'Kiril Dichev' 
> Subject: RE: [hpx-users] HPX broadcast examples
>
> I will try to come up with an example demonstrating this.
>
> 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 Kiril Dichev
> > Sent: Thursday, June 13, 2019 11:08 AM
> > To: hpx-users@stellar.cct.lsu.edu
> > Subject: [hpx-users] HPX broadcast examples
> >
> > Hi,
> >
> > I've been experimenting with the broadcasts in HPX.
> >
> > According to the comments in hpx/lcos/brodcast.hpp, there are two ways
> > to call a broadcast:
> >
> > The action can be either a plain action (in which case the global
> > identifiers have to refer to localities) or a component action (in
> > which case the global identifiers have to refer to instances of a
> > component type which exposes the action.
> >
> > There are some examples in tests/regressions/lcos/ for plain action
> > broadcasts, in such a fashion:
> > auto f =
> >  hpx::lcos::broadcast(localities,
> > bcast_array);
> >
> >
> > However, I'm failing miserably at constructing an example using a
> > broadcast on a set of component instances exposing an action (instead
> > of plain actions).
> >
> >
> >
> >
> > Any chance someone could provide an example of this?
> >
> >
> > Thanks,
> > Kiril


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

Re: [hpx-users] HPX broadcast examples

[Hartmut Kaiser]

I will try to come up with an example demonstrating this.

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 Kiril Dichev
> Sent: Thursday, June 13, 2019 11:08 AM
> To: hpx-users@stellar.cct.lsu.edu
> Subject: [hpx-users] HPX broadcast examples
>
> Hi,
>
> I've been experimenting with the broadcasts in HPX.
>
> According to the comments in hpx/lcos/brodcast.hpp, there are two ways to
> call a broadcast:
>
> The action can be either a plain action (in which case the global
> identifiers have to refer to localities) or a component action (in which
> case the global identifiers have to refer to instances of a component type
> which exposes the action.
>
> There are some examples in tests/regressions/lcos/ for plain action
> broadcasts, in such a fashion:
> auto f =
>  hpx::lcos::broadcast(localities,
> bcast_array);
>
>
> However, I'm failing miserably at constructing an example using a
> broadcast on a set of component instances exposing an action (instead of
> plain actions).
>
>
>
>
> Any chance someone could provide an example of this?
>
>
> Thanks,
> Kiril


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

Re: [hpx-users] C++20 Modules and HPX library modularization

[Hartmut Kaiser]

Michael,

> Thanks for the quick reply - unfortunately it was deemed spam and since my
> spam folder does not sync on my phone, I didn't see it until I forced an
> update.
>
> I'd certainly be interested and willing to contribute to this effort as
> well as to looking into a possible solution for GPGPUs, although I am
> going to need some guidance and help.
>
> I will respond to each topic in its appropriate thread for continuity.
>
> Given that the modularization of HPX seems to be the key to the successful
> integration of C++ modules, presumably, this should be fairly
> straightforward - the library module boundaries should probably correspond
> to the C++ module boundaries.
>
> Having said that, I will need someone to help me / review with me how to
> map the hpx modules into Modules TD (e.g. "super" - modules which just
> import other modules, which modules might be best broken into submodules,
> etc.)
>
> Is there anyone in the community who might be interested and able to
> provide some guidance?

The modularization effort is spearheaded by the guys at CSCS (Mikhal and 
Auriane, both should be subscribed here). They might be the best to contact in 
order to coordinate things. Alternatively, they normally can be reached 
through our IRC channel.

Thanks!
Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx


>
> Thanks,
> Michael
>
> --
> On May 30, 2019 7:50:57 a.m. "Hartmut Kaiser" 
> wrote:
>
> > Hey Michael,
> >
> >> I am wondering whether there are any plans in the short or mid-term
> >> to provide support in HPX for the new Modules TS which is expected to
> >> be part of C++20?
> >>
> >>
> >> While compile times are not really the main benefit of modules, I
> >> understand that we can expect to see some variable degree of
> >> improvement when using modules as compared to the existing approach.
> >>
> >>
> >> At a very early stage of the Modules TS, I took a quick look through
> >> the HPX codebase to see whether I thought it might be possible at all
> >> to try and add some conditional code to allow for possible modules TS
> >> support and was quickly discouraged.
> >>
> >>
> >> However, it also seems to me that the current modularization
> >> initiative might make it possible to export HPX as modules.
> >>
> >>
> >> Has anyone given this any consideration?
> >> Is this an ultimate goal in anyone's vision?
> >> Would an attempt to incorporate the features of the modules TS be
> >> welcomed by the community? At least, perhaps, as a proof-of-concept?
> >>
> >>
> >> I'd appreciate your thoughts and feedback
> >
> > This topic has not been discussed so far and I personally have not
> > looked much into C++20 modules. However, I believe that the current
> > modularization effort in HPX is most likely to help with introducing
> > C++20 modules. Any help you might want to give would be highly
> appreciated.
> >
> > Thanks!
> > 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] Recommended approach for hetrogenous computing

[Hartmut Kaiser]

Resending my response...

Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx


> -Original Message-
> From: Hartmut Kaiser 
> Sent: Thursday, May 30, 2019 7:03 AM
> To: 'hpx-users@stellar.cct.lsu.edu' 
> Subject: RE: [hpx-users] Recommended approach for hetrogenous computing
>
> Michael,
>
> > I was wondering whether anyone could provide some direction as to the
> > recommended approach to incorporating GPU-based execution within an
> > HPX application, either in general or, preferably if possible, for how
> > I (think I) want to use it-
> >
> > Given a number of host systems (CPU), each possibly containing one or
> > more GPGPUs.  For the sake of simplicity, right now all of my GPUs are
> NVidia.
> >
> > The specific application I'm working on is a distributed optimizer
> > implementing a global search algorithm (right now, I have implemented
> > Differential Evolution).  In its distributed form, it treats each node
> > as a separate island with occasional migration.
> >
> > When run on separate SLURM / HPX (CPU-based) nodes, each node has a
> > set of N trial parameter vectors.  Each node iterates independently.
> > When certain conditions are met, a node can initiate a migration of
> > data from a logically-adjacent node.
> >
> > Given the feature sets of the latest versions of CUDA, I believe that
> > it should be possible for me to treat each GPGPU as a node as well.  I
> > realize it won't be a native node via SLURM (as an Intel Phi node
> > might be), but rather initialized in some other way after the
> > application is initialized across the cluster).
> >
> > I've seen the HPXCL project repo, but it hasn't had any updates in
> > more than 4 months.  I've also seen at one time, though I cannot find
> > right now, scattered bits of code around the internet with a couple
> > different approaches.  Finally, I am under the impression that work is
> > being done on executors to provide this or related functionality.
> >
> > Given, I think, that this should be a reasonably common use-case, it
> > might be helpful if some official tutorials are generated at some
> > point to assist users with this.  In the meanwhile, if anyone (and
> > everyone) can provide some general direction or guidance on this, I
> > would be greatly appreciative.  I would, also, be very willing to try
> > and provide some additional tutorials and user documentation for this
> application.
> >
> > Thank you and I would greatly appreciate any help that you can provide.
>
> We've had several attempts to providing higher level support to integrate
> GPGPUs with HPX. HPXCL is one of those; HPX.Compute is another attempt.
> Neither has resulted in something we're satisfied with. However, we have
> created a couple of lower level facilities that I believe are useful.
>
> The main idea is (as always) to expose operations the CPU schedules on the
> device (data transfer, run a kernel, etc.) through API function that
> return an hpx::future. That allows for nicely hiding latencies and
> communication overheads. This also allows integrating the GPU work into
> the overall asynchronous execution flow on the CPU.
>
> HPX.Compute has also introduced the concept of 'targets' (i.e. places in
> the system) that can be used to create a) allocators, and b) executors.
> This is important to be able to control data and execution placement from
> user land while still using system facilities like parallel algorithms,
> etc.
>
> HPXCL has solved the problem of remote GPU access by encapsulating a
> device in a HPX component, that allows to submitting data and kernels for
> execution to a remote device.
>
> There is essentially no documentation of any of the above. As I said, we
> were not satisfied with the overall design or implementation, so we
> decided not to spend time on describing things.
>
> As always, any help you might be willing to give would be highly
> appreciated.
>
> Thanks!
> 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

Re: [hpx-users] TAU support v1.3.0

[Hartmut Kaiser]

Hey,

 

I’m cc’ing Kevin Huck on this email. He will be able to help.

 

Regards Hartmut

---

  http://stellar.cct.lsu.edu

  https://github.com/STEllAR-GROUP/hpx

 

From: hpx-users-boun...@stellar.cct.lsu.edu 
 On Behalf Of kniedzie
Sent: Thursday, May 30, 2019 5:07 AM
To: hpx-users@stellar.cct.lsu.edu
Subject: [hpx-users] TAU support v1.3.0

 

Hi all,

I am trying to use HPX v1.3.0 with TAU. I am following instructions from 
https://khuck.github.io/xpress-apex/usage/#hpx-louisiana-state-university and I 
am trying to integrate it using command:

cmake -DBOOST_ROOT=$HOME/libs/boost_1_62_0 \
 -DCMAKE_INSTALL_PREFIX=$HOME/libs/hpx_1.3.0_build_system_apex \
 -DCMAKE_BUILD_TYPE=RelWithDebInfo \
 -DHPX_WITH_MORE_THAN_64_THREADS=ON \
 -DHPX_WITH_MAX_CPU_COUNT=26400 \
 -DCMAKE_C_COMPILER=cc \
 -DCMAKE_CXX_COMPILER=CC \
 -DCMAKE_C_FLAGS="-latomic" \
 -DCMAKE_CXX_FLAGS="-latomic" \
 -DHPX_WITH_EXAMPLES=OFF \
 -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_APEX=TRUE \
 -DHPX_WITH_TAU=TRUE \
 -DAPEX_WITH_ACTIVEHARMONY=TRUE \
 -DAPEX_WITH_PAPI=FALSE \
 -DAPEX_WITH_MSR=FALSE \
 -DAPEX_WITH_OTF2=FALSE \
 -DACTIVEHARMONY_ROOT=$HOME/packages/harmony/ \
 -DTAU_ROOT=$HOME/libs/tau-2.26 \
 -DTAU_ARCH=x86_64 \
 -DTAU_OPTIONS=-mpi-pthread \
 $HOME/packages/hpx

I receive:

CMake Warning:
  Manually-specified variables were not used by the project:

HPX_WITH_STATIC_EXE_LINKING
TAU_ARCH
TAU_OPTIONS
TAU_ROOT
HPX_WITH_TAU

 

I checked CMakeLists.txt and there are not variables for TAU support.

So my questions are:

Does hpx still support tau?

If yes, how can I integrate it?

If no, are there any alternatives?

Best,

Karol Niedzielewski

Interdyscyplinarne Centrum Modelowania Matematycznego i Komputerowego (ICM), 
Uniwersytet Warszawski // 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] Performance evaluation software

[Hartmut Kaiser]

> On 5/13/19 1:41 PM, ??? wrote:
> > For shared-memory systems, uftrace [1] works great.
> >
> > It gives you great visualization with not too much performance impact.
>
> I tried running uftrace on exes using HPX and it consistently crashes, on
> both my exes and HPX examples:
>
> $ uftrace record fibonacci_local
> {stack-trace}: child terminated by signal: 11: Segmentation fault
>
> A trace is made, but a lot of information seems to be missing. Just to be
> sure: have you used uftrace successfully in combination with applications
> using HPX?
>
> BTW, using uftrace with non-HPX applications works fine.

Uftrace (like other tools) might become confused by HPXs stack-switching. But 
I'm just guessing here...

As an alternative, enable APEX when compiling HPX (HPX_WITH_APEX=On). APEX can 
give you traces as well. I'm cc'ing Kevin Huck, he should be able to give you 
more details on APEX and how to use it.

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

Re: [hpx-users] Asking help for understanding how to parallelize simple tasks with HPX

[Hartmut Kaiser]

Marco,

You might want to look at David Pfander's code demonstrating how to 
parallelize matrix multiplication using HPX efficiently here: 
https://github.com/DavidPfander-UniStuttgart/MatrixMultiplicationHPX.

HTH
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 Marco Ippolito
> Sent: Friday, April 5, 2019 12:00 PM
> To: hpx-users@stellar.cct.lsu.edu
> Subject: [hpx-users] Asking help for understanding how to parallelize
> simple tasks with HPX
>
> Hi all,
> I'm trying to understand how to parallelize with HPX for the first time
> simple tasks, but I do actually do not know how to proceed in a correct
> way. So I ask you an help.
>
> In MatricesMultiplicationSerial.txt you find the matrices multiplication
> function in serial mode:
> the two matrices are split in "blocks", which are smaller matrices.
> The corresponding smaller matrices are multiplied in serial (no
> parallelization), and then the single results are put into a vector, and
> composed, trhough the function  "totalSumElemWise2D" in the bigger matrix.
>
> In MatricesMultiplicationAsyncParallel.txt I tried to asynchronously
> parallelize the single small matrices multiplications, and then compose
> the results into the bigger matrix.
>
> Did I lay out the parallelization in a correct way? For example, I'm not
> so sure that unwrapping is necessary and also correctly used.
> How to gather all the smaller matrices multiplications into a results
> vector and then use the gathering  function "totalSumElemWise2D" to
> combine the results into the bigger matrix?
>
> Looking forward to your kind help.
> Marco


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

Re: [hpx-users] HPX Profiling (TAU?)

[Hartmut Kaiser]

Kilian,

I am cc'ing Kevin Huck to make sure he sees this. He is Mr. APEX and will be
able to give you all the information you need.

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 Kilian Werner
> Sent: Tuesday, February 26, 2019 3:03 AM
> To: hpx-users@stellar.cct.lsu.edu
> Subject: [hpx-users] HPX Profiling (TAU?)
>
> Dear list!
>
> I am trying to optimize my HPX project and was looking for a way to
> observe per-thread traces of the execution (in a vampir trace like
> fashion).
>
> I am already successfully utilizing APEX Support, however to my
> understanding this only yields total times/percentages.
>
> I did find references to HPX supporting TAU through APEX, however the
> HPX_WITH_TAU flag was removed in
> https://github.com/STEllAR-GROUP/hpx/pull/2380
>
> Was TAU support dropped or did the process of building hpx with tau
> change? If so, how would I go about building it.
>
> If it was dropped are there any other ways to trace HPX in a vampir trace
> / gantt-chart like fashion?
>
> Best 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] Who are the leadership of the very good HPX project? SUBSCRIBE grant.stellar AAAATTTT emailmeinfo.com

[Hartmut Kaiser]

Done.

 

Regards Hartmut

---

  http://stellar.cct.lsu.edu

  https://github.com/STEllAR-GROUP/hpx

 

From: hpx-users-boun...@stellar.cct.lsu.edu 
 On Behalf Of Grant Rostig
Sent: Saturday, February 9, 2019 1:02 PM
To: hpx-users@stellar.cct.lsu.edu
Subject: [hpx-users] Who are the leadership of the very good HPX project? 
SUBSCRIBE grant.stellar  emailmeinfo.com

 

Hi All,

 

I'm on IRC and Slack, but I think the mailing list is probably the best way to 
do serious threaded archivable communications.  Please SUBSCRIBE me at the 
address that this email was sent by, or better yet at: grant.stellar  
emailmeinfo.com   .

 

To add some real content to this message and because I really want to know, can 
someone describe the current top leadership team, or how the project is 
organized and directed?

 

HPX presents very important ideas and I look forward to their adoption by 
standard C++, which will further secure and increase c++'s role in the future. 
:)  So thanks everyone for the excellent work to far!

 

++Regards,

Grant Rostig,

Austin, TX

 

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

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

[Hartmut Kaiser]

Yongkee,

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

HPX can do both, stack-full and stack-less coroutines. The main HPX scheduler 
relies on stack-full coroutine, those however are not directly visible to the 
user. Those are disguised as HPX threads.

You can build stackl-ess coroutines in your code on top of that regardless.

We have tried to adapt co_await to our stack-full coroutines.

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

Ok, thanks for letting us know. The co_await support in HPX is experimental at 
best and was tested (if at all) with MSVC only. And, it was a while back, so 
the spec might have changed and our implementation is not correct for 
compilers today anymore. What compiler do you use?

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

As said, HPX does not directly expose coroutines, it uses a (stackfull) 
coroutine-like mechanism for scheduling its lightweight threads. Everything in 
HPX relies on essentially two scheduling functions:

Fire: create a new thread and continue:

  hpx::apply([exec, ]f, args...);

Create a new thread getting future back for extracting the result:

  hpx::future f = hpx::async([exec, ], f, args...);
  // ...
  T result = f.get();

Our co_await implementation wraps our hpx::future's

  hpx::future f = hpx::async([exec, ], f, args...);
  // ...
  T result = co_await(f);

Active messages enter the picture if either the apply or the async above 
target a remote object.

HTH
Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx


>
> Thanks,
> Yongkee
>
> On Mon, Jan 28, 2019 at 12:26 AM Thomas Heller
> <mailto:thom.hel...@gmail.com> 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
> <mailto:hartmut.kai...@gmail.com> 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
> >

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

[Hartmut Kaiser]

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

Re: [hpx-users] For GSOC 2019

[Hartmut Kaiser]

Hi,

 

I’m forwarding this to our mailing list for others to be able to chime in.

 

Thanks!

Regards Hartmut

---

https://stellar-group.org

 

 

 

From: Tech Trend [mailto:shubhu7...@gmail.com] 
Sent: Tuesday, December 11, 2018 11:54 AM
To: hkai...@cct.lsu.edu
Subject: For GSOC 2019

 

Hello ,

Dear sir,

I am from India and I am a sophomore year undergraduate student in computer 
science major and I know c,c++,STL technologies and DSA and algorithm and I 
want to participate in gsoc 2019 .so how we start to working or contributing on 
projects.

Please help me for this sir .

Thankyou

___
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

[Hartmut Kaiser]

Jayesh,

 

I do think more than one person could work on this project. There is enough
coding to do for two for sure. I even think that it might be useful for both
of you if you got in contact and worked together. There is also always the
IRC or this mailing list to discuss solutions and attempt to answer
questions.

 

Regards Hartmut

---

  http://stellar.cct.lsu.edu

  https://github.com/STEllAR-GROUP/hpx

 

From: Jayesh Badwaik  
Sent: Saturday, October 27, 2018 5:09 AM
To: hartmut.kai...@gmail.com; hpx-users@stellar.cct.lsu.edu
Subject: Re: [hpx-users] Contributing to HPX

 

Dear Harmut, 

I find this of interest to me as well. But I am still a rookie at HPX so I
am 
not sure if this I am equipped to handle it. But I can try and I was
wondering 
if you think there is space for two people in this project or will I be 
stepping/intruding on Ahmed's space. 

I have literally butted in the conversation, so I would be okay if the
answer 
is a hard no. :-) 

If instead, the answer is yes, I would start reading the paper and see what
I 
can do about it. 

Thanks 

-- 
Cheers 
Jayesh Badwaik 
https://jayeshbadwaik.github.io 

___
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

[Hartmut Kaiser]

> On Wed, Oct 24, 2018 at 10:14 PM Biddiscombe, John A.
> <mailto:biddi...@cscs.ch> 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

I'd second this suggestion. This would also align with the hwloc idea 
mentioned before.

Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx


>
>
> * 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: mailto:hpx-users-boun...@stellar.cct.lsu.edu [mailto:hpx-users-
> boun...@stellar.cct.lsu.edu] on behalf of Ahmed Ali
> [mailto:ahmed.al...@eng-st.cu.edu.eg]
> Sent: 24 October 2018 14:12
> To: mailto:hartmut.kai...@gmail.com
> Cc: mailto: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
> <mailto:hartmut.kai...@gmail.com> 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: mailto:hpx-users-boun...@stellar.cct.lsu.edu <mailto:hpx-users-
> boun...@stellar.cct.lsu.edu> On Behalf Of Biddiscombe, John A.
> Sent: Tuesday, October 23, 2018 3:43 AM
> To: mailto: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 

Re: [hpx-users] Contributing to HPX

[Hartmut Kaiser]

 

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 
 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 real advantage to this is that you can USE hpx to work on 
a project without having to understand all of hpx under the hood - then when 
you find that a feature you need in hpx doesn’t exist, then you atsrt poking 
around to find a way of implementing it or adding support.

 

One thing that is catching my eye at the moment is our interface between hwloc 
(https://www.open-mpi.org/projects/hwloc/) and hpx::topology classes. the code 
in there is not very well maintained and could do with a thorough cleaning up. 
I’d like to be able to create a topology object from hwloc and query not just 
numa domains (which we have implemented in the resource partitioner), but also 
PCI bus connections to GPUs and network cards. If I have a 2 socket machine and 
only 1 gpu - which socket is closest to the gpu etc. That hasn’t been 
implemented and it would be very useful.

 

Hartmut, Thomas Do you have anything in mind that Ahmed could work on?

 

JB

 

 

 

___
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

[Hartmut Kaiser]

> On Tue, Aug 14, 2018 at 08:58:59PM +0530, Nikunj Gupta wrote:
> > Could you please share the error log with us. I will be able to handle
> > the situation better. Also, on which platform are you on? (My
> > implementation works for Linux and Mac OSX only)
>
> How about defining HPX_NG_CUNNING_RUNTIME to defined(__linux__)... &&
> defined(__APPLE__) or whatever, and using that pin point the wrapping?
> (Makes it easier to understand what they are for...)

Yes, that's definitely something to consider doing.

Thanks!
Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx


>
> Somehow I managed to mangle my git in the meantime:
>
> Your branch and 'origin/master' have diverged, and have 17 and 13
> different commits each, respectively.
>
> when trying to rebase against Stellar - strange as I only have 9
> patches...
> - so I'm temporarily out of action..
>
> Cheers,
>
> Patrick


___
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

[Hartmut Kaiser]

FWIW, libhpx_wrap is tied into the build here:
https://github.com/STEllAR-GROUP/hpx/blob/master/cmake/HPX_SetupTarget.cmake
#L191-L198

HTH
Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx


> -Original Message-
> From: 'Patrick Welche' 
> Sent: Tuesday, August 14, 2018 4:09 AM
> To: Hartmut Kaiser 
> Cc: hpx-users@stellar.cct.lsu.edu
> Subject: Re: [hpx-users] list of OS names
>
> On Mon, Aug 13, 2018 at 02:18:41PM -0500, Hartmut Kaiser wrote:
> > > Thanks I searched for ldl and libdl... This gets me further:
> > >
> > > diff --git a/CMakeLists.txt b/CMakeLists.txt index
> > > c780ea50ef..69e8261dce
> > > 100644
> > > --- a/CMakeLists.txt
> > > +++ b/CMakeLists.txt
> > > @@ -1227,9 +1227,15 @@ if(NOT WIN32)
> > >  endif()
> > >endif()
> > >
> > > -  if(NOT ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
> > > -hpx_libraries(dl)
> > > -  endif()
> > > +  # XXXPW if(NOT ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
> > > +find_library(DL_LIBRARY NAMES dl)
> > > +if(DL_LIBRARY)
> > > +  message(STATUS "dl library found")
> > > +  hpx_libraries(dl)
> > > +else()
> > > +  message(STATUS "dl library not found")
> > > +endif()
> > > +  # XXXPW endif()
> > >
> > >if(NOT APPLE AND NOT ("${HPX_PLATFORM_UC}" STREQUAL "ANDROID"))
> > >  hpx_libraries(rt)
> > >
> > >
> > > but there are lots of ways of skinning that cat - have you a
> > > preferred way of doing AC_CHECK_LIB([dl],[dlopen]) ?
> > >
> > > (On linking I get:
> >
> > How about doing something like this:
> > https://github.com/Fadis/libdcompile/blob/master/CMakeFiles/modules/Fi
> > ndLibD
> > L.cmake
>
> It think that that assumes that you need an extra library to go with the
> include file, which isn't the case. According to hpx/util/plugin/dll.hpp,
> we assume that everyone not on windows has the include file. I think the
> find_library() is good enough, but could be convinced about a
> CHECK_LIBRARY_EXISTS().
>
> > >
> CMakeFiles/hpx.dir/runtime/threads/executors/this_thread_executors.cpp.o:
> > > In function
> > > `hpx::threads::coroutines::detail::context_base::~context_base()':
> > > this_thread_executors.cpp:(.text._ZN3hpx7threads10coroutines6detail1
> > > 2conte
> > >
> xt_baseD2Ev[_ZN3hpx7threads10coroutines6detail12context_baseD5Ev]+0x41):
> > > undefined reference to
> > > `hpx::threads::coroutines::detail::posix::use_guard_pages'
> > > )
> >
> > This is unrelated. The variable is defined here:
> > https://github.com/STEllAR-GROUP/hpx/blob/master/src/util/runtime_conf
> > igurat
> > ion.cpp#L71-L83.
>
> Thanks - I did the awful "add OS" there to carry on - really need to think
> about what we are actually testing for...
>
> Possibly related, I now get
>
> ld: cannot find -lhpx_wrap
>
> Is that also the GSoC runtime project?
>
>
> cheers,
>
> Patrick


___
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

[Hartmut Kaiser]

> On Mon, Aug 13, 2018 at 02:18:41PM -0500, Hartmut Kaiser wrote:
> > > Thanks I searched for ldl and libdl... This gets me further:
> > >
> > > diff --git a/CMakeLists.txt b/CMakeLists.txt index
> > > c780ea50ef..69e8261dce
> > > 100644
> > > --- a/CMakeLists.txt
> > > +++ b/CMakeLists.txt
> > > @@ -1227,9 +1227,15 @@ if(NOT WIN32)
> > >  endif()
> > >endif()
> > >
> > > -  if(NOT ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
> > > -hpx_libraries(dl)
> > > -  endif()
> > > +  # XXXPW if(NOT ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
> > > +find_library(DL_LIBRARY NAMES dl)
> > > +if(DL_LIBRARY)
> > > +  message(STATUS "dl library found")
> > > +  hpx_libraries(dl)
> > > +else()
> > > +  message(STATUS "dl library not found")
> > > +endif()
> > > +  # XXXPW endif()
> > >
> > >if(NOT APPLE AND NOT ("${HPX_PLATFORM_UC}" STREQUAL "ANDROID"))
> > >  hpx_libraries(rt)
> > >
> > >
> > > but there are lots of ways of skinning that cat - have you a
> > > preferred way of doing AC_CHECK_LIB([dl],[dlopen]) ?
> > >
> > > (On linking I get:
> >
> > How about doing something like this:
> > https://github.com/Fadis/libdcompile/blob/master/CMakeFiles/modules/Fi
> > ndLibD
> > L.cmake
>
> It think that that assumes that you need an extra library to go with the
> include file, which isn't the case. According to hpx/util/plugin/dll.hpp,
> we assume that everyone not on windows has the include file. I think the
> find_library() is good enough, but could be convinced about a
> CHECK_LIBRARY_EXISTS().
>
> > >
> CMakeFiles/hpx.dir/runtime/threads/executors/this_thread_executors.cpp.o:
> > > In function
> > > `hpx::threads::coroutines::detail::context_base::~context_base()':
> > > this_thread_executors.cpp:(.text._ZN3hpx7threads10coroutines6detail1
> > > 2conte
> > >
> xt_baseD2Ev[_ZN3hpx7threads10coroutines6detail12context_baseD5Ev]+0x41):
> > > undefined reference to
> > > `hpx::threads::coroutines::detail::posix::use_guard_pages'
> > > )
> >
> > This is unrelated. The variable is defined here:
> > https://github.com/STEllAR-GROUP/hpx/blob/master/src/util/runtime_conf
> > igurat
> > ion.cpp#L71-L83.
>
> Thanks - I did the awful "add OS" there to carry on - really need to think
> about what we are actually testing for...
>
> Possibly related, I now get
>
> ld: cannot find -lhpx_wrap
>
> Is that also the GSoC runtime project?

Yes. I have cc'ed the student to be in the loop.

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

Re: [hpx-users] list of OS names

[Hartmut Kaiser]

> > > 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.)
> >
> > libdl is handled here:
> > https://github.com/STEllAR-GROUP/hpx/blob/master/CMakeLists.txt#L1230-
> > L1232
>
> Thanks I searched for ldl and libdl... This gets me further:
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt index c780ea50ef..69e8261dce
> 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -1227,9 +1227,15 @@ if(NOT WIN32)
>  endif()
>endif()
>
> -  if(NOT ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
> -hpx_libraries(dl)
> -  endif()
> +  # XXXPW if(NOT ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
> +find_library(DL_LIBRARY NAMES dl)
> +if(DL_LIBRARY)
> +  message(STATUS "dl library found")
> +  hpx_libraries(dl)
> +else()
> +  message(STATUS "dl library not found")
> +endif()
> +  # XXXPW endif()
>
>if(NOT APPLE AND NOT ("${HPX_PLATFORM_UC}" STREQUAL "ANDROID"))
>  hpx_libraries(rt)
>
>
> but there are lots of ways of skinning that cat - have you a preferred way
> of doing AC_CHECK_LIB([dl],[dlopen]) ?
>
> (On linking I get:

How about doing something like this:
https://github.com/Fadis/libdcompile/blob/master/CMakeFiles/modules/FindLibD
L.cmake

>
> CMakeFiles/hpx.dir/runtime/threads/executors/this_thread_executors.cpp.o:
> In function
> `hpx::threads::coroutines::detail::context_base::~context_base()':
> this_thread_executors.cpp:(.text._ZN3hpx7threads10coroutines6detail12conte
> xt_baseD2Ev[_ZN3hpx7threads10coroutines6detail12context_baseD5Ev]+0x41):
> undefined reference to
> `hpx::threads::coroutines::detail::posix::use_guard_pages'
> )

This is unrelated. The variable is defined here:
https://github.com/STEllAR-GROUP/hpx/blob/master/src/util/runtime_configurat
ion.cpp#L71-L83.

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

Re: [hpx-users] list of OS names

[Hartmut Kaiser]

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

libdl is handled here:
https://github.com/STEllAR-GROUP/hpx/blob/master/CMakeLists.txt#L1230-L1232

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

Re: [hpx-users] list of OS names

[Hartmut Kaiser]

FWIW, I have merged #3402 just now.

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 Lars Viklund
> Sent: Monday, August 13, 2018 7:35 AM
> To: hpx-users@stellar.cct.lsu.edu
> Subject: Re: [hpx-users] list of OS names
>
> On Mon, Aug 13, 2018 at 01:22:38PM +0100, Patrick Welche wrote:
> > On Mon, Aug 13, 2018 at 01:19:42PM +0100, Patrick Welche wrote:
> > > Chugging along trying to get hpx to compile, I thought I would try
> > > the
> > > 1.1.0 patches I had so far on master. I just got an extra compile
> error:
> > >
> > > /usr/src/local/hpx/src/hpx_init.cpp: In function â?~int
> hpx::detail::run_or_start(hpx::util::function_nonser tions::variables_map&)>&, const
> boost::program_options::options_description&, int, char**,
> std::vector >&&, hpx::startup_function_type,
> hpx::shutdown_function_type, hpx::runtime_mode, bool)â?T:
> > > /usr/src/local/hpx/src/hpx_init.cpp:603:24: error: â?~hpx_startâ?T has
> not been declared
> > >  if(hpx_start::include_libhpx_wrap)
>
> The functionality in question is part of one of our GSoC student's work on
> introducing HPX even earlier in the startup process via loader tricks,
> currently only on a few OSes like GNU/Linux and macOS.
>
> There is a missing guard in this source file and it should be resolved by
> the fix in PR#3402.
>
> https://github.com/STEllAR-GROUP/hpx/pull/3402
>
> Everything else about this feature should be inert on the OSes the feature
> doesn't apply to.
>
> --
> Lars Viklund | z...@acc.umu.se
> ___
> 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] [STE||AR Gsoc] GSoC 2nd evaluation summary

[Hartmut Kaiser]

> I have to add that we told Jakub to first have a proof of concept of the
> integration of HPX. And he should not focus too much on optimization in
> the first phase. I assume we have to play around with execution policy and
> chunk size as for BLAZE to get better performance. First, HPX was much
> slower as openmp with default settings and after adjusting it was
> comparable to openmp.

Sure, no worries.

Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx


>
>
> On Sat, Jul 7, 2018, 12:12 PM Jakub Golinowski
> <mailto:jakub.golinow...@gmail.com> wrote:
> Dear Hartmut,
>
> I did not look thoroughly into the tbb and openmp implementations and
> therefore do not have a satisfying understanding why HPX is slower than
> tbb and openmp in my benchmark.
> I can look into that and get back to you.
>
> Also, if you recall any materials or existing benchmarks that may be
> useful for me in this matter please let me know.
>
> Best regards,
>
> Jakub Golinowski
>
> 2018-07-07 16:41 GMT+01:00 Hartmut Kaiser
> <mailto:hartmut.kai...@gmail.com>:
> Jakub,
>
> Thanks for your work on this!
> Do you have an understanding why HPX is slower than tbb and/or openmp yet?
>
> Regards Hartmut
> ---
> http://stellar.cct.lsu.edu
> https://github.com/STEllAR-GROUP/hpx
>
>
> > -Original Message-
> > From: mailto:gsoc-boun...@stellar-group.org <mailto:gsoc-
> boun...@stellar-group.org> On
> > Behalf Of Jakub Golinowski
> > Sent: Saturday, July 7, 2018 9:57 AM
> > To: mailto:g...@stellar-group.org; mailto:hpx-users@stellar.cct.lsu.edu
> > Subject: [STE||AR Gsoc] GSoC 2nd evaluation summary
> >
> > Hello,
> >
> > in this e-mail I am enclosing the link to the google docs with the short
> > summary of the progress I have made over the period of 2 moths of Google
> > Summer of Code.
> >
> > https://docs.google.com/document/d/1gAMrg9Zt0-
> > s8QqGgZkEoF2CkdpulbYGP40JcJVfPpoc/edit?usp=sharing
> >
> > Best regards,
> >
> > Jakub Golinowski
>
>
> ___
> gsoc mailing list
> mailto:g...@stellar-group.org
> https://mail.cct.lsu.edu/mailman/listinfo/gsoc


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

Re: [hpx-users] [STE||AR Gsoc] GSoC 2nd evaluation summary

[Hartmut Kaiser]

Jakub,

Thanks for your work on this!
Do you have an understanding why HPX is slower than tbb and/or openmp yet?

Regards Hartmut
---
http://stellar.cct.lsu.edu
https://github.com/STEllAR-GROUP/hpx


> -Original Message-
> From: gsoc-boun...@stellar-group.org  On
> Behalf Of Jakub Golinowski
> Sent: Saturday, July 7, 2018 9:57 AM
> To: g...@stellar-group.org; hpx-users@stellar.cct.lsu.edu
> Subject: [STE||AR Gsoc] GSoC 2nd evaluation summary
>
> Hello,
>
> in this e-mail I am enclosing the link to the google docs with the short
> summary of the progress I have made over the period of 2 moths of Google
> Summer of Code.
>
> https://docs.google.com/document/d/1gAMrg9Zt0-
> s8QqGgZkEoF2CkdpulbYGP40JcJVfPpoc/edit?usp=sharing
>
> Best regards,
>
> Jakub Golinowski


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

Re: [hpx-users] Unable to connect to rostam

[Hartmut Kaiser]

We've had a power outage at LSU today. We'll make the cluster available
again asap.

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 Gabriel Laberge
> Sent: Friday, June 15, 2018 5:31 PM
> To: hpx-users@stellar.cct.lsu.edu
> Subject: [hpx-users] Unable to connect to rostam
>
> Hi
> today I was working on the rostam clusters but suddenly I was unable to
> connect. I've not been able to connect since then. I'm not sure of what
> could cause such a problem.
>
> 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] HPX Citations

[Hartmut Kaiser]

> These have been updated!

Thanks Adrian! Here is another one: http://cppcast.com/2018/04/news-episode/

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


> Adrian
> 
> On 4/5/2018 9:43 AM, Patrick Diehl wrote:
> We may could add my interview and the interview from Marcin as well.
> 
> On 2018-04-04 10:34 PM, Hartmut Kaiser wrote:
> Yah, and that one ;)
> 
> https://twitter.com/MalwareMinigun/status/880299153493970945
> 
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> -Original Message-
> From: Hartmut Kaiser [mailto:hartmut.kai...@gmail.com]
> Sent: Wednesday, April 4, 2018 9:33 PM
> To: 'hpx-users@stellar.cct.lsu.edu' <hpx-users@stellar.cct.lsu.edu>
> Subject: RE: [hpx-users] HPX Citations
> 
> Adrian,
> 
> Thanks for starting this effort. Please also find a couple of links to add
> to these pages:
> 
> - https://cukic.co/2018/03/29/cxx17-and-parallel-algorithms-in-stl/
> (quote: "The HPX library seems to be significantly faster on my system
> (not Intel-based) with GCC than Intel’s PSTL, but your mileage might
> vary.")
> - http://ithare.com/using-parallel-algorithm-without-a-clue-90x-
> performance-loss-instead-of-8x-gain/
> - https://www.bfilipek.com/2017/08/cpp17-details-parallel.html
> - http://www.modernescpp.com/index.php/c-17-new-algorithm-of-the-standard-
> template-library
> - https://www.heise.de/developer/meldung/Parallelisierung-HPX-erreicht-
> erstes-Major-Release-3693058.html
> 
> 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 Adrian Serio
> Sent: Wednesday, April 4, 2018 2:31 PM
> To: hpx-users@stellar.cct.lsu.edu
> Subject: [hpx-users] HPX Citations
> 
> HPX Team,
> In response to the suggestion that we should aggregate publications
> which
> mention HPX, I have created new pages on the stellar-group.org and
> stellar.cct.lsu.edu web sites titled "Citations". Whenever you come
> across
> a new article, publication or social media post which mentions the
> STE||AR
> Group or our work please let us know so we can upload a citation.
> Web Pages:
> • http://stellar-group.org/citations/
> • http://stellar.cct.lsu.edu/citations/
> Thanks for your help!
> --
> Adrian Serio
> Scientific Program Coordinator
> 2118 Digital Media Center
> 225.578.8506
> 
> ___
> 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
> 
> 
> --
> Adrian Serio
> Scientific Program Coordinator
> 2118 Digital Media Center
> 225.578.8506

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

Re: [hpx-users] CUDA with HPX

[Hartmut Kaiser]

> > so specifying the architecture worked, but now a different
> > problem occurs.
> >
> >
> > /usr/local/include/hpx/util/optional.hpp(244): error:
> > statement may not appear in a constexpr function
> >
> > /usr/local/include/hpx/util/optional.hpp(246): error: a
> > constexpr function must contain exactly one return
> > statement
> >
> > 2 errors detected in the compilation of
> > "/tmp/tmpxft_2044_-4_data_copy.cpp4.ii".
> > CMake Error at
> > cuda_copy_exe_generated_data_copy.cu.o.cmake:279
> > (message):
> >Error generating file
> >
> >
> /home/kostov/Projects/Tests/data_copy/build/CMakeFiles/cuda_copy_exe.dir//
> > ./cuda_copy_exe_generated_data_copy.cu.o
> >
> >
> > Any idea what could be causing this?
> 
> This is another example of how broken the CUDA compiler is. Could you
> create a ticket for this please? We need to fix this in optional.hpp.
> As a workaround please replace constexpr on the function it complains
> about with HPX_CXX14_CONSTEXPR (or remove the 'constexpr' altogether).

Please see https://github.com/STEllAR-GROUP/hpx/pull/3268 for a possible
fix.

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

Re: [hpx-users] CUDA with HPX

[Hartmut Kaiser]

> so specifying the architecture worked, but now a different
> problem occurs.
> 
> 
> /usr/local/include/hpx/util/optional.hpp(244): error:
> statement may not appear in a constexpr function
> 
> /usr/local/include/hpx/util/optional.hpp(246): error: a
> constexpr function must contain exactly one return
> statement
> 
> 2 errors detected in the compilation of
> "/tmp/tmpxft_2044_-4_data_copy.cpp4.ii".
> CMake Error at
> cuda_copy_exe_generated_data_copy.cu.o.cmake:279
> (message):
>Error generating file
> 
> /home/kostov/Projects/Tests/data_copy/build/CMakeFiles/cuda_copy_exe.dir//
> ./cuda_copy_exe_generated_data_copy.cu.o
> 
> 
> Any idea what could be causing this?

This is another example of how broken the CUDA compiler is. Could you create
a ticket for this please? We need to fix this in optional.hpp.
As a workaround please replace constexpr on the function it complains about
with HPX_CXX14_CONSTEXPR (or remove the 'constexpr' altogether).

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

> 
> Best regards,
> Ivan
> 
> 
> On Wed, 28 Mar 2018 09:24:08 -0500
>   "Hartmut Kaiser" <hartmut.kai...@gmail.com> wrote:
> > compute_sm20 is just the fallback used if nothing else
> >is specified. You can
> > add a -DHPX_WITH_CUDA_ARCH=compute_sm50 to you cmake
> >configure command line
> > to specify the architecture you need.
> >
> > 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 Ivan Kostov
> >> Sent: Wednesday, March 28, 2018 9:14 AM
> >> To: hpx-users@stellar.cct.lsu.edu
> >> Subject: Re: [hpx-users] CUDA with HPX
> >>
> >> Hallo Andreas,
> >>
> >> so we did end up upgrading the OS and now I'm running
> >>CUDA
> >> 9.1. Now I have the following error:
> >>
> >> nvcc fatal   : Unsupported gpu architecture 'compute_20'
> >>
> >> which is gone as of CUDA 9. I tried to set it within my
> >> cmake file with
> >>
> >> set( CUDA_NVCC_FLAGS "${CUDA_NVCC_FLAGS} -gencode
> >> arch=compute_50,code=sm_50")
> >>
> >> which is the highest, supported by my GPU (GPX 750 Ti),
> >> but it still didn't work. Here is the whole error
> >>message
> >>
> >>
> >> /usr/bin/nvcc -M -D__CUDACC__
> >> /home/kostov/Projects/Masterarbeit/Tests/data_copy/data_copy.cu
> >> -o
> >>
> /home/kostov/Projects/Masterarbeit/Tests/data_copy/build/CMakeFiles/cuda_c
> >> opy_exe.dir//cuda_copy_exe_generated_data_copy.cu.o.NVCC-depend
> >> -ccbin /usr/bin/cc -m64
> >> -DHPX_APPLICATION_NAME=cuda_copy_exe
> >> -DHPX_APPLICATION_STRING=\"cuda_copy_exe\"
> >> -DHPX_PREFIX=\"/usr/local\" -DHPX_APPLICATION_EXPORTS
> >> -Xcompiler
> >> ,\"-D_MWAITXINTRIN_H_INCLUDED\",\"-D_FORCE_INLINES\",\"-
> >> D__STRICT_ANSI__\",\"-g\"
> >> -w -gencode=arch=compute_20,code=sm_20 -std=c++11
> >> --expt-relaxed-constexpr --expt-extended-lambda
> >> --default-stream per-thread -lcudadevrt -rdc=true
> >>-gencode
> >> arch=compute_50,code=sm_50 -DNVCC -I/usr/local/include
> >> -I/usr/local/include/hpx/external -I/usr/include
> >> nvcc fatal   : Unsupported gpu architecture 'compute_20'
> >>
> >>
> >> and my cmake file
> >>
> >>
> >> cmake_minimum_required(VERSION 3.3)
> >> project(hpxvr CXX)
> >>
> >> set(CMAKE_CXX_STANDARD 14)
> >> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> >>
> >> set(HPX_IGNORE_COMPILER_COMPATIBILITY ON)
> >>
> >> find_package(HPX REQUIRED)
> >>
> >> include_directories(${HPX_INCLUDE_DIR})
> >>
> >> set( CMAKE_CXX_FLAGS "-D_MWAITXINTRIN_H_INCLUDED
> >> -D_FORCE_INLINES -D__STRICT_ANSI__")
> >> set( CUDA_NVCC_FLAGS "${CUDA_NVCC_FLAGS} -gencode
> >> arch=compute_50,code=sm_50")
> >>
> >> add_hpx_executable(cuda_copy
> >>  ESSENTIAL
> >>  SOURCES data_copy.cu
> >> )
> >>
> >>
> >> Is HPX maybe setting the architecture to compute_20?
> >>
> >> Best regards,
> >> Ivan
> >>
> >>
> &g

Re: [hpx-users] CUDA with HPX

[Hartmut Kaiser]

compute_sm20 is just the fallback used if nothing else is specified. You can
add a -DHPX_WITH_CUDA_ARCH=compute_sm50 to you cmake configure command line
to specify the architecture you need.

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 Ivan Kostov
> Sent: Wednesday, March 28, 2018 9:14 AM
> To: hpx-users@stellar.cct.lsu.edu
> Subject: Re: [hpx-users] CUDA with HPX
> 
> Hallo Andreas,
> 
> so we did end up upgrading the OS and now I'm running CUDA
> 9.1. Now I have the following error:
> 
> nvcc fatal   : Unsupported gpu architecture 'compute_20'
> 
> which is gone as of CUDA 9. I tried to set it within my
> cmake file with
> 
> set( CUDA_NVCC_FLAGS "${CUDA_NVCC_FLAGS} -gencode
> arch=compute_50,code=sm_50")
> 
> which is the highest, supported by my GPU (GPX 750 Ti),
> but it still didn't work. Here is the whole error message
> 
> 
> /usr/bin/nvcc -M -D__CUDACC__
> /home/kostov/Projects/Masterarbeit/Tests/data_copy/data_copy.cu
> -o
> /home/kostov/Projects/Masterarbeit/Tests/data_copy/build/CMakeFiles/cuda_c
> opy_exe.dir//cuda_copy_exe_generated_data_copy.cu.o.NVCC-depend
> -ccbin /usr/bin/cc -m64
> -DHPX_APPLICATION_NAME=cuda_copy_exe
> -DHPX_APPLICATION_STRING=\"cuda_copy_exe\"
> -DHPX_PREFIX=\"/usr/local\" -DHPX_APPLICATION_EXPORTS
> -Xcompiler
> ,\"-D_MWAITXINTRIN_H_INCLUDED\",\"-D_FORCE_INLINES\",\"-
> D__STRICT_ANSI__\",\"-g\"
> -w -gencode=arch=compute_20,code=sm_20 -std=c++11
> --expt-relaxed-constexpr --expt-extended-lambda
> --default-stream per-thread -lcudadevrt -rdc=true -gencode
> arch=compute_50,code=sm_50 -DNVCC -I/usr/local/include
> -I/usr/local/include/hpx/external -I/usr/include
> nvcc fatal   : Unsupported gpu architecture 'compute_20'
> 
> 
> and my cmake file
> 
> 
> cmake_minimum_required(VERSION 3.3)
> project(hpxvr CXX)
> 
> set(CMAKE_CXX_STANDARD 14)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> 
> set(HPX_IGNORE_COMPILER_COMPATIBILITY ON)
> 
> find_package(HPX REQUIRED)
> 
> include_directories(${HPX_INCLUDE_DIR})
> 
> set( CMAKE_CXX_FLAGS "-D_MWAITXINTRIN_H_INCLUDED
> -D_FORCE_INLINES -D__STRICT_ANSI__")
> set( CUDA_NVCC_FLAGS "${CUDA_NVCC_FLAGS} -gencode
> arch=compute_50,code=sm_50")
> 
> add_hpx_executable(cuda_copy
>  ESSENTIAL
>  SOURCES data_copy.cu
> )
> 
> 
> Is HPX maybe setting the architecture to compute_20?
> 
> Best regards,
> Ivan
> 
> 
> 
> On Tue, 27 Mar 2018 15:43:48 +0200
>   Andreas Schäfer  wrote:
> > Ivan,
> >
> > could you retest this with CUDA 9.1? Version 7.5 is
> >really old and I
> > don't think it works well with modern C++. I don't think
> >you have to
> > re-install the whole OS, you could alternatively just
> >download CUDA
> > and install it manually.
> >
> > Thanks!
> > -Andreas
> >
> >
> > On 14:22 Tue 27 Mar , Ivan Kostov wrote:
> >> Hi,
> >>
> >> I am trying to understand how HPX Compute works with
> >>CUDA
> >> and wanted to compile the
> >> examples/compute/cuda/data_copy.cu example.
> >>Unfortunately,
> >> I'm getting the following error:
> >>
> >> /usr/include/c++/5/bits/stl_iterator_base_types.h(154):
> >> error: class
> >> "std::unique_ptr >> std::default_delete>"
> >> has no member "iterator_category"
> >>detected during:
> >>  instantiation of class
> >> "std::__iterator_traits<_Iterator, void> [with
> >> _Iterator=std::unique_ptr >> std::default_delete>]"
> >> (163): here
> >>  instantiation of class
> >> "std::iterator_traits<_Iterator> [with
> >> _Iterator=std::unique_ptr >> std::default_delete>]"
> >> /usr/local/include/hpx/traits/is_iterator.hpp(43): here
> >>  instantiation of class
> >> "hpx::traits::detail::is_iterator [with
> >> T=std::unique_ptr >> std::default_delete>]"
> >> /usr/local/include/hpx/traits/is_iterator.hpp(49): here
> >>  instantiation of class
> >> "hpx::traits::is_iterator [with Iter=const
> >> std::unique_ptr >> std::default_delete>
> >> &, Enable=void]"
> >> /usr/local/include/hpx/runtime/parcelset/locality.hpp(150):
> >> here
> >>
> >> /usr/include/c++/5/bits/stl_iterator_base_types.h(155):
> >> error: class
> >> "std::unique_ptr >> std::default_delete>"
> >> has no member "value_type"
> >>detected during:
> >>  instantiation of class
> >> "std::__iterator_traits<_Iterator, void> [with
> >> _Iterator=std::unique_ptr >> std::default_delete>]"
> >> (163): here
> >>  instantiation of class
> >> "std::iterator_traits<_Iterator> [with
> >> _Iterator=std::unique_ptr >> std::default_delete>]"
> >> 

Re: [hpx-users] Some Compile issue

[Hartmut Kaiser]

Hey Jin,

Welcome.

> I'm Jin Li trying to attend GSoC. I try to compile the library with Visual
> Studio 2015, there is an error raised.
> 
> In merge.hpp, Line 682, my compiler raise error C3489. I checked on VS
> document, it says: When you specify that the default capture mode for a
> lambda expression is by-value, you cannot pass a variable by value to the
> capture clause of that expression.
> 
> So I just change
> "[=,HPX_CAPTURE_FORWARD(comp),HPX_CAPTURE_FORWARD(proj)] "to "[=]" and the
> compilation is success. Will it lead to problems? And should I open an
> issue on Github?

Nothing bad will happen for you. This is a compiler problem that should go away 
if you update to VS2017 (which I'd suggest you do in any case).

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

Re: [hpx-users] hpx-users Digest, Vol 58, Issue 27

[Hartmut Kaiser]

Well Andreas Schaefer (gentryx) seems to be following this list, so he might 
respond to your inquiry.

 

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 Evgeny
Sent: Wednesday, March 21, 2018 12:32 PM
To: hpx-users@stellar.cct.lsu.edu
Subject: Re: [hpx-users] hpx-users Digest, Vol 58, Issue 27

 

Means that the project is not relevant? It's quite sadly to hear, why in that 
case it was placed in GSoC ideas list? I spent a lot of time discovering it... 
Also, mentors who was watching my draft didn't notified me.

Sincerely,

Evgeny Dedov

 

2018-03-22 0:00 GMT+07:00  >:

Send hpx-users mailing list submissions to
hpx-users@stellar.cct.lsu.edu  

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
or, via email, send a message with subject or body 'help' to
hpx-users-requ...@stellar.cct.lsu.edu 
 

You can reach the person managing the list at
hpx-users-ow...@stellar.cct.lsu.edu 
 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of hpx-users digest..."


Today's Topics:

   1. Re: GSoC'18 LibGeoDecomp Support (John Biddiscombe)


--

Message: 1
Date: Wed, 21 Mar 2018 16:23:56 +0100
From: John Biddiscombe  >
Subject: Re: [hpx-users] GSoC'18 LibGeoDecomp Support
To:  >
Message-ID: <157715f4-3be2-15e7-694a-837689b5e...@cscs.ch 
 >
Content-Type: text/plain; charset="utf-8"

Evgeny


I think the libgeocomp project must have been deprecated by now. The
chap who was in charge of it has since left the HPX group and is no
longer involved.

I'm not sure it's a good idea to pursue this one - any other mentors
disagree?


JB


On 03/21/2018 04:17 PM, Evgeny wrote:
> Hello, who can I ask about some LibGeoDecomp specific questions? I
> quite good understand how things are there, but some times
> documentation and source code do not provide enough information to
> quickly understand. I tried to ask in IRC few times, but seems like
> there I can get some HPX support only, and I can't got answer.
>
> Sincerely,
> Dedov Evgeny
>
>
> ___
> hpx-users mailing list
> hpx-users@stellar.cct.lsu.edu  
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users

-- next part --
An HTML attachment was scrubbed...
URL: 
http://mail.cct.lsu.edu/pipermail/hpx-users/attachments/20180321/a9a90b2b/attachment-0001.html

--

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


End of hpx-users Digest, Vol 58, Issue 27
*

 

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

Re: [hpx-users] [hpx-devel] HPX 1.1.0-rc1 available

[Hartmut Kaiser]

\o/

Thanks Mikael for making this happen!

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


> -Original Message-
> From: hpx-devel-boun...@stellar.cct.lsu.edu [mailto:hpx-devel-
> boun...@stellar.cct.lsu.edu] On Behalf Of Simberg Mikael
> Sent: Tuesday, March 20, 2018 7:23 AM
> To: hpx-de...@stellar.cct.lsu.edu; hpx-users@stellar.cct.lsu.edu
> Subject: [hpx-devel] HPX 1.1.0-rc1 available
> 
> Dear HPX users,
> 
> The first release candidate HPX 1.1.0 is now available! Get it by
> downloading it from https://github.com/STEllAR-
> GROUP/hpx/releases/tag/1.1.0-rc1, or by cloning the repository and
> checking out the tag:
> 
> git clone https://github.com/STEllAR-GROUP/hpx.git
> git checkout 1.1.0-rc1
> 
> Let us know about any issues that you find by opening an issue on GitHub:
> https://github.com/STEllAR-GROUP/hpx/issues.

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

Re: [hpx-users] Issue #3218 Statistic performance counters

[Hartmut Kaiser]

Hey Ahmed, welcome to GSoC.

> Can anyone give me a quick hint on how to start with this issue? I am
> interested in joining the "Add More Arithmetic Performance Counters"
> project in GSOC. I have read the documentation and some examples about the
> performance counters. So I want to get started with this issue to get more
> familiar with the HPX library. Any help to get started?

We've had quite a lot of interest in the performance counters project and
already received proposals. We want the best students we can get - but since
you're a bit later than others - you might want to consider one of the other
projects as a possibility to maximize your chances of being accepted...

However, if you are keen on this project, then please go ahead and look HPX
and how to use performance counters. Try to find out how the existing
counters are implemented and what additional counters could be useful.

If you have a project that's not listed on our page - then that would be
also possible. We are always looking for good ideas on ways to extend
improve the library.

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

Re: [hpx-users] [GSoC '18] Introduction - Kunal Agarwal

[Hartmut Kaiser]

Hey,

 

Please send your questions to the hpx-users@stellar.cct.lsu.edu 
  mailing list (cc’ed) for others to be 
able to chime is as well.

 

Thanks!

Regards Hartmut

---

  http://boost-spirit.com

  http://stellar.cct.lsu.edu

 

From: Kunal Agarwal [mailto:kunalagarwa...@gmail.com] 
Sent: Tuesday, March 13, 2018 1:37 PM
To: hartmut.kai...@gmail.com
Subject: [GSoC '18] Introduction - Kunal Agarwal

 

  

 

Dear Hartmut,

I am a third year Undergraduate student at Indian Institute of Technology 
Bombay, pursuing my majors in Chemical Engineering and Minors in Computer 
Science & Engineering. 

 

I found the project about Augment CSV Files interesting and would like to 
contribute towards it for GSoC '18. I am rather new to the Stellar Group and it 
would be of great help, if you can give me some pointers on how to proceed.

I have worked with C++ and python in past. I am already familiar with .csv 
files and pandas during my course on ML and am keen to learn more about it. 
Apart from this I have some knowledge of C and MATLAB.

Thanking you in advance

Yours Sincerely

Kunal Agarwal



‌

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

Re: [hpx-users] NumFOCUS Proposals -- Zeng Liang

[Hartmut Kaiser]

>      My basic information is as follows:
>      *Name: Zeng Liang
>      *Location: China, Beijing
>      *University: Bachelor 2014-2018 : Department of Information and
> software engineering, University of Electronic Science and Technology of
> China(UESTC) , P.R.China
>                           Ph.D. 2018.09- : Department of Institute for
> Interdisciplinary Information and Science(IIIS),Tsinghua University,
> P.R.China
>     *Future Plans: Do some research work
>     *Email: zlp...@qq.com
>     *Languages: python(3 years), C++(4 years)
>     *Github Link: github.com/zlpure
>     *Things want to do:  Applying Machine Learning Techniques on HPX
> Parallel Algorithms
>     *Deep Learning Framework: pytorch, tensorflow, keras
>     *Machine Learning/Deep Learning courses taken:
>       1. Machine-Learning on Coursera
>       2.  CS231n: Convolutional Neural Networks for Visual Recognition
> Winter2016
>       3. CS224n: Natural Language Processing with Deep Learning
>       4. CS234: Reinforcement Learning
> 
>       The attachment is my resume. For more details, you can look at my
> cv.
>       Looking forward to your replay.

Please get in contact with concrete questions, proposals etc. either on IRC
or using the mailing list hpx-users@stellar.cct.lsu.edu (please see here for
details:
https://github.com/STEllAR-GROUP/hpx/blob/master/.github/SUPPORT.md). 
Others might want to join the discussions.

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

Re: [hpx-users] CUDA in HPX

[Hartmut Kaiser]

Tim,

> what's the correct way to use CUDA with HPX nowadays? I've seen the
> HPXCL GSoC project, but apparently there is also a HPX_WITH_CUDA option
> in CMake now.
> 
> I have a hard time finding clear documentation on this.

That's because there is no documentation.

CUDA support in HPX is experimental at best. We appreciate any help we can get 
improving the picture.

We have two different ways of integrating with CUDA: HPXCL and HPX.Compute. 

HPXCL is a separate project providing a set of HPX components that allow to 
talk to a GPU device, even remotely. The API exposed resembles OpenCL to some 
extent, but if you look at the existing examples you should find your way 
around.

HPX.Compute is part of the main repository. It mainly consists of a very low 
level facility that allows to spawn any CUDA kernel on a local GPU device from 
your C++ code and representing this as a future you can use to synchronize the 
kernel execution with your cpu work. It also has higher level facilities that 
use this facility to implement some of the parallel algorithms (including the 
use of parallel::copy for transparent and asynchronous data transfer). 
HPX.Compute also has some allocators and executors that help managing data and 
execution locality.

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

Re: [hpx-users] Confirmation of My subscription

[Hartmut Kaiser]

Apparently you’re already subscribed to the list, just go ahead – ask your 
questions.

 

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 surya priy
Sent: Monday, February 12, 2018 12:20 PM
To: hpx-users@stellar.cct.lsu.edu
Subject: [hpx-users] Confirmation of My subscription

 

Hello Sir, I want to subscribe HPX-users community but I always directed to 
this link 
https://www.cct.lsu.edu/user/sso/cctsso-redir?target=https%3A//www.cct.lsu.edu/cctsso/login%3Ftarget%3Dhttp%253A//www.cct.lsu.edu/staffresources
 

 

and I don't get any list regarding how to proceed further . Please suggest How 
can I work and ask anyone on this mailing list .

 

Thanks

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

Re: [hpx-users] GSOC Generic Histogram performance counter project

[Hartmut Kaiser]

Hey Tanmay,

> I was going through your GSOC 2018 project ideas and I was thinking of
> working on these 2 projects
> 1)Add More Arithmetic Performance Counters
> 
> 2)Create Generic Histogram Performance Counter
> I don't have a lot of experience in parallel computing but I would like to
> learn more about it through this project.

Cool! I think the first (the arithmetic counters) have been implemented by now, 
but the generic histogram counter is a nice, small, and self-contained project.

I'm cc'ing this response to hpx-users@stellar.cct.lsu.edu and I'd suggest that 
all follow-on discussions are done over there. Feel free to post your questions 
on that list as this may yield response from other people as well.

Alternatively, our main communication platform is IRC, feel free to hop on at 
#ste||ar on freenode.net (see here for more communication possibilities: 
https://github.com/STEllAR-GROUP/hpx/blob/master/.github/SUPPORT.md)

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

Re: [hpx-users] HPX build problem

[Hartmut Kaiser]

Mateusz,

> I am a student of computer science at Jagiellonian University in Kraków
> (Poland).
> This will be my first attempt to participate in an open source project.
> I have a problem with build project on Ubuntu.
> I am writing for help ;) I tried to use command from this page
> https://stellar-
> group.github.io/hpx/docs/html/hpx/manual/build_system/building_hpx/build_r
> ecipes.html and github wiki without modification (I have no idea which
> CMake Variables should I change and why).
> I don't know what more I should write so I attached a screen shot.
> 
> I installed hwloc by "apt-get install hwloc"
> It should work in my opinion.

Sorry, the image you sent is too small for me to discern anything, could you 
send the log as a text file, please?
Also, I'd suggest to send mail to hpx-users@stellar.cct.lsu.edu, cc'ed for 
others to chime in.

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

Re: [hpx-users] Performance Counter Data Interpretation

[Hartmut Kaiser]

Kilian,

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

Ok, I just wanted to make whether we recently broke something.

In general, high overheads point towards either too little parallelism or
too fine grain tasks. From the performance counter data collected when
running on one core you can discern that it's at least the latter:

> threads{locality#0/total/total}/time/average,1,2.015073,[s],14938,[ns]

This tells you that the average execution time of the HPX threads is in the
range of 15 microseconds. Taking into account that the overheads introduced
by the creation, scheduling, running, and destruction of a single HPX is in
the range of one microsecond, this average time hints at that your
parallelism is too fine-grained. I'd suggest trying to somehow combine
several tasks into one to be run sequentially by one HPX thread. Average
execution times of 150-200 microseconds are a good number for HPX.

You can also see that your idle-rate is increasing significantly once you
increase the number of cores to run on. This might indicate that you have
not enough parallelism in your application to warrant parallelization to the
extent you try it to run on. Once you run on 2 cores your idle-rate goes up
to 45%, which is quite a large number (idle-rates up to 15% are relatively
ok, usually).

>From what I can see your application launches a lot of very small tasks
which depend sequentially on each other. Alternatively, you have a lot of
cross-thread synchronization going on, which prevents efficient
parallelization. But that is pure conjecture and I might be completely
wrong.

The fact that you're mostly using 'apply' to schedule your threads hints at
the fact that you need to do your own synchronization which could be causing
the problems. Changing this to use futures as the means of synchronization
(i.e. use async instead of apply) and build asynchronous execution trees out
of those futures may reduce contention and may remove the need to explicitly
synchronize between threads. 

In general, I'd suggest using a tool like APEX (non-Windows only, preferred
for Linux) or Intel Amplifier (preferred for Windows, but works on Linux as
well) to visualize your real task dependencies at runtime. Both tools
require special configuration but both of them are directly supported by
HPX. Please let us know if you need more information

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


> 
> Thanks,
> Kilian Werner
> 
> On Tue, 9 Jan 2018 08:47:12 -0600
>   "Hartmut Kaiser" <hartmut.kai...@gmail.com> 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

Re: [hpx-users] Performance Counter Data Interpretation

[Hartmut Kaiser]

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:
> 
> /threads{locality#0/total/total}/count/cumulative,1,1.814639,[s],112250
> /threads{locality#0/total/total}/time/average,1,1.814644,[s],17986,[ns]
> /threads{locality#0/total/total}/time/cumulative,1,1.814654,[s],2.01907e+0
> 9,[ns]
> /threads{locality#0/total/total}/time/cumulative-
> overhead,1,1.814647,[s],1.60469e+09,[ns]
> /threads{locality#0/pool#default/worker-thread#0}/time/cumulative-
> overhead,1,1.814599,[s],1.12562e+09,[ns]
> /threads{locality#0/pool#default/worker-thread#1}/time/cumulative-
> overhead,1,1.814649,[s],4.79071e+08,[ns]
> /threads{locality#0/total/total}/idle-rate,1,1.814603,[s],4428,[0.01%]
> 
> --hpx:threads 8:
> 
> /threads{locality#0/total/total}/count/cumulative,1,4.597361,[s],109476
> /threads{locality#0/total/total}/time/average,1,4.597373,[s],37988,[ns]
> /threads{locality#0/total/total}/time/cumulative,1,4.597335,[s],4.1588e+09
> ,[ns]
> /threads{locality#0/total/total}/time/cumulative-
> overhead,1,4.597325,[s],3.25232e+10,[ns]
> /threads{locality#0/pool#default/worker-thread#0}/time/cumulative-
> overhead,1,4.597408,[s],4.20735e+09,[ns]
> /threads{locality#0/pool#default/worker-thread#1}/time/cumulative-
> overhead,1,4.597390,[s],4.08787e+09,[ns]
> /threads{locality#0/pool#default/worker-thread#2}/time/cumulative-
> overhead,1,4.597385,[s],3.62298e+09,[ns]
> /threads{locality#0/pool#default/worker-thread#3}/time/cumulative-
> overhead,1,4.597358,[s],4.12475e+09,[ns]
> /threads{locality#0/pool#default/worker-thread#4}/time/cumulative-
> overhead,1,4.597338,[s],4.10011e+09,[ns]
> /threads{locality#0/pool#default/worker-thread#5}/time/cumulative-
> overhead,1,4.597402,[s],4.14242e+09,[ns]
> /threads{locality#0/pool#default/worker-thread#6}/time/cumulative-
> overhead,1,4.597353,[s],4.13593e+09,[ns]
> /threads{locality#0/pool#default/worker-thread#7}/time/cumulative-
> overhead,1,4.597408,[s],4.13275e+09,[ns]
> /threads{locality#0/total/total}/idle-rate,1,4.597350,[s],8867,[0.01%]
> 
> 
> ___
> 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] Resource partitioner error

[Hartmut Kaiser]

> I noticed in the IRC chat that Steven had the error
> "RuntimeError: partitioner::add_resource: Creation of 2 threads requested
> by the resource partitioner, but only 1 provided on the command-line."
> 
> in my experience, this always happens when you try to run an application
> compiled with
> HPX_WITH_MAX_CPU_COUNT=64
> HPW_WITH_MORE_THAN_64_THREADS=ON
> on a machine that has more than 64 cores.
> 
> If that turns out to be the the problem. please file an issue so we
> remember to fix it.

FWIW, the issue is currently being tracked here:
https://github.com/STEllAR-GROUP/phylanx/issues/130

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

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

[Hartmut Kaiser]

Andreas,

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

Thanks for this fix. I don't know anything about Qt but your patch looks sane 
to me. Thomas might know more, he wrote the example in the first place.

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

> 
> best regards,
> Andreas
> 
> 
> [1]
> https://github.com/STEllAR-
> GROUP/hpx/blob/2ec00bc39b5d384aeda7cdb58a893680a057e2d2/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

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

[Hartmut Kaiser]

> I am wondering how to integrate HPX with GUI applications. I'd like to
> have one GUI locality where e.g. a Qt application is running. Then I'd
> like to trigger GUI events from HPX actions.
> 
> Problem: Both HPX and Qt want the mainloop.

HPX does not 'want' access to the main loop.

> I was able to do a similar thing with ZeroMQ and Qt. There I gave the
> mainloop to Qt. ZeroMQ then provides a file descriptor and I can use a
> "QSocketNotifier" that triggers whenever the ZeroMQ-socket receives an
> event. The QSocketNotifier is then connected to a ZeroMQ event handler.
> That way, both parts are happy.
> 
> How would you do that with HPX?

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.
There is also a way to leave Qt running on the main thread (i.e. the one
that called
main()):https://github.com/STEllAR-GROUP/hpx/blob/master/examples/quickstart
/use_main_thread.cpp.

Both options allow to coordinate things between the two worlds. I'd suggest
to go with the solution based on the executor.

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

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

[Hartmut Kaiser]

> Yes I want to pass different arguments to different invocation. For
> example I can have different sets of channels that some localities will
> need to use to communicate.
> 
> I am able to use the parallel_executor as follow:
> 
> -
> hpx::parallel::execution::parallel_executor exec;
> 
> hpx::when_all(hpx::parallel::execution::bulk_async_execute(
>   exec, _bulk, args)).get();
> 
> ——
> 
> Now I am trying to understand where those tasks are launched.
> 
> When I run this using -hpx::threads 1 with 8 MPI ranks the
> hpx::find_here() is telling me that all my spmd_bulk are running on the
> same locality (even if I have 8 localities), as a consequence the
> execution is serialized.
> 
> I thought that this executor was supposed to spawn the tasks over
> different localities, but probably I am missing something (or some
> parameters).

No. This executor does local tree-style spawning of tasks. As said, for remote 
operation you could use broadcast, or write your own executor. We have a lot of 
work to do to integrate remote operation with the current executor framework.

Hold on - there is also distribution_policy_executor which can be used to send 
work to remote localities (see 
https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/parallel/executors/distribution_policy_executor.hpp).
 I need to have a look what state this is in, though. I don't think it's doing 
anything fancy like tree-style spawning, though.

> How can I spawn my tasks over multiple localities?
> 
> Should I use something like this instead? https://stellar-
> group.github.io/hpx/docs/html/hpx/manual/containers/partitioned_vector_vie
> ws/spmd_block.html

Well, let's not go there (yet).

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


> Thank you,
> Steve
> 
> 
> 
> On 13 Oct 2017, at 06:08, Hartmut Kaiser <hartmut.kai...@gmail.com> wrote:
> 
> Steve,
> 
> 
> 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.
> 
> Using the other executors that you mentioned how can I pass different
> arguments to different localities (e.g., the channels)?
> 
> Do you want to pass different arguments to different invocations and still
> use tree-spawning?
> 
> 
> Is there any example of using tree-like spawning or bulk_async_execute
> other then the tests?
> 
> For efficient _local_ tree-style spawning you can use the
> parallel_executor. See here for an example: https://github.com/STEllAR-
> GROUP/hpx/blob/master/tests/unit/parallel/executors/parallel_executor.cpp#
> L94-L113. Please note that the 3rd parameter to bulk_async_execute could
> be any (input) range, for instance a boost::irange(0, num) or similar, it
> doesn't have to be a real container.
> 
> Remote tree-style spawning can be done using broadcast (or
> broadcast_with_index), see here for an example:
> https://github.com/STEllAR-
> GROUP/hpx/blob/master/tests/unit/lcos/broadcast.cpp
> 
> HTH
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> 
> 
> Thanks,
> Steve
> 
> 
> 
> 
> 
> 
> On 12 Oct 2017, at 09:53, Hartmut Kaiser <hartmut.kai...@gmail.com> 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 

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

[Hartmut Kaiser]

Steve,

> 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.
> 
> Using the other executors that you mentioned how can I pass different
> arguments to different localities (e.g., the channels)?

Do you want to pass different arguments to different invocations and still use 
tree-spawning?

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

For efficient _local_ tree-style spawning you can use the parallel_executor. 
See here for an example: 
https://github.com/STEllAR-GROUP/hpx/blob/master/tests/unit/parallel/executors/parallel_executor.cpp#L94-L113.
 Please note that the 3rd parameter to bulk_async_execute could be any (input) 
range, for instance a boost::irange(0, num) or similar, it doesn't have to be a 
real container.

Remote tree-style spawning can be done using broadcast (or 
broadcast_with_index), see here for an example: 
https://github.com/STEllAR-GROUP/hpx/blob/master/tests/unit/lcos/broadcast.cpp

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


> 
> Thanks,
> Steve
> 
> 
> 
> 
> 
> 
> On 12 Oct 2017, at 09:53, Hartmut Kaiser <hartmut.kai...@gmail.com> 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 <hartmut.kai...@gmail.com> 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");

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

[Hartmut Kaiser]

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 <spetru...@sci.utah.edu> wrote:
> 
> Thanks Hartmut, it all makes sense now.
> 
> 
> 
> On 11 Oct 2017, at 14:51, Hartmut Kaiser <hartmut.kai...@gmail.com> 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 <spetru...@sci.utah.edu> 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 <spetru...@sci.utah.edu> wrote:
> 
> hpx::find_here()
> 
> 


___
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

[Hartmut Kaiser]

Kilian,

> following your discussion about remote dependencies
> between futures has left me with two questions:
> 
> 1.) If we pass a future as an argument to a remote
> function call, is the actual call of the function delayed,
> until the future becomes ready?
> 
> So does:
> 
> hpx::future arg = hpx::async();
> hpx::async(REMOTE_LOC, arg);
> 
> Equals:
> 
> hpx::future f= hpx::async();
> hpx::async(REMOTE_LOC, f.get());

Yes, but only for remote targets. For local targets this is not true. I 
wouldn't rely on it, though. This is an implementation detail which may change 
at any time without notice.

> 2.) When we encountered a similar problem, our solution
> was to aggregate the futures (of tasks A) inside AGAS
> adsressed components, distribute those addresses and
> referencing remote (and local) futures our dataflows
> dependet on as member variables of these components.
> How would such a solution compare to the channel based
> approach with respect to performance and scalability?

Not sure, only a test case and some measurements can tell. Please let us know 
if you find out something interesting.

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


> 
> Thanks,
> 
> Kilian
> 
> On Mon, 9 Oct 2017 17:41:54 -0600
>   Steve Petruzza <spetru...@sci.utah.edu> wrote:
> > Thank you Hartmut,
> >
> > Your suggestions are already very useful. This channels
> >mechanism looks awesome, I will give it a try.
> >
> > One other thing, where I can actually give you a code
> >example, is the following:
> > - an async function returns a future of a vector
> > - I need to dispatch the single elements of this vector
> >as separate futures, cause those will be used
> >(separately) by other async functions
> >
> > Here is what I am doing right now:
> >
> > hpx::future<std::vector> out_v =
> >hpx::dataflow(exe_act, locality, inputs);
> >
> > std::vector<hpx::future>
> >outputs_fut(out_count);
> >
> > for(int i=0; i < out_count; i++){
> >  outputs_fut[i] = hpx::dataflow(
> > [i, _v]() -> Something
> > {
> >   return out_v.get()[i];
> >}
> >   );
> > }
> >
> > This solution works but I think that the loop is just
> >creating a bunch of useless async calls just to take out
> >one of the elems as a single future.
> >
> > Is there a better way of doing this? Basically to pass
> >from a future to a vector in HPX?
> >
> > Thank you,
> > Steve
> >
> > p.s.: I also tried to use an action which runs on the
> >same locality for the second dataflow.
> >
> >> On 9 Oct 2017, at 16:56, Hartmut Kaiser
> >><hartmut.kai...@gmail.com> wrote:
> >>
> >> Steve,
> >>
> >>> The number of cores per node is 32, so the 8 threads * 4
> >>>cores should be
> >>> fine (I tried many variants anyway).
> >>>
> >>> The SPMD implementation seems like the way to go, but
> >>>after I split my
> >>> tasks into different localities how can I express data
> >>>dependencies
> >>> between them?
> >>>
> >>> Let’s say that I have tasks 0-10 in locality A and tasks
> >>>11-21 in locality
> >>> B. Now, the task 15 (in locality B) requires some data
> >>>produced by task 7
> >>> (in locality A).
> >>>
> >>> Should I encode these data dependencies in terms of
> >>>futures when I split
> >>> the tasks into the two localities?
> >>
> >> Yes, either send the future over the wire (which might
> >>have surprising effects as we wait for the future to
> >>become ready before we actually send it) or use any other
> >>means of synchronizing between the two localities,
> >>usually a channel is a nice way of accomplishing this.
> >>You can either send the channel over to the other
> >>locality or use the register_as()/connect_to()
> >>functionalities expose by it:
> >>
> >>// locality 1
> >>hpx::lcos::channel c (hpx::find_here());
> >>c.register_as("some-unique-name");  // careful:
> >>returns a future
> >>c.set(T{});// returns a future too
> >>
> >>    // locality 2
> >>hpx::lcos::channel c;
> >>c.connect_to("some-unique-name");   // careful:
> >>returns a future
> >>
> >>// this might wait for c to become valid before

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

[Hartmut Kaiser]

Steve,

> That implementation worked well for me.
> 
> Buy just a little detail:
> If I want to use vector of shared_future the only way I got it working is
> as follow:
> 
> auto temp_out = hpx::split_future(hpx::dataflow(act, locality, inputs),
> out_count);
> for(int o=0; o< out_count; o++)
> outputs[o] = std::move(temp_out[o]);
> 
> Which I guess is fine…
> 
> But to make it more compact I tried also to force the usage of
> shared_future doing:
> hpx::split_future(hpx::shared_future<std::vector>(std::move(hpx
> ::dataflow(act, locality, inputs))), out_count)
> 
> And I still get a vector of future not a vector of shared_future. Also the
> std::move on the entire vector does not help. But I don’t think it’s a big
> deal.

That design is intentional. No matter what future you give to split_future 
(shared or not), it gives you a container of (unique) futures. This shouldn't 
be a problem, though - as you can turn any unique future into a shared one by 
simply calling .share():

hpx::future f = ...;
hpx::shared_future sf = f.share();  // note: invalidates 'f'

alternatively, a shared_future is implicitly constructible from a future:

hpx::shared_future sf{std::move(f)};

I don't think there is any need for the acrobatics you tried above.

> About channels
> The only example I’ve found of usage of “remote" channels is
> this: https://stellar-group.github.io/hpx/docs/html/hpx/manual/lcos.html
> 
> In the last example of the Channel paragraph the creator of the channel is
> “sending” a series of values from a vector.
> I guess the receiver is supposed to know how many elements is going to
> receive...
> 
> But what if I want to send a structure or an std::vector over a channel?
> (since I don’t think is efficient to send bytes one by one)
> I tried to register the same datatype (Payload) that I use in my
> HPX_PLAIN_ACTIONS (successfully) but I get an error like:
> 
> —
> use of undeclared
>   identifier ‘__channel_Payload'
> HPX_REGISTER_CHANNEL(Payload);
> 
> hpx_install/include/hpx/lcos/server/channel.hpp:150:5: note:
>   expanded from macro 'HPX_REGISTER_CHANNEL'
> HPX_REGISTER_CHANNEL_(__VA_ARGS__)
> 
> hpx_install/include/hpx/lcos/server/channel.hpp:153:19: note:
>   expanded from macro 'HPX_REGISTER_CHANNEL_'
> HPX_PP_EXPAND(HPX_PP_CAT(
> \
>   ^
> hpx_install/include/hpx/util/detail/pp/cat.hpp:21:30: note:
>   expanded from macro 'HPX_PP_CAT'
> #define HPX_PP_CAT(a, b) HPX_PP_CAT_I(a, b)
>  ^
> note: (skipping 4 expansions in backtrace; use -fmacro-backtrace-limit=0
> to see all)
> hpx_install/include/hpx/util/detail/pp/cat.hpp:21:30: note:
>   expanded from macro 'HPX_PP_CAT'
> hpx_install/include/hpx/util/detail/pp/cat.hpp:29:32: note:
>   expanded from macro 'HPX_PP_CAT_I'
> #define HPX_PP_CAT_I(a, b) a ## b
>^
> :9:1: note: expanded from here
> __channel_DataFlow

Could you give us a small reproducing example, please? I think this is a bug, 
however I believe we have fixed it recently (see #2870). What version of HPX is 
that happening with?

> —
> 
> The class Payload simply implements serialize and brings inside a
> std::vector as follow:
> 
> ——
> std::vector mBuffer;
> 
> friend class hpx::serialization::access;
> 
> template 
> void serialize(Archive& ar, const unsigned int version)
> {ar & mBuffer;   }
> 
> ——
> 
> This datatype is fine for asynchronous remote actions.
> So I wonder: is it allowed to send std::vectors over channels?

Yes, definitely. Just create a channel<vector> and you will be able to send 
vectors of T's (channel should work as well).

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


> Thanks,
> Steve
> 
> 
> 
> On 10 Oct 2017, at 10:51, Hartmut Kaiser <hartmut.kai...@gmail.com> wrote:
> 
> Steve,
> 
> Please see #2942 for a first implementation of split_future for
> std::vector. Please let us know on the ticket if this solves your problem.
> We will merge things to master as soon as you're fine with it.
> 
> Thanks!
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> 
> -Original Message-
> From: Steve Petruzza [mailto:spetru...@sci.utah.edu]
> Sent: Tuesday, October 10, 2017 8:46 AM
> To: hartmut.kai...@gmail.com
> Cc: hpx-users@stellar.cct.lsu.edu
> Subject: Re: [hpx-users] Strong scalability of hpx dataflow and async
> 
> Yes that would be very useful.
> And yes I know upfront the size.
> 
> Thank you!
> Steve
> 
> 
> On Oct 10, 2017, at 7:40

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

[Hartmut Kaiser]

Steve,

> > Your suggestions are already very useful. This channels mechanism looks
> > awesome, I will give it a try.
> >
> > One other thing, where I can actually give you a code example, is the
> > following:
> > - an async function returns a future of a vector
> > - I need to dispatch the single elements of this vector as separate
> > futures, cause those will be used (separately) by other async functions
> >
> > Here is what I am doing right now:
> >
> > hpx::future<std::vector> out_v = hpx::dataflow(exe_act,
> > locality, inputs);
> >
> > std::vector<hpx::future> outputs_fut(out_count);
> >
> > for(int i=0; i < out_count; i++){
> >   outputs_fut[i] = hpx::dataflow(
> >  [i, _v]() -> Something
> >  {
> >return out_v.get()[i];
> > }
> >);
> > }
> >
> > This solution works but I think that the loop is just creating a bunch
> of
> > useless async calls just to take out one of the elems as a single
> future.
> >
> > Is there a better way of doing this? Basically to pass from a
> > future to a vector in HPX?
> 
> We do have the split_future facility doing exactly that but just for
> containers with a size known at compile time (pair, tuple, array), see
> here: https://github.com/STEllAR-
> GROUP/hpx/blob/master/hpx/lcos/split_future.hpp. Frankly, I'm not sure
> anymore why we have not added the same for std::vector as well. From
> looking at the code it should just work to do something similar as we've
> implemented for std::array. I opened a new ticket to remind me to
> implement split_future for std::vector (https://github.com/STEllAR-
> GROUP/hpx/issues/2940).

After looking into this a bit more I now understand why we have not implemented 
split_future for std::vector. Please consider:

std::vector<future> 
split_future(future<std::vector> && f);

in order for this to work efficiently we need to know how many elements are 
stored in the input vector without waiting for the future to become ready (as 
waiting for the future to become ready just for this would defeat the purpose). 
But have no way of knowing how many elements will be held by the vector before 
that.

What I could do is to implement:

std::vector<future> 
split_future(future<std::vector> && f, std::size_t size);

(with 'size' specifying the number of elements the vector is expected to hold) 
as in some circumstances you know upfront how many elements to expect. 

Would that be of use to you?

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


> 
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> > Thank you,
> > Steve
> >
> > p.s.: I also tried to use an action which runs on the same locality for
> > the second dataflow.
> >
> > On 9 Oct 2017, at 16:56, Hartmut Kaiser <hartmut.kai...@gmail.com>
> wrote:
> >
> > Steve,
> >
> >
> > The number of cores per node is 32, so the 8 threads * 4 cores should be
> > fine (I tried many variants anyway).
> >
> > The SPMD implementation seems like the way to go, but after I split my
> > tasks into different localities how can I express data dependencies
> > between them?
> >
> > Let’s say that I have tasks 0-10 in locality A and tasks 11-21 in
> locality
> > B. Now, the task 15 (in locality B) requires some data produced by task
> 7
> > (in locality A).
> >
> > Should I encode these data dependencies in terms of futures when I split
> > the tasks into the two localities?
> >
> > Yes, either send the future over the wire (which might have surprising
> > effects as we wait for the future to become ready before we actually
> send
> > it) or use any other means of synchronizing between the two localities,
> > usually a channel is a nice way of accomplishing this. You can either
> send
> > the channel over to the other locality or use the
> > register_as()/connect_to() functionalities expose by it:
> >
> >// locality 1
> >hpx::lcos::channel c (hpx::find_here());
> >c.register_as("some-unique-name");  // careful: returns a
> future
> >c.set(T{});// returns a future too
> >
> >// locality 2
> >hpx::lcos::channel c;
> >c.connect_to("some-unique-name");   // careful: returns a
> future
> >
> >// this might wait for c to become valid before calling get()
> >hpx::future f = c.get

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

[Hartmut Kaiser]

Steve,

> Your suggestions are already very useful. This channels mechanism looks
> awesome, I will give it a try.
> 
> One other thing, where I can actually give you a code example, is the
> following:
> - an async function returns a future of a vector
> - I need to dispatch the single elements of this vector as separate
> futures, cause those will be used (separately) by other async functions
> 
> Here is what I am doing right now:
> 
> hpx::future<std::vector> out_v = hpx::dataflow(exe_act,
> locality, inputs);
> 
> std::vector<hpx::future> outputs_fut(out_count);
> 
> for(int i=0; i < out_count; i++){
>   outputs_fut[i] = hpx::dataflow(
>  [i, _v]() -> Something
>  {
>return out_v.get()[i];
> }
>);
> }
> 
> This solution works but I think that the loop is just creating a bunch of
> useless async calls just to take out one of the elems as a single future.
> 
> Is there a better way of doing this? Basically to pass from a
> future to a vector in HPX?

We do have the split_future facility doing exactly that but just for containers 
with a size known at compile time (pair, tuple, array), see here: 
https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/lcos/split_future.hpp. 
Frankly, I'm not sure anymore why we have not added the same for std::vector as 
well. From looking at the code it should just work to do something similar as 
we've implemented for std::array. I opened a new ticket to remind me to 
implement split_future for std::vector 
(https://github.com/STEllAR-GROUP/hpx/issues/2940).

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


> Thank you,
> Steve
> 
> p.s.: I also tried to use an action which runs on the same locality for
> the second dataflow.
> 
> On 9 Oct 2017, at 16:56, Hartmut Kaiser <hartmut.kai...@gmail.com> wrote:
> 
> Steve,
> 
> 
> The number of cores per node is 32, so the 8 threads * 4 cores should be
> fine (I tried many variants anyway).
> 
> The SPMD implementation seems like the way to go, but after I split my
> tasks into different localities how can I express data dependencies
> between them?
> 
> Let’s say that I have tasks 0-10 in locality A and tasks 11-21 in locality
> B. Now, the task 15 (in locality B) requires some data produced by task 7
> (in locality A).
> 
> Should I encode these data dependencies in terms of futures when I split
> the tasks into the two localities?
> 
> Yes, either send the future over the wire (which might have surprising
> effects as we wait for the future to become ready before we actually send
> it) or use any other means of synchronizing between the two localities,
> usually a channel is a nice way of accomplishing this. You can either send
> the channel over to the other locality or use the
> register_as()/connect_to() functionalities expose by it:
> 
>// locality 1
>hpx::lcos::channel c (hpx::find_here());
>c.register_as("some-unique-name");  // careful: returns a future
>c.set(T{});// returns a future too
> 
>// locality 2
>hpx::lcos::channel c;
>c.connect_to("some-unique-name");   // careful: returns a future
> 
>// this might wait for c to become valid before calling get()
>hpx::future f = c.get();
> 
> on locality 2 'f' becomes ready as soon as c.set() was called on locality
> 1. While it does not really matter on what locality you create the channel
> (here defined by hpx::find_here()), I'd advise creating it on the
> receiving end of the pipe.
> 
> If you gave us some example code we were able to advise more concretely.
> 
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> 
> 
> Steve
> 
> 
> 
> 
> 
> 
> 
> On 9 Oct 2017, at 15:37, Hartmut Kaiser <hartmut.kai...@gmail.com> wrote:
> 
> SMPD
> 


___
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

[Hartmut Kaiser]

Steve,

> The number of cores per node is 32, so the 8 threads * 4 cores should be
> fine (I tried many variants anyway).
> 
> The SPMD implementation seems like the way to go, but after I split my
> tasks into different localities how can I express data dependencies
> between them?
> 
> Let’s say that I have tasks 0-10 in locality A and tasks 11-21 in locality
> B. Now, the task 15 (in locality B) requires some data produced by task 7
> (in locality A).
> 
> Should I encode these data dependencies in terms of futures when I split
> the tasks into the two localities?

Yes, either send the future over the wire (which might have surprising effects 
as we wait for the future to become ready before we actually send it) or use 
any other means of synchronizing between the two localities, usually a channel 
is a nice way of accomplishing this. You can either send the channel over to 
the other locality or use the register_as()/connect_to() functionalities expose 
by it:

// locality 1
hpx::lcos::channel c (hpx::find_here());
c.register_as("some-unique-name");  // careful: returns a future
c.set(T{});// returns a future too

// locality 2
hpx::lcos::channel c;
c.connect_to("some-unique-name");   // careful: returns a future

// this might wait for c to become valid before calling get()
hpx::future f = c.get(); 

on locality 2 'f' becomes ready as soon as c.set() was called on locality 1. 
While it does not really matter on what locality you create the channel (here 
defined by hpx::find_here()), I'd advise creating it on the receiving end of 
the pipe.

If you gave us some example code we were able to advise more concretely.

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


> 
> Steve
> 
> 
> 
> 
> 
> 
> 
> On 9 Oct 2017, at 15:37, Hartmut Kaiser <hartmut.kai...@gmail.com> wrote:
> 
> SMPD


___
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?

[Hartmut Kaiser]

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

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 <hartmut.kai...@gmail.com>
> 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' <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, );
> >>>
> >>> 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

Re: [hpx-users] Questions about benchmarking hpx tasks

[Hartmut Kaiser]

Tobias,

> Thank you all for your replies.
> I have available for me Intel VTune Amplifier 2018 and Vampir 9.2.
> 
> So far i did rebuild HPX with -DHPX_WITH_APEX=ON and -
> DCMAKE_BUILD_TYPE="RelWithDebInfo".
> I couldn't find a cmake or cmd line flag in the documentation how to
> enable OTF file creation. How is that done?

I'm cc'ing Kevin on this reply for him to answer the APEX question.

> @Hartmut: Do i need to do something extra to use VTune? A simple hotspot
> analysis looks promising, but is only showing me intern hpx function calls
> without any reference to my own code.

You can either use APEX or VTune, not both at the same time. In order to 
integrate HPX with VTune you need to specify -DHPX_WITH_ITT_NOTIFY=On and 
-DAMPLIFIER_ROOT= to cmake at configuration time. 
Please make sure that no APEX is enabled (-DHPX_WITH_APEX=Off) in this case.

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


> 
> Best regards
> Tobias Gauweiler
> 
> On 1 September 2017 at 15:53, Hartmut Kaiser <hartmut.kai...@gmail.com>
> wrote:
> 
> > If you are interested in seeing tasks like this
> >
> > https://pasteboard.co/GzF4jDa.png
> >
> > Then you should try compiling HPX with APEX enabled (and also enable
> OTF)
> > and then you can use a tool like vampir (not free but they have a trial
> > version) or some others I can’t remember the names of (wxparaver?) that
> > can display OTF2 trace files. One that I’ve never tried but keep meaning
> > to is http://vite.gforge.inria.fr/
> 
> An alternative option would be to use Intel Amplifier (former Intel VTune)
> for which we have an integration with HPX as well. Let me know if you
> would like to try that for more information.
> 
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> >
> > JB
> >
> >
> >
> >
> >
> > From: hpx-users-boun...@stellar.cct.lsu.edu [mailto:hpx-users-
> > boun...@stellar.cct.lsu.edu] On Behalf Of Tobias Gauweiler
> > Sent: 01 September 2017 13:42
> > To: hpx-users@stellar.cct.lsu.edu
> > Subject: [hpx-users] Questions about benchmarking hpx tasks
> >
> > Hello,
> >
> > i want to benchmark my hpx application and i'm not sure what's the best
> > way to do this.
> >
> > My goal is to create a gantt chart with the x axis for the time and y
> axis
> > for the hpx worker thread ids
> > and then adding boxes for each task to their corresponding hpx worker id
> > with the task computation time as length in x direction.
> >
> > The application runs on only one locality.
> >
> > Questions:
> >
> > 1.) If a task got suspended and then resumed is the hpx worker id still
> > the same? If not is there a unique identifier for tasks that i can use
> > instead?
> >
> > 2.) How to measure the computation time of each task? Should i write my
> > own performance counter or  save the start and end time per task
> manually?
> >
> >
> > Best regards
> > Tobias Gauweiler
> 
> ___
> 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 compiling with gcc 7.2

[Hartmut Kaiser]

> I've got the following error compiling hpc ver 1.0 with gcc 7.2. Compiling
> with gcc 6.1 is working.

HPX V1.0 was released quite a while ago (and definitely before gcc 7.2),
thus we don't (can't) support this compiler with HPX V1.0. May I ask you to
try top of master from the git repository instead
(https://github.com/STEllAR-GROUP/hpx)? Many things have been fixed since
the release.

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

Re: [hpx-users] Delayed execution of tasks

[Hartmut Kaiser]

> I have just started using HPX in a project and while discussing this
> with colleagues a question came up:
> 
> Given a task tree, is it possible to delay the execution of the tasks
> until it is certain that the end-result is required (for example,
> because it is written to disk)?
> 
> In my project, it is possible that parts of the task tree don't need to
> be executed. This decision can only be made at run time, after a part of
> the task tree has already been created.
> 
> I can imagine that somehow executing tasks can be delayed until
> future.get() is called, for example.

A future which was created as deferred will be executed only if future::get
is called:

hpx::future f = hpx::async(hpx::launch::deferred, []() {...});
//...
f.get(); // <-- this triggers the execution of the lambda.

FWIW, you can also pass the deferred launch policy to dataflow and
future::then, if needed.

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

Re: [hpx-users] Questions about benchmarking hpx tasks

[Hartmut Kaiser]

> If you are interested in seeing tasks like this
> 
> https://pasteboard.co/GzF4jDa.png
> 
> Then you should try compiling HPX with APEX enabled (and also enable OTF)
> and then you can use a tool like vampir (not free but they have a trial
> version) or some others I can’t remember the names of (wxparaver?) that
> can display OTF2 trace files. One that I’ve never tried but keep meaning
> to is http://vite.gforge.inria.fr/

An alternative option would be to use Intel Amplifier (former Intel VTune) for 
which we have an integration with HPX as well. Let me know if you would like to 
try that for more information.

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


> 
> JB
> 
> 
> 
> 
> 
> From: hpx-users-boun...@stellar.cct.lsu.edu [mailto:hpx-users-
> boun...@stellar.cct.lsu.edu] On Behalf Of Tobias Gauweiler
> Sent: 01 September 2017 13:42
> To: hpx-users@stellar.cct.lsu.edu
> Subject: [hpx-users] Questions about benchmarking hpx tasks
> 
> Hello,
> 
> i want to benchmark my hpx application and i'm not sure what's the best
> way to do this.
> 
> My goal is to create a gantt chart with the x axis for the time and y axis
> for the hpx worker thread ids
> and then adding boxes for each task to their corresponding hpx worker id
> with the task computation time as length in x direction.
> 
> The application runs on only one locality.
> 
> Questions:
> 
> 1.) If a task got suspended and then resumed is the hpx worker id still
> the same? If not is there a unique identifier for tasks that i can use
> instead?
> 
> 2.) How to measure the computation time of each task? Should i write my
> own performance counter or  save the start and end time per task manually?
> 
> 
> Best regards
> Tobias Gauweiler

___
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 ?

[Hartmut Kaiser]

Jean-Loup,

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

Well, channel is actually more than a concurrent queue. It currently allows for 
out-of-order insertion/extraction of elements (it's essentially a concurrent 
map with an asynchronous interface). But Thomas  is right, conceptually, 
channel exposes exactly the interface you're looking for and it should be 
possible to create a variation on the channel-theme based on a 'real' queue. 
This might give you better performance than the generic channel we have today.

For the current channel implementation, please see [1], for an example see [2].

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

[1] https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/lcos/local/channel.hpp
[2] 
https://github.com/STEllAR-GROUP/hpx/blob/master/examples/quickstart/local_channel.cpp

> 
> 
> 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] Receiving action arguments on pinned memory

[Hartmut Kaiser]

Jean-Loup,

> I am currently trying to use HPX to offload computationally intensive
> tasks to remote GPU nodes. In idiomatic HPX, this would typically be done
> by invoking a remote action:
> 
> OutputData compute(InputData input_data)
> {
> /* Asynchronously copy `input_data` to device using DMA */
> /* Do work on GPU */
> /* Copy back the results to host */
> return results;
> }
> 
> HPX_PLAIN_ACTION(compute, compute_action);
> 
> // In sender code
> auto fut = hpx::async(compute_action(), remote_locality_with_gpu,
> std::move(input_data));
> 
> So far, so good.
> 
> However, an important requirement is that the memory allocated for the
> input data on the receiver end be pinned, to enable asynchronous copy
> between the host and the GPU. This can of course always be done by copying
> the argument `input_data` to pinned memory within the function body, but I
> would prefer to avoid any superfluous copy in order to minimize the
> overhead.
> 
> Do you know if it is possible to control within HPX where the memory for
> the input data will be allocated (on the receiver end) ? I tried to use
> the `pinned_allocator` from the Thrust library for the data members of
> `InputData`, and although it did its job as expected, it also requires to
> allocate pinned memory on the sender side (for the construction of the
> object), as well as the presence of the Thrust library and the CUDA
> runtime on both machines. This led me to think that there should be a
> better way.
> 
> Ideally, I would be able to directly deserialize the incoming data into
> pinned memory. Do you know if there is a way to do this or something
> similar in HPX ? If not, do you think it is possible to emulate such
> functionality by directly using the low-level constructs / internals of
> HPX ? This is for a prototype, so it is okay to use unstable /
> undocumented code as long as it allows me to prove the feasibility of the
> approach.
> 
> I would greatly appreciate any input / suggestions on how to approach this
> issue. If anyone has experience using HPX with GPUs or on heterogeneous
> clusters, I would be very interested in hearing about it as well.

The solution for this all depends on the InputData type you're using. 

All arguments to actions are created by the (de-)serialization layer in HPX.
Normally those are first default constructed and then 'filled' by the
corresponding (de-)serialization function.

That means that in order for you to place the data into pinned memory, your
InputData type needs to know how to access your pinned memory and needs to
perform the allocation itself before the actual data is deserialized. 

The easiest would probably be to use HPX's serialize_buffer [1] which can be
customized using a C++ allocator. The other benefit of serialize_buffer is
that it supports almost perfect zero-copy semantics avoiding internal data
copies (it is 100% zero copy on the sender side, but for arcane reasons
still requires one additional copy on the receiver). A 100% zero-copy
solution would require John's RDMA object.

Using serialize_buffer should be straight-forward if you have the liberty to
use it as your InputData type. You'd still need to create a C++ allocator
which is allocating memory from your pinned memory (John has that buried
inside his RDMA_object, it might be possible to extract that, otoh - writing
an allocator is not too difficult). 

So, assuming you have a pinned_memory_allocator the code would roughly look
like:

using allocator_t = pinned_memory_allocator;
using buffer_t = hpx::serialization::serialize_buffer;

OutputData compute(buffer_t && input_data)
{
/* Asynchronously copy `input_data` to device using DMA */
async_transfer(input_data.data(), input_data.size());
...
/* Do work on GPU */
/* Copy back the results to host */
return results;
}
 
HPX_PLAIN_ACTION(compute, compute_action);

// In sender code

// allocate array of 1000 doubles using 'alloc'
allocator_t alloc;
buffer_t buff(1000, alloc);

// fill buff by accessing the underlying array using buff.data() 
// and buff.size()
// serialize_buffer also supports operator[]

auto fut = hpx::async(compute_action(), 
   remote_locality_with_gpu, std::move(input_data));

This will allocate both, the sender buff and the received input_data using
your pinned memory allocator (if invoked remotely), and will simply turn
into a pointer copy for local invocations.

Note, that serialize_buffer behaves very similar to a shared_ptr, i.e. it
exposes reference-counted shallow-copy semantics.

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

[1]
https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/runtime/serialization/s
erialize_buffer.hpp


___
hpx-users mailing list
hpx-users@stellar.cct.lsu.edu

Re: [hpx-users] Combine HPX and openmp-based library

[Hartmut Kaiser]

Patrick,

> as you may know I am working on an computational mechanics code based on
> HPX. Now I finished the basic implementation in C++ and now started to
> use HPX for the parallelism. One big issue is that application is based
> on linear algebra including solving a large equation system which of
> course is the bottle net of the application.
> 
> Is there any way to use a library which uses openmp inside of HPX? I am
> know using libeigen for the linear algebra part and what I like to use
> its parallel solver inside a future.
> 
> What is the best way to combine HPX with openmp?
> 
> I think finding a solution for the integration of parallel linear
> algebra libraries would be an huge improvement for HPX in application in
> computational engineering.

There is https://github.com/STEllAR-GROUP/hpxMP. This should allow to use both, 
OpenMP and HPX in the same application.

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

Re: [hpx-users] HPX and Raspberry Pi

[Hartmut Kaiser]

Hey Shaul,

> I took a look on your library and its great, thanks a lot for it :)
> I wonder if there is a compilation \ using manual for the Raspberry Pi, as
> I saw its mention you made it work there.
> I google it, and can't find a direct reference to it.
> Do you have a performance best practices for using HPX generally and
> specifically in the Pi.

We have no regular users for HPX on the Raspberry Pi. However we know that some 
people have managed to use it on this platform. I'm cc'ing Daniel Estermann who 
just used HPX on the Pi for his bachelors thesis. He might be able to give you 
more details about his experience and results.

Also, we have currently a student (Jesse Goncalves) visiting LSU for the summer 
who is planning to implement some (simple) HPX application on a cluster of Pis. 
I'm cc'ing him as well.

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

Re: [hpx-users] parallel::for_each over partitioned_vectors

[Hartmut Kaiser]

Chris,

> I hit an issue this week while working with parallel::for_each over
> partitioned_vectors. parallel::for_each works well over std::vector types
> but, when attempting to perform a parallel::for_each over
> partitioned_vectors, gcc complains that the lambda function I'm supplying
> isn't a structure with an overloaded operator().

That's one of the unfortunate limitations of C++ we run into. The function 
object used with partitioned_vector has to be serializable as it is sent to all 
the partitions, possibly on another locality. However, C++ does not allow for 
us to serialize lambdas, even more so if the lambda has a non-empty capture 
clause.

The work around for this (and I really hope the committee will find a way to 
fix this while adding reflection capabilities to the language) is to use 
explicit function objects:

struct pass_through
{
int& value;

int operator()(int) const
{
return value;
}

template 
void serialize(Archive& ar, unsigned)
{
ar & value;
}
};

std::vector vec(100);
int value = 100;
hpx::parallel::transform(
  hpx::parallel::execution::par,
  std::begin(vec),
  std::end(vec),
  std::begin(vec),
  pass_through{value}
);

If the function object has no members (it is empty, i.e. the corresponding 
lambda would have no captures) you can omit the serialize() function as we 
generate that for you.

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


> The code below works well:
> std::vector vec(100);
> int value = 100;
> hpx::parallel::transform(
>   hpx::parallel::execution::par,
>   std::begin(vec),
>   std::end(vec),
>   std::begin(vec),
>   [](int val) {
> return value;
>   });
> 
> hpx::parallel::for_each(
>   hpx::parallel::execution::par,
>   std::begin(vec),
>   std::end(vec),
>   [](int val) {
> hpx::cout << val << hpx::endl;
>   });
> The code below fails to compile:
> 
> hpx::partitioned_vector vec(100,
> hpx::container_layout(hpx::find_all_localities()));
> vec.register_as("intvectors");
> 
> int value = 100;
> 
> hpx::parallel::transform(
>   hpx::parallel::execution::par,
>   std::begin(vec),
>   std::end(vec),
>   std::begin(vec),
>   [](int val) {
> return value;
>   });
> 
> hpx::parallel::for_each(
>   hpx::parallel::execution::par,
>   std::begin(vec),
>   std::end(vec),
>   [](int val) {
> hpx::cout << val << hpx::endl;
>   });
> gcc throws a compiler error on the line where the for_each is supplied the
> lambda. The error implies that parallel::for_each requires/expects a data
> type similar to std::plus() with an overloaded operator().
> Did I make an error, find a new error, or is this an edge case?
> V/r,
> Chris


___
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

[Hartmut Kaiser]

Tobias,

> thank you all very much for your replies.
> 
> @Hartmut
> I did add the code you suggested and the result is the same as before.
> 
> @Praveen, Thomas
> I am using Ubuntu 17.04 with gcc 6.3.0.
> 
> I did try it with disabled stack protector with a new clean build and get
> the same result as before.
> make VERBOSE=1 shows me that the compiler gets called with the flag
> (/usr/bin/c++ -g -fno-stack-protector -Wall .) for Container and main
> so it should be disabled.

Are you sure you deleted the old binaries before rebuilding? Did you have HPX 
and your example installed? If yes, please remove those binaries as well. Also, 
please rebuild HPX with the stack protector disabled as well.

> I did look again at the hello_world_component example and the hello.sh
> bash script that compiles it.
> The -fno-stack-protector flag is not set and it compiles and runs without
> a problem on my machine.
> So if its the gcc stack protection shouldn't it fail too?
> 
> The only differences i see between the example and my code is that the
> example uses a struct and i am using a class.
> Also the example uses typedef while i am using "using" as stated in
> the docu

If it's the same code it should behave the same...
I tried your code on my machine and all runs well. So I'm at a loss what's 
causing this for you :/

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

> 
> Best Regards,
> Tobias
> 
> On 2 June 2017 at 08:06, Thomas Heller  wrote:
> 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


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

Re: [hpx-users] GSoC

[Hartmut Kaiser]

> I want to start coding from tomorrow (29-May-2017)(sunday).

Cool!

> This is my first phase plan:
>   Implementing cyclic domain map : That is creating cyclic
> distribution policy for the creating components on different
> localities.The class that takes Component type and the target localities
> using overloads of (hpx::find_here(), hpx::find_all_localities) as a
> template parameters. And creates the instance of component type on all
> localities using parallel for loops as the operation is completely
> independent of each other.
> And other possible overloads are create ' n ' number of components on
> given localities.
>1)  If n < localities.size() ->
> Create components n on the localities (i.e create  5 component  instance
> of type T over 10 localities means - The domain map class creates 5
> component instance on 5 localities (one per each localities). In this case
> the cyclic property does not hold.
>2)  If n > localities.size()  ->
> (i.e create 5 component instance  of type T over 4 localities means - The
> domain map class creates 5 component instance on  4 localities ( one per
> each locality and then again cycles , create an instance in 1 locality
> once again ).
> The class domain maps contains a vector of id's of components - it
> contains the component - id's  of components created under cyclic
> distribution policy.
> And also want to create an iterator over the vector for accessing the
> component instance created.And also want to maintain an unordered map to
> support the functionality of find_owner(). It returns the locality id for
> the given component id.

A distribution_policy is a type which exposes a certain fixed interface. Please 
have a look at the existing distribution policies to see what functions you 
will have to implement. As outlined before, currently those are two groups of 
functions: a) functions for creating components, and b) functions for invoking 
actions. The former (a) is what you should focus on as the latter (b) might get 
removed from the Concept of a distribution policy in the future.

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

Re: [hpx-users] hpx::finalize hanging

[Hartmut Kaiser]

Chris,

> Apologies that the sample I submitted was grossly inaccurate. I'll be more
> thorough in the future with code samples (instead of shooting from the
> hip). Thank you for the update - I've been using the official version
> 1.0.0 with MPI parcelport. I'll be updating my runtime system build soon!

Thanks for this information. Please let us know if this solves your problem.

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

> 
> V/r,
> Chris
> 
> 
> On Tue, May 23, 2017 at 7:37 PM, Hartmut Kaiser <hartmut.kai...@gmail.com>
> wrote:
> > Ran into an issue where an HPX action that I've been executing under
> > hpx::parallel::transform (in lieu of hpx::parallel::for_each) hangs on
> the
> > hpx::finalize() call. Are there any troubleshooting or debugging
> > techniques that could be used to figure out how to resolve this issue?
> I'm
> > using 1.0.0.
> > static void run(const size_t idx) {
> >   hpx::cout << idx << hpx::endl;
> > }
> > HPX_PLAIN_ACTION(run, run_action);
> > int hpx_main(int argc, char **argv) {
> > std::vector idx_list;
> > // fill idx_list with numbers to print ...
> >
> > std::vector< hpx::future > futures;
> > futures.reserve(idx_list.size());
> > hpx::parallel::transform(
> >   hpx::parallel::par,
> >   std::begin(idx_list),
> >   std::end(idx_list),
> >   [, ] (idx) {
> > auto loc = localities[distarr.get_partition(idx)];
> > return hpx::async(loc, idx);
> >   });
> > hpx::wait_all(futures);
> > // printing debug statements after the hpx::wait_all demonstrate the
> > hpx::wait_all has completed successfully
> >
> > hpx::finalize();
> >
> > }
> >From what I can see you actually never store the futures returned from
> async() in to the 'futures' vector.
> 
> Also, I'm surprised this code even compiles as the lambda returns a
> future which transform will attempt to assign to the current element
> (which is a size_t).
> 
> I'd assume the actual code you're running looks like:
> 
> int hpx_main(int argc, char **argv) {
>   std::vector idx_list;
>   // fill idx_list with numbers to print ...
> 
>   std::vector< hpx::future > futures(idx_list.size());
>   futures.reserve(idx_list.size());
> 
>   hpx::parallel::transform(
> hpx::parallel::par,
> std::begin(idx_list),
> std::end(idx_list),
> std::begin(futures), // <-- is this missing above?
> [, ] (idx) {
>   auto loc = localities[distarr.get_partition(idx)];
>   return hpx::async(loc, idx);
> });
>   hpx::wait_all(futures);
> 
>   return hpx::finalize();
> }
> 
> In which case I wouldn't see any problems with the code :/ Can you show me
> the full code, please (feel free to send it to me privately, if you don't
> want to share it on the list).
> 
> Hold on - there is an idea. We just fixed a shutdown problem (hang) which
> was occurring under certain circumstances (see https://github.com/STEllAR-
> GROUP/hpx/commit/ab353f656a08f3426224b4e86fa9715a52afd8ec), that was about
> 10 days ago. What version of HPX do you use?
> 
> 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::finalize hanging

[Hartmut Kaiser]

> Ran into an issue where an HPX action that I've been executing under
> hpx::parallel::transform (in lieu of hpx::parallel::for_each) hangs on the
> hpx::finalize() call. Are there any troubleshooting or debugging
> techniques that could be used to figure out how to resolve this issue? I'm
> using 1.0.0.
> static void run(const size_t idx) {
>   hpx::cout << idx << hpx::endl;
> }
> HPX_PLAIN_ACTION(run, run_action);
> int hpx_main(int argc, char **argv) {
> std::vector idx_list;
> // fill idx_list with numbers to print ...
> 
> std::vector< hpx::future > futures;
> futures.reserve(idx_list.size());
> hpx::parallel::transform(
>   hpx::parallel::par,
>   std::begin(idx_list),
>   std::end(idx_list),
>   [, ] (idx) {
> auto loc = localities[distarr.get_partition(idx)];
> return hpx::async(loc, idx);
>   });
> hpx::wait_all(futures);
> // printing debug statements after the hpx::wait_all demonstrate the
> hpx::wait_all has completed successfully
> 
> hpx::finalize();
> 
> }

>From what I can see you actually never store the futures returned from 
>async() in to the 'futures' vector. 

Also, I'm surprised this code even compiles as the lambda returns a 
future which transform will attempt to assign to the current element 
(which is a size_t).

I'd assume the actual code you're running looks like:

int hpx_main(int argc, char **argv) {
  std::vector idx_list;
  // fill idx_list with numbers to print ...
 
  std::vector< hpx::future > futures;
  futures.reserve(idx_list.size());

  hpx::parallel::transform(
hpx::parallel::par,
std::begin(idx_list),
std::end(idx_list),
std::begin(futures), // <-- is this missing above?
[, ] (idx) {
  auto loc = localities[distarr.get_partition(idx)];
  return hpx::async(loc, idx);
});
  hpx::wait_all(futures);

  return hpx::finalize();
}

In which case I wouldn't see any problems with the code :/ Can you show me the 
full code, please (feel free to send it to me privately, if you don't want to 
share it on the list).

Hold on - there is an idea. We just fixed a shutdown problem (hang) which was 
occurring under certain circumstances (see 
https://github.com/STEllAR-GROUP/hpx/commit/ab353f656a08f3426224b4e86fa9715a52afd8ec),
 that was about 10 days ago. What version of HPX do you use?

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

Re: [hpx-users] primary_namespace::resolve_grid

[Hartmut Kaiser]

Chris,

Sorry for the late reply.

> I've an application that is running a dataflow of asynchronous functions
> over a linear sequence of doubles stored in a partitioned_vector.
> 
> The application processes a fair number of elements before causing a
> segmentation fault. Upon inspection of the core file, the segmentation
> fault is happening when
> hpx::agas::server::primary_namespace::resolve_gid(hpx::naming::gid_type)
> () from libhpx.so.1 is called by the runtime.
> I've compiled the HPX runtime using the MPI ParcelPort. The application is
> running on a single remote node (using slurm for scheduling).
> Any suggestions or recommendations of how to further debug the application
> or any runtime flags to help further diagnose implementation errors would
> be appreciated.

That is very difficult to diagnose from the distance. It looks like that 
something went out of scope too early and an attempt to access it went hiwire. 
Can you give us the code to have a closer look?

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

Re: [hpx-users] Gsoc

[Hartmut Kaiser]

Praveen,

> I'm getting familiar with some code base day by day.Each day I'm trying to
> do  my best .I find that the code base is larger but I can't able to
> correctly figure it out which parts of the library I will use for
> distributed component placement project. I have also installed chapel in
> rostam so I can use it for learning the behaviors of domain maps over a
> clusters. I want to design the outline and implementation details of the
> project as soon as possible. For that I want to know what exactly hpx
> wants from domain maps of course yes,I designed my proposal by referencing
> so many things and got a OVERALL plan.But I'm lacking many things I guess.
> Yes, I do have plans about the project but I don't know how to fix it with
> hpx.
> Next is building allocators over domain maps. Actually I didn't use any
> custom allocators for my college projects,Can you please share some good
> reading on those topics.I believe that soon I will design the project
> (mostly in terms of diagrams so it can speak well than words). Any
> suggestions and advices about project is highly welcomed. I hope I will do
> my best to complete the project.

The key for this project is to understand distribution policies. The plan is to 
use those to manage the distribution of components. They are also used (amongst 
other things) by partitioned vector to determine where its partitions are 
allocated.

We have several distribution policies implemented in HPX:

default_distribution_policy 
(https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/runtime/components/default_distribution_policy.hpp)
binpacking_distribution_policy 
(https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/runtime/components/binpacking_distribution_policy.hpp)
target_distribution_policy 
(https://github.com/STEllAR-GROUP/hpx/blob/master/hpx/runtime/components/target_distribution_policy.hpp)

A distribution policy is an object which exposes two functions:

struct example_distribution_policy
{
template 
hpx::future create(Ts&&... vs) const
{
// Create an instance of the given Component.
// The policy decides where to create the component 
// instance.
// Return a future referring to the newly 
// created instance
}

// A bulk_locality_result holds all id_types for the newly
// created Component instances associated with the locality
// where they were created.
using bulk_locality_result = 
std::pair;

template 
hpx::future
bulk_create(std::size_t count, Ts&&... vs) const
{
// Create multiple Component instances on the localities 
// associated by this policy.
}

// this might not be necessary
std::size_t get_num_localities() const
{
// Return the number of localities this policy knows about.
}

// this might not be necessary
hpx::id_type get_next_target() const
{
// Return the locality which is anticipated to be used for 
// the next create operation.
}
};

The existing distribution policies also expose a couple of function related to 
task execution (async, async_cb, etc.), but I think those sdon't belong here 
and should be removed (and encapsulated by special executors). So for now I'd 
suggest you ignore those for your work. 

The bottom line is that for you project you should consider creating one (or 
more) distribution policies which encapsulate the functionality you envision.

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

Re: [hpx-users] task creation

[Hartmut Kaiser]

Praveen,

> I have doubt regarding task creation when creating nested futures like

Sorry, I'm not sure what you're asking about.

> 1. future.then(another_task.then(another_task.then(...)))

This will not work. Future::then() returns another future which represents the 
result of the execution of the attached continuation.

future f1 = ...
future f2 = f1.then([](future f) -> T2 { f.get(); return T2{}; } );

which allows to chain things:

future f3 = f2.then([](future f) -> T3 { f.get(); return T3{}; } );
...

> 2. futures inside the loop based on previous iteration (eg  future[i] =
> future[i-1].then(something))

This is just a variation to what I showed above.

> Does this have different task-creation techniques? I found it in one of
> the tutorials videos by john biddiscombe and thomas heller.
> Could anyone please explain me?

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

Re: [hpx-users] dataflow sequential processing

[Hartmut Kaiser]

Chris,

> I'm doing some experiments with hpx::dataflow and would like to
> recursively "chain" a dataflow for execution over a distributed vector of
> size_t elements.
> Sample code is provided below (apologies if it's not a perfect compile):
> static void run(
>   std::string nom,
>   size_t v) {
>   hpx::cout << v << hpx::endl;
> }
> 
> HPX_PLAIN_ACTION(run, run_action);
> 
> static hpx::future run_dataflow(
>   std::string nom,
>   hpx::partitioned_vector ,
>   std::vector locs,
>   std::vector::iterator curr,
>   std::vector::iterator end) {
> hpx::future res = (curr != end) ? run_dataflow(nom, arr, locs,
> std::next(curr), end) : hpx::make_ready_future();
> return hpx::dataflow(
>   hpx::util::unwrapped([nom, , localities, ] () ->
> hpx::future {
> size_t v = *c;
> return hpx::async(localities[arr.get_partition(v)], nom,
> v);
>   }),
>   std::move(res) );
> 
> }
> 
> int main(int argc, char **argv) {
> ... /* dvec_size is defined up here */ ...
> 
> std::vector locs = hpx::find_all_localities();
> std::string nom = "arr_nom";
> hpx::partitioned_vector arr(dvec_size,
> hpx::container_layout(locs));
> arr.register_as(nom);
> 
> std::vector pos;
> std::iota(
>   std::begin(pos),
>   std::end(pos),
>   dvec_size);
> 
> hpx::future fd = run_dataflow(
>   nom,
>   arr,
>   std::begin(pos),
>   std::end(pos) );
> fd.wait();
> 
> }
> I've been getting a runtime errors for this code (segmentation fault) -
> this is probably a semi-trivial bug or misunderstanding on my part - any
> help/assistance would be appreciated. (I'm compiling against HPX with MPI)

The main reason for this kind of problems is that variables which are captured 
by reference into a lambda (or similar) go out of scope before the lambda 
itself is being executed:

void foo()
{
vector bar = {...};
return async([]() { bar.push_back(42); });
}

foo();

In this example, the variable 'bar' is not valid anymore when the lambda (which 
is scheduled as a new thread) is eventually executed. Please note, that 
dataflow() runs the function passed to it on a new thread as well.

I'd assume that in your example the variable 'arr' goes out of scope before the 
lambda referencing it is run.

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


> 
> V/r,
> Chris

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

Re: [hpx-users] Gsoc 2017

[Hartmut Kaiser]

> This is my blog for gsoc 2017  ->
> https://parallellisa.blogspot.in/  please watch out suggest some
> corrections.

Cool, thanks! Keep it coming!

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

Re: [hpx-users] Troubleshooting (lack of) parallel execution

[Hartmut Kaiser]

> GitHub link in my original email

Sure, I saw that. This code is not really minimal, however... Could you try to 
reduce it down to not more than a couple of dozen lines, please?

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


> Get Outlook for Android
> 
> 
> 
> On Mon, May 1, 2017 at 12:04 PM -0400, "Hartmut Kaiser"
> <hartmut.kai...@gmail.com> wrote:
> Shmuel,
> 
> > Thanks for the quick reply. It appears that I was not completely clear
> in
> > my original question. Specifically, I seem to have the same problems
> > regardless of whether or not I'm using MKL. The separate matrix
> > multiplication test code that I wrote was for the purposes of
> determining
> > whether or not MKL was the cause of these issues.
> > Based on cpu usage and on timing of each of the three cases, I'm still
> > finding that:
> > 1) cpu usage is not more than 100%
> > 2) the sequential version of the multiplication function runs faster
> than
> > the parallel and vectorized versions.
> > As mentioned, changing the hpx:threads argument only adds overhead and
> > makes the code run much slower.
> 
> Could you give me a small test code which reproduces the problem, pease?
> 
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
> 
> 
> > Thanks
> > From: Hartmut Kaiser
> > Sent: Monday, May 1, 7:40 AM
> > Subject: Re: [hpx-users] Troubleshooting (lack of) parallel execution
> > To: hpx-users@stellar.cct.lsu.edu
> > Shmuel, > I'm looking for some help in understanding why my code does
> not
> > appear to > be executing in parallel with the HPX system. The only
> reason
> > I could think of for the strange behavior you're seeing would be that
> > you're using the parallel version of MKL. MKL is parallelized using
> openmp
> > and there is no way (AFAIK) to tell it to just use part of the machine.
> So
> > it will try to use all of the cores of the node you're running on. That
> in
> > turn interferes with HPX's way of binding it's worker-threads to the
> cores
> > itself. We have had good results when using MKL with HPX, but only if
> you
> > link with the sequential (non-parallel) version of MKL and leave all the
> > parallelization to HPX (by scheduling more than one MKL task at the same
> > time, if necessary. I have no experience with VML, but I'd assume it's
> the
> > same issue. HTH Regards Hartmut --- http://boost-spirit.com
> > http://stellar.cct.lsu.edu > I've first noticed the issue while working
> on
> > my main codebase, in which > I've been trying to implement a genetic-
> > algorithm-based optimizer for non- > linear systems. Since that code (at
> > the present time) uses Intel MKL > (BLAS level 3 library functions) and
> > VML (vector math library), in > conjunction with HPX futures, dataflow,
> > etc., I wasn't sure if there was > some problem caused by OpenMP or
> > something similar, which might have > prevented the code from running in
> > parallel. > > I then wrote a simpler test program using only HPX
> parallel
> > algorithms to > implement basic matrix-matrix multiplication. I found
> the
> > exact same > result in both cases - my program does not appear to be
> > running any of the > concurrent code -- neither in the case of my
> original
> > program using > futures, continuations, and dataflow lcos, nor in the
> > simplified matrix > code. > > I've tried using different options for --
> > hpx:threads, but when this number > is greater than 1, I've found that
> the
> > overhead of thread creation and > scheduling is exceedingly high and
> slows
> > down the entire program > execution. I'm not sure if that is typical
> > behaviour -- I have tried to > ensure that the amount of computation
> > within a given asynchronous function > call is fairly substantial so
> that
> > the real work is far in excess of any > overhead (although I may have
> > under-estimated). Typically, in the case of > my code, the concurrency
> is
> > at the genetic-algorithm 'population' level - > for example, the
> following
> > code snippet is where I generate random numbers > for the crossover step
> > of differential evolution. fitter_state_ is a > boost::shared_ptr. (The
> > random number generator engines are set-up > elsewhere in the code and
> > there are 1 for each trial vector, to ensure > that the code is thread-
> > safe). I realize that the code below does not > need to use dataflow,

Re: [hpx-users] Troubleshooting (lack of) parallel execution

[Hartmut Kaiser]

Shmuel,

> Thanks for the quick reply. It appears that I was not completely clear in
> my original question. Specifically, I seem to have the same problems
> regardless of whether or not I'm using MKL. The separate matrix
> multiplication test code that I wrote was for the purposes of determining
> whether or not MKL was the cause of these issues.
> Based on cpu usage and on timing of each of the three cases, I'm still
> finding that:
> 1) cpu usage is not more than 100%
> 2) the sequential version of the multiplication function runs faster than
> the parallel and vectorized versions.
> As mentioned, changing the hpx:threads argument only adds overhead and
> makes the code run much slower.

Could you give me a small test code which reproduces the problem, pease?

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


> Thanks
> From: Hartmut Kaiser
> Sent: Monday, May 1, 7:40 AM
> Subject: Re: [hpx-users] Troubleshooting (lack of) parallel execution
> To: hpx-users@stellar.cct.lsu.edu
> Shmuel, > I'm looking for some help in understanding why my code does not
> appear to > be executing in parallel with the HPX system. The only reason
> I could think of for the strange behavior you're seeing would be that
> you're using the parallel version of MKL. MKL is parallelized using openmp
> and there is no way (AFAIK) to tell it to just use part of the machine. So
> it will try to use all of the cores of the node you're running on. That in
> turn interferes with HPX's way of binding it's worker-threads to the cores
> itself. We have had good results when using MKL with HPX, but only if you
> link with the sequential (non-parallel) version of MKL and leave all the
> parallelization to HPX (by scheduling more than one MKL task at the same
> time, if necessary. I have no experience with VML, but I'd assume it's the
> same issue. HTH Regards Hartmut --- http://boost-spirit.com
> http://stellar.cct.lsu.edu > I've first noticed the issue while working on
> my main codebase, in which > I've been trying to implement a genetic-
> algorithm-based optimizer for non- > linear systems. Since that code (at
> the present time) uses Intel MKL > (BLAS level 3 library functions) and
> VML (vector math library), in > conjunction with HPX futures, dataflow,
> etc., I wasn't sure if there was > some problem caused by OpenMP or
> something similar, which might have > prevented the code from running in
> parallel. > > I then wrote a simpler test program using only HPX parallel
> algorithms to > implement basic matrix-matrix multiplication. I found the
> exact same > result in both cases - my program does not appear to be
> running any of the > concurrent code -- neither in the case of my original
> program using > futures, continuations, and dataflow lcos, nor in the
> simplified matrix > code. > > I've tried using different options for --
> hpx:threads, but when this number > is greater than 1, I've found that the
> overhead of thread creation and > scheduling is exceedingly high and slows
> down the entire program > execution. I'm not sure if that is typical
> behaviour -- I have tried to > ensure that the amount of computation
> within a given asynchronous function > call is fairly substantial so that
> the real work is far in excess of any > overhead (although I may have
> under-estimated). Typically, in the case of > my code, the concurrency is
> at the genetic-algorithm 'population' level - > for example, the following
> code snippet is where I generate random numbers > for the crossover step
> of differential evolution. fitter_state_ is a > boost::shared_ptr. (The
> random number generator engines are set-up > elsewhere in the code and
> there are 1 for each trial vector, to ensure > that the code is thread-
> safe). I realize that the code below does not > need to use dataflow,
> although I'm skeptical that this would be the cause > for the code not
> running in parallel. > > size_t trial_idx = 0; > CR_population_type
> _vector_current = > fitter_state_->crossover_vector_set_[fitter_state_-
> > >Current_Index()]; > > for (future_type _vector :
> CR_vector_current) > { > crossover_vector =
> hpx::dataflow(hpx::launch::async, [=]() { > auto  = fitter_state_-
> >cr_RNGs[trial_idx]; > modeling::model_fitter_aliases::CR_vector_type
> cr_vector_; // > cr_vector is of type std::vector >
> cr_vector_.reserve(total_number_of_parameters_); > >
> std::uniform_int_distribution CR_dist( > 0, fitter_state_-
> >crossover_range); > > for (int param_idx = 0; param_idx <
> total_number_of_parameters_; > ++param_idx) { >
> cr_vecto

Re: [hpx-users] FW: Applying machine learning techniques on HPX algorithms

[Hartmut Kaiser]

> Our focus in the Summer is to implement our technique on a distributed
> applications. This ML algorithms are a basic ML algorithms, which we have
> implemented logistic regression model so far.
> We have introduces a new ClangTool which make runtime technique, such as
> for_each, to implement ML algorithms for selecting its parameters, such as
> chunk size.
> 
> Madhavan, as I remember you told me that you have already submit a
> proposal for another project, am I right?
> And far as I know, a student cannot work on more than one project, and
> s/he will not be paid for more than one.
> So, I am not sure if you can work on two projects at the same time.

An alternative possibility would be to look at the existing solutions (as 
described above) and to devise a method for the user to be able to train the 
used models using his/her own applications.

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

> 
> 
> 
> 
> Best Regards,
> 
> Zahra Khatami | PhD Student
> Center for Computation & Technology (CCT)
> School of Electrical Engineering & Computer Science
> Louisiana State University
> 2027 Digital Media Center (DMC)
> Baton Rouge, LA 70803
> 
> 
> On Sun, Apr 2, 2017 at 1:10 AM, #SESHADRI MADHAVAN#
>  wrote:
> Hi Zahra,
> 
> I had a brief look at the code. Can I understand the direction in which
> you want to proceed with the project?
> 
> Currently, I see that a few basic algorithms have been implemented over
> the hpx framework. So, am I right to assume that more basic algorithms are
> to be implemented on top of the hpx framework?
> 
> Best Regards,
> Madhavan
> 
> From: #SESHADRI MADHAVAN#
> Sent: Friday, March 31, 2017 12:34 AM
> To: 'Zahra Khatami' ; hpx-users@stellar.cct.lsu.edu
> Subject: RE: [hpx-users] Applying machine learning techniques on HPX
> algorithms
> 
> Hi Zara,
> 
> I have already submitted a proposal for HPX (HPXCL), so I won’t be
> submitting for this one.
> 
> But I shall chip in contribution for this one as well as I find this to be
> an interesting area. My summer is currently free, so I shouldn’t have a
> problem in contributing to this in addition to HPXCL. I will begin by
> taking a look at the code base [1] and shall discuss further with you.
> 
> Best Regards,
> Madhavan
> 
> [1] https://github.com/STEllAR-GROUP/hpxML
> 
> From: Zahra Khatami [mailto:z.khatam...@gmail.com]
> Sent: Friday, March 31, 2017 12:25 AM
> To: hpx-users@stellar.cct.lsu.edu; #SESHADRI MADHAVAN#
> 
> Subject: Re: [hpx-users] Applying machine learning techniques on HPX
> algorithms
> 
> Hi Madhavan,
> 
> Thank you for your interest. I would be happy to work with you on this
> project.
> This project is mainly about combining machine learning techniques,
> compiler optimizations and runtime methods, which is a new and super
> interesting idea for our group at least ;)
> We have implemented a major part in connecting these three areas together.
> However, we have tested it on a single node, not on a distributed
> version.
> As you have worked with Hadoop, so I believe that you have a good
> background in a distributed computing area.
> For the next step of this project, focused on a Summer, we plan to
> implement our proposed techniques on a distributed applications. The first
> phase of this would be implementing distributed machine learning
> techniques, such NN or SVM.
> Then we can analyze big data and design a learning model for our
> algorithms.
> 
> So please start writing your proposal, emphasize on extending ideas about
> implementing distributed machine learning techniques with HPX and
> targeting them for tying compiler and runtime techniques.
> The proposal should be submitted before deadline (April 3rd). So I would
> suggest you to give me a first draft earlier, so we can work together for
> its final submission.
> 
> 
> 
> Best Regards,
> 
> Zahra Khatami | PhD Student
> Center for Computation & Technology (CCT)
> School of Electrical Engineering & Computer Science
> Louisiana State University
> 2027 Digital Media Center (DMC)
> Baton Rouge, LA 70803
> 
> 
> On Thu, Mar 30, 2017 at 11:13 AM, #SESHADRI MADHAVAN#
>  wrote:
> Hi Zahra,
> 
> Sorry, for high jacking the previous email thread, changed the subject in
> this one.
> 
> I have proposed the idea for working on HPXCL with Patrick, hence I shall
> not be proposing this as my GSoC project, but I would love to jump into
> "Applying machine learning techniques on HPX algorithms". The project
> seems interesting and I have had some background implementing Machine
> Learning algorithms on Hadoop, predominantly in Java. But I have been
> through the process of designing and optimizing algorithms for execution
> in parallel which I believe will be useful for this. Let me know how I can
> get started.
> 
> Best Regards,
> Madhavan
> 
> From: hpx-users-boun...@stellar.cct.lsu.edu [mailto:hpx-users-
> 

Re: [hpx-users] strange for-loop in hpx::util::find_prefixes() ?

[Hartmut Kaiser]

> thanks for the detailled answer, but I still have a few questions.
> 
> On 2017 M03 30, Thu 17:14:46 CEST Hartmut Kaiser wrote:
> > > On 2017 M03 24, Fri 16:53:03 CEST Hartmut Kaiser wrote:
> > > > Alex,
> > > >
> > > > Sorry for the delay, just as a heads-up: I'll get back to you later
> > > today.
> > > I know it's not fancy, but could you havea look ?
> >
> > Alex, I sincerely apologize for the delay. Too many things are going on
> at
> > the same time.
> >
> > > find_prefix(), according to the code and to the documentation, returns
> > "the installation path of the specified module", i.e. 1 path.
> > > Why is there the need to tokenize that using a PATH_DELIMITER (":"
> here)
> > > and
> > > then iterate over all tokens ? It looks to me like there is always
> exactly
> > > one path ?
> >
> > While find_prefix() may in principle return a list of directories. The
> > original idea was to encode there the build directory and the
> installation
> > directory of the core library.
> 
> Hmm, I'm not sure I understand.
> find_prefix() should return the prefix where the library is installed,
> right ?
> What do you mean with encode "the build dir AND the installation dir" ?
> Shouldn't the install dir be enough ?

HPX runs without being installed as well (i.e. from the build directories).

> A related question, why is HPX_PREFIX adjustable by hpx-using projects
> (e.g.
> in  hpx::init(): util::set_hpx_prefix(HPX_PREFIX);

HPX_PREFIX is a preprocessor macro pointing to the installation directory
(CMAKE_INSTALL_PREFIX). This is a fallback for the platforms where we can't
determine at runtime the directory the executable was launched from.

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

Re: [hpx-users] GSOC

[Hartmut Kaiser]

Praveen,

> In distributed component placement project the project states that we had
> to implement EDSL for placement policies for components. I'm struck in
> designing EDSL for this project and I'm in need of some more information
> in this context like clues and references.Only few days are remaining for
> the proposal submission.Could anyone please help me?

After thinking a bit more about this, I believe while the project idea refers 
to a EDSL, this does not imply that it has to be implemented using template 
meta-programming techniques. I think what is meant by EDSL is rather a 
well-defined API which integrates well with the HPX distribution policies and 
the distributed data structures with the goal to have a means of defining the 
placement of the partitions across the system. As a bonus those could define 
data layout as well, such as striping and striding.

If you look at what chapel provides you'll get a nice overview of what would be 
a good feature set.

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

Re: [hpx-users] Interest in Background Info

[Hartmut Kaiser]

Sonia,

> My name's Sonia Azad, I'm a junior at LSU doing Mathematics & Computer
> Science. I saw your blog post about the Google Summer of Code and am very
> interested. It is actually my first time hearing about this program. I
> just transferred from Carnegie Mellon, and would love to work on something
> in my hometown. This isn't a proposal though since I would just like to
> learn more background first.

What information do you need? 

> I've done a handful of hackathons and have always been interested and able
> to learn new aspects of programming on my own, but I have never done
> anything like this before. I want to stick to the easier topics such
> as the Coroutine-like interface and the arithmetic performance counters.

The coroutines like interface is not as easy as you might think, but the
performance counter are definitely a nice project for somebody starting with
HPX.

> If you have any suggested readings, that would be much appreciated.
> Otherwise, I can handle C++ and I have a strong statistics and probability
> background.

You probably have seen the code (https://github.com/STEllAR-GROUP/hpx), our
docs (http://stellar-group.github.io/hpx/docs/html/), and perhaps our
publications (http://stellar-group.org/publications/). Let us know if you
need more information.

> I will definitely submit an official proposal before the deadline. If
> there is anything else necessary during the application process, please
> let me know. I look forward to hearing back from you!

Cool, looking forward to this!

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

Re: [hpx-users] strange for-loop in hpx::util::find_prefixes() ?

[Hartmut Kaiser]

> On 2017 M03 24, Fri 16:53:03 CEST Hartmut Kaiser wrote:
> > Alex,
> >
> > Sorry for the delay, just as a heads-up: I'll get back to you later
> today.
> 
> I know it's not fancy, but could you havea look ?

Alex, I sincerely apologize for the delay. Too many things are going on at
the same time.

> find_prefix(), according to the code and to the documentation, returns
"the 
> installation path of the specified module", i.e. 1 path.
> Why is there the need to tokenize that using a PATH_DELIMITER (":" here)
and 
> then iterate over all tokens ? It looks to me like there is always exactly
one 
> path ?

While find_prefix() may in principle return a list of directories. The
original idea was to encode there the build directory and the installation
directory of the core library. Frankly, I don't remember why the code
evolved to always return just one directory. So it might be ok to assume
it's always one. Please add an HPX_ASSERT enforcing that if you change the
code.

> Related, later on in that loop, the subdirs "/bin" and "/lib" are
hardcoded.
> Could that be changed to use the result from dll.get_directory() directly 
> instead of trying to reconstruct it ?

dll.get_directory() is not supported on all platforms (Android and Mic
spring to mind). But for those platforms where it's supported we could
derive one of the directory prefixes from the name of the library (/lib).
The /bin directory would have to stay hardcoded, however.


One more remark. Historically we ended up having different directory and
file layouts on Windows compared to the other platforms.

Windows:

   //bin/:  all executables and all dlls
 /bin/hpx:   all plugins (dlls) which are dynamically
loaded
 /lib:   all libraries (libs) for the dlls
 /lib/hpx:   all libraries (libs) for plugin dlls

All other platforms

   /bin/:  all executables
 /lib:   all libraries (.so) 
 /lib/hpx:   all plugins libraries (.so) for 

If you change the hardcoded names to something else, you'd need to adjust
the cmake scripts accordingly.

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

Re: [hpx-users] GSOC 2017

[Hartmut Kaiser]

Praveen,

> I think now I have understood what was the scope of the project and I'm
> starting to write proposal for distributed component placement Project.But
> I have some doubts about implementing EDSL whether I can go for a library
> based solution or I have to design the whole Expression templates model ?

As already mentioned. A library based solution might be advantageous depending 
on the complexity of the EDSL. In any case, I'd advise against Boost.Proto as 
it's too heavyweight. There are other libraries available which are more 
lightweight, if you need one.

> And I also need some Previous gsoc proposals that comes for Stellar
> group  so that I can design my proposal well.

That will not be possible, sorry.

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

Re: [hpx-users] Gsoc 2017

[Hartmut Kaiser]

Praveen,

> The abstract of distributed component placement project says that we can
> select at least one placement police.But I  want to know which placement
> police hpx needs mostly from the user's point of view so that we can give
> it higher priority to implement first. And also suggest me some placement
> policies which are easily integrated with hpx via domain maps.

You might want to look at Chapel for inspirations:

http://chapel.cray.com/tutorials/SC16/03-DataPar.pdf
http://chapel.cray.com/docs/latest/modules/layoutdist.html

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

Re: [hpx-users] GSOC 2017

[Hartmut Kaiser]

> TURN HPX INTO A REPLACEMENT FOR C++ RUNTIME.
> I didn't able to understand it clearly.

HPX currently implements only features of the C++ Standard related to 
concurrency and parallelism. This project targets filling the missing gaps such 
that in the end HPX can be used a s a replacement (or as an alternative) to the 
standard library implementation which comes with your compiler. 

This will probably will boil down to integrate HPX seamlessly with at least one 
of the existing standard library implementations. I'd assume that an important 
precondition for this would be for the student to demonstrate a solid knowledge 
of any of those (libstdc++, libc++, the Microsoft standard library or similar).

> what I have understood is we have to dynamically link hpx libraries to the
> applications during runtime.But it is actually done by dynamic linker
> itself.Please correct me if I am wrong. And please explain me the
> statement to some extend.

Hmmm, that's a misunderstanding. HPX is normally statically linked to an 
application in the same way as is any other C++ library. HPX itself may be used 
as a shared library, though, which might have caused the misconception of it 
being dynamically linked.

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

Re: [hpx-users] [GSoC17] How about combining two vanguard project ideas related in C++17 parallelism?

[Hartmut Kaiser]

> Hi, I'm a student interested in hpx of GSoC 2017.
> I read vanguard project ideas in hpx's github wiki.
> I'm interested in some topics related to C++ standardization and parallel
> programming.
> Anyway, I think "Work on Parallel Algorithms for HPX" and "Add
> Vectorization to par_unseq Implementations of Parallel Algorithms" are
> somewhat related in because they are parts of implementations of the C++17
> parallelism (N4409).
> So, I think it would be a idea to combine these two topics.
> Is there no problem about it?? How do you think about it?

The project ideas on that page are just that ideas and suggestions. I wouldn't 
exclude combining things the way you propose to do.

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

Re: [hpx-users] GSOC 2017

[Hartmut Kaiser]

> I'm interested in c++ runtime replacement project. But I'm missing some
> key piece of information. Information at GSOC projects ideas page is not
> sufficient for me to write a proposal.Could you please share me some more
> resources on that? How many project proposals can each student is eligible
> to submit?

What kind of information are you looking for?

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] FW: build hpx as static lib?

[Hartmut Kaiser]

Forwarding response...

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


> -Original Message-
> From: niXman [mailto:i.nix...@autistici.org]
> Sent: Saturday, March 18, 2017 5:13 PM
> To: hartmut.kai...@gmail.com
> Subject: Re: [hpx-users] build hpx as static lib?
> 
> Hartmut Kaiser 2017-03-18 23:33:
> >  cmake -DHPX_WITH_STATIC_LINKING=ON ...
> >
> > should do the trick. I have nottried that in a while, though. Please
> > report
> > back if you run into any problems with this.
> 
> I faced with link error when "Linking CXX executable
> ../../bin/1d_hydro_upwind"
> 
> 
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-
> gnu/libpthread.a(pthread_create.o):
> In function `allocate_stack':
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/allocatestack.c:475: undefined
> reference to `_dl_stack_flags'
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/allocatestack.c:614: undefined
> reference to `_dl_stack_flags'
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-
> gnu/libpthread.a(ptw-write.o):
> In function `__write_nocancel':
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/../sysdeps/unix/syscall-
> template.S:81:
> undefined reference to `__syscall_error'
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/../sysdeps/unix/syscall-
> template.S:81:
> undefined reference to `__syscall_error'
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-
> gnu/libpthread.a(ptw-read.o):
> In function `__read_nocancel':
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/../sysdeps/unix/syscall-
> template.S:81:
> undefined reference to `__syscall_error'
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/../sysdeps/unix/syscall-
> template.S:81:
> undefined reference to `__syscall_error'
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-
> gnu/libpthread.a(ptw-close.o):
> In function `__close_nocancel':
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/../sysdeps/unix/syscall-
> template.S:81:
> undefined reference to `__syscall_error'
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-
> gnu/libpthread.a(ptw-close.o):/build/eglibc-oGUzwX/eglibc-
> 2.19/nptl/../sysdeps/unix/syscall-template.S:81:
> more undefined references to `__syscall_error' follow
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-
> gnu/libpthread.a(nptl-init.o):
> In function `__pthread_initialize_minimal_internal':
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/nptl-init.c:285: undefined
> reference to `__libc_setup_tls'
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/nptl-init.c:303: undefined
> reference to `_dl_cpuclock_offset'
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/nptl-init.c:419: undefined
> reference to `_dl_pagesize'
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/nptl-init.c:428: undefined
> reference to `_dl_pagesize'
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/nptl-init.c:448: undefined
> reference to `_dl_init_static_tls'
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/nptl-init.c:450: undefined
> reference to `_dl_wait_lookup_done'
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-
> gnu/libpthread.a(nptl-init.o):
> In function `__pthread_get_minstack':
> /build/eglibc-oGUzwX/eglibc-2.19/nptl/nptl-init.c:471: undefined
> reference to `_dl_pagesize'
> 
> 
> I have rerun make with "VERBOSE=1" and can see the "-Wl,-Bstatic
> -lpthread" flag. but it wrong - libpthread cant be linked statically.
> 
> How can I tell cmake not to use "-Wl,-Bstatic -lpthread" flag?
> I'm not familiar with cmake...
> 
> 
> --
> Regards, niXman
> ___
> Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
> https://sf.net/p/mingw-w64/

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

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

[Hartmut Kaiser]

> Is there any way to build HPX as static libraries?

 cmake -DHPX_WITH_STATIC_LINKING=ON ...

should do the trick. I have nottried that in a while, though. Please report
back if you run into any problems with this.

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

Re: [hpx-users] GSOC 2017

[Hartmut Kaiser]

> I had some doubts regarding hpx.
> 1. whether hpx supports lock free programming and relays on sequential
> consistency ?

I'm not sure what you mean. HPX is 'just' a C++ library and it can be used with 
any type of C++ code.
It does not rely on sequential consistency but you can write code which does so.

> 2. which type of c++ memory model hpx is using?

HPX uses the memory model provided by your C++ environment.

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

Re: [hpx-users] [hpx-devel] GSoC Interested in Project:Detecting Stack Overflow in Linux

[Hartmut Kaiser]

Hey Arpan,

> Hi! I am Arpan Parikh from Birla Institute of Technolgy and Science
> (BITS), Pilani
> 
> I am a really enthusiastic person who would like to contribute to the
> project. I have previous experience with C,C++,Bash and using Linux. (I
> have listed some of my work towards the end).I am good at Maths and have
> participated in Indian National Mathematics Olympiad 2014 and was second
> in whole state.I am a quick learner.(As you can see that I have done the
> below mentioned work in my first semester).
> 
> Among the lots of options that were listed on the ideas page  what draws
> me to Stellar is the fact that I have been learning something like this (A
> Certified course on Operating Systems) for quite some time as a part of a
> Studies under a Teaching Assistant at my University and therefore I feel
> that this is the project for me.
> 
> To get familiar with HPX I have gone through
> https://www.youtube.com/watch?v=w7ahj2MrxXE (HPX Tutorial - Supercomputing
> 2015 ) and https://www.youtube.com/watch?v=5rtY4Da4Ec8 ( Modern C++
> Workshop: HPX (C++ libs)).
> 
> I have also followed the installation and basic usage part from
> https://github.com/STEllAR-GROUP/hpx (HPX Documentation) and have a build
> on my machine.
> 
> As of now I have been working with C++ for about an year.
> 
> https://github.com/gucifer
> (Some piece of code that I open sourced.)
> 
> I have also learned a few things about HPX from the Github Wiki and both
> main and research website.I going through a method to detect stack
> overflow by looking at the way microsoft did it with windows(error code
> C0FD) at https://msdn.microsoft.com/en-
> us/library/windows/hardware/ff540620(v=vs.85).aspx and
> http://parallels.nsu.ru/~dkolbin/ntstatus.h
> I wanted to ask you further that you want a similar type of approach  like
> microsoft or are you looking for an alternate method to detect stack
> overflow in linux?
> 
> I believe in the idea of learning by doing.I actively participate in
> Hackathons.In Recently I also made a very basic game(using SFML Library in
> C++) which is at my github account https://github.com/gucifer
> 
> It would be great if you can give me some pointers about the structure of
> the project and the direction I should pursue.

Windows is a platform where the system already helps us with avoiding stack 
overflow. The project described on the Wiki page is targeting non-Windows 
platforms mainly, in particular Linux. There the system does not automatically 
increases stacks on an as-needed bases. 

This project requires low-level memory management knowledge and some experience 
with the Linux kernel might be advantageous. A couple of days ago Bryce has 
given more details, you might want to go back and re-read what he wrote (see: 
https://www.mail-archive.com/hpx-users@stellar.cct.lsu.edu/msg00450.html)

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

Re: [hpx-users] HPX dashboard ?

[Hartmut Kaiser]

> I haven't found it yet, is there a dashboard for hpx somewhere ?

We have several: all commits to all branches are compiled on circle-ci, but
this runs only one small crash & burn test:
https://circleci.com/gh/STEllAR-GROUP/hpx, buildbot checks only commits to
master, but runs all tests: rostam.cct.lsu.edu, John has a cmake dashboard
running here: http://cdash.cscs.ch/index.php?project=HPX which is showing
results from the buildbot, I belive.

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

Re: [hpx-users] Libraries installed to lib/ (and not lib64/) ?

[Hartmut Kaiser]

Alex,

> by default the hpx libraries are installed to PREFIX/lib/, also on a 64bit
> system.
> We could make use of GNUInstallDirs.cmake.
> This would provide a set of standard cache-editable destination location
> variables (e.g. CMAKE_INSTALL_LIBDIR)
> and the library install dir is initialized to lib/, lib64/ or the debian-
> multiarch dir on debian systems.
> 
> If you agree I can prepare a PR.

Please, by all means, go ahead.

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

Re: [hpx-users] Question regarding defines.hpp - many recompiles

[Hartmut Kaiser]

> >
> I had a closer look at the examples-switches.
> There are five:
> HPX_WITH_EXAMPLES_OPENMP
> HPX_WITH_EXAMPLES_TBB
> HPX_WITH_EXAMPLES_QTHREADS
> HPX_WITH_EXAMPLES_HDF5
> HPX_WITH_EXAMPLES_QT4
> 
> They all end up as #define in defines.hpp, but nothing inside the hpx-
> source
> tree makes use of these defines AFAICT.
> So, I could move those 5 into an e.g. config-examples.hpp (which
> wouldn't be
> used anywhere and I guess which shouldn't be installed), or I could
> just
> remove the hpx_add_config_define() calls for the examples.
>   <
> 
> if they are really not used, then I guess deleting them completely is the
> best thing to do, but putting any that you find that are into
> config/examples.hpp sounds good.
> 
> I must make time to have a look at the defines and see if there are some
> that are needed in core, and maybe others that could be shifted into other
> places.

I'm pretty sure the HPX_WITH_FOO configuration macros are used (by cmake). 
However, if the corresponding HPX_HAVE_FOO preprocessor constants are not
used we should remove them.

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


> 
> JB
> 
> ___
> 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] linking/cmake problem

[Hartmut Kaiser]

Alex,

Please see https://github.com/STEllAR-GROUP/hpx/pull/2540 for a possible
fix. As it turns out we simply did not properly change all uses of
target_link_libraries(), but only a few.

Thanks for reporting!
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 Alexander Neundorf
> Sent: Wednesday, March 15, 2017 4:40 PM
> To: hpx-users@stellar.cct.lsu.edu
> Subject: [hpx-users] linking/cmake problem
> 
> Hi,
> 
> I'm building hpx without cuda, and in examples/qt/, tools/ and
> tools/inspect/
> cmake errors out with the following error:
> 
> 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
> 
> 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
> ?
> 
> 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()
> 
> 3. add the if(WITH_CUDA) in the three CMakeLists.txt which have a problem
> right now.
> 
> 4. remove the "PUBLIC" from hpx_setup_target().
> But I guess there was a reason why it was added ?
> 
> 5. add PUBLIC also with CUDA, but I guess there is a reason it is not
> there ?
> 
> I think my favourite is option 2, add a keyword-variable.
> 
> 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