weld_rt_thread_id() calls in dictmerger
mihai-varga opened this issue · comments
In the cpp runtime, the dictionary calls (the expensive?) weld_rt_thread_id() (which then calls pthread_getspecific) twice for every item that is added in the dictionary. I believe the threadID is already available somewhere in the function stacks when weld_rt_dict_merge is called from llvm, so that value could be passed in the function call as well.
I don't think I'll manage to do a proper pull request any time soon, but in my small experiment involving a dictmerger, 10 mil entries and running on 1 thread I get a speedup of 1.4 by replacing the weld_rt_thread_id() call from dict-new.cpp with 0.
We've observed this too (and have run the same experiment before as well
:)) In the new runtime (which is currently only single-threaded) the
pthread parameters will be explicitly passed to multi-threaded functions so
no external function call will be necessary to retrieve this information
(it will just be a function argument loaded before spawning parallel work).
…On Mon, Jul 23, 2018 at 3:53 PM Mihai Varga ***@***.***> wrote:
In the cpp runtime, the dictionary calls (the expensive?)
weld_rt_thread_id() (which then calls pthread_getspecific) twice for
every item that is added in the dictionary. I believe the threadID is
already available somewhere in the function stacks when weld_rt_dict_merge
is called from llvm, so that value could be passed in the function call as
well.
I don't think I'll manage to do a proper pull request any time soon, but
in my small experiment involving a dictmerger, 10 mil entries and running
on 1 thread I get a speedup of 1.4 by replacing the weld_rt_thread_id()
call from dict-new.cpp with 0.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#376>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABTCY_iE4Yega7PegUu3Dn-OM0O914hrks5uJdVdgaJpZM4VbCU9>
.
--
Shoumik
Ah I see, then I'll just close the issue.