hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/ | GSoC2018: https://wp.me/p4pxJf-k1
stmatengss has joined #ste||ar
eschnett has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
K-ballo has quit [Quit: K-ballo]
parsa has joined #ste||ar
stmatengss has quit [Quit: Leaving.]
nanashi55 has quit [Ping timeout: 256 seconds]
nanashi55 has joined #ste||ar
hkaiser has joined #ste||ar
Anushi1998 has quit [Ping timeout: 240 seconds]
Anushi1998 has joined #ste||ar
hkaiser has quit [Quit: bye]
Anushi1998 is now known as anushi
Anushi1998 has joined #ste||ar
jakub_golinowski has joined #ste||ar
hkaiser has joined #ste||ar
<wash>
<heller___> right
heller___ is now known as heller
<jakub_golinowski> M-ms yt?
<M-ms> jakub_golinowski: here
<M-ms> did you find out what was wrong? I had a look yesterday and nothing obvious stood out to me yet
<jakub_golinowski> Yes, this was the error in my bash script
<jakub_golinowski> now, when it actually build the opencv with different backends in proper built_types then the application opencv_mandelbrot works as expected
<M-ms> ok, so that was it
<M-ms> and now it runs correctly in debug and release?
<jakub_golinowski> I have run some preliminary benchmarks yesterday in both debug and release and the results are sensible
<jakub_golinowski> now I am workinng on sweep over number of cores
<jakub_golinowski> as for the opencv with hpx and hpx nstripes backends
<jakub_golinowski> this is quite straightforward
<M-ms> very good, do you have some rough numbers already?
<jakub_golinowski> I only have numbers from the sweep over workload and as expected the start-stop seems to be generally slower
<jakub_golinowski> For the sweep over number of cores I am now working on a way to propagate the --hpx:threads X to the backend
<M-ms> for the nstripes backend I would still add the explicit static_chunk_size(1)
<jakub_golinowski> such that no matter how many stripes we respect the OpenCV's partitioning?
<jakub_golinowski> there should be a comma after "stripes" I believe
<M-ms> yes, it probably won't make a big difference in many cases (let's say you have 8 threads and you get 32 tasks, if nstripes is 32 or lower the chunk size is still 1) but I prefer to be explicit
<M-ms> comma after stripes?
<jbjnr_> heller : where are you staying? hartmut and I are in walhalla
<jakub_golinowski> M-ms, in my previous message on IRC (matter of English not C++)
<jakub_golinowski> so now I am adding the fixed chunksize of 1 to the backend
<M-ms> what are you planning with propagating --hpx:threads? do you mean for the start/stop case?
<M-ms> ah, ok
<jakub_golinowski> so in the start-stop case
<jakub_golinowski> If I want to do the sweep over the number of cores I need to launch the app with different number of cores each time
<heller> jbjnr_: I am staying in a crappy hotel near you called "Linda's Beauty Bed & Breakfast"
<M-ms> right, ok
<M-ms> yes, you'll need to either pass in a command line option via my_argv or use the config vector (have you seen that?)
<hkaiser> M-ms: the config vector now accepts verbatim command line options, btw
<jbjnr_> has that been merged? that's great if it has
<M-ms> hkaiser: yeah, saw that, it's very nice :)
<hkaiser> jbjnr_: yes
<M-ms> jbjnr_: it has been merged
<jakub_golinowski> M-ms, so I think I have seen the issue on github about the config vector but never used it before
<heller> jbjnr_: hkaiser: how is the meeting?
<hkaiser> boring, as always ;-)
<heller> why did you go then ;)
<hkaiser> good question
<jbjnr_> I have had a lot of interesting chats with people. the meetings themselves are very slow.
<M-ms> jakub_golinowski: it's yet another option you can pass to hpx::start/init and looks like this: https://github.com/STEllAR-GROUP/hpx/blob/30d0202dd475453b27f7ef963e921568e8266526/tests/unit/parallel/algorithms/fill.cpp#L330-L336
<M-ms> so you can now either say "hpx.os_threads=X" or "--hpx:threads=X" in the configuration vector
<jakub_golinowski> I mean given that I pull the newest master and recompile hpx
<M-ms> for the second option you need to do that, the first one works since ages
<M-ms> jbjnr_: how is pycicle's options support coming along? or no time for that?
<jbjnr_> the parsing of options is implemented, but I have not put in code to 'use' them. In principle, it should not be very hard, but it will require a day or two devoted to it.
<jbjnr_> how badly do you need it?
<jbjnr_> (I need it urgently)
<jbjnr_> really
<jbjnr_> M-ms: jakub_golinowski the first option will hopefully be deprecated in favour of the second one that is consistent with the command line
<M-ms> jbjnr_: it's not urgent and can be done without options as well (I wanted to add a c++11 builder), but if it's there I'll use it
<M-ms> you'll make an announcement here when the next version is out with support for options ;)
<jakub_golinowski> M-ms, Ok I understand, but for today I would like to stick to my current build of HPX :)
<jakub_golinowski> I as we were talking I was trying out the my_argv approach but it does not seem to be succesfull
<M-ms> jakub_golinowski: yes, that's what I'd recommend as well ?
<M-ms> ok, what's happening?
<jakub_golinowski> It seemed to igore my options
<jakub_golinowski> but now I added one option before --hpx:threads 4
<jakub_golinowski> and it seems to have worked properly
<hkaiser> jakub_golinowski: please file a ticket if that's the case
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
parsa has quit [Client Quit]
<jakub_golinowski> hkaiser, M-ms I have isolated a small example that shows the issue: https://github.com/Jakub-Golinowski/opencv_hpx_backend/blob/master/hpx_start_myargv/hpx_start_myargv.cpp
<jakub_golinowski> I will create a ticket on github based on this
<M-ms> jakub_golinowski: this is expected behaviour though
<M-ms> the first argument is always the application name
<M-ms> I would really recommend you use the configuration vector, no need to recompile for that
david_pfander has joined #ste||ar
<jakub_golinowski> M-ms, ok
<hkaiser> jakub_golinowski: this is not a bug
<jakub_golinowski> hkaiser, ok :D
<hkaiser> jakub_golinowski: argv[0] is always expected to be the path/name of the executable
<hkaiser> I'd also suggest you don't provide your own argc/argv
<jakub_golinowski> hkaiser, but if I want to launch HPX from within the backed I do not have the access to the argc/argv
<hkaiser> (you'd have to append a nullptr to argv (not counted in argc), btw)
<hkaiser> look at the init_globally example
<hkaiser> gtg, sorry
hkaiser has quit [Quit: bye]
<jakub_golinowski> you mean to ensure argv[argc]=nullptr property
<jakub_golinowski> ok thanks, I will have a look at the init_globally example
david_pfander1 has joined #ste||ar
anushi has quit [Ping timeout: 245 seconds]
stmatengss has joined #ste||ar
<github> [hpx] StellarBot pushed 1 new commit to gh-pages: https://git.io/vhz7t
<github> hpx/gh-pages f7c4cc6 StellarBot: Updating docs
<jakub_golinowski> M-ms, yt?
stmatengss has quit [Quit: Leaving.]
hkaiser has joined #ste||ar
<M-ms> jakub_golinowski: here
<jakub_golinowski> so I managed to somehow adapt the init_globally example
<jakub_golinowski> in the opencv library I declare globals argc and argb
<jakub_golinowski> argv
<jakub_golinowski> and then just set them in the user app
<jakub_golinowski> I lost an hour before I found out that CV_EXPORTS makro has to be used to set proper __attributes__ for the linker
<jakub_golinowski> now I am facing another issue
<jakub_golinowski> the argc/argv is properly propagated from user app
<hkaiser> ok, so what's the issue
<jakub_golinowski> but when I call the hpx::start(nulptr, __argc, __argv) one of the arguments is -h 480
<jakub_golinowski> which is used to set the mandelbrot height
<hkaiser> well, you get all of your commandline
<jakub_golinowski> but HPX takes it as the --hpx:help and execption is thrown
<jakub_golinowski> so the question is is the
<hkaiser> do two things
<jakub_golinowski> I have seen that in resource partitioner example the desc_cmd_line is passed
<jakub_golinowski> but for hpx::start I did not see this overload
<hkaiser> a) disable hpx command line shortcuts, and b) tell HPX to ignore (not not throw) for unknown command line options
<jakub_golinowski> ok seems to be a good idea
<jakub_golinowski> ah true
<jakub_golinowski> I should have noticed that
<jakub_golinowski> thank you very much hkaiser
<hkaiser> you should ;-)
<hkaiser> most welcome
mcopik has joined #ste||ar
hkaiser has quit [Quit: bye]
anushi has joined #ste||ar
jakub_golinowski has quit [Ping timeout: 256 seconds]
diehlpk has joined #ste||ar
jakub_golinowski has joined #ste||ar
david_pfander has quit [Ping timeout: 256 seconds]
david_pfander1 is now known as david_pfander
K-ballo has joined #ste||ar
david_pfander has quit [Quit: david_pfander]
diehlpk has quit [Ping timeout: 264 seconds]
jakub_golinowski has quit [Ping timeout: 240 seconds]
AnujSharma has joined #ste||ar
AnSh has joined #ste||ar
AnSh has quit [Remote host closed the connection]
jakub_golinowski has joined #ste||ar
hkaiser has joined #ste||ar
Anushi1998 has quit [Quit: Bye]
eschnett has quit [Quit: eschnett]
hkaiser_ has joined #ste||ar
hkaiser has quit [Ping timeout: 240 seconds]
akheir has joined #ste||ar
jakub_golinowski has quit [Ping timeout: 240 seconds]
nikunj has joined #ste||ar
jakub_golinowski has joined #ste||ar
bibek has joined #ste||ar
eschnett has joined #ste||ar
anushi has quit [Ping timeout: 248 seconds]
nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
nikunj has quit [Read error: Connection reset by peer]
jakub_golinowski has quit [Ping timeout: 264 seconds]
parsa has joined #ste||ar
parsa has quit [Client Quit]
rtohid has joined #ste||ar
hkaiser_ has quit [Quit: bye]
parsa has joined #ste||ar
Anushi1998 has joined #ste||ar
AnujSharma has quit [Ping timeout: 256 seconds]
anushi has joined #ste||ar
diehlpk has joined #ste||ar
galabc has joined #ste||ar
jakub_golinowski has joined #ste||ar
diehlpk_ has joined #ste||ar
diehlpk has quit [Ping timeout: 256 seconds]
AnujSharma has joined #ste||ar
anushi has quit [Ping timeout: 265 seconds]
Anushi1998 has quit [Ping timeout: 264 seconds]
jakub_golinowski has quit [Quit: Ex-Chat]
diehlpk_ has quit [Ping timeout: 260 seconds]
mcopik has quit [Ping timeout: 240 seconds]
stmatengss has joined #ste||ar
<stmatengss> Hello, everyone. How should I deal with the License (e.g. Boost Software License) if I use some codes from other projects. Should I make some sentences changing in the header to claim this?
<K-ballo> stmatengss: in your own code, or in code you want to contribute to HPX?
<K-ballo> we can't take non BSL code in HPX
<stmatengss> 1. In code I want to contribute to HPX. 2. Ok, I see. I will find another solution.
<heller> stmatengss: libcds is now BSL, isn't it?
<stmatengss> Of course, but I have to add some other codes beyond libcds and hpx to make it work normally.
<heller> ok, what do you have in mind?
<stmatengss> Yeah, I will try other solutions.
<heller> what?
<heller> first: 1) What's the exact problem? 2) How do you want to fix it?
<stmatengss> 1) Some codes in libcds are not correct (at least, in my environment), and will cause some runtime errors. 2) I will try to fix these exceptions or correct my environment.
<heller> please get in contact with the libcds author, he'll be able to help with those issues, he agreed to help us with that project
<stmatengss> Okay. Thx a lot.
stmatengss has left #ste||ar [#ste||ar]
stmatengss has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
parsa has quit [Client Quit]
AnujSharma has quit [Ping timeout: 264 seconds]
diehlpk_ has joined #ste||ar
stmatengss has quit [Quit: Leaving.]
parsa has joined #ste||ar
diehlpk_ has quit [Ping timeout: 264 seconds]
galabc has quit [Quit: Leaving]
galabc has joined #ste||ar
<galabc> Hi, In rostam, I have exported my $CC variable to a custom compiler
mcopik has joined #ste||ar
<galabc> but now I want to try the default compiler so I want to export the path to the default clang6.0.0 compiler to $CC
<galabc> do I simply do export CC=/opt/module/clang/6.0.0 ?
<K-ballo> unset CC?
<mcopik> CC has to point to an executable, not a compiler directory
<galabc> okok
<mcopik> galabc: what do you want to do?
mcopik_ has joined #ste||ar
eschnett has quit [Quit: eschnett]
mcopik has quit [Ping timeout: 260 seconds]
<jbjnr_> K-ballo: yt?
<K-ballo> jbjnr_: yeap
<jbjnr_> I think I know the answer to my question ...
<jbjnr_> so I don't need to ask. let me try it - I was going to ask about my shared_future operator in that gist
<jbjnr_> but give me 5 and let me check
<K-ballo> ...ok
<jbjnr_> grrrr
<jbjnr_> I'm saying shared_future<T> = my_log_thingy - and it does not convert my log thingy to a shared future automatically.
akheir has quit [Quit: Leaving]
rtohid has quit [Remote host closed the connection]
bibek has quit [Quit: Leaving]
<K-ballo> is the `T` in `shared_future<T>` deduced?
<jbjnr_> I hoped so
<jbjnr_> looking at my error closely, I see that somehow my executor is returning a future<log_thingy<future>> when it should be returning a log_thingy<future>
<jbjnr_> I will poke around. it's not the log_thingy operator that's the problem for now
<parsa[w]> galabc: please don't compile stuff on rostam's head node
diehlpk_ has joined #ste||ar
mcopik_ has quit [Ping timeout: 260 seconds]
shahrzad has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
<galabc> ah ok sorry
<galabc> my bad i forgot to go on beowulf
diehlpk_ has quit [Ping timeout: 264 seconds]
hkaiser has joined #ste||ar
galabc has quit [Read error: Connection reset by peer]
galabc has joined #ste||ar
galabc has quit [Client Quit]
hkaiser has quit [Quit: bye]