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/ | GSoD: https://developers.google.com/season-of-docs/
diehlpk has joined #ste||ar
USTOBRE has quit [Quit: Connection closed for inactivity]
hkaiser has joined #ste||ar
hkaiser has quit [Client Quit]
hkaiser has joined #ste||ar
Guest88210 has quit [Ping timeout: 245 seconds]
Guest88210 has joined #ste||ar
diehlpk has quit [Quit: Leaving.]
Amy1 has joined #ste||ar
Guest88210 has quit [Ping timeout: 276 seconds]
Amy2 has joined #ste||ar
Amy1 has quit [Ping timeout: 268 seconds]
mdiers_1 has joined #ste||ar
mdiers_ has quit [Remote host closed the connection]
mdiers_1 is now known as mdiers_
heller has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
heller has joined #ste||ar
<Yorlik> Warning: Newbie Question coming in: How could I replace the strings in CHAT_MSG with char[] such, that I can construct messages correctly like char_msg("Hello, world!") and how would I print these correctly formatted? https://godbolt.org/z/gwXQFw
<zao> If you've got literals or c-strings of sufficient storage duration, use char const*?
<zao> If you've got variable length strings, you can't have an char array of compile-time size.
<zao> If you've got non-literal data coming in from the outside, it needs some sort of storage.
<zao> You could either have an array of sufficiently large size and refuse any longer payloads, or have a "short" string optimization and fall back on dynamic allocation for larger payloads.
<zao> The crux is, you need some sort of storage.
<Yorlik> I want to use maximum sized buffers for chat messages, just wondering about the constructor and output side. Still kinda weak with the correct usage here.
<Yorlik> We might just chop messages in parts if people type too long and reaSSEMBLE IN TEH CHAT CODE:
<Yorlik> So - a max of 128 or even 64 might do
<Yorlik> We have planned to give messages on construction custom allocators, which put them in the netlib arena, where thy live until sent.
<Yorlik> On receive we might just use shared or unique pointers.
aserio has joined #ste||ar
nikunj has joined #ste||ar
hkaiser has quit [Ping timeout: 245 seconds]
hkaiser has joined #ste||ar
nikunj has quit [Read error: Connection reset by peer]
nikunj has joined #ste||ar
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 250 seconds]
aserio1 is now known as aserio
<aserio> daissgr_: Will you be joining the meeting today?
K-ballo has quit [Remote host closed the connection]
K-ballo has joined #ste||ar
aserio has quit [Remote host closed the connection]
aserio has joined #ste||ar
jaafar has quit [Ping timeout: 268 seconds]
<hkaiser> rori: yt?
<hkaiser> simbergm: do you know if Auriane is working on #4085?
<hkaiser> I do have a fix for that which I could create a PR from
jaafar has joined #ste||ar
<simbergm> hkaiser: she was looking into it, but neither I or she could reproduce it, so if you have a fix go for it
<hkaiser> simbergm: see #4095
<hkaiser> once she has the cmake overhaul in place this 'fix' might have to be changed
<hkaiser> I assume she will turn hwloc into a proper cmake target
<simbergm> hkaiser: excellent, thanks, that looks reasonable
<simbergm> I still don't understand how to reproduce that but...
<simbergm> and yes, it will become a proper target
<simbergm> also, thanks for the comments on 4093
<simbergm> can you explain why I'd be allowed to use a static function in a constexpr function?
<simbergm> (plus, I won't be around much the next two weeks, so please don't feel like you have to wait for me to merge things)
<hkaiser> ok
<hkaiser> if the static function is constexpr, why not?
<hkaiser> otherwise the whole constructor can't be constexpr anymore - and now that I think of it, we might have to remove the constexpr anyways
K-ballo1 has joined #ste||ar
<hkaiser> simbergm ^
<simbergm> hkaiser: right, I understood it as static being enough
K-ballo has quit [Ping timeout: 245 seconds]
K-ballo1 is now known as K-ballo
<simbergm> but if I'm getting the thread id etc the helper won't be constexpr either
<hkaiser> right, that's what I meant
<simbergm> so yes, my next question was going to what we gain from it being constexpr
<simbergm> okay, good, we're on the same page
<hkaiser> nothing anymore ;-)
<simbergm> what used to be the reason?
<hkaiser> compile-time vs. runtime?
<hkaiser> the constructor essentially disappeared from runtime
aserio has quit [Ping timeout: 245 seconds]
<hkaiser> not a bigyy, I guess
<simbergm> yeah, I guess my question was did it make a big difference... if it allowed other things up the chain to be constexpr as well it would probably have a bigger impact
<hkaiser> yah, I think that was what triggered it in the first place
<hkaiser> simbergm: we could split the constructor in two: one that does not expect num_tasks to be specified (in which case your logic would kick in) and one that takes (and requires num_tasks to be passsed in, and that one could stay constexpr
<simbergm> good idea
<simbergm> hmm, looks like I broke a bunch of stuff anyway with that last commit
<simbergm> par is static constexpr and it would nice to keep it that way
<hkaiser> yes'
<hkaiser> I think this is what triggered it
<simbergm> and the default constructor is the one that would need the extra logic and be constexpr
<simbergm> so what was the race you saw when the logic was in bulk_async_execute?
<hkaiser> if (num_tasks_ == -1) num_tasks_ = ...
<simbergm> ok, but if num_tasks_ can only be set once in the constructor it's fine, no?
<simbergm> oh, no...
<simbergm> now I see it
<simbergm> it's obviously not set just once in the constructor...
<simbergm> so I could just use a local variable instead
<hkaiser> simbergm: I think the previous design was wrong in the sense that it used one global (static) num_tasks for all instances of the executor
<hkaiser> I think using a local variable might be the best we can do
<simbergm> having a static is nice (for performances), but if I'm not calling hpx::get_os_thread_count (which can yield) I think we're ok
<hkaiser> nowadays we have potentially pools with different number of threads which would do the wrong thing if initialized for one, but used by another
<simbergm> yeah, so it seems
<simbergm> yep
<hkaiser> so let's make it local only, even if this creates potentially a it more overhead
<hkaiser> if the user wants to avoid that, just specify the correct number of tasks
<simbergm> yep, getting the thread local is not free but calling thread_pool_base::get_os_thread_count is essentially free
<simbergm> indeed
jaafar has quit [Quit: Konversation terminated!]
jaafar has joined #ste||ar
jaafar has quit [Ping timeout: 276 seconds]
aserio has joined #ste||ar
bibek has quit [Quit: Konversation terminated!]
<maxwellr96> Which boost should we be using for building Phylanx?
<maxwellr96> Should 1.70.0 be okay?
<hkaiser> maxwellr96: any between V1.60 and current
bibek has joined #ste||ar
hkaiser has quit [Ping timeout: 264 seconds]
<maxwellr96> Does anyone know why boost::basic_regex wouldn't be linking properly in Phylanx? I have included the CMakeToolchainFile with CMake, and I have boost regex installed
akheir has joined #ste||ar
akheir has quit [Quit: Leaving]
hkaiser has joined #ste||ar
aserio has quit [Ping timeout: 250 seconds]
aserio has joined #ste||ar
aserio has quit [Quit: aserio]
aserio has joined #ste||ar
aserio has quit [Quit: aserio]
nikunj has quit [Quit: Leaving]
hkaiser has quit [Ping timeout: 276 seconds]
jaafar has joined #ste||ar