From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: yyoncho Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Mon, 27 Apr 2020 07:41:46 +0300 Message-ID: References: <838smzq9iz.fsf@gnu.org> <8336d6rfgy.fsf@gnu.org> <83woagonl9.fsf@gnu.org> <83sgl4ojci.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000cce96705a43e55cd" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="16846"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Stefan Monnier , emacs-devel To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 27 06:42:56 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jSvbc-0004Gk-BR for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Apr 2020 06:42:56 +0200 Original-Received: from localhost ([::1]:52778 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSvbb-0002Fl-9c for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Apr 2020 00:42:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49792) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSvan-0001PY-EH for emacs-devel@gnu.org; Mon, 27 Apr 2020 00:42:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSvam-0004mo-U0 for emacs-devel@gnu.org; Mon, 27 Apr 2020 00:42:05 -0400 Original-Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:40534) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSvai-0004gT-CF; Mon, 27 Apr 2020 00:42:00 -0400 Original-Received: by mail-lj1-x233.google.com with SMTP id y4so16115148ljn.7; Sun, 26 Apr 2020 21:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m6jRNRliGsjSZViZtRctATWN1+3/aN8wsp8mPUFKRt0=; b=CqS6/miC6JiVIjtXUvMvBh+QIInHBHEMSzqf1bSKwtMQEVREPIvFyx9cvVvxrc23no XAxxPdOjPSCPfGdxMNUs1Ci69ypU1lUMynuDiQtun/O93qkwlrmiXRMlg3vzEejwIkEj 2xotHxD48YQUOiNpqSyq6JTei7aKfwyYwvKE2sl/9Q/OMxZNgmdc6z6tULR4SpIBV79E +AzCeFPbCc5eRFdlivLwHg3m52xPFFMBjg/p3hyjzVdGudeb+5wpVbYjGCkIHJLRtsPV r0vfVB5KaRgtopCVFXhcO/3rFW9meLJJRwdE8q0rjkUT1sHCoazLymW6zBmaN6TOzWVy h7cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m6jRNRliGsjSZViZtRctATWN1+3/aN8wsp8mPUFKRt0=; b=B4wPQ8xVseifJN9FY96oj+92sFchUnbzFV6YUio3eDw1iBek9S2bpNjKEq427llGX3 McU9T2F76lq9P5aKIxz8HzeOvJODenWXGlIQ2wGAOmDvcK8qcr1dPQ0x0mDg7UNjiNeF Xj1qr8WgP2HTRcPzavIzRE8PhIKScWPL9WpK6p/B7ZE8N3DG3tIly/4p8TwC5aQrXA9D LMD+nAJpTjZk7oh/YnOoLNS54LY0ihrugrZMUvhUvAW5aTZQr+yJTJ7K5VROr1WWAVKn j3GOyZV99UM8SbRl+jRvIqW7S+n6959rs2/aNymlSXQBCD7hVGun28h0Kr8BOBFZnqGk NhcA== X-Gm-Message-State: AGi0Pubcul04TreCcfVjIumpZTy0PzH1EfMxkj7kiY7AKycWBSZI+bWs NMRR/r8AZBkFBAAZZv3YruFmGz2HKtTlR29IQaY= X-Google-Smtp-Source: APiQypJuqV257spaSZFO8GRmLkh8YqTO+gqtfmpRHLnMh5zMoI1zB+EtJBkzYervKSIsW7nzyBOaKWaQ3Fs1tsrxv2c= X-Received: by 2002:a2e:b1c9:: with SMTP id e9mr13483769lja.102.1587962517972; Sun, 26 Apr 2020 21:41:57 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::233; envelope-from=yyoncho@gmail.com; helo=mail-lj1-x233.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:247889 Archived-At: --000000000000cce96705a43e55cd Content-Type: text/plain; charset="UTF-8" I am glad that my report helped to improve native-comp branch. Thanks, Ivan On Sun, Apr 26, 2020 at 3:00 PM Andrea Corallo wrote: > yyoncho writes: > > > Hi, > > > > I did benchmarks of json parsing here it is what I get: > > > > | test | non-gc avg (s) | gc avg (s) | gcs avg | tot avg > > (s) | tot avg err (s) | > > | > > > --------------+----------------+------------+---------+-------------+----------------- > > | > > | json-parsing | 2.57 | 3.32 | 318 | > > 5.89 | 0.10 | > > | > > > --------------+----------------+------------+---------+-------------+----------------- > > | > > | total | 2.57 | 3.32 | 318 | > > 5.89 | 0.10 | > > > > > > Native: > > > > | test | non-gc avg (s) | gc avg (s) | gcs avg | tot avg > > (s) | tot avg err (s) | > > | > > > --------------+----------------+------------+---------+-------------+----------------- > > | > > | json-parsing | 1.71 | 4.31 | 343 | > > 6.02 | 0.01 | > > | > > > --------------+----------------+------------+---------+-------------+----------------- > > | > > | total | 1.71 | 4.31 | 343 | > > 6.02 | 0.01 | > > > > It looks like this is bellow the average speedup you might wanna take > > a look: > > > > Here it is the benchmark code: > > > > (require 'cl-lib) > > (require 'json) > > > > (defvar json-parsing-input (with-temp-buffer > > (insert-file-contents-literally "benchmarks/sample.json") > > (buffer-string))) > > > > > > (defun elb-json-parsing-entry () > > (cl-loop repeat 1000 > > do (json-read-from-string json-parsing-input))) > > > > Thanks, > > Ivan > > Hi Ivan, > > I've got time to re-look into this. > > The perf difference was due to GC time (as Eli pointed out all json > computation is in the C world). > > I believe this delta was due to the greater number of objects allocated > in the native comp variant with the consequent more time needed to > traverse them during GC. > > Since these measures I've made several changes to reduce the number of > unnecessary live objects. Repeating the test on the current native-comp > against master I see on my machine a performance delta of 2% in favor of > master. Considering I expect this effect to fade out on a real session > with more allocated objects I consider this being acceptable. > > Andrea > > -- > akrl@sdf.org > --000000000000cce96705a43e55cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am glad that my report helped to improve=C2=A0native-com= p branch.

Thanks,
Ivan

On Sun, Apr 26= , 2020 at 3:00 PM Andrea Corallo <akrl@s= df.org> wrote:
yyoncho <yy= oncho@gmail.com> writes:

> Hi,
>
> I did benchmarks of json parsing here it is what I get:
>
> =C2=A0 | test =C2=A0 =C2=A0 =C2=A0 =C2=A0 | non-gc avg (s) | gc avg (s= ) | gcs avg | tot avg
> (s) | tot avg err (s) |
> =C2=A0 |
> --------------+----------------+------------+---------+-------------+-= ----------------
> |
> =C2=A0 | json-parsing | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2.57 | =C2= =A0 =C2=A0 =C2=A0 3.32 | =C2=A0 =C2=A0 318 | =C2=A0 =C2=A0 =C2=A0
> =C2=A05.89 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.10 |
> =C2=A0 |
> --------------+----------------+------------+---------+-------------+-= ----------------
> |
> =C2=A0 | total =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 2.57 | =C2=A0 =C2=A0 =C2=A0 3.32 | =C2=A0 =C2=A0 318 | =C2=A0 = =C2=A0 =C2=A0
> =C2=A05.89 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.10 |
>
>
> Native:
>
> =C2=A0 | test =C2=A0 =C2=A0 =C2=A0 =C2=A0 | non-gc avg (s) | gc avg (s= ) | gcs avg | tot avg
> (s) | tot avg err (s) |
> =C2=A0 |
> --------------+----------------+------------+---------+-------------+-= ----------------
> |
> =C2=A0 | json-parsing | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1.71 | =C2= =A0 =C2=A0 =C2=A0 4.31 | =C2=A0 =C2=A0 343 | =C2=A0 =C2=A0 =C2=A0
> =C2=A06.02 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.01 |
> =C2=A0 |
> --------------+----------------+------------+---------+-------------+-= ----------------
> |
> =C2=A0 | total =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 1.71 | =C2=A0 =C2=A0 =C2=A0 4.31 | =C2=A0 =C2=A0 343 | =C2=A0 = =C2=A0 =C2=A0
> =C2=A06.02 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.01 |
>
> It looks like this is bellow the average speedup you might wanna take<= br> > a look:
>
> Here it is the benchmark code:
>
> (require 'cl-lib)
> (require 'json)
>
> (defvar json-parsing-input (with-temp-buffer
> =C2=A0 =C2=A0 (insert-file-contents-literally =C2=A0"benchmarks/s= ample.json")
> =C2=A0 =C2=A0 (buffer-string)))
>
>
> (defun elb-json-parsing-entry ()
> =C2=A0 (cl-loop repeat 1000
> =C2=A0 do (json-read-from-string json-parsing-input)))
>
> Thanks,
> Ivan

Hi Ivan,

I've got time to re-look into this.

The perf difference was due to GC time (as Eli pointed out all json
computation is in the C world).

I believe this delta was due to the greater number of objects allocated
in the native comp variant with the consequent more time needed to
traverse them during GC.

Since these measures I've made several changes to reduce the number of<= br> unnecessary live objects.=C2=A0 Repeating the test on the current native-co= mp
against master I see on my machine a performance delta of 2% in favor of master.=C2=A0 Considering I expect this effect to fade out on a real sessio= n
with more allocated objects I consider this being acceptable.

Andrea

--
akrl@sdf.org
--000000000000cce96705a43e55cd--