Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Direct Memory Access #1891

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Conversation

t-sommer
Copy link
Collaborator

fixes #515

@chrbertsch
Copy link
Collaborator

Design Meeting:
Pierre: For efficient Co-Simulation we need double buffering. You want to run the FMUs in parallel. Thus we need double buffers, otherwise you do not get a benefit.
Torsten: you still get a benefits
Pierre: Single buffers are not sufficient
Torsten: The pointers might be different
Klaus: We should mention this in the layered standard.
Pierre: Switching the pointers for individual variables gets cost intensive. In order to make this efficient either pass the pointers once .... or we need a much better API
Torsten: My intention is for a variable representing 1GByte of data, not for many "small" variables
Pierre: We already have a memory order / area in the get/set call for multiple variables.
We should do just a setReal, which only affects the pointers.
We should use one pointer for multiple variables. Currently we pass a pointer, but the memory is "away" when you leave the set-call
Torsten: ... we could have an array of pointers
Pierre: this kind of indirections is expensive due to address calculation. You must make this "apparent" to the CPU. One has to dereference the memory for each individual variable. If you do this only once, you can cache it.
Torsten: You talk about multiple variables, I about few of large size.
Pierre: for resizable variable this introduces a new error possibility.
Why can we not do just a "setReal", just with a guarantee to not take the memory away after the end of the setReal call? ... to be discussed : valid until the when ...
That might be sufficient all of our needs.
Torsten: There is a tradeoff .... depending if the memory of the individual variable is distributed
Torsten: Alternative: one could provide an opaque pointer and define the internal memory structure
Pierre: This would be very complicated with few benefit.
Pierre: we have to figure out the different use cases. Our intuition fails on today's hardware. We should make benchmark experiments. E.g. multi-threaded FMU calculation, looking into performance counters.
Torsten: My goal was to keep this out of FMI and let the importer handle it.
Pierre: Memory Copy performance is very nonlinear ...
Torsten: I could create examples based on the reference FMUs
Christian: We should start an FCP listing use cases
Pierre: There is experience, e.g. with OSI (with double buffering)
Torsten: for the use cases, just commit to the documentation in this branch
Pierre: listing the uses cases is important to understand this concept
Torsten: This does not enable new functionality, but is intended to decrease CPU-time
Torsten: I will set up a meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Direct memory access in fmi3SetX / fmi3GetX functions
2 participants