Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: Igor Munkin <imun@tarantool.org>,
	Sergey Ostanevich <sergos@tarantool.org>,
	Kirill Yukhin <kyukhin@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit 1/2] jit: abort trace recording and execution for C API
Date: Fri, 3 Apr 2020 01:41:14 +0200	[thread overview]
Message-ID: <a8c17710-dbfc-5d5c-ebc4-6f6e1d3f302d@tarantool.org> (raw)
In-Reply-To: <50fe58f83ebb4e4971528641e74f99fe2f9fd8f2.1585304087.git.imun@tarantool.org>

Hi! Thanks for the patch!

> diff --git a/src/lj_api.c b/src/lj_api.c
> index a5e2465..c1f53e0 100644
> --- a/src/lj_api.c
> +++ b/src/lj_api.c
> @@ -300,7 +311,7 @@ LUA_API int lua_equal(lua_State *L, int idx1, int idx2)
>        return (int)(uintptr_t)base;
>      } else {
>        L->top = base+2;
> -      lj_vm_call(L, base, 1+1);
> +      call(L, base, 1+1);

These changes look dangerous to perf. So if I had operators ==
and < overloaded for an FFI struct, they are not jitted anymore,
right? Why? Does someone really yield in them? Could you measure
how does it affect perf of these calls? From what I see, these
changes basically kill FFI making it not better than Lua C. It no
longer helps JITting anything, does it?

The same for concat, and other things. Looks like an overkill. We
would need sandwich protection only for a few places. Is it possible
to avoid such drastic changes?

  parent reply	other threads:[~2020-04-02 23:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-27 10:47 [Tarantool-patches] [PATCH luajit 0/2] Trace abort on FFI sandwich or mode change Igor Munkin
2020-03-27 10:47 ` [Tarantool-patches] [PATCH luajit 1/2] jit: abort trace recording and execution for C API Igor Munkin
2020-03-28 16:33   ` Sergey Ostanevich
2020-03-28 20:30     ` Igor Munkin
2020-03-29  9:21       ` Sergey Ostanevich
2020-03-29 10:45         ` Igor Munkin
2020-03-30  8:58           ` Sergey Ostanevich
2020-03-30 14:25             ` Igor Munkin
2020-04-03 21:06               ` Sergey Ostanevich
2020-04-03 21:31                 ` Igor Munkin
2020-04-02 23:41   ` Vladislav Shpilevoy [this message]
2020-04-04 11:55     ` Igor Munkin
2020-04-04 21:37       ` Vladislav Shpilevoy
2020-04-07 21:16         ` Igor Munkin
2020-03-27 10:47 ` [Tarantool-patches] [PATCH luajit 2/2] jit: abort trace execution on JIT mode change Igor Munkin
2020-03-28 19:36   ` Sergey Ostanevich
2020-03-29 10:46     ` Igor Munkin
2020-04-02 23:41 ` [Tarantool-patches] [PATCH luajit 0/2] Trace abort on FFI sandwich or " Vladislav Shpilevoy
2020-04-03 21:32   ` Igor Munkin
2020-04-04 21:36     ` Vladislav Shpilevoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a8c17710-dbfc-5d5c-ebc4-6f6e1d3f302d@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=imun@tarantool.org \
    --cc=kyukhin@tarantool.org \
    --cc=sergos@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH luajit 1/2] jit: abort trace recording and execution for C API' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox