| 1 |
On Sat, 2004-07-10 at 19:08, Alexander Mieland wrote: |
| 2 |
> ACK. |
| 3 |
> it's surely in our mind to provide as much information as we can. I'm also |
| 4 |
> planning on a second dedicated machine, which has a Pentium 4 with |
| 5 |
> HT-technology to provide the SMP-part of the merge-times. In the future, |
| 6 |
> if all is running and the response of the users is good enough, we hope |
| 7 |
> that we can also provide the merge-times for other architectures than |
| 8 |
> x86. |
| 9 |
|
| 10 |
Trust me when I tell you that a P4 w/ HT is *nowhere* near the speed of |
| 11 |
true SMP. You're better off going with your arbitrary calculations |
| 12 |
below. |
| 13 |
|
| 14 |
While I do think this information is useful, I still think the best |
| 15 |
method is to come up with a new number, rather than time. A good one |
| 16 |
(stolen from LFS) is the BU or Bash Unit. The time it takes to compile |
| 17 |
bash is always 1BU. |
| 18 |
|
| 19 |
SMP is ignored, since it skews the results. So would distcc... The idea |
| 20 |
is not to even try to give the exact time for emerging things for |
| 21 |
everybody, but rather to have a strong baseline "average" that hits most |
| 22 |
people. |
| 23 |
|
| 24 |
> By the way, as long as we dont have a second machine with smp-support, it |
| 25 |
> should be possibly to get reasonably accurate results if we multiply the |
| 26 |
> number of cpus and then divide through a factor like 1.2. You can test |
| 27 |
> it, it should be reasonably accurate. |
| 28 |
> |
| 29 |
> But as I said, we are planning on a second machine with smp and also on |
| 30 |
> merge-time information for other architectures. |
| 31 |
|
| 32 |
-- |
| 33 |
Chris Gianelloni |
| 34 |
Release Engineering QA Manager/Games Developer |
| 35 |
Gentoo Linux |
| 36 |
|
| 37 |
Is your power animal a pengiun? |
| 38 |
|
| 39 |
|
| 40 |
-- |
| 41 |
gentoo-dev@g.o mailing list |
Archives