From: Ramsay Jones <ramsay@ramsay1•demon.co.uk>
To: Jeff King <peff@peff•net>, git@vger•kernel.org
Cc: "Vicent Martí" <vicent@github•com>
Subject: Re: [PATCH v3 0/21] pack bitmaps
Date: Thu, 14 Nov 2013 19:19:38 +0000 [thread overview]
Message-ID: <5285224A.2070606@ramsay1.demon.co.uk> (raw)
In-Reply-To: <20131114124157.GA23784@sigill.intra.peff.net>
On 14/11/13 12:41, Jeff King wrote:
> Here's another iteration of the pack bitmaps series. Compared to v2, it
> changes:
>
> - misc style/typo fixes
>
> - portability fixes from Ramsay and Torsten
Unfortunately, I didn't find time this weekend to finish the msvc build
fixes. However, after a quick squint at these patches, I think you have
almost done it for me! :-D
I must have misunderstood the previous discussion, because my patch was
written on the assumption that the ewah directory wouldn't be "git-ified"
(e.g. #include git-compat-util.h).
So, most of my patch is no longer necessary, given the use of the git
compat header (and removal of system headers). I suspect that you only
need to add an '#define PRIx64 "I64x"' definition (Hmm, probably to the
compat/mingw.h header).
I won't know for sure until I actually try them out, of course. I will
wait until these patches land in pu.
[Note: the msvc build is still broken, but the failure is not caused by
these patches. Unfortunately, the tests in t5310-*.sh fail. However, if
I include some debug code, the tests pass ... :-P ]
The part of the patch I was still working on was ...
>
> - count-objects garbage-reporting patch from Duy
>
> - disable bitmaps when is_repository_shallow(); this also covers the
> case where the client is shallow, since we feed pack-objects a
> --shallow-file in that case. This used to done by checking
> !internal_rev_list, but that doesn't apply after cdab485.
>
> - ewah sources now properly use git-compat-util.h and do not include
> system headers
>
> - the ewah code uses ewah_malloc, ewah_realloc, and so forth to let the
> project use a particular allocator (and we want to use xmalloc and
> friends). And we defined those in pack-bitmap.h, but of course that
> had no effect on the ewah/*.c files that did not include
> pack-bitmap.h. Since we are hacking up and git-ifying libewok
> anyway, we can just set the hardcoded fallback to xmalloc instead of
> malloc.
>
> - the ewah code used gcc's __builtin_ctzll, but did not provide a
> suitable fallback. We now provide a fallback in C.
... here.
I was messing around with several implementations (including the use of
msvc compiler intrinsics) with the intention of doing some timing tests
etc. [I suspected my C fallback function (a different implementation to
yours) would be slightly faster.]
ATB,
Ramsay Jones
next prev parent reply other threads:[~2013-11-14 19:19 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 12:41 [PATCH v3 0/21] pack bitmaps Jeff King
2013-11-14 12:42 ` [PATCH v3 01/21] sha1write: make buffer const-correct Jeff King
2013-11-14 12:42 ` [PATCH v3 02/21] revindex: Export new APIs Jeff King
2013-11-14 12:42 ` [PATCH v3 03/21] pack-objects: Refactor the packing list Jeff King
2013-11-14 12:43 ` [PATCH v3 04/21] pack-objects: factor out name_hash Jeff King
2013-11-14 12:43 ` [PATCH v3 05/21] revision: allow setting custom limiter function Jeff King
2013-11-14 12:43 ` [PATCH v3 06/21] sha1_file: export `git_open_noatime` Jeff King
2013-11-14 12:43 ` [PATCH v3 07/21] compat: add endianness helpers Jeff King
2013-11-14 12:43 ` [PATCH v3 08/21] ewah: compressed bitmap implementation Jeff King
2013-11-14 12:44 ` [PATCH v3 09/21] documentation: add documentation for the bitmap format Jeff King
2013-11-14 12:44 ` [PATCH v3 10/21] pack-bitmap: add support for bitmap indexes Jeff King
2013-11-24 21:36 ` Thomas Rast
2013-11-25 15:04 ` [PATCH] Document khash Thomas Rast
2013-11-28 10:35 ` Jeff King
2013-11-27 9:08 ` [PATCH v3 10/21] pack-bitmap: add support for bitmap indexes Karsten Blees
2013-11-28 10:38 ` Jeff King
2013-12-03 14:40 ` Karsten Blees
2013-12-03 18:21 ` Jeff King
2013-12-07 20:52 ` Karsten Blees
2013-11-29 21:21 ` Thomas Rast
2013-12-02 16:12 ` Jeff King
2013-12-02 20:36 ` Junio C Hamano
2013-12-02 20:47 ` Jeff King
2013-12-02 21:43 ` Junio C Hamano
2013-11-14 12:45 ` [PATCH v3 11/21] pack-objects: use bitmaps when packing objects Jeff King
2013-12-07 15:47 ` Thomas Rast
2013-12-21 13:15 ` Jeff King
2013-11-14 12:45 ` [PATCH v3 12/21] rev-list: add bitmap mode to speed up object lists Jeff King
2013-12-07 16:05 ` Thomas Rast
2013-11-14 12:45 ` [PATCH v3 13/21] pack-objects: implement bitmap writing Jeff King
2013-12-07 16:32 ` Thomas Rast
2013-12-21 13:17 ` Jeff King
2013-11-14 12:45 ` [PATCH v3 14/21] repack: stop using magic number for ARRAY_SIZE(exts) Jeff King
2013-12-07 16:34 ` Thomas Rast
2013-11-14 12:46 ` [PATCH v3 15/21] repack: turn exts array into array-of-struct Jeff King
2013-12-07 16:34 ` Thomas Rast
2013-11-14 12:46 ` [PATCH v3 16/21] repack: handle optional files created by pack-objects Jeff King
2013-12-07 16:35 ` Thomas Rast
2013-11-14 12:46 ` [PATCH v3 17/21] repack: consider bitmaps when performing repacks Jeff King
2013-12-07 16:37 ` Thomas Rast
2013-11-14 12:46 ` [PATCH v3 18/21] count-objects: recognize .bitmap in garbage-checking Jeff King
2013-12-07 16:38 ` Thomas Rast
2013-11-14 12:46 ` [PATCH v3 19/21] t: add basic bitmap functionality tests Jeff King
2013-12-07 16:43 ` Thomas Rast
2013-12-21 13:22 ` Jeff King
2013-11-14 12:48 ` [PATCH v3 20/21] t/perf: add tests for pack bitmaps Jeff King
2013-12-07 16:51 ` Thomas Rast
2013-12-21 13:40 ` Jeff King
2013-11-14 12:48 ` [PATCH v3 21/21] pack-bitmap: implement optional name_hash cache Jeff King
2013-12-07 16:59 ` Thomas Rast
2013-11-14 19:19 ` Ramsay Jones [this message]
2013-11-14 21:33 ` [PATCH v3 0/21] pack bitmaps Jeff King
2013-11-14 23:09 ` Ramsay Jones
2013-11-18 21:16 ` Ramsay Jones
2013-11-16 10:28 ` Thomas Rast
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=5285224A.2070606@ramsay1.demon.co.uk \
--to=ramsay@ramsay1$(echo .)demon.co.uk \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
--cc=vicent@github$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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