all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Julien Lepiller <julien@lepiller.eu>,
	Jacob Hrbek <kreyren@rixotstudio.cz>,
	Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: Proposal: Build timers
Date: Wed, 24 Nov 2021 12:31:31 +0100	[thread overview]
Message-ID: <86v90hu6wc.fsf@gmail.com> (raw)
In-Reply-To: <E7B31DF4-0D30-4628-BDB0-06ED0D678627@lepiller.eu>

Hi,

On Tue, 23 Nov 2021 at 18:50, Julien Lepiller <julien@lepiller.eu> wrote:
> Do we even care that much about accuracy? I don't really care that the
> build takes 30 or 31 seconds, or even 1 minute, but I certainly care
> whether it takes 30s or 3h. I think this is also what SBUs give you: a
> rough estimate of which build is longer than the other. I think a
> simple proportionality relation would work well enough in most common
> cases. It might be quite off on a super computer, but who cares,
> really?

What if it takes 3h and the prediction says 2h?

Which build is longer than the other is already provided by data in the
build farm.  I agree it is hard to find and one improvement could be
that Cuirass or Build Coordinator exposes this data (I think it is not
so easy because for instance Cuirass knows derivation and package,
somehow and IIUC :-)).

Who cares to know how longer it would locally take if the substitute is
available*? ;-) Because at some point, this SBU should be computed.

Anyway, what would be the typical error?

For instance, I propose that we collectively send the timings of
packages: bash, gmsh, julia, emacs, vim; or any other 5 packages for
x86_64 architecture.  Then we can compare typical errors between
prediction and real, i.e., evaluate “accuracy“ for SBU and then decide
if it is acceptable or not. :-)



*available: which is not the case for LFS, though.


Cheers,
simon


  reply	other threads:[~2021-11-24 11:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-22 22:02 Proposal: Build timers Jacob Hrbek
2021-11-23  1:06 ` zimoun
2021-11-23  6:21   ` Jacob Hrbek
2021-11-23 11:56     ` zimoun
2021-11-23 14:39       ` Jacob Hrbek
2021-11-24 11:35         ` zimoun
2021-11-25  4:00           ` Jacob Hrbek
2021-11-23 12:05     ` Julien Lepiller
2021-11-23 16:23       ` zimoun
2021-11-23 20:09 ` Liliana Marie Prikler
2021-11-23 21:31   ` Jacob Hrbek
2021-11-23 21:35   ` Jacob Hrbek
2021-11-23 23:50     ` Julien Lepiller
2021-11-24 11:31       ` zimoun [this message]
2021-11-24 20:23         ` Vagrant Cascadian
2021-11-24 21:50           ` zimoun
2021-11-25  4:03           ` Jacob Hrbek
2021-11-25  5:21             ` Liliana Marie Prikler
2021-11-25 10:23             ` zimoun

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

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

  git send-email \
    --in-reply-to=86v90hu6wc.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=julien@lepiller.eu \
    --cc=kreyren@rixotstudio.cz \
    --cc=liliana.prikler@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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.