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/ | GSoC2018: https://wp.me/p4pxJf-k1
anushi has quit [Ping timeout: 260 seconds]
anushi has joined #ste||ar
eschnett_ has joined #ste||ar
eschnett has quit [Ping timeout: 240 seconds]
anushi has quit [Ping timeout: 240 seconds]
diehlpk has joined #ste||ar
diehlpk has quit [Ping timeout: 240 seconds]
hkaiser has quit [Quit: bye]
parsa[w] has quit [Read error: Connection reset by peer]
parsa[w] has joined #ste||ar
anushi has joined #ste||ar
K-ballo has quit [Quit: K-ballo]
nanashi55 has quit [Ping timeout: 240 seconds]
nanashi55 has joined #ste||ar
nikunj has joined #ste||ar
<jbjnr>
on power I've got problems with coroutines. I tried with GENERIC_COROUTINES ON and OFF but both give errors. I seem to recall that we had to use an older boost at one time (but I though hk fixed it). Does anyone know if it's fixable with another option, or boost version etc. heller___ ?
anushi has quit [Ping timeout: 240 seconds]
anushi has joined #ste||ar
anushi has quit [Remote host closed the connection]
anushi has joined #ste||ar
anushi has quit [Ping timeout: 240 seconds]
anushi has joined #ste||ar
david_pfander has joined #ste||ar
anushi has quit [Ping timeout: 240 seconds]
anushi has joined #ste||ar
anushi has quit [Remote host closed the connection]
<github>
hpx/master ddbd108 Mikael Simberg: Fix some more c++11 build problems
<github>
hpx/master ef04f40 Mikael Simberg: Merge pull request #3372 from msimberg/fix-c++11...
<jakub_golinowski>
M-ms - for me all the perf tests passed both for the opencv from master (pthreads) and opencv from hpx_backend branch
<jakub_golinowski>
among them the test that was requested by the opencv ppl - but the results are far from satisfying - in all cases opencv with hpx backend is considerably slower sometimes the overall test run time for opencv with hpx backend is multiple times bigger than the opencv wiht pthreads runtime
<M-ms>
jakub_golinowski: do you mean (opencv master branch with pthreads backend) and (opencv hpx_backend branch with pthreads backend)?
<M-ms>
jakub_golinowski: mmh, that's a problem
<jakub_golinowski>
ah, no sorry I mean: (1) opencv master with pthreads backend vs. (2) opencv hpx_backend branch with hpx backend
<jbjnr>
jakub_golinowski: the time taken for the hpx runtime to start up is quite long and can contribute to longer tests. I hope the test time reported for the graphs is only the copmoutation part and does not include the startup.
<jakub_golinowski>
jbjnr, in the mandelbrot benchmark it is only the computation time. However, note that in case of start-stop backend the runtime needs to be started after the call to parallel_for_() and therefore is included in the computation time (but this is a fair measurement, since in the start-stop version we always have to start and stop the rutime whenever we call parallel_for)
<jbjnr>
ok
<jakub_golinowski>
M-ms, you said something that employing HPX might somehow disrupt OpenCL - maybe this is the reason?
<M-ms>
jakub_golinowski: yeah, may be but I don't know what, it just seemed to be a commonality for some of the failing tests
<M-ms>
so we know now that HPX is a bit slower but not by much in your mandelbrot benchmark
<M-ms>
but something else is happening in the perf tests that's making it really slow
<M-ms>
so you could try profiling one of the perf tests (also filtered to just one test) and see if there are any hints
<M-ms>
although before that, all perf tests pass now? so what about unit tests? any change there or still some failing?
<jakub_golinowski>
M-ms, do you have something exact in mind when saying profiling? Use some special tool?
eschnett_ has quit [Quit: eschnett_]
<M-ms>
jakub_golinowski: yeah, my favourite is perf because all you need to do is "perf my_program" (and build with debug symbols)
<M-ms>
it's not fancy but it gives something useful quickly
<jbjnr>
users/biddisco/src/hpx/hpx/runtime/threads/coroutines/detail/context_generic_context.hpp:209:35: error: use of undeclared identifier 'Functor'
<jbjnr>
and
<jbjnr>
users/biddisco/src/hpx/hpx/runtime/threads/coroutines/detail/coroutine_impl.hpp:62:17: error: use of class template 'context_base' requires template arguments
<jbjnr>
typedef context_base super_type;
<jbjnr>
context type problems
<jbjnr>
boost-1.65.1
<jbjnr>
too new?
<jakub_golinowski>
M-ms, as for the unit tests I think there are some failing still I am reruning them now to make sure no new segfaults pop-up.
<jakub_golinowski>
M-ms, do you want me to push the test resutls to repo?
<jbjnr>
I didn't spend any time looking at the code yet cos I have other things to work on too, but I do recall us having issues with bost context on power and maybe I need to do something. But I can't remember, so I thought I'd ask instead before spending time on it
<jbjnr>
heller___: ^^^^
<jakub_golinowski>
M-ms, thank you for the reference to profiler - I will familiarize myself with it
<heller___>
jbjnr: strange, I was compiling a more or less recent HPX with generic context coroutines for ARM the other day
<heller___>
using boost 1.6 something
<jbjnr>
PowerPC
<heller___>
boost 1.67
<heller___>
sure
<heller___>
let me check
jakub_golinowski has quit [Ping timeout: 256 seconds]
quaz0r has quit [Ping timeout: 240 seconds]
quaz0r has joined #ste||ar
jakub_golinowski has joined #ste||ar
anushi has quit [Ping timeout: 265 seconds]
anushi has joined #ste||ar
<M-ms>
jakub_golinowski: nah, no need to push the test results
<jakub_golinowski>
M-ms, so after filtering out a few tests the accuracy tests for pthreads from master vs. tests for hpx from hpx_backend have the same results in terms of fail/pass
<jakub_golinowski>
M-ms, and the result is that all the tests pass - I realized I was not correctly passing the path to the opencv_extra/testdata and this was the reason for tests that were failing yesterday
<M-ms>
jakub_golinowski: ok, I assume the ones you're filtering out are still only failing with the hpx backend? how many are we roughly talking about?
<jakub_golinowski>
M-ms, sth like 10 tests
<M-ms>
hmm, that actually sounds pretty good
<jakub_golinowski>
M-ms, I remember mostly they were producing the segfault with the error of sth like longjump sth sth
<M-ms>
so some of these are the ocl tests?
<jakub_golinowski>
yes
<M-ms>
ah, the ones we saw in the beginning
<M-ms>
so non-core tests are mostly good then
<jakub_golinowski>
M-ms, yes and some other tests that at first sight do not seem to have a lot in common (at least by looking at their names)
<jakub_golinowski>
I modified a bit the run_tests script and will push it in a secodn
<M-ms>
ok, thanks
<jakub_golinowski>
there is the full list of failing tests - or to be more specific tests that I have seen at least one failing
<M-ms>
could you also make it run perf tests (if you haven't already)?
<jakub_golinowski>
M-ms, yes yes it runs perf tests as well
<M-ms>
ok, good
<jakub_golinowski>
M-ms, and about the changes I have as a PR - can I merge then now?
<M-ms>
jakub_golinowski: sorry, I didn't have time to look at it properly
<M-ms>
the only thing I wanted to comment was that you don't in principle need to have project(xxx) and find_package(HPX) in all the sub-CMakeLists.txt, it would be enough to do that at the top level
<M-ms>
on the other hand they now still work as standalone examples which is still nice
<M-ms>
but please go ahead and merge so you're not stuck juggling branches
<heller___>
jbjnr: can you please post the full error message?
<jakub_golinowski>
M-ms, thanks - with the projects at the single-example level the idea was exactly to still be able to build single example. For instance the mandelbrot benchmark is based on rebuilding the single opencv_mandelbrot example
jakub_golinowski has quit [Ping timeout: 265 seconds]
<M-ms>
jbjnr: I don't know but I assume he didn't have any special options
<M-ms>
But maybe that's why he was having problems later...
<jbjnr>
M-ms: it's ok. turns out my branch is screwed up. redoing everything now with stdlib=libstdc++ and clean master branch
<M-ms>
ok
<zao>
Sounds like you're having about as much fun as I do on FreeBSD :)
eschnett has quit [Quit: eschnett]
eschnett has joined #ste||ar
hkaiser has joined #ste||ar
<nikunj>
hkaiser: So I looked into the cmake source code in detail today. Turns out hpx_wrap got added due to it's addition in HPX_PKG_LIBRARIES and not due to hpx_targets. I made the change and tested the code with Debug/Release with dynamic main turned on and off
<nikunj>
Phylanx worked fine on my laptop with the HPX build
anushi has quit [Remote host closed the connection]
<zao>
Amusingly enough, they don't seem to have implemented the Power one.
<zao>
jbjnr: ^
<jbjnr>
thanks. That tells me what I need to know. newer cmake won't help
<zao>
Anyway, building a Boost in non-"versioned" flavour should get rid of it, together with the rest of the useful tags.
<jbjnr>
ok. I will remove the versioned tag
<jbjnr>
thanks
<jbjnr>
that was what I wanted to know
K-ballo has joined #ste||ar
<zao>
Not sure if the layout "tagged" will work, or if you need to go down to "system".
<zao>
Or building a newer CMake, with a FindBoost handpatched :P
<jbjnr>
trying now with 'tagged'
<jbjnr>
I will build newer boost if this fails
<jbjnr>
I begin to see why our users dislike boost so much.
<jbjnr>
zao: thanks. libs look good in tagged mode
<jbjnr>
now I try cmake on them
<jbjnr>
yat \o/
<jbjnr>
yay \o/
<jbjnr>
I meant.
<jbjnr>
works!!!!
<zao>
\o/
<jbjnr>
zao: cpp tests compiling, linking and giving the right output. All is well with the world. Cheers.
<jbjnr>
now for hpx again ....
<nikunj>
jbjnr: HPX cmake for some reason don't find boost if the layout is set to system or versioned but finds it with layout set to tagged. That's one thing I faced while installing HPX
<jbjnr>
nikunj: ok. I usually use versioned without problems, but it looks like some new stuff is added and cmake has not caught up.
<jbjnr>
heller___: M-ms hkaiser pycicle is being upgraded so that you can now trigger N builds per PR, with random combinations of CMake options and settings for each build. Options can be dependent on other options (so if HPX_WITH_CUDA is ON, then blah blah blah can be added with random combinations of sub options). Also, boost versions, compiler type (gcc/clang) can be handled in the same pass, so we now have a way of replicating buildbot
<jbjnr>
and going further becuase we can explore option spaces more thoroughly.
<jbjnr>
I will need help setting up good combinations of options for testing.
<jbjnr>
terminating with uncaught exception of type std::invalid_argument: hpx::resource::get_partitioner() can be called only after the resource partitioner has been allowed to parse the command line options.
<jbjnr>
Aborted (core dumped)
<jbjnr>
Can someone remind me what causes the error above^^^ ?
<nikunj>
jbjnr: which HPX build are you using?
quaz0r has quit [Ping timeout: 260 seconds]
<jbjnr>
the one I have just done on a power machine
<nikunj>
jbjnr: it might be due to previous incomplete implementation that got merged
<nikunj>
could you try building the current master?
<jbjnr>
this is master
<jbjnr>
from today
<jbjnr>
M-ms: can you rememeber what causes the RP error above?
jakub_golinowski has joined #ste||ar
<nikunj>
jbjnr: my commit got merged like an hour ago. Could you retry with that?
<jbjnr>
ok
<M-ms>
jbjnr: HPX_WITH_MAX_CPU_COUNT?
<jbjnr>
nikunj: your merge has nothing to do with this error
<jbjnr>
M-ms: aha!
<jbjnr>
thanks
<jbjnr>
I check ...
<jbjnr>
we need to fix that. its a huge PITA
<jbjnr>
I forget every time
<M-ms>
not sure if it's that but there's an equally unhelpful message if you forget that
<nikunj>
jbjnr: That error also appears when you try to access HPX functionality without initiating HPX (I faced it quite a lot during implementing). So I got confused :/
<jbjnr>
I think I will add a CMake check that greps /proc/cpuinfo and gives a warning just in case. It won't be reliable because login/compute nodes, but at least it might help
<M-ms>
does someone know why we can't have the masks be dynamic? was it for a performance reason at some point?
<jbjnr>
yes. for <64 we use an int with bit masks, for larger we use a bitset. I doubt there's much difference in speed though
<heller___>
shouldn't
<jakub_golinowski>
M-ms, could you tell me what should I expect from perf? Is there an option to have it tell me how much time was spent in each function or sth like this?
<heller___>
we used to use a dynamic bitset once. that was a performance hit
<jbjnr>
balls.
<jbjnr>
fixing CPU count did not make error go away
quaz0r has joined #ste||ar
<M-ms>
jbjnr: ?
<jbjnr>
?
<M-ms>
just to be sure, you set it high enough? because it has something like 8 hyperthreads, no?
<jbjnr>
grrrr
<jbjnr>
lstop gives me 160 PUs and I set it to 256
<jakub_golinowski>
M-ms, I got as far as this: Overhead Command Shared Object Symbol ◆
<M-ms>
jakub_golinowski: yeah, so I usually run "perf record -F99 --call-graph dwarf my_program"
<M-ms>
-F sets the sampling frequency, call-graph dwarf was useful for some reason
<M-ms>
it then outputs a file which you can view with perf report
<hkaiser>
: jbjnrI still think this is a problem in the resource_manager
<hkaiser>
we need to correct things there, using the cmake option just prevents it from happening
<M-ms>
ah, yeah, so you probably need to recompile with RelWithDebInfo for it to be useful
<jakub_golinowski>
M-ms, but actually this is from the debug build :/
<jbjnr>
M-ms: hwloc 1.x or 2.0 on power? opinion?
<M-ms>
note that hpx is going to have a lot of entries there while opencv is doing single threaded stuff
<jbjnr>
no differnce I would hope
<hkaiser>
M-ms: any optinion on that?
<M-ms>
hrm
<M-ms>
jbjnr: I think neither was significantly worse when we tested with mathieu (but some affinity test was giving problems)
<jbjnr>
I was just looking for possible reasons why the RP was choking.
<hkaiser>
jbjnr, M-msI believe the problem you're seeing is at least diagnosable, if not preventable
<M-ms>
hkaiser: you mean checking properly in the resource manager if hpx is configured with a bad max cpu count?
<hkaiser>
M-ms: at least, if not find a way for the resource manager to use only as many cores as hpx was configured with
<jbjnr>
it might not be an RP problem. it might be some unrelated error
<hkaiser>
jbjnr: there is also the hpx_main snafu on master nikunj is trying to resolve, currently
<hkaiser>
could be resolved now, could be not
<M-ms>
mmh, yeah if it's cpu count related I'm sure we could do something better there, if it's something else depends on what that something else is...
<hkaiser>
results in a similarily useless error message
<M-ms>
jakub_golinowski: so are you getting more lines of output than that one line?
<hkaiser>
M-ms: well, you can work around the issue by specifying the cpu count, so it looks to be related
<nikunj>
jbjnr: could you please tell the environment you're on?
<hkaiser>
jbjnr: last resort: use HPX_WITH_DYNAMIC_HPX_MAIN=OFF
<jakub_golinowski>
M-ms, ah yes, of course - but I still het the somewhat obfuscated Symbols
<M-ms>
jakub_golinowski: another approach would be to just time the parallel_for loop to see if that's where the time is spent or if it's somewhere else
<hkaiser>
M-ms, jakub_golinowskihave you ocnsidered using APEX? allows to collect traces, timings, etc.
<jbjnr>
nikunj: I'm on a powerpc node. OS is RedHad Enterprise Server 7.5. 160 cores. Shitload of memory. etc etc
<M-ms>
hkaiser: ah, ok
<hkaiser>
shows every hpx thread in the end
<jbjnr>
Clang 7.0 compiled from source today
<hkaiser>
jbjnr: is it one of those summit nodes?
<jbjnr>
nikunj: hkaiser I did not realize that nikunj was working on something related to this. I will pul from master again now
<hkaiser>
6 GPUs?
<jbjnr>
hkaiser: similar
<hkaiser>
cool
<jbjnr>
it's a local node here we are using for summit type testing
<hkaiser>
nice
<nikunj>
jbjnr: redhat does come with glibc. So my code should work. Please try with the current merged commit. If it's related to my implementation then it should (most likely) get fixed
<M-ms>
hkaiser: that's a good idea, wanted to start off easy though
<jakub_golinowski>
M-ms, so basically I should not see Symbols like this: _ZN3hpx7threads10coroutines6detail2lx10trampolineINS2_14coroutine_implEEEvPT_
<jakub_golinowski>
but sth more readable?
<nikunj>
jakub_golinowski: are you trying to see assembly for a code?
<jakub_golinowski>
nikunj, no no :D I am trying to profile a cpp application. Specifically one of the OpenCV tests
<jakub_golinowski>
using perf for the first time and trying to first get to know what should I expect from it
<nikunj>
jakub_golinowski: oh my bad then. Those symbols come in assembly so I was a bit curious
<jbjnr>
nikunj: using latest master I get the same exception
<jbjnr>
terminating with uncaught exception of type std::invalid_argument: hpx::resource::get_partitioner() can be called only after the resource partitioner has been allowed to parse the command line options.
<jbjnr>
Aborted (core dumped)
<nikunj>
jbjnr: It might not be related to my code then. As a last resort can you try building with -DHPX_WITH_DYNAMIC_HPX_MAIN=OFF
<jbjnr>
building now
<nikunj>
jbjnr: just to be sure, it comes with glibc right?
<jbjnr>
nikunj: -DHPX_WITH_DYNAMIC_HPX_MAIN=OFF fixes it.
<jbjnr>
Thanks
<jbjnr>
I have hello world from 160 cores
<nikunj>
jbjnr: so it is related to my implementation. Could you please tell me the result of: ldd --verion
<jbjnr>
openpower01:~/build/hpx$ ldd --version
<jbjnr>
-bash: otool: command not found
<jbjnr>
we are missing some bintools by the looks of it
<nikunj>
jbjnr: that explains it!
<jbjnr>
how?
<nikunj>
My implementation requires glibc. It was not found in your machine
<nikunj>
that is why it did not work. I could not find a macro that could specifically targeted glibc, so I used linux in general (thinking most of them come with glibc by default)
<jbjnr>
ok. makes sense. I am not very expert with some of the sysdmin side of stuff.
<jakub_golinowski>
M-ms, not sure if doing sth wrong but other libraries have more readable Symbols (including so from OpenCV) however HPX has still this style:
<M-ms>
jakub_golinowski: I don't know why that's happening
<M-ms>
some more basic things you could try are change the number of threads hpx uses, and play with the idling settings
<jakub_golinowski>
M-ms, to probe the performance increase
<jakub_golinowski>
?
<M-ms>
you'll get 8 threads by default and it might be that the serial parts of the tests are slowed down significantly by a second thread spinning in the scheduling loop on the same core
<M-ms>
just to see if it makes some difference to start with, don't care about exact numbers yet
<hkaiser>
jakub_golinowski: have you tried to feed those symbols through c++filt?
<jakub_golinowski>
hkaiser, no, what is that?
galabc has quit [Quit: Leaving]
<jakub_golinowski>
Ah I see
<jakub_golinowski>
hkaiser, it works :D
<hkaiser>
jaafar: you can pass the whole file through it, it will ignore everything but the symbols
<nikunj>
hkaiser: all tests have passed with #519. This should fix things for now.
<hkaiser>
nikunj: let me merge things and retrigger all the other PRs
david_pfander has quit [Ping timeout: 260 seconds]
hkaiser has quit [Quit: bye]
mcopik has quit [Ping timeout: 265 seconds]
mcopik has joined #ste||ar
<jakub_golinowski>
M-ms, hkaiser: I found out that the package perf for ubuntu is built with NO_DEMANGLE
<jakub_golinowski>
I rebuilt the package manually changing NO_DEMANGLE to 0 and now it works withot the c++filt trick
jakub_golinowski has quit [Quit: Ex-Chat]
nikunj has quit [Quit: Leaving]
jakub_golinowski has joined #ste||ar
nikunj has joined #ste||ar
anushi has joined #ste||ar
<nikunj>
jbjnr: yt?
<jbjnr>
nikunj: just logged in from home
<nikunj>
ohk, jbjnr could you share the options that ld gives you in Redhat (run: man ld and share a gist) the next time you operate on it.
<jbjnr>
jakub_golinowski: you should try --hpx:threads=4 --hpx:bind=balanced to use only one PU per core
<jbjnr>
nikunj: I'll try now
<jakub_golinowski>
jbjnr, in order to boost performance?
<jbjnr>
jakub_golinowski: yes, if you have 4 cores, 8 hyperthreads, you often find that performance drops when you use both PUs on a core compared to just one
hkaiser has joined #ste||ar
<jakub_golinowski>
ok, thank for the hint!
<jakub_golinowski>
jbjnr, I will run the mandelbrot benchmark with this config
<jbjnr>
nikunj: pulled from master but it gave ma a conflict - I assume you force pushed. I reset --hard origin/master and recompiled. Same output, just main
<nikunj>
jbjnr, yes it was a force push
<nikunj>
jbjnr, i see
<nikunj>
jbjnr, could you tell if it's a powerpc or a powerpc64?
<jbjnr>
64
<nikunj>
also which environment is it (with version)
<jbjnr>
ehat do you mean? what do you want to know
jakub_golinowski has quit [Ping timeout: 244 seconds]
<jbjnr>
nikunj: /usr/lib/gcc/ppc64le-redhat-linux/4.8.5/../../../../lib64/crt1.o: In function `_start':
<jbjnr>
(.text+0x24): undefined reference to `__wrap___libc_start_main'
<jbjnr>
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
<diehlpk_work>
hkaiser, Could you finish your gsoc evaluation by today?
<jbjnr>
nikunj: I tried adding extern "C" to the __Wrap_xxx but it segfaulted when I did that
jakub_golinowski has joined #ste||ar
<nikunj>
ok
<nikunj>
hkaiser, yt?
<hkaiser>
nikunj: here
<nikunj>
I have a wonderful idea (which I should have thought of before). Instead of wrapping __libc_start_main, let's wrap the main instead. Call to main for every architecture is same so it will flawlessly
<hkaiser>
ok
<nikunj>
I thought that __libc_start_main would work similarly (so I never bothered changing main) but turns out a slight change in definition won't allow it to work properly on powerpc
<hkaiser>
...or other platforms
<hkaiser>
we new it was brittle
<hkaiser>
knew*
<nikunj>
yes
<nikunj>
main should not be brittle
<nikunj>
jbjnr, could you try the current master?
<nikunj>
just to check if my main hypothesis is correct
<jbjnr>
wrap_libc.cpp:(.text+0x44): undefined reference to `__real_main'
<nikunj>
jbjnr, the wrap symbol (from ld) provides you a way to wrap a symbol and define your own wrapper for it. I chose _libc_start_main as a wrapper initially thinking that we might be able to initiate the HPX runtime pretty early on. It failed pretty miserably, but the entry point was changed to our own custom entry point.
<nikunj>
Thinking that the solution is still portable enough I implemented it only later to identify it won't work on powerpc
<nikunj>
So now we are wrapping main instead since that will now be our new portable entry point
<nikunj>
that should do things nicely
<jbjnr>
good work
<nikunj>
jbjnr, thanks!
<nikunj>
hkaiser: working on a pr now. Will try this to get merged then rebase apple to merge it as well. sounds good?
<hkaiser>
let focus on one thing at a time
<nikunj>
hkaiser: what should I focus on?
<hkaiser>
finish linux support
<nikunj>
hkaiser: the pr was to make the linux support better. This would prevent us from using multiple versions of __libc_start_main for different platforms
<hkaiser>
nikunj: do you have ppc support under control now?
<nikunj>
if we wrap main, we will have it under control. Things work on jbjnr machine
<nikunj>
hkaiser: changing the wrapper symbol will help us gain better overall control over the linux platform
<hkaiser>
nikunj: isn't that what I suggested? finish linux support?
<nikunj>
hkaiser: ohk on it then, pr will arive soon
<hkaiser>
nikunj: is main a weak symbol too?
<nikunj>
if it's letting us wrap it then yes it is as well
<nikunj>
hkaiser: i'm not too sure though
<hkaiser>
also, pls be careful, hpx_init defines its own main (which would have to be wrapped with a pp constant anyways in your case, now that I think about it)
<hkaiser>
it even defines several versions of it
<nikunj>
hkaiser: actually the fact with wrap is it let's you wrap any function (weak or strong)
<hkaiser>
does it?
<nikunj>
Basically it tells the compiler to call the __wrap_<symbol_name> instead of the actual one
<nikunj>
It's very much like dlsym method. But the plus point here is it can be extended to static executables as well
<nikunj>
in case of dlsym it is limited only to dynamic executable
<nikunj>
that was the primary reason i chose wrap over dlsym. dlsym had one thing done right, if you chose to call dlsym when the symbol does not exists then it would simply not refuse to work. In case of wrap we had to add checks to get things right
<github>
[hpx] NK-Nikunj opened pull request #3375: Replacing wrapper for __libc_start_main with main (master...Linux_better_impl) https://git.io/fNIXC
nikunj has quit [Quit: goodnight]
<jakub_golinowski>
M-ms, for your reference and to start a discussion about how to read the perf logs: https://pastebin.com/8NueJTEa
mcopik has quit [Ping timeout: 260 seconds]
quaz0r has joined #ste||ar
quaz0r has quit [Ping timeout: 268 seconds]
hkaiser has quit [Read error: Connection reset by peer]
diehlpk has joined #ste||ar
quaz0r has joined #ste||ar
jakub_golinowski has quit [Ping timeout: 240 seconds]