unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: wip-ports-refactor
Date: Tue, 10 May 2016 18:53:47 +0200	[thread overview]
Message-ID: <87wpn1q2g4.fsf@pobox.com> (raw)
In-Reply-To: <871t5aq7la.fsf@pobox.com> (Andy Wingo's message of "Tue, 10 May 2016 17:02:41 +0200")

On Tue 10 May 2016 17:02, Andy Wingo <wingo@pobox.com> writes:

>   (with-output-to-file "/tmp/testies.txt" (lambda () (do-times #e1e6 (write-char #\a))))

Sorry, I meant #e1e7.  The file really does have 10M characters.
Actually 10M+1 because of a do-times bug :P
>
> This is in a UTF-8 locale.  OK.  So we have 10M "a" characters.  I now
> want to test these things:
>
>   1. peek-char, 1e7 times.
>   2. read-char, 1e7 times.
>   3. lookahead-u8, 1e7 times.  (Call it peek-byte.)
>   4. get-u8, 1e7 times.  (Call it read-byte.)
>
>                        | peek-char | read-char | peek-byte | read-byte
>   ---------------------+-----------+-----------+-----------+----------
>   2.0                  | 0.811s    | 0.711s    | 0.619s    | 0.623s
>   master               | 0.410s    | 0.331s    | 0.428s    | 0.411s
>   port-refactor C      | 0.333s    | 0.358s    | 0.265s    | 0.245s
>   port-refactor Scheme | 1.041s    | 1.820s    | 0.682s    | 0.727s
>
> Again, measurements on my i7-5600U, best of three, --no-debug.
>
> Conclusions:
>
>   1. In Guile master and 2.0, reading is faster than peeking, because it
>      does a read then a putback.  In wip-port-refactor, the reverse is
>      true: peeking fills the buffer, and reading advances the buffer
>      pointers.
>
>   2. Scheme appears to be about 3-4 times slower than C in
>      port-refactor.  It's slower than 2.0, unfortunately.  I am certain
>      that we will get the difference back when we get native compilation
>      but I don't know when that would be.
>
>   3. There are some compiler improvements that could help Scheme
>      performance too.  For example the bit that updates the port
>      positions is not optimal.  We could expose it from C of course.
>
> Note that this Scheme implementation passes ports.test, so there
> shouldn't be any hidden surprises.
>
> I am not sure what to do, to be honest.  I think I would switch to
> Scheme if it let me throw away the C code, but I don't see the path
> forward on that right now due to bootstrap reasons.  I think if I could
> golf `read-char' down to 1.100s or so it would become more palatable.
>
> Andy



  reply	other threads:[~2016-05-10 16:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-06 20:46 wip-ports-refactor Andy Wingo
2016-04-07  4:16 ` wip-ports-refactor Christopher Allan Webber
2016-04-12  8:52   ` wip-ports-refactor Andy Wingo
2016-04-13 14:27     ` wip-ports-refactor Christopher Allan Webber
2016-04-12  9:33 ` wip-ports-refactor Andy Wingo
2016-04-14 14:03 ` wip-ports-refactor Ludovic Courtès
2016-04-17  8:49   ` wip-ports-refactor Andy Wingo
2016-04-17 10:44     ` wip-ports-refactor Ludovic Courtès
2016-04-19  8:00       ` wip-ports-refactor Andy Wingo
2016-04-19 14:15         ` wip-ports-refactor Ludovic Courtès
2016-05-10 15:02     ` wip-ports-refactor Andy Wingo
2016-05-10 16:53       ` Andy Wingo [this message]
2016-05-11 14:00       ` wip-ports-refactor Christopher Allan Webber
2016-05-11 14:23       ` wip-ports-refactor Ludovic Courtès
2016-05-12  8:15         ` wip-ports-refactor Andy Wingo
2016-04-24 11:05 ` wip-ports-refactor Chris Vine
2016-05-10 14:30   ` wip-ports-refactor Andy Wingo
2016-05-11 10:42     ` wip-ports-refactor Chris Vine
2016-05-12  6:16       ` wip-ports-refactor Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wpn1q2g4.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=guile-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).