mit-scheme-devel
[Top][All Lists]
Advanced

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

Re: [MIT-Scheme-devel] Faster ports.


From: Matt Birkholz
Subject: Re: [MIT-Scheme-devel] Faster ports.
Date: Thu, 23 Jun 2011 16:06:59 -0700

> From: Taylor R Campbell <address@hidden>
> Date: Thu, 23 Jun 2011 19:04:55 +0000
> 
> [...] EXTERNAL-STRING-REF -- some bignum arithmetic followed by an
> out-of-line primitive -- is non-negligibly slower than STRING-REF.
> This is not acceptable for, e.g., using OPEN-OUTPUT-OCTETS to
> accumulate a chunk of bits in-memory.

C-peek-uchar can do it (with a fixnum index) withOUT consing a single
drop.  Open-coded:

    ; r40 = alien, r41 = index (both already type-masked)
    (load (r 42) (word (r 40) 2))      ; r42 <- (%alien/high-bits r40)
    (load (r 43) (word (r 40) 3))      ; r43 <- (%alien/low-bits r40)
    (lsh (r 42) half-word-size)
    (and (r 43) type-mask)
    (and (r 42) (r 43))                ; r42 <- address of bytes
    (load (r 45) (byte (r 42) (r 41))) ; r45 <- your u8 (without type code)

Acceptable?

> [...]  That's why I would prefer `octet' for ports -- they have to
> do with exchanging data in well-defined formats with external
> systems.

Fair enough.

>    > - There is no support for memory-mapped I/O [...]
> 
>    Whoa.  Don't get the portability drums started...
> 
> What portability drums?  What serious system in 2011 that MIT Scheme
> is likely to run on doesn't support memory-mapped I/O?

*I* don't have a portashmility drum.  I can't even SPELL portabimini.

> If you look closely, you'll see that SOURCE-OCTET (i.e. READ-U8) is
> integrated.

So... if you wanted characters, you'd tickle the port.  If you wanted
its octets, you'd first get ahold of its octet-source.  Octet-level
work doesn't involve the port.  OK.

>    How did/would you take measurements?
> 
> Simple things such as copying octet-by-octet [...] go from being
> very clearly CPU-bound to being very clearly disk-bound.

Maybe parsing a large file of scheme or xml should be included.  I
don't want a fast cat(1); I want a fast HTML::Tree.  (I also want a
fast uuencode(1), so I probably want both.)  If cpress.scm used
octet-sources we would have a challenging test.  We could compare the
speed of compression using both internal and external buffers.



reply via email to

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