From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: For a cheaper =?utf-8?Q?=E2=80=98bytevector-=3Epointer?= =?utf-8?Q?=E2=80=99?= Date: Mon, 25 Nov 2019 10:05:12 +0100 Message-ID: <875zj81g3b.fsf@igalia.com> References: <87zhglzgue.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="26981"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: Guile Devel To: Ludovic =?utf-8?Q?Court=C3=A8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Nov 25 10:07:18 2019 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iZAL0-0006sx-6p for guile-devel@m.gmane.org; Mon, 25 Nov 2019 10:07:18 +0100 Original-Received: from localhost ([::1]:41542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZAKy-0003eg-SS for guile-devel@m.gmane.org; Mon, 25 Nov 2019 04:07:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55191) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZAJF-0001oq-1X for guile-devel@gnu.org; Mon, 25 Nov 2019 04:05:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZAJD-0000bP-Ot for guile-devel@gnu.org; Mon, 25 Nov 2019 04:05:28 -0500 Original-Received: from fanzine.igalia.com ([178.60.130.6]:40697) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iZAJD-0000ap-6w; Mon, 25 Nov 2019 04:05:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=47OJwN4rZIwY62Fz9FWz9ppv5yXmK6tT0/ZnPUNmNb8=; b=nTUEFoBogAoUAOwSdWHuFXc8JzCqNXnuyoG2VPJ+ygrb1O2TQ/ka0BC8h0NR8Tz4j4kjs5qedW/TXgS4V/JPmRZ1DOo845BQovkddEiLDswdmcPSfWe08xi92v2VRHErejt0l1u6EO9YpD26fInkRECSOGZEHw7hvfyvUuPMqq+kLW1N498nMKBXqgUlRM89jBlB35EoDJF4zDuxK33wEMifjpL4xkIzmh+hDnPUgeEjt578s2A4MjuE0OYpEdPv7tReHvD+CZirKTDRo/UHH/kD6G7w4TcSHh2uc4rQ37yQDhEuVdHMG5NTV0bhpdB9diB4Mftbk90U53cecrrWcA==; Original-Received: from lfbn-ann-1-376-195.w86-200.abo.wanadoo.fr ([86.200.91.195] helo=milano) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) id 1iZAJ8-0002UT-E8; Mon, 25 Nov 2019 10:05:22 +0100 In-Reply-To: <87zhglzgue.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 24 Nov 2019 11:52:41 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 178.60.130.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:20163 Archived-At: On Sun 24 Nov 2019 11:52, Ludovic Court=C3=A8s writes: > A few days ago David was explaining on #guile how =E2=80=98bytevector->po= inter=E2=80=99 > was generating too much garbage for his use case. An idea we came up > with was to embed the pointer object in the bytevector. > > The patch below does that but it leads to segfaults because I=E2=80=99m g= uessing > there=E2=80=99s generated bytecode somewhere that still uses the wrong of= fset; I > adjusted code that emits =E2=80=98pointer-ref/immediate=E2=80=99, what el= se did I > miss? The compiler :) Bytevector literals are stored statically in the .go files, so the assembler would need to change to emit the new layout. Also, compiled access to bytevectors; see prepare-bytevector-access in (language tree-il compile-cps). > Also, since we disable internal pointers, we=E2=80=99d need to register an > additional displacement, and I=E2=80=99m not sure if this is a good idea. > > Thoughts? Honestly I would prefer not to do this. If I understand correctly, the problem is in FFI calls -- you have a bytevector and you want to pass it as a pointer. In that case the "right" optimization is to avoid the scm_tc7_pointer altogether and instead having an unboxed raw pointer. The idioms used in FFI are local enough that a compiler can do this. More broadly -- the current FFI is an interpreter but it should be a compiler. When a call happens, the code interprets the description of the ABI. Instead, pointer->function should ideally *compile* a trampoline. In an ideal world this compilation can happen ahead-of-time, when the .go file is compiled. In the short term, what about allowing bytevectors as arguments whereever a pointer is allowed? Perhaps it's bad to expand the domain of these functions but it may be the right trade-off. Andy