From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Zelphir Kaltstahl Newsgroups: gmane.lisp.guile.user Subject: Re: Use core or SRFIs? Date: Thu, 24 Oct 2019 21:47:15 +0200 Message-ID: <65d13994-0020-37bd-80ec-edf89e4e1e03@posteo.de> References: <9ef7ae59-a2b8-ea06-131c-569512409047@posteo.de> 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="221388"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: Guile User To: John Cowan Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Oct 24 21:48:15 2019 Return-path: Envelope-to: guile-user@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 1iNj5j-000vQR-AT for guile-user@m.gmane.org; Thu, 24 Oct 2019 21:48:15 +0200 Original-Received: from localhost ([::1]:51518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNj5h-0005HJ-KC for guile-user@m.gmane.org; Thu, 24 Oct 2019 15:48:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60263) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNj50-00057c-Dz for guile-user@gnu.org; Thu, 24 Oct 2019 15:47:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iNj4t-0006WX-Ic for guile-user@gnu.org; Thu, 24 Oct 2019 15:47:28 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:42909) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iNj4r-0006Vd-Qq for guile-user@gnu.org; Thu, 24 Oct 2019 15:47:23 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id E9D242400FF for ; Thu, 24 Oct 2019 21:47:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1571946439; bh=aZiIdYpULA2v57qCb6fan2RHWl6tSVs8PbrkKdXWlf4=; h=Subject:To:Cc:From:Date:From; b=U+xGrJ/BA6B5V1PDbpDVfVEKmXTN/p7QKo31bSIp52op0gIyI7Am5CHhkY7r6NmCM FcHupQdogS2s7jvDcyTEn7kxkl1L+PhipyBNvNbhDkV0CYvuEoOrunTCjKyVSNNdpU 5LxTSZZsVKZ5k1o2Sb+Qqg9vcaLKCo1dknBnasqXOsKuStvNTT42XDx+sWiH/HbZHn FH6ghGjsGA+tbyxGVAEtlFOJPhkBK4yq9a6GkUFLBvRqKw40FkBvJud3TkJgMk14Ks Jim35ZTiD2JNKS62Kf7Uzo2FIf7su4LK9SEWw/7YJoM+xIV+jGg4sSJsIbltJubHq6 GwCza15q6M0zA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 46zd776Brqz9rxL; Thu, 24 Oct 2019 21:47:15 +0200 (CEST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 185.67.36.66 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:15831 Archived-At: Sorry, I am a bit clueless right now. I have the following questions: Where would I find srfi-151.sld? What is a *.sld file? (If I had to come up with a guess: "Scheme language definition"?) If it is already standard Scheme code, why would I need to adapt it for Guile? Does it need to be modified? I think modifying an external library, which does not exist for Guile yet, is a bit out of scope for my project. I also found logand, logior and similar to be super fast. I expect that the SRFI 60 functions are mapped to the Guile core logand and similar internally. I ran a million times logand in approximately 1.3 seconds. Is that slow? Background: I am working on a bit board implementation and my current (working) implementation uses bit vectors, because I did initially not get it, that I could use integers with those bit-wise operations instead of bit vectors. I had the initial impression, that the code ran fast, but using logand and logior and similar, I already have an approximate 300x speedup. Not sure whether that should still be considered slow. Here is some timing code I used to measure a very simple case: ~~~~~ (use-modules (srfi srfi-19)) (define-syntax time =C2=A0 (syntax-rules () =C2=A0=C2=A0=C2=A0 [(time expr expr* ...) =C2=A0=C2=A0=C2=A0=C2=A0 (begin =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (define start-time (current-time tim= e-monotonic)) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expr =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expr* ... =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (define end-time (current-time time-= monotonic)) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (let* ([diff (time-difference end-ti= me start-time)] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 [elapsed-ns (+ (/ (time-nanosecond diff) 1e9) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 (time-second diff))]) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (display (format #t "~fs= ~%" elapsed-ns))))])) (time =C2=A0(let ([int1 #b10101010] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [int2 #b01010101]) =C2=A0=C2=A0 (do ([i 1 (+ i 1)]) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ([> i 1000000]) =C2=A0=C2=A0=C2=A0=C2=A0 (logand int1 int2)))) ~~~~~ And here is the one for my old / current code: ~~~~~ (use-modules (srfi srfi-19)) (define-syntax time =C2=A0 (syntax-rules () =C2=A0=C2=A0=C2=A0 [(time expr expr* ...) =C2=A0=C2=A0=C2=A0=C2=A0 (begin =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (define start-time (current-time tim= e-monotonic)) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expr =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 expr* ... =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (define end-time (current-time time-= monotonic)) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (let* ([diff (time-difference end-ti= me start-time)] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 [elapsed-ns (+ (/ (time-nanosecond diff) 1e9) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 (time-second diff))]) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (display (format #t "~fs= ~%" elapsed-ns))))])) (define (binary-bit-vector-operation bv1 bv2 proc) =C2=A0 (define (iter bit-list1 bit-list2) =C2=A0=C2=A0=C2=A0 (cond [(or (null? bit-list1) (null? bit-list2)) '()] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [else (cons (proc = (car bit-list1) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (car bit-list2)) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (iter (cdr bit-list1) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 (cdr bit-list2)))])) =C2=A0 (list->bitvector =C2=A0=C2=A0 (iter (bitvector->list bv1) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (bitvector->list bv2)))) (time =C2=A0(let ([bv1 #*10101010] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [bv2 #*01010101]) =C2=A0=C2=A0 (do ([i 1 (+ i 1)]) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ([> i 1000000]) =C2=A0=C2=A0=C2=A0=C2=A0 (binary-bit-vector-operation =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bv1 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bv2 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (lambda (b1 b2) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (and b1 b2)))))) ~~~~~ It is also in my todo file on: https://notabug.org/ZelphirKaltstahl/bitboard/src/dev/todo.org (Btw.: I really like that notabug renders Emacs Org-mode files!) Regards, Zelphir On 10/24/19 8:50 PM, John Cowan wrote: > Compile it yourself!=C2=A0 Just look at the logic in srfi-151.sld and s= ee > how it needs to be modified for Guile.=C2=A0 Easy-peasy. > > It's a lot less work to port a SRFI implementation than to do things > from scratch. > > On Thu, Oct 24, 2019 at 2:26 PM Zelphir Kaltstahl > > wrote: > > Ah, but SRFI 151 is not implemented in my version of Guile: > > ~~~~~ > scheme@(guile-user)> (use-modules (srfi srfi-151)) > While compiling expression: > no code for module (srfi srfi-151) > scheme@(guile-user)> > ~~~~~ > > Guile version: 2.2.6 from Guix: > > ~~~~~ > guile (GNU Guile) 2.2.6 > Copyright (C) 2019 Free Software Foundation, Inc. > > License LGPLv3+: GNU LGPL 3 or later > > . > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > ~~~~~ > > Are you suggesting, that I copy the code for SRFI 151 from > somewhere and put it into my project? > > Regards, > > Zelphir > > On 10/24/19 7:02 PM, John Cowan wrote: >> For bitwise integers, I recommend SRFI 151.=C2=A0 If you use your >> implementation to provide the seven core functions bitwise-not, >> bitwise-and, bitwise-ior, bitwise-xor, arithmetic-shift, >> integer-length, and bit-count, all of which have definitions in >> bitwise-core.scm that are very slow, then you'll have a package >> that can do pretty much what all the bitwise SRFIs provide and >> more with acceptable performance. >> >> There is a conversion table at the end of the SRFI between the >> names used by other SRFIs and the names used by SRFI 151; they >> are as close to SRFI 33 and SRFI 60 as practical.=C2=A0 It is part= of >> the Tangerine Edition of R7RS-large. >> >> On Thu, Oct 24, 2019 at 12:43 PM Nala Ginrut >> > wrote: >> >> Personally, I prefer srfi. But sometimes I mix with RnRS. >> I think it's better to avoid Guile specific things, however, >> Guile provides >> many good things that the standard doesn't have. >> >> On Thu, Oct 24, 2019 at 11:56 PM Zelphir Kaltstahl < >> zelphirkaltstahl@posteo.de >> > wrote: >> >> > Hello Guile Users! >> > >> > I have a question regarding usage of SRFIs in Guile code. >> > >> > Sometimes there are core functions, which are also >> available from an >> > SRFI implementation. One example I am currently dealing >> with are bitwise >> > operations for integer numbers. There is SRFI 60 and there >> are the core >> > functions like logand, logior and so on. >> > >> > Usually I tend to think, that using the SRFI implementation >> in such >> > situation is better, as it is an implementation of a common >> interface, >> > which other Schemes might also have implemented. Using that >> makes code >> > more portable to other Schemes. However, I want to be sure, >> that this is >> > a good way of thinking about it. Are there ever arguments >> against using >> > an SRFI implementation, when an SRFI implementation >> provides what I need? >> > >> > Another example are structs. I usually use SRFI 9 to make >> some structs, >> > instead of the core record or struct type. >> > >> > What do you think? >> > >> > Best regards, >> > >> > Zelphir >> > >> > >> > >>