From: Karsten Blees <karsten.blees@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Thomas Rast <tr@thomasrast.ch>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)
Date: Wed, 18 Dec 2013 14:10:20 +0100 [thread overview]
Message-ID: <52B19EBC.50609@gmail.com> (raw)
In-Reply-To: <20131209234500.GY29959@google.com>
Am 10.12.2013 00:45, schrieb Jonathan Nieder:
> Karsten Blees wrote:
>
>> Googling some more, I believe the most protable way to achieve this
>> via 'compiler settings' is
>>
>> #pragma pack(push)
>> #pragma pack(4)
>> struct hashmap_entry {
>> struct hashmap_entry *next;
>> unsigned int hash;
>> };
>> #pragma pack(pop)
>>
>> This is supported by at least GCC, MSVC and HP (see your link). The
>> downside is that we cannot use macros (in git-compat-util.h) to emit
>> #pragmas. But we wouldn't have to, as compilers aren't supposed to
>> barf on unknown #pragmas.
>
> Technically this can be done using macros:
>
> #if (gcc)
> # define BEGIN_PACKED _Pragma("pack(push,4)")
> # define END_PACKED _Pragma("pack(pop)")
> #elif (msvc)
> # define BEGIN_PACKED __pragma(pack(push,4))
> # define END_PACKED __pragma(pack(pop))
> #else
> /* Just tolerate a little padding. */
> # define BEGIN_PACKED
> # define END_PACKED
> #end
>
> Then you can do:
>
> BEGIN_PACKED
> struct hashmap_entry {
> ...
> };
> END_PACKED
>
Sorry for the delay...
My intention with #pragma pack was to support as many compilers / platforms as possible (even though I can't test them all). From what I could find on the 'net, support for the _Pragma operator is slim. And as the MSVC build is 32-bit only (AFAIK), this is pretty much a GCC-only solution (and thus equivalent, but much more verbose than the initial __attribute__((__packed__)) variant).
> Whether that's nicer or uglier than the alternatives I leave to you.
> ;-)
If it was really up to me ( :-) ), I'd like to do this:
------ 8< -------
Subject: [PATCH] hashmap.h: make sure map entries are tightly packed
Extending 'struct hashmap_entry' with an int-sized member shouldn't waste
memory on 64-bit systems. This is already documented in api-hashmap.txt,
but struct hashmap_entry needs to be packed for this to work. E.g.
struct name_entry {
struct hashmap_entry ent; /* consists of pointer + int */
int namelen;
char *name;
};
should be 24 instead of 32 bytes.
Packing structures is compiler-specific, most compilers support [1]:
#pragma pack(n) - to set structure packing
#pragma pack() - to reset structure packing to default
Compilers are supposed to ignore unknown #pragmas, so using this without
further #if <compiler> guards should be safe.
Wasting a few bytes for padding is acceptable, however, compiling the rest
of git with packed structures (and thus mis-aligned arrays of structs) is
not. Add a test to ensure that '#pragma pack()' really resets the packing.
[1] Compiler docs regarding #pragma pack:
http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Structure_002dPacking-Pragmas.html#Structure_002dPacking-Pragmas
http://msdn.microsoft.com/en-us/library/2e70t5y1%28v=vs.80%29.aspx
http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/Online_Help/pragmas.htm#pragma-PACK
http://clang.llvm.org/docs/UsersManual.html#microsoft-extensions
http://uw714doc.sco.com/en/SDK_cprog/_Preprocessing_Directives.html
http://osr507doc.sco.com/en/tools/ANSI_F.3.13_Preprocessing.html
http://docs.oracle.com/cd/E19422-01/819-3690/Pragmas_App.html#73499
http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7a.doc%2Fcompiler%2Fref%2Frnpgpack.htm
Supposedly wants #pragma pack(0) to reset:
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/0650/bks/SGI_Developer/books/Pragmas/sgi_html/ch04.html
Not supported:
http://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-DD32852C-A0F9-4AC6-BF67-D10D064CC87A.htm
Signed-off-by: Karsten Blees <blees@dcon.de>
---
hashmap.h | 7 +++++++
t/t0011-hashmap.sh | 6 ++++++
test-hashmap.c | 17 +++++++++++++++++
3 files changed, 30 insertions(+)
diff --git a/hashmap.h b/hashmap.h
index a816ad4..93b330b 100644
--- a/hashmap.h
+++ b/hashmap.h
@@ -15,10 +15,17 @@ extern unsigned int memihash(const void *buf, size_t len);
/* data structures */
+/*
+ * Set struct packing to 4 so that we don't waste memory on 64-bit systems.
+ * Struct hashmap_entry is used as prefix to other (un-packed) structures,
+ * so this won't cause alignment issues e.g. for odd elements in an array.
+ */
+#pragma pack(4)
struct hashmap_entry {
struct hashmap_entry *next;
unsigned int hash;
};
+#pragma pack()
typedef int (*hashmap_cmp_fn)(const void *entry, const void *entry_or_key,
const void *keydata);
diff --git a/t/t0011-hashmap.sh b/t/t0011-hashmap.sh
index 391e2b6..3f3c90b 100755
--- a/t/t0011-hashmap.sh
+++ b/t/t0011-hashmap.sh
@@ -237,4 +237,10 @@ test_expect_success 'grow / shrink' '
'
+test_expect_success '"#pragma pack()" resets packing to default' '
+
+ test_hashmap "pragma-pack" "ok"
+
+'
+
test_done
diff --git a/test-hashmap.c b/test-hashmap.c
index f5183fb..2d5a63a 100644
--- a/test-hashmap.c
+++ b/test-hashmap.c
@@ -36,6 +36,12 @@ static struct test_entry *alloc_test_entry(int hash, char *key, int klen,
return entry;
}
+struct pointer_int
+{
+ void *ptr;
+ int i;
+};
+
#define HASH_METHOD_FNV 0
#define HASH_METHOD_I 1
#define HASH_METHOD_IDIV10 2
@@ -136,6 +142,7 @@ static void perf_hashmap(unsigned int method, unsigned int rounds)
* remove key -> NULL / old value
* iterate -> key1 value1\nkey2 value2\n...
* size -> tablesize numentries
+ * pragma-pack -> ok / failure
*
* perfhashmap method rounds -> test hashmap.[ch] performance
*/
@@ -239,6 +246,16 @@ int main(int argc, char *argv[])
/* print table sizes */
printf("%u %u\n", map.tablesize, map.size);
+ } else if (!strcmp("pragma-pack", cmd)) {
+
+ if ((sizeof(struct pointer_int) % sizeof(void *)) == 0)
+ printf("ok\n");
+ else
+ printf("sizeof(pointer+int) (%u) is not a "
+ "multiple of sizeof(pointer) (%u)!\n",
+ sizeof(struct pointer_int),
+ sizeof(void *));
+
} else if (!strcmp("perfhashmap", cmd) && l1 && l2) {
perf_hashmap(atoi(p1), atoi(p2));
--
1.8.5.1.276.g562b27a
next prev parent reply other threads:[~2013-12-18 13:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 23:52 What's cooking in git.git (Dec 2013, #02; Fri, 6) Junio C Hamano
2013-12-07 10:03 ` Felipe Contreras
2013-12-07 20:30 ` Felipe Contreras
2013-12-09 21:00 ` Junio C Hamano
2013-12-07 17:03 ` Thomas Rast
2013-12-09 22:33 ` Jeff King
2013-12-09 22:51 ` Junio C Hamano
2013-12-07 18:49 ` Matthieu Moy
2013-12-07 19:56 ` Karsten Blees
2013-12-07 22:23 ` Thomas Rast
2013-12-07 22:32 ` Karsten Blees
2013-12-08 10:20 ` Thomas Rast
2013-12-09 14:03 ` Karsten Blees
2013-12-09 20:08 ` Jonathan Nieder
2013-12-09 23:19 ` Karsten Blees
2013-12-09 23:45 ` Jonathan Nieder
2013-12-18 13:10 ` Karsten Blees [this message]
2013-12-18 14:05 ` Karsten Blees
2013-12-18 14:12 ` Karsten Blees
2013-12-09 17:43 ` Junio C Hamano
2013-12-09 17:48 ` Junio C Hamano
2013-12-18 13:41 ` [PATCH] hashmap.h: Use 'unsigned int' for hash-codes everywhere Karsten Blees
2013-12-18 17:46 ` Junio C Hamano
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=52B19EBC.50609@gmail.com \
--to=karsten.blees@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=tr@thomasrast.ch \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.