fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<mjw>
constitute an algorithmic fix that takes pass-2 runtime
<mjw>
from 22s (stap 4.0 release)
<mjw>
through 19s (git HEAD^^)
<mjw>
down to 0.3s (git HEAD)
<fche>
yeah, overdue
<fche>
was afraid of string processing, but really it's not that bad in c++ :)
<mjw>
while in C...
* mjw
always makes at least one crashing mistake even for simple things like concatenation... sigh
<fche>
which reminds me ....
<fche>
when we get started with that debuginfo file server thingamabob
<fche>
any objection if elfutils were to gain a little bit of c++ code (not in the library but in the client) ?
<mjw>
fche, in the tools I don't think it would be bad. In the libraries I am worried about maintaining API.
<jistone>
would you use it in implementation, keeping only C API?
<mjw>
fche, the other thing has been that as long as we want to support things like RHEL6 we cannot really use c++11, which I think we would like.
<mjw>
this has also come up with atomics
* jistone
whispers DTS
<mjw>
I think we are ready to drop plain RHEL6 support now though, tell people to use DTS or something
<jistone>
yeah that
<mjw>
jistone, yeah, that could also be done, keep C interface, but c++ implementation.
<fche>
yea
orivej_ has joined #systemtap
orivej has quit [Ping timeout: 268 seconds]
<mjw>
BTW. The other thing atomics is more of an issue.
<mjw>
The official c11 atomics are only available since gcc 4.9
<mjw>
which would rule out the rhel7 system compiler
<mjw>
so then we would probably use the gcc atomic builtins instead
<mjw>
or, if we want to support older systems we would have to only use the older sync builtins
<mjw>
choices, choices...
<mjw>
and of course there is also openmp to consider...
<mjw>
Or reimplemnt it all in rust with an external C interface of course :)
gila has quit [Read error: No route to host]
gila has joined #systemtap
sofini is now known as mauved
<fche>
or forget the apis etc
<fche>
I mean forget atomics etc. usage down at the elfutils level
<fche>
it's really the client side code that would be library code, so C, and it wouldn't have to be parallelized at a level visible to the rest of libelf
<fche>
just maybe some parallel outgoing http connections
<mjw>
yeah, but the dyninst people really want to
<fche>
yeah, I don't blame them ...just a separate effort
<mjw>
surely
<mjw>
and we did talk about it a couple of times (off-list) and "soon" they will have someone do the work...
slowfranklin has quit [Quit: slowfranklin]
<jistone>
mjw, RIIR, yes! :D
<jistone>
the Send and Sync traits are great for thread safety in pure Rust
<jistone>
but... doesn't really help you across FFI boundaries, unless you make sure all your FFI types are Send + Sync
irker464 has joined #systemtap
<irker464>
systemtap: wcohen systemtap.git:refs/heads/master * release-4.0-166-ga1ae3af / testsuite/systemtap.speculate/speculate.stp: Fix the speculate.stp test http://tinyurl.com/yyu58ukj
<irker464>
systemtap: smakarov systemtap.git:refs/heads/master * release-4.0-170-g14b90ae / testsuite/systemtap.examples/memory/cachestat.stp: systemtap.examples :: cachestat.stp can use format specifiers now http://tinyurl.com/yxrrleae