nikunj has quit [Remote host closed the connection]
rori has joined #ste||ar
jgurhem has quit [Ping timeout: 245 seconds]
jgurhem has joined #ste||ar
david_pfander has quit [Quit: david_pfander]
hkaiser has joined #ste||ar
<hkaiser>
simbergm: yt?
<hkaiser>
simbergm, rori: I was thinking the other day whether it would be a good time now to start formally tracking dependencies between the modules
<hkaiser>
i.e. building/using a tool that makes sure no cycles creep into the dependencies'
<hkaiser>
that should also help to start classifying modules by 'tiers', i.e. things that belong to the same tier only depend on things on lower tiers
* K-ballo
sheds a tear of joy
<rori>
yep !
<hkaiser>
sounds like a relatively simple graph problem, however I'd like to avoid developing our own tools
<hkaiser>
does anybody know of existing solution for this?
<simbergm>
hkaiser: I looked into this at some point
<simbergm>
cmake generates graphviz files, and there are python libraries for parsing these and checking for cycles
<simbergm>
doing it in cmake might get ugly (unless there's something built in)
<simbergm>
with shared libraries cmake would enforce this for us
<K-ballo>
cppdependencies could help when each module is its own directory
<hkaiser>
they are
<hkaiser>
simbergm: I don't think shared libraries would be a good idea...
eschnett has joined #ste||ar
lsl88 has joined #ste||ar
lsl88 has quit [Client Quit]
<simbergm>
hkaiser: yeah, just sad that we can't make cmake check dependencies when it clearly knows how to do it :/
hkaiser has quit [Quit: bye]
aserio has joined #ste||ar
lsl88 has joined #ste||ar
lsl88 has quit [Ping timeout: 245 seconds]
lsl88 has joined #ste||ar
hkaiser has joined #ste||ar
lsl88 has quit [Ping timeout: 245 seconds]
aserio has quit [Ping timeout: 264 seconds]
lsl88 has joined #ste||ar
diehlpk has joined #ste||ar
rori has quit [Quit: bye]
<diehlpk>
nikunj97, yet?
<diehlpk>
Is Dominic around?
aserio has joined #ste||ar
diehlpk has quit [Ping timeout: 250 seconds]
hkaiser has quit [Quit: bye]
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 245 seconds]
aserio1 has joined #ste||ar
aserio has quit [Ping timeout: 264 seconds]
aserio1 is now known as aserio
hkaiser has joined #ste||ar
<nikunj97>
diehlpk_work: yes
<nikunj97>
I don't see Dominic around
aserio has quit [Ping timeout: 276 seconds]
eschnett has quit [Quit: eschnett]
aserio has joined #ste||ar
<nikunj97>
hkaiser: yt?
<hkaiser>
here
<nikunj97>
hkaiser: the thing with launch policy made things explanable
<nikunj97>
turns out that was the only issue
<nikunj97>
now I'm getting results that I can explain
<nikunj97>
but with significantly more overheads as well
<hkaiser>
ohh, ok
<nikunj97>
we're talking something like 2.7-2.8s of overhead
<hkaiser>
we can leave it as it was if the overheads are smaller
<nikunj97>
while the previous one had about 0.2s
<nikunj97>
yes I think so too, and we can tell them that the reasons for decreased time is due to the launch policy we chose by default
<nikunj97>
it's async and not sync
<nikunj97>
so we end up reducing the amount of overheads in the end
<nikunj97>
should I run the final scripts then with previous specification?
<hkaiser>
yes, I think so
aserio has quit [Quit: aserio]
<nikunj97>
hkaiser: alright, I'll create the final set of benchmarks and send an email to keita as well. We should get the graphs by thursday or friday end, let's see where it goes. Also I'll do the same with async versions as well.
<nikunj97>
also hkaiser see pm
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<hkaiser>
nikunj97: ok
<nikunj97>
hkaiser: btw our 1d case A even with the slower input gives us about 2.73% overhead (theirs have 7%)
<nikunj97>
I guess we could also use the same case A and a more favorable case B of ours that shows not a lot of overheads
<nikunj97>
ours case B shows 10.7% while theirs have 9%