EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS shared library performance
From: Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>
To: Mark Rivers <rivers at cars.uchicago.edu>, EPICS core-talk <core-talk at aps.anl.gov>
Date: Mon, 29 Jun 2020 07:31:56 -0700
> ... performance drop by about 10% ...

Is this an observed increase in total runtime?  CPU load?

> ... Is there a way to determine that? ...

Maybe, depending on GCC version.

> $ readelf -p .comment bin/...

There is also the .gnu.version special section, but I'm not sure how to interpret this.

Random first thoughts.

* Spectre mitigations?  (I would think not, unless redhat has backported to gcc 4.8)

* Compare executable text size.  (use 'size' not 'ls')

> ... OS-independent thread pool ...

Do you have any metric on whether individual job runtime has increased?

On 6/29/20 7:12 AM, Mark Rivers via Core-talk wrote:
> I have a question about performance of a shared library built with the EPICS build system on Linux.
> 
>  
> 
> I have  been using a version of the library built in 2013 with base 3.14.12.3.  This library uses libCom to perform parallel reconstruction of tomography data.  It is not using anything from EPICS except libCom (e.g. epicsMessageQueue, epicsEvent, epicsThread), etc.  EPICS is basically being used to implement an OS-independent thread pool where each slice gets reconstructed by the first thread that is available.
> 
>  
> 
> Performance is really important for this application, since there is a lot of data we need to process quickly.
> 
>  
> 
> I recently rebuilt the library and saw the performance drop by about 10% compared to the version built in 2013.  My first thought was that it was the version of base.  I don’t have a 3.14.12.3 build at hand right now, but I do have 3.14.12.6, 3.15.5, and 7.0.4.  I have tested with all of them, and they all have the same performance, ~10% less than the 2013 build.  It is very reproducible, if I use the 2013 build it is 10% faster every time.
> 
>  
> 
> Since it now seems unlikely to be EPICS base I am thinking it is a change in the compiler.  I am building the library and running it on Centos 7 systems with gcc 4.8.5.  I don’t know for what version of gcc or Linux I was using when I built it in 2013.  Is there a way to determine that?  Any idea what could cause this?
> 
>  
> 
> Thanks,
> 
> Mark
> 
>  
> 


References:
EPICS shared library performance Mark Rivers via Core-talk

Navigate by Date:
Prev: Re: EPICS shared library performance Konrad, Martin via Core-talk
Next: Re: EPICS shared library performance Michael Davidsaver via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: EPICS shared library performance Mark Rivers via Core-talk
Next: Re: EPICS shared library performance Michael Davidsaver via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
ANJ, 29 Jun 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·