Re: [ccache] useful test package to use with ccache at the outset in Gentoo.....

[Michael Fothergill via ccache]

On 8 December 2017 at 15:13, Scott Bennett  wrote:

> Michael Fothergill via ccache  wrote:
>
> > On 8 December 2017 at 01:35, Scott Bennett via ccache <
> > ccache@lists.samba.org> wrote:
> >
> > > Michael Fothergill via ccache  wrote:
> > >
> > > > I have an amd64 kaveri box with 8GB RAM and run Gentoo stable on it.
> > > >
> > > > I have just installed ccache with 2GB memory allocated to it.
> > >
> > >  By that, I assume you have allocated some kind of memory-based
> device
> > > for the cache.  Is that a correct understanding?
> > >
> >
> > ?Thanks for your reply and comments.  I am assuming that by having the
> > standard command ?
> >
> > ?CCACHE_SIZE="4G" (I have increased the allocation)
>
>  As ccache is installed on my system, I cannot find an environment
> variable of that name documented.  Are you sure it is being used?  What I
> do find documented are CCACHE_MAX_SIZE and the corresponding ccache.conf
> parameter max_size.  If you're going to build large items like libreoffice
> or a LINUX world, you probably ought to have a much larger cache.  I also
> found it a good idea to change limit_multiple from its default value of 0.8
> to 0.95 to avoid half-hour-long cleanups in the middle of build runs.
>  It is worth noting that, by my understanding of ccache the last time
> I dug into it a bit, ccache actually maintains 16 distinct caches, but the
> max_size and limit_multiple values apply to the total size and usage
> fraction of the aggregate of all 16 caches.  When a cleanup occurs, ccache
> chooses one of the 16 caches and begins deleting the least recently used
> entries in it until the total space allocated has been reduced to the
> limit_multiple fraction of the max_size.  If it runs out of things to
> delete in that cache while the total allocated remains above that fraction,
> ccache chooses another cache from which to begin deleting entries, and so
> on.
> This procedure differs from the one described in the ccache man page and is
> one reason I like to give more space to the cache(s) in order to prevent
> recent entries from disappearing from a cache while other, far less
> recently
> used entries remain in the other 15 caches.  By having a max_size large
> enough to hold the last several iterations of frequently built items,
> cleanups are more likely to satisfy the limit_multiple by deleting the
> oldest
> few iterations of updates while sparing the more recently used entries
> in a cache.  These days the disk space is cheap enough to give it 10 GB to
> 30 GB without creating any problems for me, so I just do that.  Another
> trick
> to keep the caches useful is to allocate separate ones for different
> purposes.
> For example, I set up one for building the OS userland and kernel, another
> for building libreoffice, and a third for building everything else.  Doing
> this keeps the OS and libreoffice from evicting everything else or each
> other
> prematurely. :-)
>
> > then memory from the hard drive is being used by default here - I was not
> > trying to use e.g. RAM memory.
> >
>  Oh.  Okay.
>  If your system is used heavily for compiling software, you may see
> some
> performance gains from putting the cache area onto an SSD.  Using a system
> memory-based cache is, of course, lightning fast, but the entire cache
> evaporates when the device is deallocated (e.g., during a system shutdown
> or
> failure).  I tried using software five- and six-way RAID-0 devices for the
> file system containing my caches for a while, but decided their performance
> was poor.  At present I'm using a software CONCAT made of two two-way
> software
> RAID-1's, all on the same kind of hard drives as the earlier setups, and
> this
> setup seems to do very nicely for now.  I just have to remember not to run
> updates at the same time as scrubs on the six-way raidz2 that occupies the
> bulk of the same drives. :-)  I only scrub that pool about every three to
> four
> weeks, though, so it usually isn't a problem.
> > >
> > > > I have tried some repeat compilations to see if there would be any
> speed
> > > > increase.
> > > >
> > > > So far I have not seen much change but I am not skilled enough to
> improve
> > > > things yet.
> > >
> > >  Your statistics show that slightly more than 45% of your total
> > > compiler invocations (hits/(hits+misses)) were avoided.  Did that not
> > > make a dent in your timings?
> > > >
> > > > I tried compiling gcc, glibc and imagemagick but did not see much
> > > > improvement.
> > >
> > >  If you run the full build process for gcc, I would not expect
> > > to see much improvement because most of it involves the use of either
> > > a) a temporarily built compiler in a temporary location or b) the
> > > newly built compiler being used for testing, but not yet installed
> > > into the production location on your system.
> > >
> >
> > ?Would cachecc1 perform any better with gcc??
> >
>  I don't know what cachecc1 is, so I have no idea.  Sorry.
>

Re: [ccache] useful test package to use with ccache at the outset in Gentoo.....

[Scott Bennett via ccache]

Michael Fothergill via ccache  wrote:

> On 8 December 2017 at 01:35, Scott Bennett via ccache <
> ccache@lists.samba.org> wrote:
>
> > Michael Fothergill via ccache  wrote:
> >
> > > I have an amd64 kaveri box with 8GB RAM and run Gentoo stable on it.
> > >
> > > I have just installed ccache with 2GB memory allocated to it.
> >
> >  By that, I assume you have allocated some kind of memory-based device
> > for the cache.  Is that a correct understanding?
> >
>
> ?Thanks for your reply and comments.  I am assuming that by having the
> standard command ?
>
> ?CCACHE_SIZE="4G" (I have increased the allocation)

 As ccache is installed on my system, I cannot find an environment
variable of that name documented.  Are you sure it is being used?  What I
do find documented are CCACHE_MAX_SIZE and the corresponding ccache.conf
parameter max_size.  If you're going to build large items like libreoffice
or a LINUX world, you probably ought to have a much larger cache.  I also
found it a good idea to change limit_multiple from its default value of 0.8
to 0.95 to avoid half-hour-long cleanups in the middle of build runs.
 It is worth noting that, by my understanding of ccache the last time
I dug into it a bit, ccache actually maintains 16 distinct caches, but the
max_size and limit_multiple values apply to the total size and usage
fraction of the aggregate of all 16 caches.  When a cleanup occurs, ccache
chooses one of the 16 caches and begins deleting the least recently used
entries in it until the total space allocated has been reduced to the
limit_multiple fraction of the max_size.  If it runs out of things to
delete in that cache while the total allocated remains above that fraction,
ccache chooses another cache from which to begin deleting entries, and so on.
This procedure differs from the one described in the ccache man page and is
one reason I like to give more space to the cache(s) in order to prevent
recent entries from disappearing from a cache while other, far less recently
used entries remain in the other 15 caches.  By having a max_size large
enough to hold the last several iterations of frequently built items,
cleanups are more likely to satisfy the limit_multiple by deleting the oldest
few iterations of updates while sparing the more recently used entries 
in a cache.  These days the disk space is cheap enough to give it 10 GB to
30 GB without creating any problems for me, so I just do that.  Another trick
to keep the caches useful is to allocate separate ones for different purposes.
For example, I set up one for building the OS userland and kernel, another
for building libreoffice, and a third for building everything else.  Doing
this keeps the OS and libreoffice from evicting everything else or each other
prematurely. :-)

> then memory from the hard drive is being used by default here - I was not
> trying to use e.g. RAM memory.
>
 Oh.  Okay.
 If your system is used heavily for compiling software, you may see some
performance gains from putting the cache area onto an SSD.  Using a system
memory-based cache is, of course, lightning fast, but the entire cache
evaporates when the device is deallocated (e.g., during a system shutdown or
failure).  I tried using software five- and six-way RAID-0 devices for the
file system containing my caches for a while, but decided their performance
was poor.  At present I'm using a software CONCAT made of two two-way software
RAID-1's, all on the same kind of hard drives as the earlier setups, and this
setup seems to do very nicely for now.  I just have to remember not to run
updates at the same time as scrubs on the six-way raidz2 that occupies the
bulk of the same drives. :-)  I only scrub that pool about every three to four
weeks, though, so it usually isn't a problem.
> >
> > > I have tried some repeat compilations to see if there would be any speed
> > > increase.
> > >
> > > So far I have not seen much change but I am not skilled enough to improve
> > > things yet.
> >
> >  Your statistics show that slightly more than 45% of your total
> > compiler invocations (hits/(hits+misses)) were avoided.  Did that not
> > make a dent in your timings?
> > >
> > > I tried compiling gcc, glibc and imagemagick but did not see much
> > > improvement.
> >
> >  If you run the full build process for gcc, I would not expect
> > to see much improvement because most of it involves the use of either
> > a) a temporarily built compiler in a temporary location or b) the
> > newly built compiler being used for testing, but not yet installed
> > into the production location on your system.
> >
>
> ?Would cachecc1 perform any better with gcc??
>
 I don't know what cachecc1 is, so I have no idea.  Sorry.
>
> >  ImageMagick and GraphicsMagick both should provide useful timings
> > and ccache statistics.  glibc probably would, too, though it's not
> > nearly as big.  I don't know what sort of build procedures Gentoo uses,
> > but from the FreeBSD ports tree

Re: [ccache] useful test package to use with ccache at the outset in Gentoo.....

[Michael Fothergill via ccache]

On 8 December 2017 at 01:35, Scott Bennett via ccache <
ccache@lists.samba.org> wrote:

> Michael Fothergill via ccache  wrote:
>
> > I have an amd64 kaveri box with 8GB RAM and run Gentoo stable on it.
> >
> > I have just installed ccache with 2GB memory allocated to it.
>
>  By that, I assume you have allocated some kind of memory-based device
> for the cache.  Is that a correct understanding?
>

​Thanks for your reply and comments.  I am assuming that by having the
standard command ​

​CCACHE_SIZE="4G" (I have increased the allocation)
then memory from the hard drive is being used by default here - I was not
trying to use e.g. RAM memory.

>
> > I have tried some repeat compilations to see if there would be any speed
> > increase.
> >
> > So far I have not seen much change but I am not skilled enough to improve
> > things yet.
>
>  Your statistics show that slightly more than 45% of your total
> compiler invocations (hits/(hits+misses)) were avoided.  Did that not
> make a dent in your timings?
> >
> > I tried compiling gcc, glibc and imagemagick but did not see much
> > improvement.
>
>  If you run the full build process for gcc, I would not expect
> to see much improvement because most of it involves the use of either
> a) a temporarily built compiler in a temporary location or b) the
> newly built compiler being used for testing, but not yet installed
> into the production location on your system.
>

​Would cachecc1 perform any better with gcc?​



>  ImageMagick and GraphicsMagick both should provide useful timings
> and ccache statistics.  glibc probably would, too, though it's not
> nearly as big.  I don't know what sort of build procedures Gentoo uses,
> but from the FreeBSD ports tree, here are some other good examples of
> test cases:  math/octave, www/webkit-gtk2, www/webkit-gtk3,
> www/webkit2-gtk3, devel/llvm40.  Be prepared to wait a long time for
> the first compilation of each of the webkits.  They are big and slow
> to compile and, in the past, have shown instabilities in their build
> procedures when parallel make runs were used.
>

​I have now compiled qtwebengine, libreoffice and and dramatically reduced
the compile time with ccache
now I am using the 3.3.4 version of the program ( see here
https://forums.gentoo.org/viewtopic-t-1073298.html
​ ). I think the earlier version of ccache was not working properly.

People on the thread have suggested that maybe cachecc1 might not work so
well with gcc in practice and I should stick
with ccache as is.

But you may take a different view.  ​



> YMMV on another OS.
>  One big savings for me was in running "make buildworld" and "make
> buildkernel".  buildworld, on my last machine, was taking about six
> hours elapsed time for a first run.  When running it later after
> updating the source tree, the elapsed time was reduced by 2/3 to 3/4,
> depending upon the number and sizes of source modules affected by the
> updates.
>

​These sound like the emerge --ask --update --deep @world command used in
Gentoo (and similar versions).​

​It's not time to update the system again yet but I think that it could
well speed things up as long as the cache size is big enough for a lot of
packages (e.g. 200 plus)

Thanks and comments appreciated.

Michael Fothergill​



> Note that ccache and some other things need a slightly
> different setup in order to build FreeBSD.  Your OS may also need some
> special provision, so be sure to read the ccache installation
> instructions for Gentoo carefully.
>
>
>   Scott Bennett, Comm. ASMELG, CFIAG
> **
> * Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
> **
> * "A well regulated and disciplined militia, is at all times a good  *
> * objection to the introduction of that bane of all free governments *
> * -- a standing army."   *
> *-- Gov. John Hancock, New York Journal, 28 January 1790 *
> **
>
> ___
> ccache mailing list
> ccache@lists.samba.org
> https://lists.samba.org/mailman/listinfo/ccache
>
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] useful test package to use with ccache at the outset in Gentoo.....

[Scott Bennett via ccache]

Michael Fothergill via ccache  wrote:

> I have an amd64 kaveri box with 8GB RAM and run Gentoo stable on it.
>
> I have just installed ccache with 2GB memory allocated to it.

 By that, I assume you have allocated some kind of memory-based device
for the cache.  Is that a correct understanding?
>
> I have tried some repeat compilations to see if there would be any speed
> increase.
>
> So far I have not seen much change but I am not skilled enough to improve
> things yet.

 Your statistics show that slightly more than 45% of your total
compiler invocations (hits/(hits+misses)) were avoided.  Did that not
make a dent in your timings?
>
> I tried compiling gcc, glibc and imagemagick but did not see much
> improvement.

 If you run the full build process for gcc, I would not expect
to see much improvement because most of it involves the use of either
a) a temporarily built compiler in a temporary location or b) the
newly built compiler being used for testing, but not yet installed
into the production location on your system.
 ImageMagick and GraphicsMagick both should provide useful timings
and ccache statistics.  glibc probably would, too, though it's not
nearly as big.  I don't know what sort of build procedures Gentoo uses,
but from the FreeBSD ports tree, here are some other good examples of
test cases:  math/octave, www/webkit-gtk2, www/webkit-gtk3,
www/webkit2-gtk3, devel/llvm40.  Be prepared to wait a long time for
the first compilation of each of the webkits.  They are big and slow
to compile and, in the past, have shown instabilities in their build
procedures when parallel make runs were used.  YMMV on another OS.
 One big savings for me was in running "make buildworld" and "make
buildkernel".  buildworld, on my last machine, was taking about six
hours elapsed time for a first run.  When running it later after
updating the source tree, the elapsed time was reduced by 2/3 to 3/4,
depending upon the number and sizes of source modules affected by the
updates.  Note that ccache and some other things need a slightly
different setup in order to build FreeBSD.  Your OS may also need some
special provision, so be sure to read the ccache installation
instructions for Gentoo carefully.


  Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
**
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."   *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**

___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

Re: [ccache] useful test package to use with ccache at the outset in Gentoo.....

[Michael Fothergill via ccache]

Dear All,

I upgraded from ccache 3.2.4 to 3.3.4.  I think it is working now..

I might try out cachecc1.

A manual install will be required for that.

Regards

MF

On 7 December 2017 at 16:24, Michael Fothergill <
michael.fotherg...@gmail.com> wrote:

> Dear Ccache community,
>
> I have an amd64 kaveri box with 8GB RAM and run Gentoo stable on it.
>
> I have just installed ccache with 2GB memory allocated to it.
>
> I have tried some repeat compilations to see if there would be any speed
> increase.
>
> So far I have not seen much change but I am not skilled enough to improve
> things yet.
>
> I tried compiling gcc, glibc and imagemagick but did not see much
> improvement.
>
> My cache data looks like this:
>
> djt /home/mikef # CCACHE_DIR="/var/tmp/ccache" ccache -s
> cache directory /var/tmp/ccache
> primary config  /var/tmp/ccache/ccache.conf
> secondary config  (readonly)/etc/ccache.conf
> cache hit (direct) 12997
> cache hit (preprocessed) 517
> cache miss 16291
> called for link 2141
> called for preprocessing1709
> multiple source files  4
> compile failed   197
> preprocessor error62
> bad compiler arguments79
> unsupported source language 2275
> autoconf compile/link   1399
> unsupported compiler option8
> no input file   2617
> files in cache 44633
> cache size 891.9 MB
> max cache size   2.0 GB
>
> Could you recommend a gentoo package that I could recompile twice that you
> think is one that is ideally suited to benefit from ccache being installed?
>
> Comments appreciated.
>
> Regards
>
> Michael Fothergill
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache

[ccache] useful test package to use with ccache at the outset in Gentoo.....

[Michael Fothergill via ccache]

Dear Ccache community,

I have an amd64 kaveri box with 8GB RAM and run Gentoo stable on it.

I have just installed ccache with 2GB memory allocated to it.

I have tried some repeat compilations to see if there would be any speed
increase.

So far I have not seen much change but I am not skilled enough to improve
things yet.

I tried compiling gcc, glibc and imagemagick but did not see much
improvement.

My cache data looks like this:

djt /home/mikef # CCACHE_DIR="/var/tmp/ccache" ccache -s
cache directory /var/tmp/ccache
primary config  /var/tmp/ccache/ccache.conf
secondary config  (readonly)/etc/ccache.conf
cache hit (direct) 12997
cache hit (preprocessed) 517
cache miss 16291
called for link 2141
called for preprocessing1709
multiple source files  4
compile failed   197
preprocessor error62
bad compiler arguments79
unsupported source language 2275
autoconf compile/link   1399
unsupported compiler option8
no input file   2617
files in cache 44633
cache size 891.9 MB
max cache size   2.0 GB

Could you recommend a gentoo package that I could recompile twice that you
think is one that is ideally suited to benefit from ccache being installed?

Comments appreciated.

Regards

Michael Fothergill
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache