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 DB5616EC40; Tue, 10 Aug 2021 15:45:29 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org DB5616EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1628599530; bh=MvvUtzjMGzrFiEQVNTIkywaFzDL7DEmlRNWiAU/XXvE=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=YMj0mYNJWErglK+nlIYV9LDXY5zmIUlklWIuXb4Wq/bath1uL6KO1AbWvFE6NCLo4 dY98ja8GvaHXn/Qyuuwe27yntN1Z+BT90WUAf+khGI9Aqtk2Fodl7CtswInNP6Fo56 g0ReuY3AaxtDIp7HMp6wXtUVXCnqv0XAwUtFY2bU= Received: from smtpng1.i.mail.ru (smtpng1.i.mail.ru [94.100.181.251]) (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 44BB16EC40 for ; Tue, 10 Aug 2021 15:45:28 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 44BB16EC40 Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1mDR8I-0000lU-NV; Tue, 10 Aug 2021 15:45:27 +0300 Date: Tue, 10 Aug 2021 15:21:47 +0300 To: Vladislav Shpilevoy Message-ID: <20210810122147.GK27855@tarantool.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8e779f32-f4e0-f3ac-45c3-c976f32bfd75@tarantool.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.10.1 (2018-07-13) X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD92087353F0EC44DD910164DC12A5633065676A9727AC27C74182A05F538085040B67743A5DEFC1EBF2FD85F0B0F245FD16FD15C1E1F6C9BD96E8622EE9DEB4983 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7DB7B102DCB413779EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006373768BF035B57E5168638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8A64CFE71CE5C904BE994B28590C8013B117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC3A703B70628EAD7BA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD186FD1C55BDD38FC3FD2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B60A62CEF541B197C8089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5F2E4C0EBEEB4398D14F5D54EB1EB92848C15F64CF2C624B3D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA753177526CD55AFC11410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3498910055B812BD9C75F59A93E44CDA78B0734047A320815ED1E3989F2E11CC613C565ADDF7B4C8971D7E09C32AA3244C74C42BCF028D1CEE302BA6230B0244F9F2F5F14F68F1805B8D5DD81C2BAB7D1D X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojGhQhWEp1aB8FmgcXZCJd0Q== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5D5A74B17E4D7CADEE0CB5C9CFB7F14637A7C8D0F45F857DBFE9F1EFEE2F478337FB559BB5D741EB964C8C2C849690F8E70A04DAD6CC59E33667EA787935ED9F1B 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: Igor Munkin via Tarantool-patches Reply-To: Igor Munkin Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" 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. > -- Best regards, IM