From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: fixes to goops + light structs + 'u' slots Date: Sun, 13 Apr 2008 20:47:30 +0200 Message-ID: <87fxtpwq0t.fsf@gnu.org> References: <87zls1bdk6.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1208112500 4538 80.91.229.12 (13 Apr 2008 18:48:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Apr 2008 18:48:20 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 13 20:48:49 2008 connect(): Connection refused Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Jl7Fv-0000po-NZ for guile-devel@m.gmane.org; Sun, 13 Apr 2008 20:48:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jl7FH-0003o3-Hx for guile-devel@m.gmane.org; Sun, 13 Apr 2008 14:48:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jl7F4-0003hf-3X for guile-devel@gnu.org; Sun, 13 Apr 2008 14:47:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jl7F1-0003gk-EC for guile-devel@gnu.org; Sun, 13 Apr 2008 14:47:53 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jl7F1-0003gd-93 for guile-devel@gnu.org; Sun, 13 Apr 2008 14:47:51 -0400 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jl7Er-0002j8-7z for guile-devel@gnu.org; Sun, 13 Apr 2008 14:47:50 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jl7En-00085o-KJ for guile-devel@gnu.org; Sun, 13 Apr 2008 18:47:37 +0000 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 13 Apr 2008 18:47:37 +0000 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 13 Apr 2008 18:47:37 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 148 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: reverse-83.fdn.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 25 Germinal an 216 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: i686-pc-linux-gnu User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) Cancel-Lock: sha1:6HQHRrOyIJMAhPXmWYUj6/Z28K0= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7139 Archived-At: --=-=-= Hi Andy, Andy Wingo writes: > I have heard that in a well-done CLOS implementation, accessors are are > generally faster than slot-ref, because they can perform this class/slot > allocation calculation once, and have the method implementation just > dispatch using that table, compiling down to struct-ref instead of > slot-ref. So working this into accessors and method compilation would be > one way to do this. Yeah. More pragmatically, things like SRFI-9 accessors could be implemented as applicable SMOBS: http://thread.gmane.org/gmane.lisp.guile.devel/6716 > Another option would be, as you say, storing more information in the > classes. But on the other hand what we currently have strikes a fine > balance, and is extensible via compute-get-n-set. I don't see GOOPS > objects suddenly becoming faster than structs themselves. But perhaps > benchmarking is really the way to go here. Yes. Since `struct-ref' and `struct-set!' are in C, the optimization I had in mind consists in using a compact C-friendly representation of the layout string, along with an (additional) integer in struct's "hidden" fields describing the size of that layout array. However, the fact that layout strings are used internally is exposed and built upon, e.g., in `make-record-type', which builds vtables using `make-struct'. Maybe that's not something we should worry about in 1.9? > Well, with the old code: > > (define-class () (bar #:init-keyword #:bar)) > (define x (make #:bar 1)) > > In theory, the struct has one slot, 'bar, stored in slot 0 of its > struct. > > (struct? x) => #t > > But: > > (struct-ref x 0) => undefined > > Because struct-ref reads `nfields' from one of the hidden words. Thanks, I added the attached tests for that. > For some crazy reason, only instances with 1 or more slots are set to be > "light", so be sure to define a slot when you are testing this. Also, > only pure instances will be light: instances of are classes, so > they will not be light. Hmm, after applying them, I noticed that they use two slots instead of one. But for sure, they yield a segfault when I undo your patch (commit 4650d115020924e8da5547d4c346cbe5cd01029e). Do you think the segfault is another problem? > To be honest I do not understand the light/non-light thing; to me all > instances should be what is called "light" and all vtables should also > be "light", but hold the necessary information in normal (i.e., > non-negatively indexed) slots of the struct. It seems the difference > only exists because historically things were one way, and the better way > did not have time to fully supplant the old. At first sight, I'd be in favor of having all instances as non-light, because they have a "size" field that's useful. Another interesting possibility would be to remove support for tail arrays, since they don't appear to be used (not even in the test suite), and they're probably broken, and they make the code more complex. Thanks, Ludo'. --=-=-= Content-Type: text/x-patch; charset=iso-8859-1 Content-Disposition: inline; filename*=us-ascii''%2c%2cgoops-struct-tests.diff Content-Transfer-Encoding: 8bit Content-Description: The tests diff --git a/test-suite/ChangeLog b/test-suite/ChangeLog index fa169bc..518e53f 100644 --- a/test-suite/ChangeLog +++ b/test-suite/ChangeLog @@ -1,3 +1,10 @@ +2008-04-13 Ludovic Courtès + + * tests/goops.test (defining classes)[interaction with + `struct-ref', interaction with `struct-set!']: New test. Checks + the interaction of `struct-ref' with "light structs", fixed on + 2008-04-10 (commit 4650d115020924e8da5547d4c346cbe5cd01029e). + 2008-04-06 Ludovic Courtès * standalone/test-asmobs-lib.c, standalone/test-conversion.c, diff --git a/test-suite/tests/goops.test b/test-suite/tests/goops.test index 8ed697c..e4c2df9 100644 --- a/test-suite/tests/goops.test +++ b/test-suite/tests/goops.test @@ -1,6 +1,6 @@ ;;;; goops.test --- test suite for GOOPS -*- scheme -*- ;;;; -;;;; Copyright (C) 2001,2003,2004, 2006 Free Software Foundation, Inc. +;;;; Copyright (C) 2001,2003,2004, 2006, 2008 Free Software Foundation, Inc. ;;;; ;;;; This program is free software; you can redistribute it and/or modify ;;;; it under the terms of the GNU General Public License as published by @@ -148,7 +148,31 @@ #t) (lambda args #f))) - )) + + (pass-if "interaction with `struct-ref'" + (eval '(define-class () + (foo #:init-keyword #:foo) + (bar #:init-keyword #:bar)) + (current-module)) + (eval '(let ((x (make + #:foo 'hello + #:bar 'world))) + (and (struct? x) + (eq? (struct-ref x 0) 'hello) + (eq? (struct-ref x 1) 'world))) + (current-module))) + + (pass-if "interaction with `struct-set!'" + (eval '(define-class () + (foo) (bar)) + (current-module)) + (eval '(let ((x (make ))) + (struct-set! x 0 'hello) + (struct-set! x 1 'world) + (and (struct? x) + (eq? (struct-ref x 0) 'hello) + (eq? (struct-ref x 1) 'world))) + (current-module))))) (with-test-prefix "defining generics" --=-=-=--