-
Notifications
You must be signed in to change notification settings - Fork 52
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
Improve uniform ShortByteString
#116
Conversation
Stop relying on `bytestring` for architecture independent generation of `ShortByteString` and `ByteString`
Any idea how to test it on BE arch? |
Besides spinning up an AMD server from some cloud provider, like Hetzner for instance and running tests there, I have no other ideas. |
Which AMD machines are big-endian? I thought all of them are little-endian, as well as modern ARM. |
@juhp I recall you raising s390-related issues at GHC bug tracker. Do you possibly have an access to a big-endian machine to test this patch? |
Oh look at that. AMD is LE too. In that case I have no clue how to get hold of BE hardware :D |
src/System/Random/Internal.hs
Outdated
@@ -105,6 +103,8 @@ import GHC.ForeignPtr | |||
import Data.ByteString (ByteString) | |||
#endif | |||
|
|||
#include "MachDeps.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can avoid CPP: there is GHC.ByteOrder
plus ghc-byteorder
package for old GHCs:
if impl(ghc < 8.4)
build-depends: ghc-byteorder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the suggestion. Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the sake of anyone stumbling on this suggestion, this will not work. See: https://gitlab.haskell.org/ghc/ghc/-/issues/20338
I can probably do a test build in the Fedora buildsystem. You can see our latest release build here for example. So you just want me to build this change? Get the testsuite to run looks rather tricky. |
Here is a scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=74908079 |
@juhp Thank you for your help. Unfortunately it is the |
Okay, I feared as much, perhaps I can get temporary access to a Fedora s390x instance... Otherwise in the worst case we will find out later I guess ;-) |
|
@juhp Awesome!!! Thank you very much for verifying this PR!!! |
Sorry please wait - that was the wrong log... rechecking now |
I ran the testsuite on Fedora 34 s390x now correctly in your branch and I am afraid there was 1 test failure:
(Sorry for the false confirmation earlier) |
@juhp Dammit, that is unfortunate. Thank you for rechecking it! |
@lehins actually, what is our goal here? To produce the same random numbers from the same seed both on LE and BE platforms? Why it does not suffice just to produce some random numbers, but not necessarily the same? |
yes
I don't follow. |
@Bodigrim Not random numbers, but sequence of random bytes |
@Bodigrim I'll describe what is going on in a little more detail: In order to to generate a ByteString (or a However this would generate 64bits for every byte that will be used, which is extremely wasteful and inefficient. What we do instead is generate one There is also an extra issue at the end of a ByteString as well, since we often will have a tail that is smaller than So the failing test in this #116 (comment) depicts that there is a problem in the logic (or in my assumptions of how it works) somewhere and we will get bytes in different order on BE vs LE machines. Now, all I need is to figure out how can I get hands on BE machine so I can experiment with this, I can't be constantly bugging Jens to verify if a change works or not. I suspect the problem was there prior to this PR as well, except the test was not present until now and if anyone would ever run |
It looks like this project lets you run an emulated s390x Ubuntu with QEMU + Docker:
https://github.com/multiarch/qemu-user-static#getting-started That might help. |
Halleluja! I am not going crazy! @curiousleo enormous thank you for this suggestion with docker. It was a bit painful to get it to work, anything complicated like So it appears my sanity is fine and GHC is not reporting ByteOrder correctly: https://gitlab.haskell.org/ghc/ghc/-/issues/20338 @Bodigrim thank you for suggesting to avoid @juhp thank you again for helping debug this. If you don't mind I'll ask you again in a little bit to run the test suite one last time, just to be sure. For now I'll need to bring back the CPP approach first. |
Oh, that's pretty big. Thanks for debugging it. |
Damn, nice find @lehins. |
I was able to use |
😄 As I said, painful indeed |
random-1.2.0 contained a shortcut where architecture independent generation of bytes relied on
bytestring
's builder functionality, which forced us to generateShortByteString
as pinned. This PR fixes that technical debt.This is a non-breaking change.