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

Maximum Output Buffer Size PaRSEC with MADNESS Serialisation #151

Open
rohanmclure opened this issue Sep 9, 2021 · 3 comments
Open

Maximum Output Buffer Size PaRSEC with MADNESS Serialisation #151

rohanmclure opened this issue Sep 9, 2021 · 3 comments
Assignees

Comments

@rohanmclure
Copy link

Was using TTG with the PaRSEC backend but with TTG_SERIALIZATION_SUPPORTS_MADNESS enabled.

It appears like ttg/ttg/parsec/ttg.h:728 caps the maximum size of messages to just under 1MB. Would it be possible to have the buffer size determined dynamically?

This behaviour should align with: https://github.com/m-a-d-n-e-s-s/madness/blob/320e2c0d9728312b7d41470dbfc4d20e8dac5120/src/madness/world/buffer_archive.h#L100, that is the nbyte value should be indicative of the real size of the buffer.

@devreal devreal self-assigned this Sep 9, 2021
@devreal
Copy link
Contributor

devreal commented Sep 9, 2021

Thanks for the report. This is indeed an issue we need to solve (shouldn't be hard to fix).

In the meantime, depending on your data structure, you may want to use the split-metadata interface we introduced recently. It allows you to describe your data as iovecs and have the runtime transfer the blob(s) without serialization. You can find a usage example in the POTRF code: https://github.com/TESSEorg/ttg/blob/master/examples/potrf/potrf_pdc.cc#L338

@rohanmclure
Copy link
Author

Thanks Joseph, I might try and adapt to the slit-metadata interface. The code example is very helpful.

@devreal
Copy link
Contributor

devreal commented Sep 9, 2021

Let me know if you have any questions :)

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

2 participants