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

Reduce overhead of read_data and write_data #202

Open
fsimonis opened this issue Apr 22, 2024 · 0 comments
Open

Reduce overhead of read_data and write_data #202

fsimonis opened this issue Apr 22, 2024 · 0 comments

Comments

@fsimonis
Copy link
Member

fsimonis commented Apr 22, 2024

In this discourse thread, I tracked down the increased duration spent in the "do-nothing solver" down to read_data and write_data.

Most logical explanation would be the additional

  • input vertex_ids and values are copied to a vector, even though passing np.reshape(X, -1) to the preCICE API suffices and prevents copies.
  • output values are allocated, then passed to the API, then allocated to build an np.array
  • we do a lot of additional error checking (which is good)

Example of rhoVW on solver2, being vectorial data of large mesh:

  • Time measured in preCICE: 7ms (note: this doesn't allocate)
  • Time measured in Python: 40ms (including overhead from activating profiling in python, this needs to allocate, so overhead scales with size)

Notes:

  • With some tweaking I can get this down to 30ms. This makes the function actually shorter, simpler, and easier to follow.
  • np.flatten() copies the input, while np.reshape doesn't if it can avoid it.
  • The majority of the generated code seems to be error handling, which we could potentially be avoided by using the CPP API directly for calls to getDataDimensions and do this in one place.
  • This overhead could be profiled with something like Profiling of user-code via API precice#1647
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

No branches or pull requests

1 participant