EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: What I learned today...
From: Andrew Johnson <[email protected]>
To: [email protected]
Date: Fri, 1 Mar 2013 10:50:41 -0600
Hi Ben,

On 2013-03-01 Benjamin Franksen wrote:
> On Thursday, February 28, 2013 11:22:06 Andrew Johnson wrote:
> > We get around that in Base now by always generating files into the
> > O.<arch> directory and moving them into O.Common afterwards.  A move is
> > an atomic operation in the file-system, so it doesn't matter if there is
> > a race because the generated files *should* be identical.
> 
> But won't this mean that architecture independent targets (db files,dbd
> files,operator panels, etc.) will all be built several times (once for
> each target architecture)?

In general no, although there can be times when they get built more than once 
(hence the protection we had to add, see previous email).  The main reason is 
that we have a dependency in place so that no cross-builds can start until 
after the host build has completed.  Those files will usually be built and 
installed as part of the host build, so make will see them as already up to 
date when it later checks them for each of the cross-build targets.

> I may be missing something, but it seems to me that if
> CROSS_COMPILER_TARGET_ARCHS contains more entries than the machine has
> cores, make -j with rules that are as you describe above will be slower
> than serial make with the old make rules, at least if the build time is
> dominated by such architecture independent targets. The latter is the case
> if e.g. device lists and configuration data are generated by scripts that
> query a SQL database server.

I don't claim to understand how make allocates build processes amongst sub-
makes when there is a limit given with the -j option, but I do know that it 
doesn't end up allocating one process to each target architecture.  If you set 
up your rules so that the host build is the one that does the SQL queries and 
installs a config file with the results then you can ensure that it will only 
be run once.  However if your SQL queries are architecture-specific they will 
have to be done for each architecture anyway and the results should not get 
installed into a common directory.

I have seen that builds on a single-core Windows system actually go faster if 
you specify a small -j limit (maybe 2 or 3) than if you build serially.

- Andrew
-- 
There is no such thing as a free lunch.  When invited for lunch,
it is best to check if you are there to eat, or to be eaten.
-- Clive Robinson

Replies:
Re: What I learned today... Benjamin Franksen
References:
What I learned today... Benjamin Franksen
Re: What I learned today... Andrew Johnson
Re: What I learned today... Benjamin Franksen

Navigate by Date:
Prev: RE: areaDetector R1-9 released Mark Rivers
Next: Re: What I learned today... Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: What I learned today... Benjamin Franksen
Next: Re: What I learned today... Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·