precice / precice/python-bindings
Reduce overhead of read_data and write_data
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Cython
- Sterne
- 30
- Forks
- 19
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beschreibung
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_idsandvaluesare copied to a vector, even though passingnp.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, whilenp.reshapedoesn'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
getDataDimensionsand do this in one place. - This overhead could be profiled with something like https://github.com/precice/precice/issues/1647
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Beginne bei den Python-Binding-Einstiegspunkten read_data und write_data und nutze den verlinkten Discourse-Thread, um den gemeldeten Overhead sowie die Hinweise zu reshape, Allokationen und Fehlerprüfung zu verstehen. Vergleiche die Timings auf Python-Seite mit den preCICE-Timings und überprüfe anschließend, dass die Funktionen ihr Verhalten beibehalten und gleichzeitig unnötige Kopien und Allokationen vermeiden.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- numpy, python
- Bereich
- api, performance
- Issue-Typ
- Refactoring
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 35/100