[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gperf] unsigned long vs. unsigned int
|
From: |
Sei Lisa |
|
Subject: |
Re: [bug-gperf] unsigned long vs. unsigned int |
|
Date: |
Thu, 5 Sep 2019 02:26:11 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 |
Bruno Haible wrote on 2019-09-05 01:58:
With 64 bit machines, "unsigned long" is probably more efficient to pass
around than "unsigned int". An option --return_type = "unsigned int"
with --return_type = "unsigned long" could be helpful.
'unsigned long' is generally faster to access and move around on 64-bit
machines than 'unsigned int'.
Is compatibility with C standards < C99 an issue?
C99 introduces uint_fast32_t via stdint.h, which would be perfect for the task.
It's not an optional type like uint32_t and others, it's mandatory.
Anyway, instead of a gperf option, it could be an overridable C macro in the
output, like flex/bison do with YYLTYPE and similar.
- [bug-gperf] One usability and 4 fine tuning performance suggestions (cache lines and array size), Mark Stankus, 2019/09/04
- Re: [bug-gperf] gperf as a library, Bruno Haible, 2019/09/04
- Re: [bug-gperf] unsigned long vs. unsigned int, Bruno Haible, 2019/09/04
- Re: [bug-gperf] unsigned long vs. unsigned int,
Sei Lisa <=
- Re: [bug-gperf] large lengths, Bruno Haible, 2019/09/04
- Re: [bug-gperf] shrinking the asso_values array, Bruno Haible, 2019/09/04
- Re: [bug-gperf] bit packing tricks, Bruno Haible, 2019/09/04