[Top][All Lists]
[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.
- [MIT-Scheme-devel] pclsr, Matt Birkholz, 2011/06/22
- [MIT-Scheme-devel] pclsr, Matt Birkholz, 2011/06/22
- Re: [MIT-Scheme-devel] pclsr, Taylor R Campbell, 2011/06/22
- [MIT-Scheme-devel] Faster ports., Matt Birkholz, 2011/06/22
- Re: [MIT-Scheme-devel] Faster ports., Taylor R Campbell, 2011/06/22
- Re: [MIT-Scheme-devel] Faster ports., Matt Birkholz, 2011/06/23
- Re: [MIT-Scheme-devel] Faster ports., Arthur A. Gleckler, 2011/06/23
- Re: [MIT-Scheme-devel] Faster ports., Taylor R Campbell, 2011/06/23
- Re: [MIT-Scheme-devel] Faster ports.,
Matt Birkholz <=
- Re: [MIT-Scheme-devel] Faster ports., Taylor R Campbell, 2011/06/23
- Re: [MIT-Scheme-devel] Faster ports., Taylor R Campbell, 2011/06/24
- Re: [MIT-Scheme-devel] Faster ports., Matt Birkholz, 2011/06/25
- Re: [MIT-Scheme-devel] Faster ports., Taylor R Campbell, 2011/06/25