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

Comparative benchmarks for hGetSome(at) and their replacement functions #55

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

Conversation

jorisdral
Copy link
Collaborator

A first step towards #50. These micro-benchmarks should allow us to determine whether we can replace the HasFS get-primitives by the HasBufFS primitives, without losing functionality or performance.

@jorisdral
Copy link
Collaborator Author

jorisdral commented Apr 23, 2024

One thing I am unsure about is whether we can replace the HasFS put-primitives by the HasBufFS primitives easily. Some background first :

Defining hGetSome in terms of hGetBufSome requires conversion from a MutableByteArray to a ByteString, which is possible using unsafeByteArrayToByteString or copyByteArrayToByteString. The former function is a little bit hacky, but it ensures we don't copy bytes from the MutableByteArray to the ByteString, which is what the latter function would do.

Defining hPutSome in terms of hPutBufSome requires conversion from a ByteString to a MutableByteArray. This will not always be possible without copying, because a ByteString is a ForeignPtr under the hood which is a Ptr with optionally a reference to its underlying MutableByteArray. If the reference isn't there, then we can do nothing but copy the bytes to a fresh MutableByteArray.

The question is: do we want to keep both the "old" and the "new" primitives, if we can't ensure that the new primitives are as performant as the old ones?

@jorisdral jorisdral force-pushed the jdral/bench-redefine-hgetsome branch 4 times, most recently from 7f6f0d0 to e508cf7 Compare April 23, 2024 15:01
The function is now no longer constrained to `PrimBase m`, but any `m` for which
`PrimState m ~ PrimState IO`.
…ions.

`hGetSome'` is a new function that provides the same functionality as
`hGetSome`, but uses the `hGetSomeBuf` primitive. Similary, we implement a new
`hGetSomeAt'` function that provides the same functionality as `hGetSomeAt`.
These comparative benchmarks should show whether we can replace the
`hGetSome(At)` primitives with `hGetBufSome(At)` primtives and the new compound
functions.
@jorisdral jorisdral force-pushed the jdral/bench-redefine-hgetsome branch from e508cf7 to 3b57cd3 Compare April 23, 2024 15:44
@jorisdral jorisdral self-assigned this May 1, 2024
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.

1 participant