unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neil@ossau.homelinux.net>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-devel@gnu.org
Subject: Re: our benchmark-suite
Date: Sat, 28 Apr 2012 23:09:35 +0200	[thread overview]
Message-ID: <87aa1vzhps.fsf@neil-laptop.ossau.uklinux.net> (raw)
In-Reply-To: <874ns77dh6.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 25 Apr 2012 22:39:33 +0200")

ludo@gnu.org (Ludovic Courtès) writes:

>> My proposal is to rebase the iteration count in 0-reference.bm to run
>> for 0.5s on some modern machine, and adjust all benchmarks to match,
>> removing those benchmarks that do not measure anything useful.
>
> Sounds good.  However, adjusting iteration counts of the benchmarks
> themselves should be done rarely, as it breaks performance tracking like
> <http://ossau.homelinux.net/~neil/bm_master_i.html>.
>
>> Finally we should perhaps enable automatic scaling of the iteration
>> count.  What do folks think about that?
>>
>> On the positive side, all of our benchmarks are very clear that they are
>> a time per number of iterations, and so this change should not affect
>> users that measure time per iteration.
>
> If the reported time is divided by the global iteration count, then
> automatic scaling of the global iteration count would be good, yes.

For http://ossau.homelinux.net/~neil I do still have all of the raw data
including iteration counts, so I could easily implement dividing by the
iteration count, and hence allow for future iteration count changes.

Is there any downside from doing that?  (I don't think so.)

Regards,
        Neil



  reply	other threads:[~2012-04-28 21:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-23  9:22 our benchmark-suite Andy Wingo
2012-04-24  8:26 ` Andy Wingo
2012-04-25 20:39 ` Ludovic Courtès
2012-04-28 21:09   ` Neil Jerram [this message]
2012-05-02 21:24     ` Ludovic Courtès
2012-05-04 21:43       ` Neil Jerram
2012-05-07 14:38         ` Ludovic Courtès
2012-05-15 20:48         ` Andy Wingo
2012-05-19 21:54           ` Neil Jerram
2012-05-16 17:01   ` Andy Wingo
2012-05-16 21:01     ` 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=87aa1vzhps.fsf@neil-laptop.ossau.uklinux.net \
    --to=neil@ossau.homelinux.net \
    --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).