From: Alejandro Colomar <colomar.6.4.3@gmail.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: mtk.manpages@gmail.com, linux-man@vger.kernel.org,
GNU C Library <libc-alpha@sourceware.org>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: [PATCH 05/16] system_data_types.7: Add int_fastN_t family of types
Date: Thu, 1 Oct 2020 13:15:10 +0200 [thread overview]
Message-ID: <8dc9e60d-f838-87d5-2fc6-c34a84118916@gmail.com> (raw)
In-Reply-To: <CAH6eHdQPvsfHcsWXNKXZsZcvWkmH6JOvcAivVFjq+HJEctG62w@mail.gmail.com>
On 2020-10-01 13:07, Jonathan Wakely wrote:
[...]
>> +Notes:
>> +Some of these types may be optimized for size
>> +instead of raw performance.
>
> I'm not sure what this tells me as a programmer. What does "raw
> performance" means exactly? The text above says it's "the fastest",
> but then it says "may be optimized for size". I don't know how to
> interpret this. Is it fast or is it small, or something else? Is it
> optimized for small size? Natural word size? Cacheline size?
>
> I prefer the phrasing of the caveats in the C and POSIX standards
> which just say it might not be fastest for all purposes.
>
> How about "Where there is no single type that is fastest for all
> purposes, the implementation may choose any type with the required
> signedness and at least the minimum width."
>
> I don't see anything in this man page saying that the <stdint.h> types
> are all typedefs, rather than new types that are distinct from the
> standard integer types. That seems like useful information.
>
Hi Jonathan,
I wasn't sure about how to word it.
In theory, they should be the fastest types; just that.
But then, for some reason, GCC decided that
int_fast8_t should be int8_t instead of int64_t,
because when using arrays of int_fast8_t,
it will create smaller arrays, which will be faster (less cache, etc.).
(I remember having read that a long time ago, but I don't remember the
source, or if it's the actual reason).
How would you word that?
Thanks,
Alex
next prev parent reply other threads:[~2020-10-01 11:15 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-01 10:15 [PATCH 00/16] Fixes; Document remaining stdint.h types Alejandro Colomar
2020-10-01 10:15 ` [PATCH 01/16] malloc_get_state.3: ffix Alejandro Colomar
2020-10-01 11:32 ` Michael Kerrisk (man-pages)
2020-10-01 10:15 ` [PATCH 02/16] system_data_types.7: srcfix Alejandro Colomar
2020-10-01 11:33 ` Michael Kerrisk (man-pages)
2020-10-01 10:15 ` [PATCH 03/16] " Alejandro Colomar
2020-10-01 11:33 ` Michael Kerrisk (man-pages)
2020-10-01 10:15 ` [PATCH 04/16] " Alejandro Colomar
2020-10-01 11:34 ` Michael Kerrisk (man-pages)
2020-10-01 10:15 ` [PATCH 05/16] system_data_types.7: Add int_fastN_t family of types Alejandro Colomar
2020-10-01 11:07 ` Jonathan Wakely
2020-10-01 11:15 ` Alejandro Colomar [this message]
2020-10-01 11:27 ` Jonathan Wakely
2020-10-01 14:16 ` Alejandro Colomar
2020-10-01 15:13 ` Alejandro Colomar
2020-10-01 10:15 ` [PATCH 06/16] int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3, int_fastN_t.3: New links to system_data_types(7) Alejandro Colomar
2020-10-01 10:15 ` [PATCH 07/16] system_data_types.7: Add uint_fastN_t family of types Alejandro Colomar
2020-10-01 10:15 ` [PATCH 08/16] uint_fast8_t.3, uint_fast16_t.3, uint_fast32_t.3, uint_fast64_t.3, uint_fastN_t.3: New links to system_data_types(7) Alejandro Colomar
2020-10-01 10:15 ` [PATCH 09/16] system_data_types.7: Add int_leastN_t family of types Alejandro Colomar
2020-10-01 10:15 ` [PATCH 10/16] int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least64_t.3, int_leastN_t.3: New links to system_data_types(7) Alejandro Colomar
2020-10-01 10:15 ` [PATCH 11/16] system_data_types.7: Add uint_leastN_t family of types Alejandro Colomar
2020-10-01 10:15 ` [PATCH 12/16] uint_least8_t.3, uint_least16_t.3, uint_least32_t.3, uint_least64_t.3, uint_leastN_t.3: New links to system_data_types(7) Alejandro Colomar
2020-10-01 10:15 ` [PATCH 13/16] system_data_types.7: Add 'intptr_t' Alejandro Colomar
2020-10-01 11:35 ` Michael Kerrisk (man-pages)
2020-10-01 10:15 ` [PATCH 14/16] intptr_t.3: New link to system_data_types(7) Alejandro Colomar
2020-10-01 11:35 ` Michael Kerrisk (man-pages)
2020-10-01 10:15 ` [PATCH 15/16] system_data_types.7: Add 'uintptr_t' Alejandro Colomar
2020-10-01 11:35 ` Michael Kerrisk (man-pages)
2020-10-01 10:16 ` [PATCH 16/16] uintptr_t.3: New link to system_data_types(7) Alejandro Colomar
2020-10-01 11:35 ` Michael Kerrisk (man-pages)
2020-10-01 11:32 ` [PATCH 00/16] Fixes; Document remaining stdint.h types Michael Kerrisk (man-pages)
2020-10-01 11:41 ` Alejandro Colomar
2020-10-01 11:50 ` Michael Kerrisk (man-pages)
2020-10-01 11:51 ` Alejandro Colomar
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=8dc9e60d-f838-87d5-2fc6-c34a84118916@gmail.com \
--to=colomar.6.4.3@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=jwakely.gcc@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
/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).