[gentoo-dev] compile time statistics

[gentoo-dev] compile time statistics

[Rutger Lubbers]

People,

This mail is about a question. The question is "how long does package x.y.z 
take to compile on my machine?" Now my idea is, we have the emerge.log file 
and can obtain some data from it, so we might "predict" that compile time for 
that user.

To get a fairly good prediction I need data. To get data I perhaps need a 
prediction. Which needs data. So at the moment I don't know what to do. 

One part I have finished right now, I can get the compile times from the 
emerge.log and submit it to a central database (see http://ripat.xs4all.nl).
Some "basic" querying I can do too.

My questions to you is:
- would this be a nice feature to have?
- would you be willing to provide me with compile time statistics?
- do you have any hints / ideas what I can do to get this from a no dataless 
project to a data having project?

Thanks,


Rutger Lubbers


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Chris Gianelloni]

emerge splat && splat -s openoffice | grep Average
	Average Time:  7 hours, 17 minutes, and 59 seconds


On Fri, 2003-07-25 at 13:56, Rutger Lubbers wrote:
> People,
> 
> This mail is about a question. The question is "how long does package x.y.z 
> take to compile on my machine?" Now my idea is, we have the emerge.log file 
> and can obtain some data from it, so we might "predict" that compile time for 
> that user.
> 
> To get a fairly good prediction I need data. To get data I perhaps need a 
> prediction. Which needs data. So at the moment I don't know what to do. 
> 
> One part I have finished right now, I can get the compile times from the 
> emerge.log and submit it to a central database (see http://ripat.xs4all.nl).
> Some "basic" querying I can do too.
> 
> My questions to you is:
> - would this be a nice feature to have?
> - would you be willing to provide me with compile time statistics?
> - do you have any hints / ideas what I can do to get this from a no dataless 
> project to a data having project?
> 
> Thanks,
> 
> 
> Rutger Lubbers
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Chris Gianelloni
Developer, Gentoo Linux


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Svyatogor]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

I was actually thinking of making this proposal :)
Just a small comment. In LFS you can find estimate compile time in SBU
(Standart Bash Units - time required to compile bash). It would be nice
if we could include this kind of information into ebuild. Any ideas on
whether that would be possible to do?

В ?? 25.07.2003, в 20:56, Rutger Lubbers пишет:
> People,
> 
> This mail is about a question. The question is "how long does package x.y.z 
> take to compile on my machine?" Now my idea is, we have the emerge.log file 
> and can obtain some data from it, so we might "predict" that compile time for 
> that user.
> 
> To get a fairly good prediction I need data. To get data I perhaps need a 
> prediction. Which needs data. So at the moment I don't know what to do. 
> 
> One part I have finished right now, I can get the compile times from the 
> emerge.log and submit it to a central database (see http://ripat.xs4all.nl).
> Some "basic" querying I can do too.
> 
> My questions to you is:
> - would this be a nice feature to have?
> - would you be willing to provide me with compile time statistics?
> - do you have any hints / ideas what I can do to get this from a no dataless 
> project to a data having project?
> 
> Thanks,
> 
> 
> Rutger Lubbers
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Let the Force be with us!
Sergey Kuleshov <svyatogor@gentoo.org>
Pulic Key: http://dev.gentoo.org/~sergey/gentoo-gpg

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] compile time statistics

[Rutger Lubbers]

I believe that that is possible... That's why I started this.
Only getting data into the ebuilds... thats something else... 
I could obtain data for a package class (net-www) or a package 
(net-www/mozilla) or for a version (net-www/mozilla-0.0.1-alpha). 
Now to port that data back.... thats difficult... perhaps emerge sync should 
get the data for your cpu type and we should modify emerge so that it takes 
advantage of that info.....

> I was actually thinking of making this proposal :)
> Just a small comment. In LFS you can find estimate compile time in SBU
> (Standart Bash Units - time required to compile bash). It would be nice
> if we could include this kind of information into ebuild. Any ideas on
> whether that would be possible to do?


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Werner Van Belle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hmmm,

Altough it's a nice proposal that would be really usefull, I still think there 
are some serious problems involved. Compilation time is non lineair. 
Depending on how much cache, how much memory, how fast your hard-disk is, 
what your bus-speed is and above all, what the user is doing at the same time 
while upgrading his machine will seriously impact compilation time. All of 
these factors are very difficult to take into account. 

With kind regards, 

Werner,-

On Friday 25 July 2003 21:13, Svyatogor wrote:
> I was actually thinking of making this proposal :)
> Just a small comment. In LFS you can find estimate compile time in SBU
> (Standart Bash Units - time required to compile bash). It would be nice
> if we could include this kind of information into ebuild. Any ideas on
> whether that would be possible to do?
>
> В ?? 25.07.2003, в 20:56, Rutger Lubbers пишет:
> > People,
> >
> > This mail is about a question. The question is "how long does package
> > x.y.z take to compile on my machine?" Now my idea is, we have the
> > emerge.log file and can obtain some data from it, so we might "predict"
> > that compile time for that user.
> >
> > To get a fairly good prediction I need data. To get data I perhaps need a
> > prediction. Which needs data. So at the moment I don't know what to do.
> >
> > One part I have finished right now, I can get the compile times from the
> > emerge.log and submit it to a central database (see
> > http://ripat.xs4all.nl). Some "basic" querying I can do too.
> >
> > My questions to you is:
> > - would this be a nice feature to have?
> > - would you be willing to provide me with compile time statistics?
> > - do you have any hints / ideas what I can do to get this from a no
> > dataless project to a data having project?
> >
> > Thanks,
> >
> >
> > Rutger Lubbers
> >
> >
> > --
> > gentoo-dev@gentoo.org mailing list

- -- 
Werner,-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/IXxZxiU3uL/NdUYRAsAAAJ9wW5Euyazi7SAHeXi8ZXClQQG2ewCgjMHU
WQ//loK+G6T/DpBToJF0gPI=
=bWGf
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Håvard Wall]

Werner Van Belle wrote:
> Altough it's a nice proposal that would be really usefull, I still think there 
> are some serious problems involved. Compilation time is non lineair. 
> Depending on how much cache, how much memory, how fast your hard-disk is, 
> what your bus-speed is and above all, what the user is doing at the same time 
> while upgrading his machine will seriously impact compilation time. All of 
> these factors are very difficult to take into account. 

I believe gentoo-stats is already sampling a lot of the needed 
information. An estimate could primarly be based on some "major" 
factors; perhaps cpu-type and clock frequency. Then, if enough 
statistics is available for the current architecture, on other settings 
as well, sucb as -O flags and size of main memory (MAKEOPTS?). A kind of 
hierarchical estimate... Could perhaps be hard to implement in practice 
though (?).

But I believe there probably is some limited set of factors that could 
provide a reasonably good estimate.

--
hw


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1251 bytes --]

On Saturday 26 July 2003 10:56 am, Håvard Wall wrote:
> I believe gentoo-stats is already sampling a lot of the needed
> information. An estimate could primarly be based on some "major"
> factors; perhaps cpu-type and clock frequency. Then, if enough
> statistics is available for the current architecture, on other settings
> as well, sucb as -O flags and size of main memory (MAKEOPTS?). A kind of
> hierarchical estimate... Could perhaps be hard to implement in practice
> though (?).
>
> But I believe there probably is some limited set of factors that could
> provide a reasonably good estimate.

Whoever actually implements these ideas, please don't forget that you need a 
solution for capturing accurate stats on machines that use Portage's distcc 
support.  Because otherwise, your stats will not be as accurate as you'd 
like.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Upcoming packages list                http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] compile time statistics

[Håvard Wall]

Stuart Herbert wrote:
> Whoever actually implements these ideas, please don't forget that you need a 
> solution for capturing accurate stats on machines that use Portage's distcc 
> support.  Because otherwise, your stats will not be as accurate as you'd 
> like.
Woah! So true. And what about ccache? That could really mess up 
statistics! I guess you would have to disregard such timings...

-- 
hw



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Rutger Lubbers]

> > I believe gentoo-stats is already sampling a lot of the needed
> > information. An estimate could primarly be based on some "major"
> > factors; perhaps cpu-type and clock frequency. Then, if enough
> > statistics is available for the current architecture, on other settings
> > as well, sucb as -O flags and size of main memory (MAKEOPTS?). A kind of
> > hierarchical estimate... Could perhaps be hard to implement in practice
> > though (?).
> >
> > But I believe there probably is some limited set of factors that could
> > provide a reasonably good estimate.
>
> Whoever actually implements these ideas, please don't forget that you need
> a solution for capturing accurate stats on machines that use Portage's
> distcc support.  Because otherwise, your stats will not be as accurate as
> you'd like.

Yeah, this crossed my mind also. I believe that using distcc would "void" 
those stats, perhaps we can store it and maybe possible analyze if we can use 
any of it.

Rutger


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Chris Gianelloni]

On Sat, 2003-07-26 at 05:56, Håvard Wall wrote:
> information. An estimate could primarly be based on some "major" 
> factors; perhaps cpu-type and clock frequency. Then, if enough 
> statistics is available for the current architecture, on other settings 
> as well, sucb as -O flags and size of main memory (MAKEOPTS?). A kind of 
> hierarchical estimate... Could perhaps be hard to implement in practice 
> though (?).

To be anywhere near the correct answer you would need to know:
- CPU type
- CPU speed
- Number of CPUs
- MAKEOPTS
- USE flags
- Some of the CFLAGS, particularly -march and -O

You would also have to cancel out any data gotten from a machine with
distcc or ccache enabled, since those will throw your accuracy way off. 
For example, I have a P166MMX machine running Gentoo on 32MB of RAM.  It
runs fine.  How is it setup?  Simple, I have it setup for distcc with
MAKEOPTS=-j4 and DISTCC_HOSTS="smpbox1/2 smpbox2/2 othermachine".  It
pretty much never does any compiling locally.  It can compile
applications almost as fast as working with one of my SMP machines.  The
data would be completely off on this machine if it were to be submitted.

-- 
Chris Gianelloni
Developer, Gentoo Linux


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Stewart Honsberger]

Chris Gianelloni wrote:
> To be anywhere near the correct answer you would need to know:
> - CPU type
> - CPU speed
> - Number of CPUs
> - MAKEOPTS
> - USE flags
> - Some of the CFLAGS, particularly -march and -O

I'm seeing a matrix of information stored in a database. With Gentoo 
being so dynamic, we could have a stats component check each of the 
variables and take a sampling of similar system configurations in the 
database.

What I forsee (correct me if this has already been discussed; I'm only 
getting around to reading this list seriously now after some time 
working long hours) goes along the lines of this;

Integrate stats into Portage somehow so that it becomes transparent. 
Perhaps even a module that can be merged separately of Portage. 
Otherwise, were it merged directly into Portage itself, we have a 
make.conf flag that enables stats. We inform the user, naturally, what 
stats will be taken, how they will be processed, and where they will be 
stored. We inform users that stats are a two-way street. Much like the 
GPL, you can't take without giving. If you want a figure on how long 
each item should take to compile, you have to permit the sending of how 
long it TOOK to compile on your system to add to the numbers in the 
database.

As with any statistical reporting, I also see a system whereby numbers 
that are really off-base with the rest of the numbers in the same 
category be disgarded. If my Athlon XP 1800+ system reports that it took 
 >48 or <2 hours to compile OpenOffice, for example, that number would 
be thrown away as somehow invalid.

In this matrix we could include a variable for 'ccache', which would 
give us a good baseline of how well ccache helps compile times. For 
example, my system some time ago would be reported / queried using;

CPU = AMD Athlon 1800+
RAM = 512MB DDR
CC = gcc (GCC) 3.2.2
CFLAGS = CFLAGS="-march=athlon-xp -Os -pipe -mfpmath=sse,387"
CCACHE = yes

Perhaps the logic used in "emerge -v {package}" could be incorporated to 
find systems with similar USE flags. Obviously nomozillamail et al. will 
decrease Mozilla's compile time.

(Depositing $0.02 on table)

-- 
Stewart Honsberger
Gentoo Developer
http://www.snerk.org/


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Chris Gianelloni]

Creating your own unit of measure is probably the best way to go about
it.  There are simply so many variables that can affect the build time
of an ebuild... CPU type/speed, number of CPUs, USE flags, CFLAGS.  We
would definitely have to base the default USE/CFLAGS of the GRP.

On Fri, 2003-07-25 at 15:13, Svyatogor wrote:
> I was actually thinking of making this proposal :)
> Just a small comment. In LFS you can find estimate compile time in SBU
> (Standart Bash Units - time required to compile bash). It would be nice
> if we could include this kind of information into ebuild. Any ideas on
> whether that would be possible to do?
> 
> В ?? 25.07.2003, в 20:56, Rutger Lubbers пишет:
> > People,
> > 
> > This mail is about a question. The question is "how long does package x.y.z 
> > take to compile on my machine?" Now my idea is, we have the emerge.log file 
> > and can obtain some data from it, so we might "predict" that compile time for 
> > that user.
> > 
> > To get a fairly good prediction I need data. To get data I perhaps need a 
> > prediction. Which needs data. So at the moment I don't know what to do. 
> > 
> > One part I have finished right now, I can get the compile times from the 
> > emerge.log and submit it to a central database (see http://ripat.xs4all.nl).
> > Some "basic" querying I can do too.
> > 
> > My questions to you is:
> > - would this be a nice feature to have?
> > - would you be willing to provide me with compile time statistics?
> > - do you have any hints / ideas what I can do to get this from a no dataless 
> > project to a data having project?
> > 
> > Thanks,
> > 
> > 
> > Rutger Lubbers
> > 
> > 
> > --
> > gentoo-dev@gentoo.org mailing list
-- 
Chris Gianelloni
Developer, Gentoo Linux


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Håvard Wall]

Why not log compile times with emerge, and let the statistics be sent 
with gentoo-statistics? As far as I can see 
(http://stats.gentoo.org/statistics-profiles.htm), there is several 
thousands of users providing information with gentoo-statistics. Could 
provide a fairly good base for calculations.

Rutger Lubbers wrote:
> People,
> 
> This mail is about a question. The question is "how long does package x.y.z 
> take to compile on my machine?" Now my idea is, we have the emerge.log file 
> and can obtain some data from it, so we might "predict" that compile time for 
> that user.
> 
> To get a fairly good prediction I need data. To get data I perhaps need a 
> prediction. Which needs data. So at the moment I don't know what to do. 
> 
> One part I have finished right now, I can get the compile times from the 
> emerge.log and submit it to a central database (see http://ripat.xs4all.nl).
> Some "basic" querying I can do too.
> 
> My questions to you is:
> - would this be a nice feature to have?
> - would you be willing to provide me with compile time statistics?
> - do you have any hints / ideas what I can do to get this from a no dataless 
> project to a data having project?
> 
> Thanks,
> 
> 
> Rutger Lubbers
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
> 



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[FRLinux]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

I think that is the right way to do it since we explain in the last
install process of the documentation what gentoo-stats does. Let's just
add a line about compile times and we should be pretty much sorted.

Steph

Le sam 26/07/2003 à 12:35, Håvard Wall a écrit :
> Why not log compile times with emerge, and let the statistics be sent 
> with gentoo-statistics? As far as I can see 
> (http://stats.gentoo.org/statistics-profiles.htm), there is several 
> thousands of users providing information with gentoo-statistics. Could 
> provide a fairly good base for calculations.
> 


[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] compile time statistics

[Rutger Lubbers]

Good idea, now does anybody know how to contact Maik Schreiber 
<blizzy@gentoo.org>? 
I tried mailing that adres, but I get an error, saying it cannot be delivered.

Anybody any ideas? 

Rutger
 
--- email msg
Hi. This is the qmail-send program at gentoo.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<blizzy@dev.gentoo.org>:
64.5.62.82 does not like recipient.
Remote host said: 550 unknown user
Giving up on 64.5.62.82.
--- end email msg

> I think that is the right way to do it since we explain in the last
> install process of the documentation what gentoo-stats does. Let's just
> add a line about compile times and we should be pretty much sorted.
>
> Steph
>
> Le sam 26/07/2003 à 12:35, Håvard Wall a écrit :
> > Why not log compile times with emerge, and let the statistics be sent
> > with gentoo-statistics? As far as I can see
> > (http://stats.gentoo.org/statistics-profiles.htm), there is several
> > thousands of users providing information with gentoo-statistics. Could
> > provide a fairly good base for calculations.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Lisa Marie Seelye]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On Sat, 2003-07-26 at 10:50, Rutger Lubbers wrote:
> Good idea, now does anybody know how to contact Maik Schreiber 
> <blizzy@gentoo.org>? 
> I tried mailing that adres, but I get an error, saying it cannot be delivered.
> 


If I recall correctly, blizzy resigned her Gentoo dev status.

-- 
Regards,
-Lisa
<Vix ulla tam iniqua pax, quin bello vel aequissimo sit potior>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] compile time statistics

[Tal Peer]

On Sat, 26 Jul 2003, Rutger Lubbers wrote:

> Good idea, now does anybody know how to contact Maik Schreiber 
> <blizzy@gentoo.org>? 
> I tried mailing that adres, but I get an error, saying it cannot be delivered.
> 
> Anybody any ideas? 
> 
> Rutger
>  

Blizzy is no longer a developer.

--
Tal Peer
Gentoo Developer

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x253D2947
Key Fingerprint: C0B1 D91D 7323 6C0F 227A CBD6 D635 E53D 253D 2947


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] compile time statistics

[Rutger Lubbers]

> On Sat, 26 Jul 2003, Rutger Lubbers wrote:
> > Good idea, now does anybody know how to contact Maik Schreiber
> > <blizzy@gentoo.org>?
> > I tried mailing that adres, but I get an error, saying it cannot be
> > delivered.
> >
> > Anybody any ideas?
> >
> > Rutger
>
> Blizzy is no longer a developer.

ok, that explains that bounce. :-)

Who maintains the gentoo-stats package then?
Who maintains the stats.gentoo.org machine then? 

Or should I add the stuff I need to the gentoo-stats package and duplicate 
part of the data? This is not desirable I think.

Rutger


--
gentoo-dev@gentoo.org mailing list