Re: Use core or SRFIs?

[Zelphir Kaltstahl]

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
  (syntax-rules ()
    [(time expr expr* ...)
     (begin
       (define start-time (current-time time-monotonic))
       expr
       expr* ...
       (define end-time (current-time time-monotonic))
       (let* ([diff (time-difference end-time start-time)]
              [elapsed-ns (+ (/ (time-nanosecond diff) 1e9)
                             (time-second diff))])
         (display (format #t "~fs~%" elapsed-ns))))]))


(time
 (let ([int1 #b10101010]
       [int2 #b01010101])
   (do ([i 1 (+ i 1)])
       ([> i 1000000])
     (logand int1 int2))))
~~~~~

And here is the one for my old / current code:

~~~~~
(use-modules (srfi srfi-19))

(define-syntax time
  (syntax-rules ()
    [(time expr expr* ...)
     (begin
       (define start-time (current-time time-monotonic))
       expr
       expr* ...
       (define end-time (current-time time-monotonic))
       (let* ([diff (time-difference end-time start-time)]
              [elapsed-ns (+ (/ (time-nanosecond diff) 1e9)
                             (time-second diff))])
         (display (format #t "~fs~%" elapsed-ns))))]))


(define (binary-bit-vector-operation bv1 bv2 proc)
  (define (iter bit-list1 bit-list2)
    (cond [(or (null? bit-list1) (null? bit-list2)) '()]
          [else (cons (proc (car bit-list1)
                            (car bit-list2))
                      (iter (cdr bit-list1)
                            (cdr bit-list2)))]))
  (list->bitvector
   (iter (bitvector->list bv1)
         (bitvector->list bv2))))


(time
 (let ([bv1 #*10101010]
       [bv2 #*01010101])
   (do ([i 1 (+ i 1)])
       ([> i 1000000])
     (binary-bit-vector-operation
      bv1
      bv2
      (lambda (b1 b2)
        (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!  Just look at the logic in srfi-151.sld and see
> how it needs to be modified for Guile.  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
> <address@hidden <mailto:address@hidden>> 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
>     <http://gnu.org/licenses/lgpl.html>
>     <http://gnu.org/licenses/lgpl.html>.
>     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.  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.  It is part of
>>     the Tangerine Edition of R7RS-large.
>>
>>     On Thu, Oct 24, 2019 at 12:43 PM Nala Ginrut
>>     <address@hidden <mailto:address@hidden>> 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 <
>>         address@hidden
>>         <mailto:address@hidden>> 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
>>         >
>>         >
>>         >
>>