hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar-group.org | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | This channel is logged: irclog.cct.lsu.edu
hkaiser has quit [Quit: Bye!]
Yorlik__ has joined #ste||ar
Yorlik_ has quit [Ping timeout: 248 seconds]
K-ballo1 has joined #ste||ar
K-ballo has quit [Ping timeout: 252 seconds]
K-ballo1 is now known as K-ballo
K-ballo has quit [Quit: K-ballo]
K-ballo has joined #ste||ar
K-ballo has quit [Client Quit]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<dkaratza[m]> can sb explain what is the difference between `hpx::chrono::steady_time_point` and `std::chrono::steady_clock`
<dkaratza[m]> s/`/`?/
<hkaiser> steady_clock measures time, time_point represents a point in time
<dkaratza[m]> so we extended the std with some extra functionalities or not?
<hkaiser> ahh, it's hpx and std... missed that
<hkaiser> no, we did not extend anything
<hkaiser> hpx::steady_time_point is equivalent to std::chrono::time_point: https://en.cppreference.com/w/cpp/chrono/time_point
<dkaratza[m]> oh alright, but why do we use a different name? usually we have the same names as the std
<hkaiser> I think our types are remnants of a time where we had to support std::chrono and boost::chrono
<hkaiser> our types allow to use both with our APIs that expect a duration or time_point
<hkaiser> but by now we have removed the support for boost::chrono, so we could essentially remove our steady_time_point and steady_duration types
<dkaratza[m]> now i see
<dkaratza[m]> hkaiser: do you think i should add this in one of the tickets?
<hkaiser> yah, good point
<dkaratza[m]> i think itr's better to document it after we update it
<hkaiser> right
<pansysk75[m]> hkaiser: The scheduler that is passed on to the scheduler_executor is, as we discussed, a scheduler as described by P2300.
<pansysk75[m]> Is there any similar "scheduler-like" concept for the p0443r3-based executors? Would it be the execution policies that play that role?
<pansysk75[m]> Or is the "scheduling" just an implementation detail?
<hkaiser> they never got around to talk about schedulers in p0443
<hkaiser> there they talked about executors and execution contexts
<hkaiser> I think a scheduler in p2300 is closer to a context in p0443
<hkaiser> it's the thing that owns the execution resources (i.e. threads)
<hkaiser> whereas executors are just referring to contexts, e.g. they are very lightweight
<hkaiser> and cheap to construct
<pansysk75[m]> Nice, thanks!
hkaiser has quit [Quit: Bye!]
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ste||ar
hkaiser has joined #ste||ar
K-ballo has quit [Ping timeout: 252 seconds]
K-ballo has joined #ste||ar
hkaiser has quit [Quit: Bye!]
hkaiser has joined #ste||ar
Yorlik__ has quit [Ping timeout: 248 seconds]
K-ballo has quit [Ping timeout: 250 seconds]
K-ballo has joined #ste||ar
hkaiser has quit [Quit: Bye!]