> ... 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
<2020>
2021
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
<2020>
2021
2022
2023
2024
|