Performance

Performance

Introduction

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