Re: [gentoo-user] Re: Mammoth emerge ...

[Mick]

On Thursday, 3 May 2018 18:22:01 BST Mick wrote:

> I will give USE="jumbo-build" a spin later to see what improvement I may
> get.


I rebuilt chromium with USE="jumbo-build" with amazing results:

 Fri May  4 12:37:06 2018 >>> www-client/chromium-66.0.3359.139
   merge time: 1 day, 41 minutes and 56 seconds.

 Sat May  5 18:28:05 2018 >>> www-client/chromium-66.0.3359.139
   merge time: 9 hours, 20 minutes and 1 second.


Inevitably the first build took place to a large extent overnight when the PC 
was not in use.  Otherwise during day time the PC saw similar usage, light 
browsing, emails.  The above result shows more than a 60% shorter emerge time!

I noticed slightly more swap was being used (c. 100M or so).

Thanks Neil for suggesting it.  :-)

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Mammoth emerge ...

[Mick]

On Thursday, 3 May 2018 18:00:45 BST Corbin Bird wrote:
> .
> Chromium switched to 'clang++ v5.x' as its primary compiler.
> Why?
> The Chromium devs are using 'c++' features supported in gcc v8+.
> .
> So ... first compile run is with 'gcc' ... then Chromium is re-compiled
> with 'clang++'.
> That is what I am seeing ( console && log wise ).
> 2 Compile runs ... twice the time.
> .
> No gold linker setup on my system.
> Just how is 'clang++' supposed to work with 'ld.bfd'?
> .
> As far as I can tell, all optimization depending on '-march= / -mtune= '
> is still discarded, as well.
> ( clang / clang ++, does not seem to accept the '-march= / -mtune= / -O2
> / -pipe' switches either. )
> .
> Corbin

Thanks Corbin, it makes sense.  Back in November build time jumped from 8 to 
20 hours on my system.  It's only gone further downhill since.  :-(

I will give USE="jumbo-build" a spin later to see what improvement I may get.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Mammoth emerge ...

[Mick]

On Thursday, 3 May 2018 17:57:20 BST Neil Bothwick wrote:
> On 3 May 2018 16:41:55 BST, Grant Edwards  wrote:
> >On 2018-05-03, Mick  wrote:
> >> OK, I know my laptop is quite old, or at least Intel thinks so, but
> >
> >emerging
> >
> >> chromium is now taking *much* longer than it ever did:
> >A while back I accidentally broke the CPU throttling on my laptop, and
> >it was always running at 1/4 speed.  [That effected all emerges.]  I'd
> >start by doing a "grep MHz /proc/cpuinfo" during the build to verify
> >that all the CPUs have open throttles.
> >
> >That said, I've noticed that Chromium in particular is taking a lot
> >longer than it used to...
> 
> I had similar issues with swapping on an 8GB laptop.. Limiting the numbers
> of jobs helped but using jumbo-build more than halved the build time .

Interesting ... I had made a mental note to try out USE="jumbo-build".  I'm 
not sure what pressure it will place on my limited resources, but the proof of 
the pudding ... 

I will give it a spin tomorrow, or whenever this emerge completes.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Mammoth emerge ...

[Corbin Bird]

.
Chromium switched to 'clang++ v5.x' as its primary compiler.
Why?
The Chromium devs are using 'c++' features supported in gcc v8+.
.
So ... first compile run is with 'gcc' ... then Chromium is re-compiled
with 'clang++'.
That is what I am seeing ( console && log wise ).
2 Compile runs ... twice the time.
.
No gold linker setup on my system.
Just how is 'clang++' supposed to work with 'ld.bfd'?
.
As far as I can tell, all optimization depending on '-march= / -mtune= '
is still discarded, as well.
( clang / clang ++, does not seem to accept the '-march= / -mtune= / -O2
/ -pipe' switches either. )
.
Corbin

Re: [gentoo-user] Re: Mammoth emerge ...

[Neil Bothwick]

On 3 May 2018 16:41:55 BST, Grant Edwards  wrote:
>On 2018-05-03, Mick  wrote:
>
>> OK, I know my laptop is quite old, or at least Intel thinks so, but
>emerging 
>> chromium is now taking *much* longer than it ever did:
>
>A while back I accidentally broke the CPU throttling on my laptop, and
>it was always running at 1/4 speed.  [That effected all emerges.]  I'd
>start by doing a "grep MHz /proc/cpuinfo" during the build to verify
>that all the CPUs have open throttles.
>
>That said, I've noticed that Chromium in particular is taking a lot
>longer than it used to...

I had similar issues with swapping on an 8GB laptop.. Limiting the numbers of 
jobs helped but using jumbo-build more than halved the build time .

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Re: Mammoth emerge ...

[Mick]

On Thursday, 3 May 2018 16:41:55 BST Grant Edwards wrote:
> On 2018-05-03, Mick  wrote:
> > OK, I know my laptop is quite old, or at least Intel thinks so, but
> > emerging
> > chromium is now taking *much* longer than it ever did:
> A while back I accidentally broke the CPU throttling on my laptop, and
> it was always running at 1/4 speed.  [That effected all emerges.]  I'd
> start by doing a "grep MHz /proc/cpuinfo" during the build to verify
> that all the CPUs have open throttles.
> 
> That said, I've noticed that Chromium in particular is taking a lot
> longer than it used to...

Thank you Peter and Grant for your replies.  I have once or twice used a 
faster machine to build a Chromium binary and then copied over to the slow 
laptop, but it is a bit of a faff.  I may have to do this in the future, 
although with the landscape changing (GPZ patches, gcc upgrade, etc.) the 
build times are changing all the time.  They may never reduce again, in which 
case it will be an option to consider.

I don't think I have an issue with CPU throttling.  i7z shows the CPU with 
turbo regularly goes up to 2.6GHz:

=
Cpu speed from cpuinfo 1595.00Mhz
cpuinfo might be wrong if cpufreq is enabled. To guess correctly try 
estimating via tsc
Linux's inbuilt cpu_khz code emulated now
True Frequency (without accounting Turbo) 1595 MHz
  CPU Multiplier 12x || Bus clock frequency (BCLK) 132.92 MHz

Socket [0] - [physical cores=4, logical cores=8, max online cores ever=4]
  TURBO ENABLED on 4 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 1727.92 MHz (132.92 x [13])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4 Cores is  21x/18x/13x/13x
  Real Current Frequency 2244.06 MHz [132.92 x 16.88] (Max of below)
Core [core-id]  :Actual Freq (Mult.)  C0%   Halt(C1)%  C3 %   C6 %  
 
C7 %  Temp   VCore
Core 1 [0]:   1454.95 (10.95x)  4.7611.254.629.9
   0
69  0.
Core 2 [1]:   1634.49 (12.30x)  3.09 4.552.639.7
   0
69  0.
Core 3 [2]:   2244.06 (16.88x)  99.5   0   0   0
   072  
0.
Core 4 [3]:   2235.68 (16.82x)  99.4   0   0   0
   0
69  0.



C0 = Processor running without halting
C1 = Processor running with halts (States >C0 are power saver modes with cores 
idling)
C3 = Cores running with PLL turned off and core cache turned off
C6, C7 = Everything in C3 + core state saved to last level cache, C7 is deeper 
than C6
  Above values in table are in percentage over the last 1 sec
[core-id] refers to core-id number in /proc/cpuinfo
'Garbage Values' message printed when garbage values are read
=

/proc/cpuinfo shows a number of cores regularly @1600MHz while syslog does not 
report any problems.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: Mammoth emerge ...

[Grant Edwards]

On 2018-05-03, Mick  wrote:

> OK, I know my laptop is quite old, or at least Intel thinks so, but emerging 
> chromium is now taking *much* longer than it ever did:

A while back I accidentally broke the CPU throttling on my laptop, and
it was always running at 1/4 speed.  [That effected all emerges.]  I'd
start by doing a "grep MHz /proc/cpuinfo" during the build to verify
that all the CPUs have open throttles.

That said, I've noticed that Chromium in particular is taking a lot
longer than it used to...

-- 
Grant Edwards   grant.b.edwardsYow! I have a very good
  at   DENTAL PLAN.  Thank you.
  gmail.com