All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karsten Blees <karsten.blees@gmail.com>
To: Thomas Rast <tr@thomasrast.ch>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)
Date: Mon, 09 Dec 2013 15:03:28 +0100	[thread overview]
Message-ID: <52A5CDB0.2020206@gmail.com> (raw)
In-Reply-To: <87lhzvhceb.fsf@linux-1gf2.Speedport_W723_V_Typ_A_1_00_098>

Am 08.12.2013 11:20, schrieb Thomas Rast:
> Karsten Blees <karsten.blees@gmail.com> writes:
> 
>> Am 07.12.2013 23:23, schrieb Thomas Rast:
>>> Karsten Blees <karsten.blees@gmail.com> writes:
>>>
>>>> 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 needs '__attribute__((__packed__))' to work. Reduces e.g.
>>>
>>> You'd have to guard __attribute__((__packed__)) with some compiler
>>> detection in git-compat-util.h though.
>>>
>>
>> Isn't that already handled? __attribute__ is already widely used
>> (e.g. for printf formats), and platforms that don't support it define
>> it as empty (e.g. MSVC). Or do you mean I should account for
>> compiler-specific variants (#pragma pack...)?
> 
> True, __attribute__ expands to nothing on unknown compilers, but what
> does the compiler do when it sees an unknown attribute?  If some of them
> choke, you need a separate macro.
> 
> I'm a bit confused myself though, many attributes have special macros in
> git-compat-util.h but others we just use in the code.
> 

So what do you propose? I basically see three options:

1.) Trial and error

GCC supports __packed__ as of 2.3 (1992), so any other compilers that copied the __attribute__ feature probably won't complain.

2.) Accept the wasted memory

Moving the hash code from the hash table (as in hash.[ch]) to the entry is already a big improvement, as it no longer multiplies hash code + wasted bytes with the load factor. 64-bit software uses more memory in general, so we could just live with it (and only fix the documentation in api-hashmap.txt).

3.) Inject individual fields via macro

Instead of injecting a struct hashmap_entry, which implies alignment to sizeof(struct hashmap_entry), we could inject the individual fields, e.g.

 #define HASHMAP_ENTRY_HEADER struct hashmap_entry __next; unsinged int __hash;

 struct name_entry {
   HASHMAP_ENTRY_HEADER
   int namelen;
   char *name;
 };


What do you think?

Karsten

  reply	other threads:[~2013-12-09 14:03 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 [this message]
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
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=52A5CDB0.2020206@gmail.com \
    --to=karsten.blees@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.