[Top][All Lists]

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

Re: Pure (side-effect-free) calls into c/c++?

From: Linas Vepstas
Subject: Re: Pure (side-effect-free) calls into c/c++?
Date: Sat, 11 Jan 2020 12:52:32 -0600

Or, thinking aloud a bit: boxes and symbols....

So, for example, if I was able to tell apart calls (f 42) from calls (f x)
where x is a "symbol" (or "variable", *see below*) referencing an integer,
then, for the former case, I could create a new symbol (in guile) and
attach it to a box, fill that box with whatever (f 42) would have returned.
Thence-forward, any call site in the guile code that had (f 42) in it would
get replaced by the symbol (or the unboxed value)...

At the moment, I don't know how to tell apart 42, the literal number, from
x, a symbol that references a number. (Somehow, I can't make symbol? work
...)  I also don't know how to "edit" the call site (the cell, the box?)
that has (f 42) as the call-target, and replace it by a constant (or a
boxed constant).

But my naive thinking fails:
(define x 0)
(symbol? x)  => #f
(variable? x) => #f

So I guess that x is not a symbol, from the guile point of view!?  This is
.. confusing. What is x, then, if not a symbol?

(define (foo x)  (format #t "its ~A ~A\n" (symbol? x) (variable? x)) (+ x
(foo 42)
its #f #f
(define y 66)
(foo y)
its #f #f

How can I tell apart "42" from "y"  ?

-- Linas

On Sat, Jan 11, 2020 at 12:11 PM Linas Vepstas <address@hidden>

> Hmm Thanks.  Perhaps I should have been more clear.  I'm talking about a
> handful of values that behave like constants, and NOT about memoization.
> So here's a bit more detail. The only thing the C++ code is doing is
> stuffing the values into a giant hash table... in C++. So its already very
> fast. The return value is a pointer into that hash table.  Replicating that
> hash table a second time, in guile is ... well ... it has tens/hundreds of
> millions of entries, it would blow out RAM.  (And the other functions,
> those that are actually CPU-intensive, already got the Grand Wazoo
> treatment for memization; some in guile, some in C++)
> For this particular issue, I'm thinking I need to understand macros,
> somehow.  The point being that there is just a tiny handful of values --
> some dozens, maybe hundreds, that some human has written into the code, and
> are being treated as if they were literal constants (because, in the C++
> code, they *are* constants -- they're really just fixed entries in a symbol
> table) and so I want to automatically replace these by the actual constant
> value (the location in the c++ table).  To recap:  a macro that would
> convert
> (define (foo x)   (g  (f 42) (f x) (f 43))
> into
> (define c42 (f 42))
> (define c43 (f 43))
> (define (foo x) (g c42 (f x) c43))
> so that guild can treat c42 and c43 as constants (boxes, I guess).
> -- Linas
> On Sat, Jan 11, 2020 at 8:39 AM Matt Wette <address@hidden> wrote:
>> On 1/10/20 2:36 PM, Linas Vepstas wrote:
>> > So, I've got lots of C code wrapped up in guile, and I'd like to declare
>> > many of these functions to be pure functions, side-effect-free, thus
>> > hopefully garnering some optimizations.  Is this possible? How would I
>> do
>> > it? A cursory google-search reveals no clues.
>> >
>> > To recap, I've got functions f and g that call into c++, but are pure
>> (i.e.
>> > always return the same value for the same arguments).   I've got
>> > user-written code that looks like this:
>> >
>> > (define (foo x)
>> >      (g  (f 42) (f x) (f 43))
>> >
>> > and from what I can tell, `f` is getting called three times whenever the
>> > user calls `foo`. I could tell the user to re-write their code to cache,
>> > manually: viz:
>> >
>> > (define c42 (f 42))
>> > (define c43 (f 43))
>> > (define (foo x) (g c42 (f x) c43))
>> >
>> > but asking the users to do this is .. cumbersome.  And barely worth it:
>> `f`
>> > takes under maybe 10 microseconds to run; so most simple-minded caching
>> > stunts don't pay off. But since `foo` is called millions/billions of
>> times,
>> > I'm motivated to find something spiffy.
>> >
>> > Ideas? suggestions?
>> >
>> > -- Linas
>> read this:
>> and look at
> --
> cassette tapes - analog TV - film cameras - you

cassette tapes - analog TV - film cameras - you

reply via email to

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