From: Andi Kleen <ak@linux.intel.com>
To: Michal Jires <mjires@suse.cz>
Cc: gcc-patches@gcc.gnu.org, hubicka@ucw.cz
Subject: Re: [PATCH 4/7 v2] lto: Implement ltrans cache
Date: Thu, 20 Jun 2024 10:45:38 -0700 [thread overview]
Message-ID: <8734p7wlrx.fsf@linux.intel.com> (raw)
In-Reply-To: <wjmjyztoxlfj4boe3anvum7fg23ksjoozgtgthdusoujqisqtp@pken7ze2yb5x> (Michal Jires's message of "Thu, 20 Jun 2024 13:31:22 +0200")
Michal Jires <mjires@suse.cz> writes:
No performance data?
> +
> +static const md5_checksum_t INVALID_CHECKSUM = {
> + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> +};
There are much faster/optimized modern hashes for good collision detection over
MD5 especially when it's not needed to be cryptographically secure. Pick
something from smhasher.
Also perhaps the check sum should be cached in the file? I assume it's
cheap to compute while writing. It could be written at the tail of the
file. Then it can be read by seeking to the end and you save that
step.
The lockfiles scare me a bit. What happens when they get lost, e.g.
due to a compiler crash? You may need some recovery for that.
Perhaps it would be better to make the files self checking, so that
partial files can be detected when reading, and get rid of the locks.
-Andi
next prev parent reply other threads:[~2024-06-20 17:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-17 20:16 [PATCH 0/7] lto: Incremental LTO Michal Jires
2023-11-17 20:16 ` [PATCH 1/7] lto: Skip flag OPT_fltrans_output_list_ Michal Jires
2023-12-29 21:16 ` Jan Hubicka
2023-11-17 20:16 ` [PATCH 2/7] lto: Remove random_seed from section name Michal Jires
2023-12-29 21:17 ` Jan Hubicka
2024-01-09 16:49 ` [PATCH 2/7 v2] " Michal Jires
[not found] ` <c480760c-f167-4e60-a27e-52bebdd1351b@suse.cz>
2024-05-14 11:28 ` Fwd: " Jan Hubicka
2023-11-17 20:17 ` [PATCH 3/7] Lockfile Michal Jires
2023-12-29 21:23 ` Jan Hubicka
2024-01-09 17:10 ` Michal Jires
2024-06-20 11:24 ` [PATCH 3/7 v2] Lockfile Michal Jires
2024-06-20 12:36 ` Richard Biener
2023-11-17 20:17 ` [PATCH 4/7] lto: Implement ltrans cache Michal Jires
2024-05-14 11:51 ` Jan Hubicka
2024-06-20 11:31 ` [PATCH 4/7 v2] " Michal Jires
2024-06-20 17:45 ` Andi Kleen [this message]
2024-06-21 11:12 ` Jan Hubicka
2024-06-21 19:07 ` Andi Kleen
2024-06-21 19:16 ` Sam James
2024-06-21 16:59 ` Michal Jireš
2024-06-21 19:09 ` Andi Kleen
2023-11-17 20:17 ` [PATCH 5/7] lto: Implement cache partitioning Michal Jires
2024-05-14 12:10 ` Jan Hubicka
2023-11-17 20:17 ` [PATCH 6/7] lto: squash order of symbols in partitions Michal Jires
2024-05-14 12:20 ` Jan Hubicka
2023-11-17 20:17 ` [PATCH 7/7] lto: partition specific lto_clone_numbers Michal Jires
2024-05-14 12:11 ` Jan Hubicka
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=8734p7wlrx.fsf@linux.intel.com \
--to=ak@linux.intel.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=mjires@suse.cz \
/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).