Re: [Tarantool-patches] [PATCH] relay: yield explicitly every N sent rows

[Serge Petrenko via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

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