chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] efficient bytevector-ieee-double-native-ref


From: Alaric Snell-Pym
Subject: Re: [Chicken-users] efficient bytevector-ieee-double-native-ref
Date: Tue, 17 Feb 2009 16:09:17 +0000


On 17 Feb 2009, at 3:47 pm, Eduardo Cavazos wrote:

Eduardo Cavazos wrote:

(define (bytevector-ieee-double-native-ref blob i)
 (f64vector-ref (blob->f64vector/shared blob) i))

So the obvious problem here is the conversion is going to impact
performance.

If somebody who is familiar with Chicken internals can suggest a way
to extract an 'f64' element from a blob directly, I think I'll be
set. :-)

Hello!

There's a few ways. For a start, you can always make shared vectors,
as you do above - since they share the storage, creating them should
be pretty efficient.

Or you can write a C function that does tevector-ieee-double-native-
ref; see the section in the manual about accessing foreign functions -
a blob is passed to the C world as a pointer, and you can do
((double*)ptr)[index] in C and lo, a double will emerge. (IIRC, an f64
is a double, right?).

But, in the long run, I think Something Must Be Done.

Personally, I feel that "bytevector" is a bad idea - vector-of-bytes
is just one possible interpretation of a region of memory. I like the
idea of a "blob" that has no inherent access primitives - but that has
ways of making 'aliases' to regions of it that have types.

I made a proposal about this a while ago - I also wanted to avoid
having to copy memory blocks returned by foreign code into blobs for
use in the Chicken world; my proposal was to rewrite chicken's blobs
so that they may either be a heap-allocated region (for small blobs)
or an arbitrary pointer and length with a custom finalizer function
(which can handle calling free() on malloc-ed blocks). Having thus
abstracted out the management of the memory block, the underlying blob
system could then form a basis for other large-data types - such as
SRFI-4 vectors or R6RS bytevectors (if you must). These types would
all keep a reference to a blob used as the "backing store", then a
base index and a length, so they can refer to just a subregion of the
blob. It might also be worth storing a custom stride that's used as
the multiplier when referencing rather than just sizeof(element), so
that it'd be possible to make:

1) A vector that represents a row *or* column out of a 2D array - or
any higher dimension
2) A vector that goes *backwards* without having to reverse it
explicitly, by having a negative stride
3) An infinite vector of the same element (by having a zero stride and
a MAXINT length)

Then it'd be possible to make sub*vector/shared functions that just
make a new vector referring to the same underlying blob, but having
different start/length.

ABS

--
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/?author=4






reply via email to

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