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

[Cyrill Gorcunov via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

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.