FMI Efficiency: Performance improvements for structured variables

[IZacharias]

This issue is used for discussing and creation of an FCP as discussed in FMI Design meeting in June2025 (see https://github.com/modelica/fmi-design/blob/master/Meetings/2025/2025-06-02-04-FMI-F2F-Berlin/20250603_FMI_Communication_Performance.pdf).

The idea is to avoid calling fmi3GetXXX() and fmi3SetXXX() functions whenever possible for large structures and read/write them with a single memory copy call, or not copying them at all. This will save either many calls with a single valueReference, or in case of a single call with a list of valueReferences it will save the required loops on both ends to write/read the values.

We need to make the FMU declare which memory areas are such structures and how they are structured.

Sketch of the approach:

• Enable FMU to describe the memory layout for structured variables:
  • Terminals would list a number of variables in order of the memory layout
  • The referenced variables are known in their size (now we define bitness for integer and float) etc.
  • The terminal would receive an attribute to signal what kind of memory access is possible:
    • memory is internal to the FMU (requiring at least single copy)
    • memory is external to the FMU - the simulator must point the FMU to the memory area to be used for that struct/terminal (potential 0-copy)
• The standard needs to add pointer handling fmi3GetPtr (if memory remains in FMU), fmi3SetPtr (if memory can be outside FMU)
• We need to define synchronisation/access guaranties for ME/CS/SE:
  • e.g. for FMU internal memory, the FMU must guarantee that it accesses this memory only during fmi3DoStep (or maybe during fmi3GetXXX ?)
  • For FMU external memory...
• We need to define the "serialization" of the memory layout, order being trivial, arrays like in array access serialization, (preferrably) 0 padding, integer and float now having defined number of bytes, mentioning arrays with variable dimensions...

The advantages of this approach:

• If an importer does not support these structs, element-wise fmi3Get/Set is still available
• Element access is available for debugging also
• Incompatible structures can be mapped by the importer with element-to-element copy
• Compatibility of structures is relatively easy to define and check

[jkCXf9X4]

I did a speed tests of different variable access methods, it can be found under https://github.com/jkCXf9X4/fmi_speed_test

It evaluates:

• Variable access via a function, uses switch to select variable, this is the same behavior that the reference FMUs have.
• Variable access via a function, uses an array and position to select variable
• Direct pointer access
• Copies of memory areas

It also has some methods to view timing differences when it comes to data location and data access order

[trulede]

I did a speed tests of different variable access methods, it can be found under https://github.com/jkCXf9X4/fmi_speed_test

I tried these tests, and provided some feedback. My impression of FMI, not the speed tests, is that the interface itself should not be the determinant factor in performance (when vectorisation is active), but rather the data which is exchanged (which % of variables, and their order), and the implementation of variable indexing in the FMU itself.

However, also, with FMI the number of get/set needed (so many types) is not an insignificant factor. Each of those call pairs need associated marshalling calls (memcpy ... etc) which only makes things worse.

[timrulebosch]

I tried these tests, and provided some feedback. My impression of FMI ...

In addition to my (this) comment, we are considering a "bypass-mode" for the FMI variable interface. The approach is not particularly sophisticated.