2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | EPICS shared library performance |
From: | Mark Rivers via Core-talk <core-talk at aps.anl.gov> |
To: | EPICS core-talk <core-talk at aps.anl.gov> |
Date: | Mon, 29 Jun 2020 14:12:08 +0000 |
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 |