[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more advanced bytevector => supervectors

From: lloda
Subject: Re: more advanced bytevector => supervectors
Date: Wed, 8 Sep 2021 09:18:05 +0200

On 8 Sep 2021, at 04:04, Stefan Israelsson Tampe <> wrote:


So using get-setter typically means
((get-setter #f bin1 #f 
   (lambda (set) (set v 2 val)))

   #:is-endian 'little          ;; only consider little endian setters like I know 
   #:is-unsigned  #t         ;; only use unsigned
   #:is-integer      #t         ;; only use integer representations
   #:is-fixed          #t        ;; do not use the scm value vector versions
So a version where we only consider handling nonegative integers of up to 64bit. The gain is faster compilation as this ideom will dispatch
between 4 different versions of the the loop lambda and the compiler could inline all of them or be able to detect the one that are used and hot compile that version
(a feature we do not have yet in guile) now whe you select between a ref and a set you will similarly end up with 4*4 versions = 16 different loops that. full versions
is very large and a double loop with all featurs consists of (2*2 + 3*2*2*2 + 4 + 1)**2 = 33*33 ~ 1000 versions of the loop which is crazy if we should expand the loop
for all cases in the compilation. Now guile would just use a functional approach and not expand the loop everywhere. We will have parameterised versions of
libraries so that one can select which versions to compile for. for example the general functions that performs transform form one supervector to another is a general
ideom that would use the full dispatc which is not practical, 

I'm curious where you're going with this.

I implemented something similar (iiuc) in, specifically , where the lookup/set methods are inlined in the loop. The compilation times indeed grow exponentially so I'm forced to have a default 'generic' case. 

The idea for fixing this was to have some kind of run time compilation cache so only a fixed number of type combinations that actually get used would be compiled, instead of the tensor product of all types. But I haven't figured out, or actually tried to do that yet.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]