Roadmap for the stdlib `random` module

Mojo Standard Library
1

These are some questions I asked in the #learn-mojo Discord channel. I’ve been advised to repost them here, and to tag @JoeLoser .

Right now everything in random seems hardcoded around the global Philox instance, which is a process-wise global variable (common across all threads) rather than thread-local.

This presumably makes a lot of sense in terms of early stage development (simple to implement, guaranteed to work on the GPU if needed) but has consequences (well documented in the code): use across multiple threads requires a sync mechanism to avoid race conditions. This leaves the user faced with either a multithreaded performance bottleneck, or limits them to writing single-threaded code, or puts them in a roll-your-own scenario where they have to re-implement a lot of the wrapper functionality that currently assumes the global RNG.

My question is, are there existing roadmap plans for how this will evolve (presumably involving defining traits that RNGs and/or PRNGs must implement, and adding overloads to random functions that accept an RNG parameter implementing those traits)? And if so, is there any interest in contributions to this right now, or is this something best left until after the 1.0 release is out?

Alternatively: are there any library projects working on more fully featured random support which are worth using and contributing to in the meanwhile?

Thanks for any thoughts and advice anyone can offer,

–Joe

2 Likes
2

Apparently he’s @joe on the forums.

1 Like
3

Hi @JosephWakeling thanks for opening this forum discussion!
I don’t have all the answers but I’ll do my best to answer the big points you bought up.

This is correct. Currently the generator is “global” is the sense that it is shared across all threads and would require synchronization. Theoretically we could provide a thread-local generator. One thing to note, it that this isn’t currently an issue with Mojo since we don’t have any multithreading capabilities yet. (We do have a parallelize, though this is only really used on the GPU). Because we don’t support multithreading (unless you manually write calls to pthread for example) we haven’t had this be much of an issue. Most of our usage of PRNG is for test code. But even for GPU test code, the PRNG is used host-side in a single thread.

This isn’t a priority ATM since we don’t easily support multithreading and PRNG is only really used in test code on our end. There is a bunch of room for improvement in terms of potential PRNG traits or us supporting multiple different PRNG algorithms. However, this likely won’t be until post-1.0.
That being said, if you feel passionate about this, please feel free to make some Github issues to help track this work! You could even make a [proposal] lining out what you would like to see for a PRNG trait.

I’m not too sure about this. However, if you ask around in the Discord, I’m sure other Mojo devs might have some side projects they are working on!

1 Like
4

I have some vague memory (no pun intended) of someone else playing with random. My search came up empty.

There’s a couple of scientific modules like

NuMojo/numojo/routines/random.mojo at main · Mojo-Numerics-and-Algorithms-group/NuMojo · GitHub. though I think you’re asking about something different.

I seem to vaguely remember a more specific random module. If it comes to me, I’ll post it here.

1 Like
5

Completely fair and understandable.

I was thinking a good start might be to craft a small standalone library that sketches out some design ideas, which could inform a later [proposal]. I’d be happy to put some time into that, although no promises about when (I need to spend more time getting my head around Mojo idioms first). Just wanted to make sure I didn’t step on the toes of any existing projects before doing that.

2 Likes