unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Noah Lavine <noah.b.lavine@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 12033@debbugs.gnu.org, nalaginrut <nalaginrut@gmail.com>
Subject: bug#12033: closed (Re: bug#12033: format should be faster)
Date: Tue, 21 Aug 2012 07:52:39 -0400	[thread overview]
Message-ID: <CA+U71=ObOYcqrLAWjoodRC-fmh3rFC_MJpiiiOK6HdkUF1zngA@mail.gmail.com> (raw)
In-Reply-To: <87ipccqxvq.fsf@gnu.org>

Hi,

On Tue, Aug 21, 2012 at 7:37 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi,
>
> Noah Lavine <noah.b.lavine@gmail.com> skribis:
>
>>> --------------------code-------------------
>>> scheme@(guile-user)> ,profile (let lp ((i 10000)) (if (> i 0) (begin
>>> (format #f "0x~2'0x, 0x~2'0x, 0x~2'0x" i i i) (lp (1- i)))))
>>> %     cumulative   self
>>> time   seconds     seconds      name
>>> 22.58      0.56      0.23  tilde-dispatch
>>> 12.90      1.00      0.13  format
>>> 12.90      0.13      0.13  number->string
>>>   8.06      0.13      0.08  format:out-char
>>>   4.84      0.80      0.05  format:format-work
>>> --------------------end-------------------
>>>
>>> In this case, we tried "0x~2'0x" and it's so slow that we can't bare it.
>>> i=10000 is fast, but we need (* 600 80000)
>>> And we found that "tilde-dispatch" cost too much. Is there any possible
>>> to optimize it?
>>
>> It seems clear that in this case, Guile "should" know how to dispatch
>> on the format string just once, outside of the loop, instead of doing
>> it in every iteration.
>
> I think Andy would say: “inline cache!”.  :-)
>
>> What do people think of declaring format as a macro?
>
> That’s tempting, but it breaks the ABI (so not for 2.0), and it breaks
> for users who do ((@ (ice-9 format) format) #t "foo"), for instance.
>
> Maybe we could have a ‘format*’ macro that does as much as possible of
> the dispatch at compile-time?  The difficulty would be to factorize
> dispatch code with the ‘format’ procedure.

What I was hoping to do is have a macro that is also
identifier-syntax, so if format is used in a way that can't be
macroexpanded, it falls back to the procedure. I think I've seen an
example of this before, but I'm not sure where.

> Another (IMO less elegant) option would be to have an optional compiler
> optimization pass that would do something similar.

Yes, but I agree it's less elegant, because it splits the format logic
across two pieces of code, and puts some of it in the compiler, which
shouldn't really have to know about it. This is a problem that I'd
like to solve more generally, by letting functions tell the compiler
how to optimize themselves, but that's a big project, and using a
macro seemed like a much simpler way to get the same effect here.

However, I wonder if the partial evaluator would actually solve this
problem if it knew how to do cross-module inlining. That's another big
project, but it could be a way to solve this problem and keep format
as a function.

> Thanks,
> Ludo’.

Thanks,
Noah





  reply	other threads:[~2012-08-21 11:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-23  6:11 bug#12033: format should be faster nalaginrut
2012-08-18 22:19 ` Ludovic Courtès
2012-08-20  6:27   ` nalaginrut
2012-08-20 21:51     ` Ludovic Courtès
     [not found] ` <handler.12033.D12033.134549952018901.notifdone@debbugs.gnu.org>
2012-08-20 22:37   ` bug#12033: closed (Re: bug#12033: format should be faster) Ludovic Courtès
2012-08-21  2:50     ` nalaginrut
2012-08-21  3:00       ` Noah Lavine
2012-08-21  3:32         ` Ian Price
2012-08-21 11:37         ` Ludovic Courtès
2012-08-21 11:52           ` Noah Lavine [this message]
2012-08-21 13:40             ` Ludovic Courtès
2012-08-21 19:35           ` Andy Wingo
2012-08-23  3:23             ` nalaginrut
2012-08-23 21:55               ` Ludovic Courtès

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='CA+U71=ObOYcqrLAWjoodRC-fmh3rFC_MJpiiiOK6HdkUF1zngA@mail.gmail.com' \
    --to=noah.b.lavine@gmail.com \
    --cc=12033@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=nalaginrut@gmail.com \
    /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).