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/
daissgr has joined #ste||ar
daissgr has quit [Ping timeout: 264 seconds]
chinz07[m] has quit [Remote host closed the connection]
simbergm has quit [Remote host closed the connection]
chinz07[m] has joined #ste||ar
simbergm has joined #ste||ar
eschnett has joined #ste||ar
hkaiser has quit [Quit: bye]
eschnett has quit [Quit: eschnett]
daissgr has joined #ste||ar
daissgr has quit [Ping timeout: 252 seconds]
<nikunj> Hi! I'm playing around with some c++17 features and I'm stuck on one of the examples on fold_expressions. Can someone please tell what I'm doing wrong? https://pastebin.com/tL7mQFJX
<nikunj> I'm getting this error https://pastebin.com/sEShD7Jz
<nikunj> so I was missing a ','?
<Yorlik> seems so
<Yorlik> I'm a toddler in these things
<Yorlik> ;)
<nikunj> could you please explain the need for a ','?
<nikunj> I'm new to fold expressions
<Yorlik> Which compiler do you use?
<nikunj> I prefer clang
<Yorlik> Certain fold expression do not work on MSVC
<Yorlik> I had issues with them when calling members
<nikunj> I do most of my coding work on linux, so it's either gcc or clang
<Yorlik> They said they fixed it in 2019
<nikunj> ohh
<Yorlik> Then it doesn't matter for you
<nikunj> but again, I didn't understand why we need a comma
<Yorlik> Me neither ;)
<Yorlik> Fold expression are still sortof black magic to me. Probably it's just described somewhere where you won't find it.
<nikunj> so it's a right fold expression, I write the initial param and then continue
* nikunj I think so too
<Yorlik> The second link also has a push_back example
<nikunj> aah!
<nikunj> thanks!
<Yorlik> :)
david_pfander has joined #ste||ar
<Yorlik> parsa: I played a little with your idea yesterday when I asked for the conditional constexpr and hit a difference bwtween gcc and msvc. Finally found a solution which works on both: Check line 26 ff. https://wandbox.org/permlink/MXx7ll4biuzYha7V
<Yorlik> Line 38 ff finally works with both compilers
<Yorlik> It's all about using std::conditional_t and not std::conditional<...>::type
<simbergm> Yorlik: conditional_t is just sugar over conditional<>::type added in C++14 (https://en.cppreference.com/w/cpp/types/conditional)
<Yorlik> I know - I was digging into the std lib code
<Yorlik> Still - cl and gcc behave differently here
<Yorlik> I didn't try to figure out why - just realized the oddity.
<simbergm> :/
<Yorlik> The three variations to initialize the constexpr conditionally work different, and the activated one works on both compilers
nikunj97 has joined #ste||ar
nikunj has quit [Ping timeout: 272 seconds]
<heller> No data flow engine from Intel soon :(
hkaiser has joined #ste||ar
<K-ballo> Yorlik: do you still have the variation for which cl and gcc disagree around? where you missing `typename`, msvc accepted, gcc rejected?
<Yorlik> line 26 ff
<K-ballo> I don't know, is that the one? gcc accepts, so I suppose msvc rejects?
<Yorlik> the active version compiles on both
<Yorlik> Yes
<K-ballo> oh, there's commented out code, I see
<Yorlik> 26 is gcc only, 32 is cl only and 38 is both
<Yorlik> I was pondering to build a freelist which could take either pointers or slot numbers
<Yorlik> woops?
<Yorlik> moment thats odd
<K-ballo> no, note the compilation flags
<K-ballo> C++20 does not require as much `typename` as it did before
<K-ballo> the resulting type of `std::conditional< std::is_pointer<E>::value, badptr_t, badsize_t>::type` is dependent on `E`, and as far as the compiler care it could either be a value or a type.. it assumes it is a value, so it needs `typename` to flag it is actually a type
<Yorlik> I guess thats why the wrapped and sugared version worked for both
<K-ballo> since C++20 the language is a bit smarter, and realizes that if you say `using x = ...;` then the thing on the right must be a type already
eschnett has joined #ste||ar
<Yorlik> We are working crossplatform, since cl,ient and server will share some code
<Yorlik> So I think it's good to try out things on wandbox while I'm developing in cs
<K-ballo> indeed it is
<Yorlik> I still have to fix my build system such, that it works properly crossplatform.
<Yorlik> There are some quirks to iron out
<K-ballo> and for this particular case, note the `XYZ_t` flavors add both `typename` and `::type`, so they are probably preferred
<Yorlik> I'll stick with these
eschnett has quit [Client Quit]
<Yorlik> After all my basic allocator works
<Yorlik> I can now reserver a huge amount of virtual memory and commit pages as need such, that I never have to move stuff
<Yorlik> Looking forward to see it in practise
aserio has joined #ste||ar
eschnett has joined #ste||ar
hkaiser has quit [Quit: bye]
bibek has quit [Quit: Konversation terminated!]
bibek has joined #ste||ar
bibek has quit [Client Quit]
bibek has joined #ste||ar
tianyi93 has joined #ste||ar
daissgr has joined #ste||ar
jaafar has quit [Quit: Konversation terminated!]
Yorlik has quit [Disconnected by services]
Yorlik has joined #ste||ar
<diehlpk_work> daissgr, jbjnr_ I send around some scaling results for a small instance of v1309
<diehlpk_work> daissgr, yet
<Yorlik> Seems my allocator need ~5 ns for a raw allocation per object (80 B PODs) now without the object construction. I think I can leave it at that for now.
daissgr has quit [Ping timeout: 252 seconds]
eschnett has quit [Read error: Connection reset by peer]
eschnett has joined #ste||ar
hkaiser has joined #ste||ar
aserio has quit [Ping timeout: 250 seconds]
aserio has joined #ste||ar
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 252 seconds]
aserio1 is now known as aserio
jaafar has joined #ste||ar
aserio has quit [Ping timeout: 258 seconds]
<heller> hkaiser: ready whenever you are
<hkaiser> heller: sec
<hkaiser> heller: I'm in
aserio has joined #ste||ar
aserio has quit [Quit: aserio]
aserio has joined #ste||ar
<aserio> heller: praise goodness
hkaiser has quit [Quit: bye]
bibek has quit [Quit: Konversation terminated!]
eschnett has quit [Quit: eschnett]
diehlpk_mobile has joined #ste||ar
hkaiser has joined #ste||ar
<aserio> hkaiser: Any opinion on versioning of hpxr?
<hkaiser> HPXr V1.0?
<hkaiser> ;-)
<aserio> Lol, that's what I figured
<diehlpk_mobile> hkaiser, have you contacted Sterling?
<diehlpk_mobile> I hope to get some response from the German group by Friday and like to finalize things
aserio has quit [Quit: aserio]
<hkaiser> diehlpk_mobile: I have not, should we still contact him?
diehlpk_mobile has quit [Read error: Connection reset by peer]
eschnett has joined #ste||ar
quaz0r has quit [Ping timeout: 246 seconds]
quaz0r has joined #ste||ar
eschnett has quit [Quit: eschnett]
diehlpk_mobile has joined #ste||ar
<diehlpk_mobile> hkaiser, do you have someone else in mind?
<hkaiser> diehlpk_mobile: no
<diehlpk_mobile> should we sent an reminder to the two previous candidates?
<Yorlik> I just measured a ratio of 22:1 for random array access vs sequential access - is it realistic to have such a strong cache effect? I was reading 2 cacheline sized PODs.
<diehlpk_mobile> I think Sterling could be an interesting candidate
<hkaiser> ok
jaafar has quit [Ping timeout: 272 seconds]
<heller> Yorlik: random might mean a cache miss on every access
<Yorlik> It surela was - it was a 1G sized array
<Yorlik> I created like 8G of data and queried randomly across it
<Yorlik> Then read sequentially the first 1000000 elements
<Yorlik> Also did empty loop/RNG measurement
<Yorlik> Just wondering is a ratio of 22-30:1 is realistic
<Yorlik> Probably I should do several runs and chose the minimum numbers
<Yorlik> Err 1.28 G data with 128 byte sized PODs - however ..
<Yorlik> Chance for cache hits with Random access was very low
<hkaiser> Yorlik: what are you trying to measure?
<Yorlik> My allocator
<K-ballo> think not only cache but also prefetch
<Yorlik> I made a custom allocator for a typed growable array
<hkaiser> I think you're measuring hardware properties (i.e. effect of cache sizes, etc.) and not your allocator
<Yorlik> It is backed up by reserved virtual memory addrersses
<Yorlik> Thats the plan
<Yorlik> The allocator was written to exploit t he hardware
<Yorlik> Its the structure which will store my entities
<Yorlik> In the update loop I'm reading sequentially