hkaiser changed the topic of #ste||ar to: The topic is '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/
diehlpk has joined #ste||ar
<diehlpk>
hkaiser, I only got my apointment at the notary at 11:30, so I might need to leave the meeting earlier
<hkaiser>
diehlpk: sure, np
<diehlpk>
For the second level scaling looks good
<diehlpk>
At least with the MPI port we see good scaling
<diehlpk>
hkaiser, Can you take care of the performance counter and hpx section
<hkaiser>
diehlpk: I can try
<diehlpk>
Ok, I will take care of the computer science results and can join later
<diehlpk>
hkaiser, Areyou fine with the technical report for the hpxmp paper?
<diehlpk>
So I will submit it to arxiv.org and we can add it to the webpage
<hkaiser>
yes, sure
<hkaiser>
there no body interested in continuing that work, so let's get it uploaded
<diehlpk>
Ok, will do it tonight.
<diehlpk>
Dominic checked the simulation results with previous results and it looks good
<hkaiser>
nice
<diehlpk>
We are off at some points but they believe this could be due to the low res
<hkaiser>
is this the 0.5 or the 0.7 run?
<diehlpk>
double white dwarf
<hkaiser>
well, the 400 million K temperature didn't look convincing...
<diehlpk>
At least the other quantitites look better
<hkaiser>
ok
<diehlpk>
Dominic will check the resolution of the previous run
<diehlpk>
yet the small start is only 20 cells
<diehlpk>
*star
diehlpk has quit [Ping timeout: 245 seconds]
hkaiser has quit [Quit: bye]
nikunj97 has joined #ste||ar
nikunj97 has quit [Ping timeout: 260 seconds]
nikunj97 has joined #ste||ar
nikunj has joined #ste||ar
nikunj97 has quit [Ping timeout: 248 seconds]
nikunj has quit [Ping timeout: 248 seconds]
diehlpk_work has quit [Remote host closed the connection]
heller1 has quit [*.net *.split]
hkaiser has joined #ste||ar
nikunj has joined #ste||ar
nikunj97 has joined #ste||ar
<simbergm1>
it's been tagged and it looks like I managed to make it point to the correct tag :)
<simbergm1>
but docs and download links on stellar-group.org should already be up
<rori>
Thanks :D
<hkaiser>
simbergm1: thanks a lot!
nikunj has quit [Ping timeout: 272 seconds]
nikunj97 has quit [Ping timeout: 272 seconds]
nikunj has joined #ste||ar
nikunj97 has joined #ste||ar
Nikunj__ has joined #ste||ar
Nikunj__ has quit [Client Quit]
Nikunj__ has joined #ste||ar
nikunj97 has quit [Ping timeout: 240 seconds]
nikunj has quit [Ping timeout: 240 seconds]
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
nikunj97 has joined #ste||ar
Nikunj__ has quit [Ping timeout: 255 seconds]
hkaiser has quit [Ping timeout: 240 seconds]
hkaiser has joined #ste||ar
<hkaiser>
simbergm1: hey
<hkaiser>
we now have two threading modules: threading_base and thread_support
<hkaiser>
do you think we could unify the naming scheme (i.e. either 'thead_base' or threading_support')?
<hkaiser>
from looking at the other modules, we might want to name it threading_support
<hkaiser>
well, not quite, we have both naming styles (iterator_support/allocator_support and naming_base)
<hkaiser>
should we think about such details at all?
<hkaiser>
:/
<K-ballo>
who is the official namer of modules?
<hkaiser>
do we have one?
<hkaiser>
sounds like something to discuss in the next coordination/PMC call
<simbergm1>
hkaiser: K-ballo we definitely don't have an official namer :P
<simbergm1>
yeah, I'm not married to the name...
<simbergm1>
I guess base and support have slightly different connotations
<simbergm1>
threading_base has the base classes (plus helper stuff which could of course be called support...)
<simbergm1>
thread_support is for os threads
<simbergm1>
then there's basic_execution as well...
<simbergm1>
I'm not sure how to distinguish between modules that deal with os threads and ones that deal with hpx threads
<simbergm1>
concurrency is also for os threads, synchronization is for hpx threads...
<simbergm1>
added a bullet point for tomorrow's call
nikunj97 has quit [Read error: Connection reset by peer]
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]
<hkaiser>
simbergm1: I'm more about the thread vs. threading naming convention, _base and _support are ok
K-ballo has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]
<simbergm1>
hkaiser: ah, sure
<simbergm1>
threading_support sounds a tiny bit better than thread_base, but I don't care too much
<simbergm1>
I can definitely change it if you'd like
<simbergm1>
note that #4399 adds one named just hpx_thread because all it contains is hpx::thread
K-ballo has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]
<hkaiser>
sure
<hkaiser>
simbergm1: I know it's a superfluous problem ;-)
K-ballo has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]
<simbergm1>
hkaiser: should we wait a bit with renaming? We might want to change others as well when we have (even) more modules
<hkaiser>
we might indeed, otoh, for the new module now might be a good time to avoid having to generate the forwarding headers
<hkaiser>
but let's discuss this tomorrow
<simbergm1>
Yeah, let's discuss tomorrow
<Yorlik>
Would this be UB or just dangerous? I'm experimenting with data containing its own type. https://godbolt.org/z/XqeXkJ
<Yorlik>
The idea would be to store this kind of data in a monotonic allocator.
<Yorlik>
And then traverse the list of void* in a thin wrapper.
<hkaiser>
casting through void* is always at least dangerous
<Yorlik>
Ya - that's clear. But do you spot any UB stuff in what I'm doing here?
<Yorlik>
And - what would be a better idea, if you want polymorphic data in a monotonic storage area and you need to iterate over it.
<Yorlik>
I am pondering top use this for my internal message system and have the mailboxes be backed my monotonic memory buffers
<Yorlik>
After all the system will process a lot of messages, so I'm thinking about throughput optimization for these too.
<hkaiser>
Yorlik: I usually stop looking when I see (void*) casts
<hkaiser>
so I don't know
<hkaiser>
you're 100% on your own here
<Yorlik>
OK. Got it.
<Yorlik>
Is it considered UB?
<Yorlik>
With danger I can live, with UB not.
<hkaiser>
well, casting a void* to some type T* should be done using reinterpret_cast and this is UB for anything but if the void* was the result of a reinterpret_cast from a T*
<hkaiser>
IOW: T1*->void*->T2* is ok only if T1 == T2
<hkaiser>
you should never use C-style casts, btw
K-ballo has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
K-ballo has quit [Read error: Connection reset by peer]
K-ballo has joined #ste||ar
nikunj has joined #ste||ar
nikunj has quit [Read error: Connection reset by peer]
hkaiser has quit [Quit: bye]
nikunj has joined #ste||ar
hkaiser has joined #ste||ar
<Yorlik>
hkaiser: I will guarantee, that the void* arriving at this system are derived from the correct classes. I think I can make this thing safe to the outside.
<hkaiser>
*sure* - famous last words
<Yorlik>
BTW - I measured my machines memory throughput - from what I see we are practically at the limit for my machine with the server. So - it's good :)
<hkaiser>
nice
<hkaiser>
the auto_chunk_size was merged, btw
<Yorlik>
The best measurement I made was 22 GB/sec and that's practically the result for my machine loading large datasets with 4 threads.
<Yorlik>
I used this thing for measuring the memory: file:///C:/__A/download/pmbw-0.6.2-win64/pmbw%20-%20Parallel%20Memory%20Bandwidth%20Benchmark%20_%20Measurement%20-%20panthema.net.html