-
Notifications
You must be signed in to change notification settings - Fork 393
Performance
Here we can talk about performance.
Software performance (and I think we're mostly talking about execution time) is a daunting issue, and encompasses many considerations, such as:
-
The General Definition.
-
Who cares about E+ performance? (and a bridge to that question: why do we care [about performance]?)
- What are the performance frontiers that building energy modeling practitioners are encountering?
-
Why do we care? Because EnergyPlus is the most comprehensive and accurate modeling tool around for building energy performance, with many person-years of expert development.
-
We care about energy usage. We don't want designers, maintainers and policy enforcers to settle for second best when determining a building design, operation schedule or government mandates (because it takes too long for E+ to deliver an answer)
-
EnergyPlus deserves to be the reference simulation tool
-
-
EnergyPlus is a (highly) multifaceted building energy simulation tool (where do we focus)?
-
Our concerns have to be clearly defined in the form of a set of inputs, i.e. IDF(s)
-
-
The EnergyPlus C++ translation
-
C++ gives us code with a more transparent path to the metal, i.e. the machine level instructions
-
There are hiccups -- performance has suffered. Edit: EnergyPlus C++ is in its post-conversion performance tuning phase. Performance is advancing rapidly and should reach Fortran parity for tuned cases by June 2014.
-
The bright side: we have our work laid out for us -- we have many models for which we know the execution time differentials and for which we can generate profiling data
-
We have very clean C++ code from which to optimize
-
-
In order to accomplish our goal of having a high performance simulation tool, we need clearly defined goals that can be measured. So we have to have this data:
-
Clearly defined problems (e.g. 'autosizing is taking 40% of the time for model X)
-
Models that encapsulate the problems
-
Performance statistics (profiling data -- gprof, perf, Intel, etc -- and different tools should correlate)
-
Clearly defined goals, such as reducing the problem area execution time by 90%
-
At least maintain cognizance of the effect of our changes on the performance of shorter execution time models that may not reflect real-world usage, but do keep the pulse of various internal features of EnergyPlus
What do we know now? We have a few issues on hand:
-
C++ translation issues
-
Fixed length string representation used in E+ along with the operations upon these were a performance problem before the translation to C++. The replacement of the emulation of Fortran FLSs with C++ standard strings is still being evaluated, but appears to have had a major impact to len_trim bottlenecks and the like. We do need to analyze the effects of this change overall. Edit: The C++ has been migrated to std::string and many slow string operations and unnecessary string creations have been addressed. Additional string usage tuning is possible but much of the string-related slowness has been fixed.
-
There are (predicted) issues with Fortran emulated arrays, mostly with slicing and other pass by value semantics. Edit: Array slicing and passing tricks are done with lightweight proxy arrays so to clarify they are pass by value but no array data copying occurs, although there is still a bit of overhead for the proxy creation at the time of call so strength reduction to array pass by reference is a good tuning step for high call count functions.
-
(more to come on this issue)
-
-
We have some long standing performance issues with legacy EnergyPlus -- including
-
HeatBalanceInteriorRadExchange module / namespace
-
SolarShading
*[fill in the blank, please]
-
There is data forthcoming that will support these.
We need to maintain the following in our interest in making E+ a performer:
-
A set of performance models
-
Performance data for each model
-
A catalog of projects that address the issues -- they will most likely cascade, as the elimination of one bottleneck will expose the next
-
these projects include a description of the problem, with supporting data; steps taken to mitigate the performance deficit; and data to illustrate the effectiveness of the modifications
-
data includes overall execution time per model, profiling data, and analysis connecting the two
-
Top level information can include:
-
General information
- profiling techniques
- timing techniques
- build performance
-
Hot Spots
- where they're evident (which models) and how they present themselves
-
Model History