llvm dev - Apr 2017 - RFC: Improving the performance of ItaniumDemangle

well, top-of-branch lldb uses this code, that's how I found it.  Do you
mean libc++'s demangler?

FYI when I said 14+% (and now it's 17%), I mean the overall performance of
starting lldb, not just the demangler itself.  It's probably several times
faster now with this change (https://reviews.llvm.org/D32500)


On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk at apple.com> wrote:
> I thought the plan of record was (r280732):
>
> '''
> Once the fast demangler in lldb can handle any names this
> implementation can be replaced with it and we will have the one true
> demangler.
> '''
>
> What is the status of lldb's fast demangler? Is it available on Ubuntu
> 16.04?
>
> vedant
>
>
> > On Apr 24, 2017, at 6:02 PM, Scott Smith via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > (Again), while trying to improve the performance of lldb, I ran into a
> bottleneck with the demangler.  This may be specific to my platform -
> Ubuntu 16.04, probably using libstdc++, not libc++.  It makes extensive use
> of std::string and std::vector, and I see memory allocation at the top.  I
> prototyped a version that uses an arena-style memory allocator (you can
> allocate, but you can't ever free).  It is approximately 14+% faster. 
I
> think I can further optimize it by making repeated appends zero-copy (for
> the string being appended too).
> >
> > The code right now is a little ugly, because it uses a thread local
> variable to pass around the arena pointer, rather than change every + and
> += to be function calls that take db.arena as a parameter.  I'm not
sure
> what you guys would prefer for that either (thread local variable vs api
> change).
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/b96fc1d2/attachment.html>

> On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at
purestorage.com> wrote:
> 
> well, top-of-branch lldb uses this code, that's how I found it.  Do you
mean libc++'s demangler?
Thanks for explaining, this is the first time I'm looking at the demangler
situation. It looks like libcxxabi has an arena-based demangler, and that the
one in llvm is different.

I'm confused by this because the comment in llvm says that libcxxabi is
supposed to reuse the llvm demangler. This doesn't seem to be happening,
right?

> FYI when I said 14+% (and now it's 17%), I mean the overall performance
of starting lldb, not just the demangler itself.  It's probably several
times faster now with this change (https://reviews.llvm.org/D32500)
Do you know what the llvm policy is on using TLS in library code? I can't
find any mention of this in the programmer's manual, and my officemates
don't know either.

vedant

> On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk at apple.com>
wrote:
> I thought the plan of record was (r280732):
> 
> '''
> Once the fast demangler in lldb can handle any names this
> implementation can be replaced with it and we will have the one true
> demangler.
> '''
> 
> What is the status of lldb's fast demangler? Is it available on Ubuntu
16.04?
> 
> vedant
> 
> 
> > On Apr 24, 2017, at 6:02 PM, Scott Smith via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> >
> > (Again), while trying to improve the performance of lldb, I ran into a
bottleneck with the demangler.  This may be specific to my platform - Ubuntu
16.04, probably using libstdc++, not libc++.  It makes extensive use of
std::string and std::vector, and I see memory allocation at the top.  I
prototyped a version that uses an arena-style memory allocator (you can
allocate, but you can't ever free).  It is approximately 14+% faster.  I
think I can further optimize it by making repeated appends zero-copy (for the
string being appended too).
> >
> > The code right now is a little ugly, because it uses a thread local
variable to pass around the arena pointer, rather than change every + and += to
be function calls that take db.arena as a parameter.  I'm not sure what you
guys would prefer for that either (thread local variable vs api change).
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
>

On Tue, Apr 25, 2017 at 12:36 PM, Vedant Kumar <vsk at apple.com> wrote:
>
> > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at
purestorage.com>
> wrote:
> >
> > well, top-of-branch lldb uses this code, that's how I found it. 
Do you
> mean libc++'s demangler?
>
> Thanks for explaining, this is the first time I'm looking at the
demangler
> situation. It looks like libcxxabi has an arena-based demangler, and that
> the one in llvm is different.
>
> I'm confused by this because the comment in llvm says that libcxxabi is
> supposed to reuse the llvm demangler. This doesn't seem to be
happening,
> right?
>
I'm confused too.  I'm new here :-)

>
> > FYI when I said 14+% (and now it's 17%), I mean the overall
performance
> of starting lldb, not just the demangler itself.  It's probably several
> times faster now with this change (https://reviews.llvm.org/D32500)
>
> Do you know what the llvm policy is on using TLS in library code? I
can't
> find any mention of this in the programmer's manual, and my officemates
> don't know either.
>
I don't know, and frankly I don't like using it.  It was more "to
get the
conversation started."  I can change all the string routines to take the
arena as a parameter, it'll just make the diff look larger.

But if libcxxapi has already done the heavy lifting then maybe I should
just benchmark their demangler instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/437dd347/attachment.html>

On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at
purestorage.com>
> wrote:
> >
> > well, top-of-branch lldb uses this code, that's how I found it. 
Do you
> mean libc++'s demangler?
>
> Thanks for explaining, this is the first time I'm looking at the
demangler
> situation. It looks like libcxxabi has an arena-based demangler, and that
> the one in llvm is different.
>
> I'm confused by this because the comment in llvm says that libcxxabi is
> supposed to reuse the llvm demangler. This doesn't seem to be
happening,
> right?
>
This seems correct. libcxxabi demangler [1] is different from the one used
by llvm [2]. I'm hoping Saleem, Eric or Jon (copied) knows a bit of history
as to why this is so (perhaps because the two projects evolved
independently ?).

>
> > FYI when I said 14+% (and now it's 17%), I mean the overall
performance
> of starting lldb, not just the demangler itself.  It's probably several
> times faster now with this change (https://reviews.llvm.org/D32500)
>
> Do you know what the llvm policy is on using TLS in library code? I
can't
> find any mention of this in the programmer's manual, and my officemates
> don't know either.
>
Both libcxx and libcxxabi use __libcpp_tls_*() functions of the threading
API [2] (which call pthread functions on most platforms) for thread-local
storage needs. IIRC thread_local is not implemented across all the
platforms that llvm support.

If the idea is to improve libcxxabi's demangler, then it should be
straightforward to use these functions instead of thread_local.

[1] https://github.com/llvm-mirror/libcxxabi/blob/master/
src/cxa_demangle.cpp
[2]
https://github.com/llvm-mirror/llvm/blob/master/lib/Demangle/ItaniumDemangle.cpp
[3] https://github.com/llvm-mirror/libcxx/blob/master/
include/__threading_support

PS: Here's a particularly amusing bug of the current libcxxabi demangler:
https://bugs.llvm.org//show_bug.cgi?id=31031

Cheers,

/ Asiri

>
> vedant
>
>
> > On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk at
apple.com> wrote:
> > I thought the plan of record was (r280732):
> >
> > '''
> > Once the fast demangler in lldb can handle any names this
> > implementation can be replaced with it and we will have the one true
> > demangler.
> > '''
> >
> > What is the status of lldb's fast demangler? Is it available on
Ubuntu
> 16.04?
> >
> > vedant
> >
> >
> > > On Apr 24, 2017, at 6:02 PM, Scott Smith via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > >
> > > (Again), while trying to improve the performance of lldb, I ran
into a
> bottleneck with the demangler.  This may be specific to my platform -
> Ubuntu 16.04, probably using libstdc++, not libc++.  It makes extensive use
> of std::string and std::vector, and I see memory allocation at the top.  I
> prototyped a version that uses an arena-style memory allocator (you can
> allocate, but you can't ever free).  It is approximately 14+% faster. 
I
> think I can further optimize it by making repeated appends zero-copy (for
> the string being appended too).
> > >
> > > The code right now is a little ugly, because it uses a thread
local
> variable to pass around the arena pointer, rather than change every + and
> += to be function calls that take db.arena as a parameter.  I'm not
sure
> what you guys would prefer for that either (thread local variable vs api
> change).
> > >
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > llvm-dev at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/48cc375e/attachment.html>

On 25 April 2017 at 15:36, Vedant Kumar <vsk at apple.com>
wrote:
>
>> On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at
purestorage.com> wrote:
>>
>> well, top-of-branch lldb uses this code, that's how I found it.  Do
you mean libc++'s demangler?
>
> Thanks for explaining, this is the first time I'm looking at the
demangler situation. It looks like libcxxabi has an arena-based demangler, and
that the one in llvm is different.
>
> I'm confused by this because the comment in llvm says that libcxxabi is
supposed to reuse the llvm demangler. This doesn't seem to be happening,
right?
The one in llvm required a few changes to be more portable. If it can
be made faster that is a good thing.

If possible you should make the change in libcxxabi and copy the code
to llvm given the license difference between the two.

Cheers,
Rafael