From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 C405046970F for ; Thu, 28 Nov 2019 17:05:47 +0300 (MSK) Date: Thu, 28 Nov 2019 17:03:40 +0300 From: Igor Munkin Message-ID: <20191128140340.GB1214@tarantool.org> References: <156ce93b495648d6f3fd6c879b0d9aaf56754a1e.1574773773.git.lvasiliev@tarantool.org> <20191126210520.GE23422@atlas> <20191126211701.mhavpytwkemux3vm@tkn_work_nb> <20191127083123.GA2752@atlas> <20191128123445.GC29714@atlas> <20191128130005.GA1214@tarantool.org> <20191128131804.GE29714@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191128131804.GE29714@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: > * Igor Munkin [19/11/28 16:03]: > > 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]. > > I fully agree on all points, there is some buggy trace stitching, > there is an overhead of switching to Lua/C and back, > (FFI is slower in Lua/C partly for this reason), and > FFI is not a silver bullet. We faced several platform failures recently in FFI machinery, thus I can't claim which one LuaJIT part from these two is much more buggy. > > Despite all of the above we should be aiming at using FFI more, > not less, going forward, don't you agree? > Why should we be aiming at using FFI more? The root cause is that current fiber machinery (as well as some parts of triggers mechanism) doesn't respect the Lua coroutine switch semantics, thereby breaking trace recording. Lua-C API implicitly (or non-intentionally) prevents breakage by JIT trace aborts when recording FUNCC. Therefore, I guess we should be aiming either at changing fiber switching to the one respecting the LuaJIT runtime or at tuning JIT compiler way more regarding the Lua-C usage. Besides, we can't fully prevent platform failures if there is an FFI misusage in users code. > What should be the rule of thumb in your opinion, ffi or > lua/c? If you want to know my rule of thumb: FFI is for external existing libraries to be used in Lua code (and all compiler related benefits are nothing more than a godsend consequence, since all guest stack manipulations are implemented in LuaJIT runtime, not in an external code) and Lua-C is a well-designed and well-documented API for embedding Lua into a host application / extending Lua with external low-lewel libs. I totally do not insist on my point of view, since everyone has it's own vision on LuaJIT features. > > > > 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. > > Nick Zavaritsky himself is the only link here, unfortunately. > Perhaps he has this patch in one of his personal branches. I > suggest someone contacts him :) > > -- > Konstantin Osipov, Moscow, Russia -- Best regards, IM