Tarantool development patches archive
 help / color / mirror / Atom feed
From: Serge Petrenko via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>,
Subject: Re: [Tarantool-patches] [PATCH] relay: yield explicitly every N sent rows
Date: Wed, 24 Feb 2021 13:35:49 +0300	[thread overview]
Message-ID: <bcc52d6d-d873-7efa-0878-93ca4d2ab67e@tarantool.org> (raw)
In-Reply-To: <YDYnJsGWQhsPGUh6@grain>

24.02.2021 13:15, Cyrill Gorcunov пишет:
> On Wed, Feb 24, 2021 at 12:48:07PM +0300, Serge Petrenko wrote:
> ...
>>>>> 1. But it is not a size of anything, right? Maybe make it
>>>>> int64_t then?
>>>> uint64_t, probably?
>>> Nope, int64_t. It is supposed to be 'faster'. Because it does
>>> not have defined overflow rules, and therefore the hardware does
>>> not need to handle it.
>>> But honestly, I didn't measure. For me it is more cargo cult. I
>>> just use signed integers where I can assuming that the hardware
>>> really may omit an instruction or so.
>>> Up to you.
>> Long story short, I'd like to leave it as is. Besides, we have an unsigned
>> type (size_t) in local recovery.
>> Ok, now I see what you meant.
>> I never thought of this, and brief googling showed no signs of a speedup
>> with signed arithmetic vs unsigned.
>> Actually, the standard says signed overflow is an undefined behaviour while
>> an unsigned overflow should result in a wrap (modulo 2^64 in our case).
>> Do you think this wrap may be costly on some architecture?
> Addition on hardware level _always_ setup OF/CF flags so in this term it
> doesn't matter which to use int64 or uint64 (iow hw treats addition as
> signed integers all the time and it is up you how you gonna use this
> flags in later code).
> What is more interesting is that older compilers (at least gcc) generate
> more efficient code for *signed* integers, ie int64_t. I've been pretty
> surprised when discovered this. I dont get you a reference because I
> don't remember the exact versions though. In summary: rule of thumb
> is to use signed integers if you really need some addition in a cycle.
> For more rare access unsigned is more that enough and latest gcc already
> can handle it the same way as signed numbers.

Thanks for your answer!
What do you propose? Should I hange it to int64_t then?

Serge Petrenko

  reply	other threads:[~2021-02-24 10:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-12 11:25 Serge Petrenko via Tarantool-patches
2021-02-12 11:37 ` Cyrill Gorcunov via Tarantool-patches
2021-02-12 11:46   ` Cyrill Gorcunov via Tarantool-patches
2021-02-12 12:08   ` Serge Petrenko via Tarantool-patches
2021-02-12 17:00     ` Cyrill Gorcunov via Tarantool-patches
2021-02-12 21:48 ` Vladislav Shpilevoy via Tarantool-patches
2021-02-12 22:25   ` Cyrill Gorcunov via Tarantool-patches
2021-02-15  8:45     ` Serge Petrenko via Tarantool-patches
2021-02-15  8:40   ` Serge Petrenko via Tarantool-patches
2021-02-17 21:11     ` Vladislav Shpilevoy via Tarantool-patches
2021-02-18 20:24       ` Serge Petrenko via Tarantool-patches
2021-02-23 22:30         ` Vladislav Shpilevoy via Tarantool-patches
2021-02-24  9:48           ` Serge Petrenko via Tarantool-patches
2021-02-24 10:15             ` Cyrill Gorcunov via Tarantool-patches
2021-02-24 10:35               ` Serge Petrenko via Tarantool-patches [this message]
2021-02-24 12:07                 ` Cyrill Gorcunov via Tarantool-patches
2021-02-24 12:14                   ` Serge Petrenko via Tarantool-patches
2021-02-24 22:20 ` Vladislav Shpilevoy via Tarantool-patches
2021-02-26  8:41 ` Kirill Yukhin via Tarantool-patches
2021-02-26 20:24   ` Vladislav Shpilevoy via Tarantool-patches
2021-03-01 11:25     ` Serge Petrenko via Tarantool-patches
2021-03-01 21:24       ` Vladislav Shpilevoy via Tarantool-patches
2021-03-02  9:52       ` Kirill Yukhin via Tarantool-patches

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bcc52d6d-d873-7efa-0878-93ca4d2ab67e@tarantool.org \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=gorcunov@gmail.com \
    --cc=sergepetrenko@tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH] relay: yield explicitly every N sent rows' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox