From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Vibhav Pant Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] feature/byte-switch 086c4ea: * src/bytecode.c: (exec_byte_code) Use hash_lookup for Bswitch Date: Thu, 19 Jan 2017 17:53:50 +0000 Message-ID: References: <20170118171311.10996.72260@vcs.savannah.gnu.org> <20170118171311.A84EA220125@vcs.savannah.gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113f2b9ce644010546763768 X-Trace: blaine.gmane.org 1484849107 8346 195.159.176.226 (19 Jan 2017 18:05:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 19 Jan 2017 18:05:07 +0000 (UTC) Cc: "emacs-devel@gnu.org" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 19 19:04:59 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cUH4K-00074x-AB for ged-emacs-devel@m.gmane.org; Thu, 19 Jan 2017 19:04:16 +0100 Original-Received: from localhost ([::1]:50154 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cUH4P-0007s3-8a for ged-emacs-devel@m.gmane.org; Thu, 19 Jan 2017 13:04:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cUGuR-0000RG-AC for emacs-devel@gnu.org; Thu, 19 Jan 2017 12:54:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cUGuQ-0006q2-D6 for emacs-devel@gnu.org; Thu, 19 Jan 2017 12:54:03 -0500 Original-Received: from mail-yw0-x22e.google.com ([2607:f8b0:4002:c05::22e]:34846) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cUGuQ-0006ps-7M for emacs-devel@gnu.org; Thu, 19 Jan 2017 12:54:02 -0500 Original-Received: by mail-yw0-x22e.google.com with SMTP id l19so42585697ywc.2 for ; Thu, 19 Jan 2017 09:54:02 -0800 (PST) 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=QFLbe6g/Q9ZTzXRWbD85Ncs5ZqSkHchnRlEMGGVdc48=; b=E3oDyGunaDQxhsAHepDLrf/+6JqAZTV0X3Kz/VkspbfL2TEkeMAXRvKnRMRPcr5Iok I2V47exI2sfe7WJWXlr4xR0i1aX6dsrvWBYj03DlVlat+mXzHYkGWqyCirnnRDnR6y+m yTcqwt+n7yoKovhDR5etL0D+LmCpEgXfDS9lGdeXfUq+B/EDqrYu3mkYG6/Cjlnrm6JC mQqBNdIJ0UB1lG3M98VFyr9EwCLpGl+fAxQQjJvG5V3FZrHjWaKbv2A+PN647ieQNxEV /GNsKq7bPw5zOQefa6L3iQ0tgLImLJp321n6/HmcZrim+UGjEtiymvTmvppsOeiPhD3X 6gKQ== 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=QFLbe6g/Q9ZTzXRWbD85Ncs5ZqSkHchnRlEMGGVdc48=; b=NcR9bT98gzC4It3kUOZ3Z5HeUfVK9tMoJJSqN8sAzxCKvx7bgjRS4eOkRX09DLFzw+ Gl4sdCr/rFyYbnypUULs2F6o2cW04jpMytTGubtiGMVyQzIgyD/VBm2ywpwdguJSyw54 lWnOUR5z42YXu7q6Au4VNtk60yL7+AZ8SQCZ4IijxZWbmq0/Ir7BmZf/5OK3kxiAscLr +RqeLRuJ1eZmivhKuQg/i5WLgiqvLSUvsx5W6sxhlsekEqWugmeHGVa0oFTRfmGBWZsG MgfP0Sa6HX8iki4kMK2q/d9x43OTZpdgLdsOpNR/3Bj/+eHUmnj3bQzpSp4lkNgGjZFb KpvQ== X-Gm-Message-State: AIkVDXLBilvWBqOdZ64NOlCeZd7oNZ+skuElmcsdn8yOuh4iSor/PkG4fnPcRvkUBgf/PDj/M0WRt95Z3xeh1A== X-Received: by 10.129.85.211 with SMTP id j202mr7473435ywb.287.1484848441464; Thu, 19 Jan 2017 09:54:01 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4002:c05::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211408 Archived-At: --001a113f2b9ce644010546763768 Content-Type: text/plain; charset=UTF-8 I see. For now, I've made the type check only work when BYTE_CODE_SAFE is defined at compile time. I'll make it a part of the regular code once the byte-switch is implemented and there are no performance issues with doing so. On Thu, 19 Jan 2017, 22:04 Stefan Monnier, wrote: > > On another thought, `byte-switch` is used while compiling certain > > `cond` forms. It > > replaces the traditional goto-if-nil bytecode by using a hash table > mapping > > values to addresses/tags to be jumped to. Since `byte-switch` is > essentially a > > "dynamic" goto (in the sense that the address/tag cannot be known at > > compile time), > > wouldn't doing a runtime type check in the bytecode VM for what is a > > hash table lookup + goto have a significant performance penalty? > > I don't know. Only measurement can tell. My guess is that hash_lookup > already takes a significant amount of time, so a HASH_TABLE_P test would be > negligible in comparison. > > > Stefan > > > > On Wed, Jan 18, 2017 at 11:18 PM, Stefan Monnier > > wrote: > >>> * src/bytecode.c: (exec_byte_code) Use hash_lookup for Bswitch > >>> Fgethash type checks the provided table object, which is unnecessary > >>> for compiled bytecode. > >> > >> While it's true that we can cause a core dump of Emacs if we feed it an > >> invalid .elc file, that's a "feature" I'd rather shrink rather > >> than generalize. > >> > >> > >> Stefan > > > > > -- > > Vibhav Pant > > vibhavp@gmail.com > --001a113f2b9ce644010546763768 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I see. For now, I've made the type check only work when = BYTE_CODE_SAFE is defined at compile time. I'll make it a part of the r= egular code once the byte-switch is implemented and there are no performanc= e issues with doing so.


On Thu, 19 Jan 2017, 22:04 = Stefan Monnier, <monnier@iro= .umontreal.ca> wrote:
> O= n another thought, `byte-switch` is used while compiling certain
> `cond` forms. It
> replaces the traditional goto-if-nil bytecode by using a hash table ma= pping
> values to addresses/tags to be jumped to. Since `byte-switch` is essen= tially a
> "dynamic" goto (in the sense that the address/tag cannot be = known at
> compile time),
> wouldn't doing a runtime type check in the bytecode VM for what is= =C2=A0 a
> hash table lookup + goto have a significant performance penalty?

I don't know.=C2=A0 Only measurement can tell.=C2=A0 My guess is that h= ash_lookup
already takes a significant amount of time, so a HASH_TABLE_P test would be=
negligible in comparison.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan


> On Wed, Jan 18, 2017 at 11:18 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>>> * src/bytecode.c: (exec_byte_code) Use hash_lookup for Bswitch=
>>> Fgethash type checks the provided table object, which is unnec= essary
>>> for compiled bytecode.
>>
>> While it's true that we can cause a core dump of Emacs if we f= eed it an
>> invalid .elc file, that's a "feature" I'd rather= shrink rather
>> than generalize.
>>
>>
>> Stefan



> --
> Vibhav Pant
> vibhavp@gmail.com
--001a113f2b9ce644010546763768--