From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (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 D77F346970F for ; Thu, 28 Nov 2019 16:02:12 +0300 (MSK) Date: Thu, 28 Nov 2019 16:00:05 +0300 From: Igor Munkin Message-ID: <20191128130005.GA1214@tarantool.org> References: <156ce93b495648d6f3fd6c879b0d9aaf56754a1e.1574773773.git.lvasiliev@tarantool.org> <20191126210520.GE23422@atlas> <20191126211701.mhavpytwkemux3vm@tkn_work_nb> <20191127083123.GA2752@atlas> <20191128123445.GC29714@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191128123445.GC29714@atlas> Subject: Re: [Tarantool-patches] [PATCH] Move txn from shema to a separate module (use C API instead of FFI) List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov Cc: tarantool-patches@dev.tarantool.org Kostja, On 28.11.19, Konstantin Osipov wrote: > * Leonid Vasiliev [19/11/28 11:10]: > > 4) About converts others txn functions from FFI to C-API: > > I think it's a good practice, use one or the other (FFI or C-API) in module > > My complaint is about this part. Jit trace can go through FFI but > can't go through Lua/C. This is why many of these functions were > in FFI in the first place. > > We could make a conscious choice to make all box API Lua/C - but > this will literally kill JIT, so then why not just move to LuaJIT v2.1 provides trace stitching feature (for more info see here[1]), so strictly saying, it doesn't kill JIT but yes, performance is nerfed comparing to traces recorded for an FFI code. I have no proofs/benchmarks for now, so it sounds kinda bullshit, but I look forward to make some in the nearest future. Furthermore, FFI is not a silver bullet considering this issue[2]. > plain Lua 5.3 and forget about grievances with LuaJIT altogether. JIT is not the only killing feature provided by LuaJIT and infrastructure for Lua 5.1 is much richer. > > Nick Zavaritsky had a patch that would detect sandwich stacks in > runtime and assert. Nobody had time to look at it back then - Could you please provide the issue/link for this changeset, I'll take a look on it with pleasure. > everyone was busy with vinyl and sql. > > Why not dig it up to protect from future erosion of the code base? > > This would be more valuable contribution than just falling back to > Lua/C for everything. I have a tiny patch for JIT in my branch[3], respecting most remarks given by Mr Egorov, however it's not yet fully tested and there're still some pitfalls not being fixed. I'm working on it for now. > > -- > Konstantin Osipov, Moscow, Russia [1]: http://wiki.luajit.org/NYI [2]: https://github.com/tarantool/tarantool/issues/4630 [3]: https://github.com/tarantool/luajit/commit/a3a47015842c7e7c1bee2f4fc30345aa7d4e5dba -- Best regards, IM