From: Thomas Neumann <thomas.neumann@in.tum.de>
To: Tamar Christina <Tamar.Christina@arm.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Jason Merrill <jason@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>,
Jakub Jelinek <jakub@redhat.com>,
Jonathan Wakely <jwakely.gcc@gmail.com>
Subject: Re: [PATCH v4] eliminate mutex in fast path of __register_frame
Date: Mon, 21 Nov 2022 12:22:32 +0100 [thread overview]
Message-ID: <b4b30340-0854-e2d2-03ce-a76c5052e335@in.tum.de> (raw)
In-Reply-To: <VI1PR08MB532513A4AF91751CAA34A2D7FF0A9@VI1PR08MB5325.eurprd08.prod.outlook.com>
Hi,
> When dynamically linking a fast enough machine hides the latency, but when
> Statically linking or on slower devices this change caused a 5x increase in
> Instruction count and 2x increase in cycle count before getting to main.
>
> This has been quite noticeable on smaller devices. Is there a reason the btree
> can't be initialized lazily? It seems a bit harsh to pay the cost of unwinding at
> startup even when you don't throw exceptions..
we cannot easily do that lazily because otherwise we need a mutex for
lazy initialization, which is exactly what we wanted to get rid of.
Having said that, I am surprised that you saw a noticeable difference.
On most platforms there should not be dynamic frame registration at all,
as the regular frames are directly read from the ELF data.
Can you please send me an precise description on how to reproduce the
issue? (Platform, tools, a VM if you have one would be great). I will
then debug this to improve the startup time.
Best
Thomas
next prev parent reply other threads:[~2022-11-21 11:22 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-16 10:19 Thomas Neumann
2022-09-16 14:49 ` Jason Merrill
2022-09-18 8:59 ` Dimitar Dimitrov
2022-09-18 9:20 ` Thomas Neumann
2022-09-18 10:02 ` Thomas Neumann
2022-09-19 13:46 ` Stephan Bergmann
2022-09-19 13:55 ` Thomas Neumann
2022-09-19 14:00 ` Stephan Bergmann
2022-09-19 15:33 ` Thomas Neumann
2022-09-20 5:39 ` Stephan Bergmann
2022-11-21 11:14 ` Tamar Christina
2022-11-21 11:22 ` Thomas Neumann [this message]
2022-11-21 11:48 ` Jakub Jelinek
2022-11-21 17:13 ` H.J. Lu
2022-11-22 0:31 ` Thomas Neumann
2022-11-22 8:20 ` Florian Weimer
2022-11-22 9:12 ` Thomas Neumann
2022-12-09 17:34 ` [PATCH] initialize fde objects lazily Thomas Neumann
2022-12-15 16:11 ` Tamar Christina
2022-12-16 17:25 ` Jason Merrill
2023-05-02 14:32 ` [PATCH] release the sorted FDE array when deregistering a frame [PR109685] Thomas Neumann
2023-05-10 10:49 ` [PATCH] fix radix sort on 32bit platforms [PR109670] Thomas Neumann
2023-08-10 11:33 ` [PATCH] preserve base pointer for __deregister_frame [PR110956] Thomas Neumann
2023-08-11 15:21 ` Jeff Law
2024-03-15 10:29 ` [PATCH] handle unwind tables that are embedded within unwinding code, [PR111731] Thomas Neumann
2024-03-20 8:25 ` Richard Biener
2024-03-22 13:35 ` Jeff Law
2024-03-22 13:36 ` Jeff Law
2024-03-22 14:43 ` Thomas Neumann
2022-11-22 8:00 ` [PATCH] speed up end_fde_sort using radix sort Thomas Neumann
2022-12-16 18:02 ` Jason Merrill
2022-11-21 11:49 ` [PATCH v4] eliminate mutex in fast path of __register_frame Tamar Christina
2022-11-21 11:53 ` Thomas Neumann
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=b4b30340-0854-e2d2-03ce-a76c5052e335@in.tum.de \
--to=thomas.neumann@in.tum.de \
--cc=Tamar.Christina@arm.com \
--cc=fweimer@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jason@redhat.com \
--cc=jwakely.gcc@gmail.com \
/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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).