From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 039FC70202; Wed, 24 Feb 2021 13:15:08 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 039FC70202 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1614161708; bh=EoScHgH10lzhunG8/BLwDEbX2gvCiC7kXHVT+D+s3sM=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=WYktJ0Y0ctYUeu7Qood1j6MXnFH7OE6ClWIJfDkm9F+LiLmTxkrUaU/fVgQHliTzx 4jBC2cQ51BMkpn7hZqD4p4x5NRP8I7hQitklVbEPBlP0DkstOKPI2QU4bTM8MiOuRF R+ytrHxlFpnSgjPY2GNBKOZRCBWGT8YqqgPu/Bt0= Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id C723570202 for ; Wed, 24 Feb 2021 13:15:05 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C723570202 Received: by mail-lf1-f50.google.com with SMTP id h125so2195648lfd.7 for ; Wed, 24 Feb 2021 02:15:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KDfIm0wRSmSwm6hk4fAzlIzQ2SPfGU38bSh3Fe2uCBI=; b=uoIjGJpkuDnAnf7yEsIDtTpbJRi8ZMnqUeA2H4O2geEkoQDsblqac5mRnonJ7yW94p 6Pknanj4p92dVI5nhaIGj5c3nONq/h8jxHdSp+qzKBYbufH6kLvjEabOdC3GVYQAwnA9 thd6xdniMDm5Utk0UkV9fPK8D6tAZ5UmggykwD9WqQY+nJoovu55e+WhDOKL0MNXB/cH Ge46KVdOYgK0adv28nLHh8vYnqV+CUVmRTSOjY3JouBIlFQk17kOb2nY4pNJEyvTIqdH e+UCrq+MVnZ4oxGIT2YLHySW8Q4z2Zraqxe13KIs5LMd7RYVvIHuJTXQqcFjbtGClGqA cgaQ== X-Gm-Message-State: AOAM533Iuon+7qROd2cQ71R+bjQjNS0BUydbktkd083BXeZ7gedw4h7X JqlnxCk51bLKA6F366IaOED6YUdNf17ciw== X-Google-Smtp-Source: ABdhPJxPzI56/dstKrf95Q/WKm5vDHsICvpXkVGXvSvYCL6TbxI70K3pr4gATb5q6dm4/4rrA6ofZg== X-Received: by 2002:ac2:5ed9:: with SMTP id d25mr11250752lfq.514.1614161704654; Wed, 24 Feb 2021 02:15:04 -0800 (PST) Received: from grain.localdomain ([5.18.171.94]) by smtp.gmail.com with ESMTPSA id a30sm397028lfo.56.2021.02.24.02.15.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Feb 2021 02:15:03 -0800 (PST) Received: by grain.localdomain (Postfix, from userid 1000) id C72B7560158; Wed, 24 Feb 2021 13:15:02 +0300 (MSK) Date: Wed, 24 Feb 2021 13:15:02 +0300 To: Serge Petrenko Cc: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org Message-ID: References: <20210212112541.27561-1-sergepetrenko@tarantool.org> <57b04874-1bb7-3d62-856d-b60df700514a@tarantool.org> <774363df-6be5-a7b4-ea7f-d72903f3c409@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.5 (2021-01-21) Subject: Re: [Tarantool-patches] [PATCH] relay: yield explicitly every N sent rows X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" 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.