Prev: Comparing Lisp to Python, what you consider more important: speed or macros.
Next: LispBox - truncated result?
From: Tamas K Papp on 29 Apr 2010 14:46
On Thu, 29 Apr 2010 17:27:14 +0000, Peter Keller wrote:

> Speaking of memcpy, in lisp what is the equivalent of memcpy? replace?
> Hrm... I should use that in a few places I stupidly wrote the byte
> copies with a do loop.

Pretty much. Usually, if you want top speed, it pays to look into
your implementations sources and see what they use, then call that
directly. Or, alternatively, declare array types so that the compiler
will do that for you. Eg look at the transforms related to REPLACE in
SBCL, you will see that it will be heavily optimized when given enough
information.

Tamas
From: Paul Wallich on 29 Apr 2010 16:11
Peter Keller wrote:
> Giovanni Gigante <giov(a)cidoc.iuav.it> wrote:
>>> My question is: This adjustment happens at the _end_ of the array, can I
>>> expand the array at the beginning?
>>
>> Naive idea:
>> what about building a list (you can cons to the beginning of that) and
>> mapping it to an array only when you are done?
>
> That doesn't solve the problem, suppose:
>
> (#(1 2 3) (#4 5 6))
>
> I still have to allocate a 6 element array somewhere to map all of that
> into a single array: #(1 2 3 4 5 6)

Do you know for sure that you can do a better job managing all these
bits than the garbage collector can. If many/most of incoming chunks of
data are short-lived, GC might do better than all the copying.

paul working first, fast later
From: Espen Vestre on 29 Apr 2010 16:31
Peter Keller <psilord(a)merlin.cs.wisc.edu> writes:

> I was just wondering if I had missed something in Lisp's array management
> which would allow me to grow an array at the head of the array. The
> answer is somewhat yes, but I'd have to preallocate the array and that
> means the application code would have to use a special abstraction of
> make-array. There are problems with that I'd rather avoid.

Can't you just use the array as a "growable ring buffer"? If the ring
buffer is full, you grow the array, and you can move the start or the
end pointers into your buffer depending on where you want to add data.

(I use one ring buffer per client in a server I've written, but they're
fixed-size with 30000 elements, because in my case if the clients have
a lag of that many transactions, it's better for the clients if the
server just flushes part of its buffer)
--
(espen)
From: Peter Keller on 29 Apr 2010 20:22
Espen Vestre <espen(a)vestre.net> wrote:
> Peter Keller <psilord(a)merlin.cs.wisc.edu> writes:
>
>> I was just wondering if I had missed something in Lisp's array management
>> which would allow me to grow an array at the head of the array.

This idea I might check out in more detail.... Thanks!

-pete
From: Peter Keller on 29 Apr 2010 20:23
Paul Wallich <pw(a)panix.com> wrote:
> Do you know for sure that you can do a better job managing all these
> bits than the garbage collector can. If many/most of incoming chunks of
> data are short-lived, GC might do better than all the copying.

I don't know for sure, it is just a feeling I have for where a nsaty thing
might happen.

> paul working first, fast later

That is very true, I don't so much want fast, as resident in memory. :)

Thank you all for your suggestions! They have been very helpful!

-pete
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Comparing Lisp to Python, what you consider more important: speed or macros.
Next: LispBox - truncated result?