Tarantool development patches archive
 help / color / mirror / Atom feed
From: Cyrill Gorcunov via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Serge Petrenko <sergepetrenko@tarantool.org>
Cc: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>,
	tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH] relay: yield explicitly every N sent rows
Date: Wed, 24 Feb 2021 13:15:02 +0300	[thread overview]
Message-ID: <YDYnJsGWQhsPGUh6@grain> (raw)
In-Reply-To: <fd98be2e-6bf6-d937-4b4f-2c8c57ccf57d@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.

  reply	other threads:[~2021-02-24 10:15 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 [this message]
2021-02-24 10:35               ` Serge Petrenko via Tarantool-patches
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:
  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=YDYnJsGWQhsPGUh6@grain \
    --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' \
    /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

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