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 960A66EC40; Thu, 12 Aug 2021 23:47:55 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 960A66EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1628801275; bh=F3rdHSQp15HmxyMeK37cH4cCVufnZ7qCpJDkTY8sVqY=; h=To:References:Date:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=hLCCiU2gHX4vj7qb/F6NwxrYIF5HYeMTAyv7DStk84c8WZkKLxsyS//wpp8pzhAED DE7S9tX6hnRmbZQZHnTyojFwo/+AoH8JeQ/GyOGtnW65a6brb3/nDFQtjqtlEcXHNh Q6tp7ZCL9cVqr81BmlbnyFrhR1k6WF5Am1Nh6KVY= Received: from smtp49.i.mail.ru (smtp49.i.mail.ru [94.100.177.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id A76766EC40 for ; Thu, 12 Aug 2021 23:47:54 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org A76766EC40 Received: by smtp49.i.mail.ru with esmtpa (envelope-from ) id 1mEHcH-0003rK-8S; Thu, 12 Aug 2021 23:47:53 +0300 To: Igor Munkin , Vladislav Shpilevoy References: <449cb4c7-c738-ed07-8517-61b663ad9f79@tarantool.org> <0931c9db-bd8e-0687-2c96-73fac1aeff7e@tarantool.org> <18971894-830a-6bbd-a87b-83cd6abe5f34@tarantool.org> <3349aff9-a95c-cab5-4610-ca1089c1e762@tarantool.org> <8e779f32-f4e0-f3ac-45c3-c976f32bfd75@tarantool.org> <20210810122147.GK27855@tarantool.org> Message-ID: Date: Thu, 12 Aug 2021 23:47:46 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210810122147.GK27855@tarantool.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD92087353F0EC44DD9F9A2272A1D086A28553D1D5C4B4124EF182A05F5380850407DBEE205D3E83B7B32517A87596CDF5EB907CB71F2F1EC212E33A3C56B8694FE X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7195F30236A8D43B4EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637352A1F9739ED04D38638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D829213E1EAEC9A1A3CD736086817C7136117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC2EE5AD8F952D28FBA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18CB629EEF1311BF91D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE0AC5B80A05675ACDE21AE983DBD7FFC1D8FC6C240DEA7642DBF02ECDB25306B2B78CF848AE20165D0A6AB1C7CE11FEE3724336BCC0EE1BA803F1AB874ED89028C4224003CC836476EA7A3FFF5B025636E2021AF6380DFAD1A18204E546F3947CB11811A4A51E3B096D1867E19FE1407959CC434672EE6371089D37D7C0E48F6C8AA50765F790063788B3B24285A3CD0EEFF80C71ABB335746BA297DBC24807EABDAD6C7F3747799A X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A213B5FB47DCBC3458F0AFF96BAACF4158235E5A14AD4A4A4625E192CAD1D9E79D94463893BF8742D0C3B8520C0FC9B02C X-C1DE0DAB: 0D63561A33F958A521E7F83AA6FD5E67748D43A4D898A084D84604636963F981D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA752DA3D96DA0CEF5C48E8E86DC7131B365E7726E8460B7C23C X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34C5CF6F4B28551E3FC6C48DF7BA1B806BD01631BB964F10DBBE129771EF3C5239549CE239036EE5821D7E09C32AA3244C1B688085BBAC1859259F6EA14B3150E4FE8DA44ABE2443F783B48618A63566E0 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj0dLV0c3jbkyGp91fnw6qlw== X-Mailru-Sender: B5B6A6EBBD94DAD86A422A53D9D37A7DC8FBF457E3F6D9DC83E3E571AD6BE39C3120E6DF4C99E8C91EC9E4A2C82A33BC8C24925A86E657CE0C70AEE3C9A96FBAB3D7EE8ED63280BE112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v3 2/9] lua: built-in module datetime 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: Safin Timur via Tarantool-patches Reply-To: Safin Timur Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On 10.08.2021 15:21, Igor Munkin wrote: > Vlad, > > On 10.08.21, Vladislav Shpilevoy wrote: >> Hi! Thanks for the fixes! >> >> On 08.08.2021 19:35, Safin Timur wrote: >>> Much respect that you've found some time for review, even while being on vacation! Thanks! >>> >>> On 08.08.2021 14:26, Vladislav Shpilevoy wrote: >>>>>>> +local datetime_index_handlers = { >>>>>>> +    unixtime = function(self) >>>>>>> +        return self.secs >>>>>>> +    end, >>>>>>> + >>>>>>> +    timestamp = function(self) >>>>>>> +        return tonumber(self.secs) + self.nsec / 1e9 >>>>>> >>>>>> 11. If you are saying the Lua number value range is enough, >>>>>> why do you store them as 64bit integers in 'self' and >>>>>> convert to a number only for the external API? >>>>> >>>>> May be I misunderstood your sentence, but let me elaborate here. >>>>> I need seconds and nanoseconds kept separately for their efficient and precise handling, and for passing to c-dt. >>>>> >>>>> If we would keep 32-bit integers in seconds then we would be able to handle only dates upto 2038 year, thus we need 64-bit seconds for extended range. >>>>> >>>>> OTOH, not whole 64-bit range is practical, and required for expected in real-life datetime range values. It's not a problem that Lua number and int64_t have very different range for precise integer values. Lua number could handle integer values upto 9e15, which is corresponding to ... >>>> >>>> I know all that. The question is why do you keep storing cdata 64 bits numbers >>>> inside of the datetime objects, if you convert them all to Lua numbers before >>>> return? You could store self.secs as just number. And the other fields too. Lua >>>> number is double, it does not loose precision for integers < 2^53, which should >>>> be enough for the ranges you want to support. Correct? >>> >>> I keep using 64-bit because the primary code operating with fields is on C-side, and we need Lua number only on rare cases when user asked for composed attribute date.timestamp. Whenever we deal with seconds within arthmetic operations or transfer to c-dt, we need integer C type, larger than 32-bit. It's good fit for int64_t. >> >> But it is slower. Notably slower last time I benched, when I also >> thought integers should be faster than doubles. But cdata 64 bit integers >> are slower than plain Lua numbers. Perhaps because they involve too much >> work with metatables for everything. Besides, doubles are larger than 32 >> bits - they are 53 bits until they start loosing int precision. And it is >> just enough for you, isn't it? > > Sorry for breaking into the party, but reasoning is much simpler: Lua > numbers are just double values stored on the guest stack (or other > TValue storage); cdata 64-bit integers are GCcdata objects, so like all > others GC objects it has its lifetime, has to be allocated and freed and > traversed by GC. You can consider them as GCstr except they are not > interned. Hence, if the precision is fine (and it is AFAICS), then there > is not need to use GCcdata instead of Lua native numbers. In other > words, I totally agree with you. > >> > > > > Either I do something totally wrong, or may be I'm absolutely clueless. Oh rather both... Here is experiment I've proceed https://gist.github.com/tsafin/f7f21aad53f23801839b3b278cfac380 I try to compare speed of accessing datetime.secs field: - when it is current int64_t redirected via ffi to the `struct datetime`; - when it is wrapped as (calculated) attribute of type double which we access via FFI datetime_secs() function accessor; - or when it's declared as `double` in the similar `struct datetime_double`. No surpise that calculated attribute is 3x orders of magnitude slower than direct ffi access to either int64_t or double field. OTOH, differences for timings to access to int64_t (which should be boxed) and double (which should be unboxed) are negligible, and essentially the same: ``` ✔ ~/datetime/tarantoolt/build [tsafin/gh-5941-datetime-v4 ↑·4|✚ 3…4⚑ 3] 23:40 $ ./src/tarantool ../../bench-datetime-secs.lua ctype date.secs 0.00035929679870605 ctype date.secsf 0.49544525146484 ctype date_double.secs 0.00042939186096191 ✔ ~/datetime/tarantoolt/build [tsafin/gh-5941-datetime-v4 ↑·4|✚ 3…4⚑ 3] 23:40 $ ./src/tarantool ../../bench-datetime-secs.lua ctype date.secs 0.00034856796264648 ctype date.secsf 0.40926361083984 ctype date_double.secs 0.00043344497680664 ✔ ~/datetime/tarantoolt/build [tsafin/gh-5941-datetime-v4 ↑·4|✚ 3…4⚑ 3] 23:40 $ ./src/tarantool ../../bench-datetime-secs.lua ctype date.secs 0.00034213066101074 ctype date.secsf 0.46818256378174 ctype date_double.secs 0.00037813186645508 ✔ ~/datetime/tarantoolt/build [tsafin/gh-5941-datetime-v4 ↑·4|✚ 3…4⚑ 3] 23:40 $ ./src/tarantool ../../bench-datetime-secs.lua ctype date.secs 0.00051259994506836 ctype date.secsf 0.6695671081543 ctype date_double.secs 0.00048208236694336 ``` What did I do wrong? Thanks, Timur