From: Emily Shaffer <nasamuffin@google.com>
To: Git List <git@vger.kernel.org>
Subject: Re: Video conference libification eng discussion, this Thursday 16:30 UTC
Date: Thu, 13 Apr 2023 10:00:07 -0700 [thread overview]
Message-ID: <CAJoAoZ=A7hPbFHw_7btD0+dFzpQOXSpVa7ss2O0zbG2S_d3rKQ@mail.gmail.com> (raw)
In-Reply-To: <CAJoAoZnBPH6j93eRRuVKZkDix9h7S287eTMfF9dK0CvC+meMxQ@mail.gmail.com>
The notes from today's session follow.
- (asynchronous) What's cooking in libification?
- Patches we sent regarding libification
- Coccinelle conventions
https://lore.kernel.org/git/pull.1495.git.git.1681329955.gitgitgadget@gmail.com
- Patches for review related to the libification effort
- cache.h cleanups
https://lore.kernel.org/git/pull.1509.v2.git.1680571348.gitgitgadget@gmail.com
- (asynchronous) What happened in the past 1-2 weeks that interested
parties or intermittent contributors need to know?
- (asynchronous) Where are you stuck? What eng discussions do we want
to have? (We'll choose a topic from this list at the beginning of the
meeting.)
- Session topic: <TBD>
* Elijah: I have the next set of cache.h cleanups waiting around,
but I'm waiting for the first set to make it in, and wondering whether
I should rebase onto Calvin
* Calvin: you should send yours without waiting, I don't think
there will be a conflict
* Elijah: ok, will try to avoid strbuf and git-compat-util changes
* Glen: Hey take a look at
https://lore.kernel.org/git/pull.1495.git.git.1681329955.gitgitgadget@gmail.com
* Elijah: I also wasn't sure how to review these, the how-to
sounds useful but I don't know any better either?
* Glen: If this series doesn't seem to make your life easier,
then it hasn't achieved its purpose
* Should this come with MyFirstSemanticPatch..?
* General approval 🙂
* Maybe it can come later
* Calvin: We've been working on the idea of a "git-std-lib" internally
* Libification of "just strbuf" and "just hashmap" vs.
libification of "all the shared low-level stuff that depends on each
other"
* Removing the dependency on wrapper.h/usage.h is really tricky
* So instead, a standard library which is includable from git
library callers and also used throughout Git's own codebase
* Stuff like strbuf, string\_list, abspath, strmap, strvec,
wrapper, usage, utf8, etc etc etc all in a single library
* To get the proof of concept, made some cleanups to
git-compat-util, removed dependencies on repository.h, trace2.h, etc
were refactored or replaced with a stub in the unit test makefile
* Have something promising internally
* Does this seem like a good idea..? Hoping to send RFC after
OOO next week sometime
* Elijah: Expecting lots of people to ask what's the purpose of
the standard library, does it imply backwards compatibility, etc etc
* No backwards compatibility, if consumers want to accept
that churn then they can use it with no promises
* Emily: In fact, it's likely to start out pretty rough,
with still prints and dies and so on, so we will intend to change it a
lot afterwards
* Calvin: You might ask, why not do that first? Mostly, to
unblock others as quickly as possible 🙂 If we can make it possible to
build something on top of it and prove it's usable, then that gives us
more momentum to keep polishing it
* Randall: Do we want to mark these apis as experimental?
* Emily: Yes, this and all the apis we're working on for
the foreseeable future
* Elijah: static? Dynamic?
* Calvin: static for now. I don't have a lot of
experience with Makefile
* Where are these makefile changes going?
* Emily: Early stages, we want to make a guarantee about
the ability to compile and unit test, that's likely to go into
t/Makefile
* Glen: Maybe later it makes sense to move things into
lib/ and stand up a lib/Makefile, but we can cross that bridge when we
come to it
* Randall: atexit() is used in Git, be careful with deps
on atexit() in a dynamic library please! It's not very platform
consistent
* Emily: Randall, can you take one of these sessions and
tell us all the stories about atexit() 🙂
* Elijah: hash.h depending on repository.h, stringmap
depending on hash.h, this is gross. But FYI I did work on something to
remove repository.h from hash.h
* Calvin: we ran into that problem, yeah. Very cool to
hear you have some fix, can we see it 🙂
* Elijah: mempool?
* Calvin: not worried about mempool
* Elijah: Was doing some performance testing moving functions into a
new file and determining if it was helpful or not (to see if I can
replace rust stuff)
* Turns out there's a small performance degradation moving
something into a new file like this?
* We might be able to use this to increase performance in some places too
* Calvin: do we know why?
* Elijah: maybe code locality..? It's a function that's being
passed to qsort, so it was being run in a very tight loop, it seems
like that difference in cache locality made a difference
* Jonathan: I've seen this kind of thing as an argument to be
pro-C++ because templates mean you can choose this functionality at
compile time and avoid this penalty.
* Elijah: I spent a lot of time on microoptimizations for the
merge code, it was difficult to parallelize it as it is (in C/++). Why
not 🦀? Was an interesting experiment to look into performance
regressions. Putting the sort into rust actually gave some speedup.
Being able to optimize that sort was really helpful.
* Randall: Other compilers, like Intel C99, the optimizer can do
some things with comparators in the same object as the qsort
invocation to avoid that penalty.
* Randall: Happy to talk about C multithreading too, look over code, etc
* Randall: Have been pressed into service as CVE analysis manager.
Thinking about the libification project and tests as a very good thing
for tracking down CVEs in the base code (if they lurk there). Being
able to test libraries on their own is really helpful from there,
thanks!
On Tue, Apr 11, 2023 at 11:40 AM Emily Shaffer <nasamuffin@google.com> wrote:
>
> Hello folks,
>
> Google is hosting a standing engineering discussion about libifying
> Git, for contributors interested in participating in or hearing about
> the progress of this effort. Expect this discussion to be free-form
> and casual - no powerpoints here!
>
> We're hoping to hold this meeting every Thursday at 9:30am Pacific
> (16:30 UTC) via Google Meet.
>
> To get an invite to the video conference and the notes document,
> please reply to this email. Please also add points to the agenda
> (template follows) if you want to raise awareness of them.
>
> We'll choose a topic to discuss at the beginning of the meeting, and
> I'll reply afterwards with the notes.
>
> - (asynchronous) What's cooking in libification?
> - Patches we sent regarding libification
> - Patches for review related to the libification effort
> - (asynchronous) What happened in the past 1-2 weeks that interested
> parties or intermittent contributors need to know?
> - (asynchronous) Where are you stuck? What eng discussions do we want
> to have? (We'll choose a topic from this list a day ahead of the
> meeting.)
> - Session topic: <TBD>
next prev parent reply other threads:[~2023-04-13 17:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 18:40 Video conference libification eng discussion, this Thursday 16:30 UTC Emily Shaffer
2023-04-13 17:00 ` Emily Shaffer [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-05-30 21:26 Emily Shaffer
2023-05-09 21:08 Emily Shaffer
2023-04-25 21:22 Emily Shaffer
2023-04-04 17:14 Emily Shaffer
2023-04-11 18:39 ` Emily Shaffer
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='CAJoAoZ=A7hPbFHw_7btD0+dFzpQOXSpVa7ss2O0zbG2S_d3rKQ@mail.gmail.com' \
--to=nasamuffin@google.com \
--cc=git@vger.kernel.org \
/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).