| View previous topic :: View next topic |
| Author |
Message |
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
 Posted: Tue Nov 20, 2018 7:17 am Post subject: Upgrades can take A LOT of time! |
 |
|
Hi.
Disclaimer: this is *not* a rant, I'm reporting my longest compile times just to show them off.
I've just upgraded my main machine. I sat and watch'ed (literally) the whole process. What astounded me the most is that it took far more time for certain packages that I was aware of. I remember back in the days glibc and GCC were the biggest packages, came along Firefox, Seamonkey, Hugin, Xorg... Around 2004 GCC would take about half an hour on the machine I had at that time. Now GCC is not even the slowest to compile, glibc is blazingly fast compared to other packages. The longest package — I sat and watched it for the whole time — is LLVM: one hour and a half! CLANG came just afterwards, about one hour long (IIRC).
Here are the longest times gathered with qlop:
| qlist -CI | sudo xargs qlop -Ct | sort -nk2: | ...
gcc: 804 seconds average for 11 merges
gcc: 804 seconds average for 11 merges
kicad: 2007 seconds average for 6 merges
gcc: 2112 seconds average for 25 merges
gcc: 2112 seconds average for 25 merges
firefox: 2126 seconds average for 33 merges
llvm: 2241 seconds average for 12 merges
llvm: 2241 seconds average for 12 merges
seamonkey: 2360 seconds average for 18 merges
clang: 3617 seconds average for 1 merges
rust: 5875 seconds average for 1 merges |
Note however this report is wrong, i.e. results are off by one line in the unsorted results. Here it's as if rust had taken ~5900 seconds but LLVM actually did. Also, CLANG has the amount of time of LLVM. There must be a bug in qlop as to time calculations. Durations are consistent, just attributed to the wrong package.
If I query rust only I get | Code: | $ sudo qlop -t rust
rust: 2941 seconds average for 2 merges |
Obviously something's not right. But that's not the most important here.
I got those times on a Core i3-2100 @ 3.10GHz. I bought that machine a few years ago and I don't consider replacing it (not even for of Spectre  )
As an anecdote, I'm using ccache. I know there's been some recommendation against using it unconditionally (as it would slow down compilation) but I had two "No space left on device" errors while I upgraded my machine. One was about the filesystem on which I have portage "/distfiles" (no big deal), the other one with my root filesystem, because /usr grew too much and I have /usr with the root filesystem — you don't want things to get worse, there, just stay calm and praise your LVM usage.
The second error occurred while installing Kicad — it had compiled completely. The latter package had taken more than one hour to compile and I was relieved to see emerge --resume take only 15 minutes with Kicad. It's clear *rebuilding* the same package was sped up thanks to ccache by a factor 4-5, it's true. So it's a good use case scenario to apply it. And unconditionally because you might not always know when emerge is going to fail, when disk space is going to lack... in short when Murphy's going to show his pointy nose. And it's when you're going to recompile packages that take hours that you realize you've forgotten ccache .
But ccache is like wine: use it adequately, don't abuse it. I have a 6GB ccache and I don't know if it's wise but it damn helped.
The interesting one thing to notice there is that clang and llvm are mandated by mesa (at least). Given how long it takes to compile makes me wonder though... Not a surprise some of us don't upgrade in months!
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
 |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9677
Location: almost Mile High in the USA
|
| Posted: Tue Nov 20, 2018 7:23 am Post subject: |
|
|
how about typing the category/name
| Code: | # qlop -t dev-lang/rust
rust: 24800 seconds average for 2 merges |
It got me a few times when it averaged in the virtual.
After reenabling distcc, my qlop numbers will be inaccurate once more.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Tue Nov 20, 2018 7:35 am Post subject: |
|
|
| eccerr0r wrote: | | how about typing the category/name[...] |
Aha, good tip indeed. Times are consistent now. However they're still "off by one line". Some reported compile times don't match what I observed so there's still a bug somewhere.
For example:
| ll -t /portage.d/log/: | ...
-rw-rw---- 1 portage portage 183571 15 nov 23:49 sys-libs:compiler-rt-6.0.1:20181115-224858.log
-rw-rw---- 1 portage portage 906159 15 nov 23:48 sys-libs:compiler-rt-sanitizers-6.0.1:20181115-224635.log
-rw-rw---- 1 portage portage 1823239 15 nov 23:46 sys-devel:clang-6.0.1:20181115-214618.log
-rw-rw---- 1 portage portage 3973677 15 nov 22:46 sys-devel:llvm-6.0.1:20181115-201255.log
-rw-rw---- 1 portage portage 2660 15 nov 21:12 sys-power:acpid-2.0.28:20181115-201251.log
-rw-rw---- 1 portage portage 13476 15 nov 21:12 sys-power:acpid-2.0.30:20181115-201238.log
... |
There's about 1.5 hours (~5400 seconds) between acpid-2.0.28 and llvm-6.0.1, which is how much it took to compile the *latter*. Next is clang with exactly one hour. *That* doesn't quite show exactly as is in qlop results.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9677
Location: almost Mile High in the USA
|
| Posted: Tue Nov 20, 2018 7:49 am Post subject: |
|
|
Well, if you average timings, it may not reflect the actual number of the last run.
Clang taking 3617 seconds is just 17 seconds over 1 hour, so that jives.
However your llvm number is an average over 12 merges, for one of my machines it took anywhere from 1223 seconds to 31753 seconds (no idea what circumstances each of these happened...) and the reported average of 6320 seconds will not match either of these.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Tue Nov 20, 2018 8:20 am Post subject: |
|
|
| eccerr0r wrote: | Well, if you average timings, it may not reflect the actual number of the last run.
Clang taking 3617 seconds is just 17 seconds over 1 hour, so that jives.
However your llvm number is an average over 12 merges, for one of my machines it took anywhere from 1223 seconds to 31753 seconds (no idea what circumstances each of these happened...) and the reported average of 6320 seconds will not match either of these. |
You're right. Wait... 31,000 seconds? That's about 9 hours!  (I feel happy on my side )
About rust, here's what shows:
| Code: | -rw-rw---- 1 portage portage 1271 16 nov 02:22 x11-misc:shared-mime-info-1.9:20181116-012204.log
-rw-rw---- 1 portage portage 304 16 nov 02:21 virtual:cargo-1.29.1:20181116-012147.log
-rw-rw---- 1 portage portage 14588 16 nov 02:21 dev-util:cargo-0.30.0:20181116-011251.log
-rw-rw---- 1 portage portage 303 16 nov 02:12 virtual:rust-1.29.1:20181116-011244.log
-rw-rw---- 1 portage portage 450354 16 nov 02:12 dev-lang:rust-1.29.1-r1:20181115-233450.log
-rw-rw---- 1 portage portage 12684 16 nov 00:34 dev-python:requests-2.18.4:20181115-233446.log
-rw-rw---- 1 portage portage 24511 16 nov 00:34 dev-python:requests-2.18.4-r1:20181115-233438.log |
Indeed that's more than one hour and a half . Here are the details for llvm (finally found the right arguments...)
| Code: | # qlop -tg sys-devel/llvm
llvm: Sun Apr 1 09:20:54 2012: 370 seconds
llvm: Tue Sep 18 21:37:01 2012: 387 seconds
llvm: Mon Dec 31 14:08:52 2012: 436 seconds
llvm: Thu Apr 3 10:01:11 2014: 550 seconds
llvm: Fri Nov 7 14:11:36 2014: 549 seconds
llvm: Sat Jun 13 22:51:04 2015: 788 seconds
llvm: Sun Jul 26 22:46:39 2015: 1742 seconds
llvm: Mon Jul 25 06:12:02 2016: 1888 seconds
llvm: Mon Feb 26 08:39:47 2018: 4760 seconds
llvm: Mon Feb 26 14:53:15 2018: 4766 seconds
llvm: Wed May 30 09:01:40 2018: 5059 seconds
llvm: Thu Nov 15 21:12:56 2018: 5603 seconds |
Needless to say it has exploded.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
Muso
Veteran
Joined: 22 Oct 2002
Posts: 1052
Location: The Holy city of Honolulu
|
| Posted: Tue Nov 20, 2018 9:23 am Post subject: |
|
|
| Code: | genlop -t chromium
* www-client/chromium
Thu Nov 15 23:09:29 2018 >>> www-client/chromium-71.0.3578.30
merge time: 4 hours, 31 minutes and 47 seconds.
|
Without the jumbo-build USE flag.
When trying the jumbo-build USE flag with an 8 core CPU and 16 gigs of ram, all ram was eaten and the system locked.
_________________
"You can lead a horticulture but you can't make her think" ~ Dorothy Parker
2021 is the year of the Linux Desktop! |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54214
Location: 56N 3W
|
| Posted: Tue Nov 20, 2018 10:14 am Post subject: |
|
|
rust has its own bundled LLVM, so you actually build LLVM in the course of build rust.
Worse, until recently, it built all LLVM targets too.
That's fixed now.
| Code: | # genlop -t libreoffice
* app-office/libreoffice
Fri Apr 15 04:48:57 2016 >>> app-office/libreoffice-5.1.2.2
merge time: 2 days, 7 hours, 43 minutes and 41 seconds. |
but that's on a 64 bit Raspberry Pi.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Tue Nov 20, 2018 10:45 am Post subject: |
|
|
Damn!
Reminds me of Bryan Lunduke's «Programmers are evil» and «Linux sucks. Forever.»
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9677
Location: almost Mile High in the USA
|
| Posted: Tue Nov 20, 2018 4:43 pm Post subject: |
|
|
Yeah I can't trust my build times as a performance guide. As I experiment with distcc and sometimes I set up -j ( and -l ) with values that conflict with broken distcc, I get really messed up times.
That 31753 second llvm build time may have been one of the times when distcc wasn't working (i.e., I got no helpers) and -j was set to 6 and -l was set to 3, and just that time for some reason I got 6 jobs on this poor 1GB single core computer (incidentally I don't know why -l doesn't always stop at 3, sometimes I've seen it spawn all 6 jobs when the load average drops below 3).
And I left it to run unattended... It swapped and swapped and finally got done in 9 hours...
Dang, I prefer loud hard drives, then I can at least hear when it's crying when asked to do something ridiculous. :(
(Incidentally, this machine appears to have my longest emerge.log history.... going all the way back to 2004... have to save this! :))
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Dwosky
Tux's lil' helper
Joined: 07 Nov 2018
Posts: 135
|
| Posted: Tue Nov 20, 2018 6:04 pm Post subject: |
|
|
That performance its curious, I have the oposite as VinzC, since llvm (which I didn't have it some time ago) compiles more or less quick, but gcc its the one I'm checking its being slower overtime:
| Code: | -> # qlop -tg sys-devel/llvm
llvm: Sun Feb 25 20:21:50 2018: 2417 seconds
llvm: Fri Mar 2 10:53:15 2018: 2381 seconds
llvm: Fri Jun 8 12:31:18 2018: 2369 seconds
llvm: Fri Aug 24 07:41:24 2018: 2588 seconds
llvm: Mon Nov 5 14:47:49 2018: 2602 seconds
llvm: Wed Nov 7 10:07:46 2018: 2590 seconds
llvm: Fri Nov 9 03:48:48 2018: 2613 seconds
llvm: 7 times |
| Code: | -> # qlop -tg sys-devel/gcc
gcc: Fri Oct 17 01:12:51 2014: 1545 seconds
gcc: Fri Oct 17 02:36:21 2014: 1854 seconds
gcc: Wed Oct 29 09:55:30 2014: 1917 seconds
gcc: Wed Apr 8 10:16:49 2015: 1950 seconds
gcc: Wed Jun 3 18:46:49 2015: 1892 seconds
gcc: Wed Sep 2 19:12:58 2015: 1898 seconds
gcc: Mon Oct 12 18:43:10 2015: 2151 seconds
gcc: Wed May 11 19:51:09 2016: 2446 seconds
gcc: Wed Jun 22 20:13:00 2016: 2465 seconds
gcc: Fri Dec 23 19:04:14 2016: 2472 seconds
gcc: Fri Apr 21 11:48:36 2017: 3227 seconds
gcc: Sat Sep 30 11:04:46 2017: 3514 seconds
gcc: Fri Nov 24 10:44:14 2017: 4021 seconds
gcc: Fri Dec 1 10:03:36 2017: 4027 seconds
gcc: Fri Dec 1 14:45:51 2017: 4003 seconds
gcc: Thu Jan 18 11:49:29 2018: 3680 seconds
gcc: Fri Jun 22 06:44:36 2018: 4204 seconds
gcc: Thu Nov 8 23:16:21 2018: 4459 seconds
gcc: 18 times |
In my case I'm running an i3-3220T, which its a little slower than VinzC's i3-2100 |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9677
Location: almost Mile High in the USA
|
| Posted: Tue Nov 20, 2018 6:47 pm Post subject: |
|
|
Within the same time period, those versions should all be similar, your llvm history is less than 1 year. Even them you still see a 200 second increase - over 3 minutes - over that year. It's no explosion but it's going up.
But yes you can see your gcc history of 4 years going up and up. Consider that the trend.
My emerge.log history is kind of messed up as I've also even upgraded CPUs, RAM, motherboards, and even hard drives while keeping the same emerge.log on some machines ... so even if I wasn't messing with distcc, these aren't very useful information :)
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Mon Jun 17, 2019 6:28 pm Post subject: |
|
|
Here's an update. I think I'm going insane!
I started upgrading my laptop again today and I was staring at GCC 8.3: it started around 17:40, finished around 20:20, i.e. 10,080 seconds! Almost 3 f****** hours! All records exploded!? I just can't believe that!
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Mon Jun 17, 2019 6:34 pm Post subject: |
|
|
With each major version of gcc it takes longer
sys-devel/gcc-4.9.4
merge time: 21 minutes and 51 seconds.
sys-devel/gcc-7.3.0-r3
merge time: 33 minutes and 40 seconds.
sys-devel/gcc-8.2.0-r6
merge time: 41 minutes and 23 seconds.
This is on the desktop 1/2 again to twice as long for the laptop
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10587
Location: Somewhere over Atlanta, Georgia
|
| Posted: Mon Jun 17, 2019 6:36 pm Post subject: |
|
|
How many cores? It has been taking longer and longer. For grain-of-salt comparison, on my 24-core Xeon: | Code: | ~ $ genlop -t --date last month gcc
* sys-devel/gcc
Fri Jun 7 18:25:25 2019 >>> sys-devel/gcc-8.3.0-r1
merge time: 30 minutes and 11 seconds. |
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Mon Jun 17, 2019 6:46 pm Post subject: |
|
|
| John R. Graham wrote: | | How many cores? |
It's a Core i5 3230 @ 2.3GHz ...
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10587
Location: Somewhere over Atlanta, Georgia
|
| Posted: Mon Jun 17, 2019 6:51 pm Post subject: |
|
|
So 4 cores. That's very similar to my Lenovo Flex 5 laptop: Core i5 @ 2.8 GHz. Will post comparison times this evening.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Mon Jun 17, 2019 6:54 pm Post subject: |
|
|
Looking forward to reading your results. Compiling with GCC 8.2 here...
EDIT: BTW I'm curious to know what causes those tremendous changes. I know the Intel platform is not quite optimal (to stay politely correct) but to *that* extent?
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Mon Jun 17, 2019 8:20 pm Post subject: |
|
|
On my laptop i3 7100u (2.4g 4 core)
sys-devel/gcc-4.9.4
merge time: 23 minutes and 55 seconds.
sys-devel/gcc-6.4.0-r1
merge time: 45 minutes and 29 seconds.
sys-devel/gcc-7.3.0-r3
merge time: 51 minutes and 15 seconds.
sys-devel/gcc-8.2.0-r6
merge time: 1 hour, 6 minutes and 22 seconds.
For gcc 8.3 to take 3 hours, one of these is likely - you weren't running all 4 cores, performance was cut back because of power/heat, if you have a swap file and it was on disk and being used it would affect times.
On my laptop (8 gig memory), I usually run with /var/tmp/portage as a tmpfs
except for gcc (8 and up), firefox, etc. those I have to unmount it or it runs out of space (not running a swap partition, but it's on an ssd so relatively fast)
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Mon Jun 17, 2019 9:57 pm Post subject: |
|
|
Of what you enumerated, maybe the temperature was likely to cause that slowdown. I checked with sensors and it reported up to 87°C on the cores. I don't know if that's normal when compiling on the 4 cores. Now I also computed compile time from file create date/times, genlop only gives less than 4000 seconds (IIRC).
EDIT: Here's (after the upgrade) what genlop shows
| genlop -t gcc: | Mon Jun 17 20:21:57 2019 >>> sys-devel/gcc-8.3.0-r1
merge time: 1 hour, 39 minutes and 26 seconds. |
I might have been off by one hour when I posted... I dunno 
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!
Last edited by VinzC on Tue Jun 18, 2019 7:19 am; edited 1 time in total |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Mon Jun 17, 2019 10:25 pm Post subject: |
|
|
87 is warm but not out of spec, 105C max, but I don't know if any throttling takes place with high temps and what that temp would be.
You might check the air intake area and make sure it's getting good airflow.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10587
Location: Somewhere over Atlanta, Georgia
|
| Posted: Tue Jun 18, 2019 12:28 am Post subject: |
|
|
My laptop: Core i5-7200U @ 2.5 GHz: | Code: | ~ # genlop -t gcc
* sys-devel/gcc
Fri May 17 10:34:59 2019 >>> sys-devel/gcc-8.3.0-r1
merge time: 1 hour, 21 minutes and 3 seconds. |
I was wrong on clock rate I reported above.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Tue Jun 18, 2019 7:25 am Post subject: |
|
|
| Anon-E-moose wrote: | 87 is warm but not out of spec, 105C max, but I don't know if any throttling takes place with high temps and what that temp would be.
You might check the air intake area and make sure it's getting good airflow. |
You're right, I'll check the air intake. I did that not so long ago but it might still have picked up dust and dirt...
| John R. Graham wrote: | I was wrong on clock rate I reported above.
- John |
I updated one of my posts above. Your results and mine look quite similar. Although I could swear it actually took far more time. But, yeah, human perception of time...
EDIT: Nope!
| ll /portage.d/log/*gcc-8.3*: | -rw-rw---- 1 portage portage 404 17 jun 17:47 /portage.d/log/sys-devel:gcc-8.3.0-r1:20190617-154742.log
-rw-rw---- 1 portage portage 23065177 17 jun 20:21 /portage.d/log/sys-devel:gcc-8.3.0-r1:20190617-164231.log
|
Just from the log times, there's almost a 3 hours gap! Guess which is right now?
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
Goverp
Veteran
Joined: 07 Mar 2007
Posts: 1994
|
| Posted: Tue Jun 18, 2019 11:01 am Post subject: |
|
|
Seems to be taking me about 2 hrs to compile gcc 8 on 4-code AMD Phenom at 3600 BogoMips (i.e. 1.8 GHz).
_________________
Greybeard |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jun 18, 2019 11:12 am Post subject: |
|
|
Watch out for differences between qlop and genlop
If you want my feeling, genlop do a way better job there:
| Code: | qlop -t dev-lang/rust
rust: 1373 seconds average for 2 merges
genlop -t dev-lang/rust
* dev-lang/rust
Sun Aug 26 03:11:35 2018 >>> dev-lang/rust-1.28.0-r1
merge time: 45 minutes and 41 seconds.
|
do note:
1/ qlop report "rust" and not "dev-lang/rust"
2/ qlop report 2 merges, while genlop report one only
and look if i ask a more generic "rust" only, the answer from genlop show a virtual (which might explains the strange 2 merges answer from qlop before)
| Code: | genlop -t rust
* dev-lang/rust
Sun Aug 26 03:11:35 2018 >>> dev-lang/rust-1.28.0-r1
merge time: 45 minutes and 41 seconds.
Sun Aug 26 03:11:41 2018 >>> virtual/rust-1.28.0
merge time: 6 seconds.
|
1373s is 22.8minutes, and 45.41m+6s/2=22.735s so for me qlop wronly report average of the rust base on rust+virtual compile times
making qlop of poor value to check timing |
|
| Back to top |
|
|
389292
Guru
Joined: 26 Mar 2019
Posts: 504
|
| Posted: Tue Jun 18, 2019 12:16 pm Post subject: |
|
|
| Code: | genlop -t gcc
* sys-devel/gcc
Tue Jun 18 14:54:18 2019 >>> sys-devel/gcc-8.3.0-r1
merge time: 38 minutes and 38 seconds. |
X5660 @ 3.8GHz -j11 |
|
| Back to top |
|
|
|
Other Things Gentoo
