mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: David Wang <00107082@163.com>
Cc: musl@lists.openwall.com, Markus Wichmann <nullplan@gmx.net>
Subject: Re: [musl] Re:Re: [musl] Re:Re: [musl] Re:Re: [musl] qsort
Date: Fri, 10 Feb 2023 09:19:55 -0500	[thread overview]
Message-ID: <20230210141955.GA4163@brightrain.aerifal.cx> (raw)
In-Reply-To: <23b37232.4d4c.1863b92aa13.Coremail.00107082@163.com>

On Fri, Feb 10, 2023 at 09:45:12PM +0800, David Wang wrote:
> 
> 
> 
> At 2023-02-10 21:10:45, "Rich Felker" <dalias@libc.org> wrote:
> >On Fri, Feb 10, 2023 at 06:00:27PM +0800, David Wang wrote:
> 
> >What tool was used for this? gprof or anything else invasive is not
> >meaningful; for tiny functions, the entire time measured will be the
> >profiling overhead. perf(1) is the only way I know to get meaningful
> >numbers.
> >
> >In particular, it makes no sense that significant time was spent in
> >wrapper_cmp, which looks like (i386):
> >
> >   0:   ff 64 24 0c             jmp    *0xc(%esp)
> >
> >or (x86_64):
> >
> >   0:   ff e2                   jmpq   *%rdx
> >
> >or (arm):
> >
> >   0:   4710            bx      r2
> >
> >but I can imagine it being (relatively) gigantic with a call out to
> >profiling code.
> >
> >Rich
> 
> I have myself implemented a profiling tool, using perf_event_open to
> start profiling and mmap to collect callchains, the source code is
> here
> https://github.com/zq-david-wang/linux-tools/blob/main/perf/profiler/profiler.cpp
> (Still buggy, there is always strange callchain which I could not
> figure out...and I am still working on it...)

Thanks for sharing. It's nice to see another tool like this.

> Also, I did not use any optimization when compile the code, which
> could make a difference, I will take time to give it a try .

Yes, that would make a big difference. For this to be meaninful the
measurement needs to be with optimizations.

> About wrapper_cmp, in my last profiling, there are total 931387
> samples collected, 257403 samples contain callchain ->wrapper_cmp,
> among those 257403 samples, 167410 samples contain callchain
> ->wrapper_cmp->mycmp, that is why I think there is extra overhead
> about wrapper_cmp. Maybe compiler optimization would change the
> result, and I will make further checks.

Yes. On i386 here, -O0 takes wrapper_cmp from 1 instruction to 10
instructions.

Rich

  reply	other threads:[~2023-02-10 14:20 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20  1:49 Guy
2023-01-20 12:55 ` alice
2023-01-30 10:04   ` [musl] " David Wang
2023-02-01 18:01     ` Markus Wichmann
2023-02-02  2:12       ` [musl] " David Wang
2023-02-03  5:22         ` [musl] " David Wang
2023-02-03  8:03           ` Alexander Monakov
2023-02-03  9:01             ` [musl] " David Wang
2023-02-09 19:03       ` Rich Felker
2023-02-09 19:20         ` Alexander Monakov
2023-02-09 19:52           ` Rich Felker
2023-02-09 20:18             ` Rich Felker
2023-02-09 20:27               ` Pierpaolo Bernardi
2023-02-10  4:10             ` Markus Wichmann
2023-02-10 10:00         ` [musl] " David Wang
2023-02-10 13:10           ` Rich Felker
2023-02-10 13:45             ` [musl] " David Wang
2023-02-10 14:19               ` Rich Felker [this message]
2023-02-11  5:12                 ` [musl] " David Wang
2023-02-11  5:44                   ` alice
2023-02-11  8:39                     ` Joakim Sindholt
2023-02-11  9:06                       ` alice
2023-02-11  9:31                         ` [musl] " David Wang
2023-02-11 13:35                         ` Rich Felker
2023-02-11 17:18                           ` David Wang
2023-02-16 15:15       ` David Wang
2023-02-16 16:07         ` Rich Felker
2023-02-17  1:35           ` [musl] " David Wang
2023-02-17 13:17           ` Alexander Monakov
2023-02-17 15:07             ` Rich Felker
2023-02-11  9:22     ` [musl] " Markus Wichmann
2023-02-11  9:36       ` [musl] " David Wang
2023-02-11  9:51       ` David Wang
2023-01-20 13:32 ` [musl] qsort Valery Ushakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230210141955.GA4163@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=00107082@163.com \
    --cc=musl@lists.openwall.com \
    --cc=nullplan@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).