Continuing the Journey: A Community-Maintained Fork for Modern C++ and Platform Support

[JkarVN]

Dear Professor O'Neill (@imneme) and the PCG community,

First of all, thank you for the incredible work on the PCG family of generators. It has been a cornerstone for high-quality random number generation in the C++ community for years.

As the original repository has not seen updates for over 3 years, many users (including ourselves) have encountered significant hurdles when integrating pcg-cpp into modern environments. Specifically, the community has produced several critical patches that remain unmerged:

Windows ARM64 Support: Essential for modern mobile and desktop hardware (contributed by Demonese).

MSVC Compatibility: Fixing C2678 ambiguous operator errors on Windows (contributed by Jkar).

Fallback for 128-bit types: Ensuring functionality on systems/compilers without __uint128_t (contributed by rstub).

To ensure these improvements are available to everyone and to provide a stable, actively maintained home for this library, we have established the Total-Random organization. We have integrated the fixes mentioned above and are committed to maintaining the library for modern C++ standards (C++17/20/23) and cross-platform compatibility.

Our goal is not to replace the original vision, but to keep it alive and functional for today's development landscape.

For anyone looking for an actively maintained version of pcg-cpp with the latest fixes, you can find our fork here: Total-Random/pcg-cpp
We welcome any feedback and would be honored to collaborate if the original project ever resumes activity.

Best regards, The Total-Random Team

[bhaller]

Somebody needed to do this. Thank you.

The current library builds on C++11. Do you intend to keep compatibility with C++11 going forward? I ask because you wrote "committed to maintaining the library for modern C++ standards (C++17/20/23)" above; I hope C++11 will continue to be supported, as my project is not yet ready to move to C++17.

[JkarVN]

Somebody needed to do this. Thank you.

The current library builds on C++11. Do you intend to keep compatibility with C++11 going forward? I ask because you wrote "committed to maintaining the library for modern C++ standards (C++17/20/23)" above; I hope C++11 will continue to be supported, as my project is not yet ready to move to C++17.

Thank you for asking. I would like to confirm my commitment to continuing to use C++11, as previously stated. I also ensure that the code will remain compatible and will not cause issues when compiled with C++17, C++20, C++23, or newer standards in the future

[JkarVN]

@bhaller

We have officially released version v1.0.0 at Total-Random/pcg-cpp. All future changes will be rigorously tested to ensure they do not affect simulation projects such as SLiM. We very much look forward to receiving your feedback.

[bhaller]

@bhaller

We have officially released version v1.0.0 at Total-Random/pcg-cpp. All future changes will be rigorously tested to ensure they do not affect simulation projects such as SLiM. We very much look forward to receiving your feedback.

Sounds good. I've just switched to this release. I gave a bit of feedback at https://github.com/orgs/Total-Random/discussions/1#discussioncomment-15320469. Thanks!

[david-fong]

• What involvement has LLM or related AI technology had (or will it have) on this fork?
• "Best regards, The Total-Random Team" - who is in this team? Do you have a track record for maintaining open-source libraries?
• Do you plan to address Cache misses with ccache when pcg-cpp is included, possibly due to __DATE__ and __TIME__ #59?

[bhaller]

@david-fong these are good questions. It may be an AI-driven project; it has that feel to it. I got an invite to join the team, and accepted because why not, and it appears to be only @JkarVN and, now, myself (although I've made no contribution). JkarVN's profile says that they are part of the "Sao Tin Developer Team", and googling that turns up a web page (saotin.kesug.com) that describes a software group that does seem to be in the AI space; it says "And thank you Google Colab for providing server services, supporting us in training AI models". And the messages posted, etc., have the feel of being AI-generated or AI-assisted – although many people for whom English is not a first language (@JkarVN's profile indicates they are from Vietnam) use AI to help with writing in English, so I wouldn't necessarily read too much into that.

In the end, I'm not sure what I think about this. I'm not a fan of AI in software development, and don't use it myself. At the same time, this repo is pretty much abandoned (sadly), and there's a need for a fork that takes up the reins and provides something that is maintained, merges PR fixes, etc. I'm not aware of another fork doing this; I poked around a while back and didn't find one that looked well-maintained. I actually emailed the author of PCG a while back, too, saying how useful it is and how it'd be great if it got maintained a bit more; I got no reply from her, who knows why (I hope she's OK). So even if this fork is AI-driven, it seems to me they're doing the community a service. I don't know. I'd be interested to hear your thoughts on all this; I'm rather naive in this area (your questions didn't even occur to me!). For the time being, I diffed the fork vs. this repo's head and the changes in the fork look innocent to me; at least one set of changes was taken from an unmerged PR here.

[david-fong]

I also emailed Melissa this year and got no reply. I'd really like for this project to be actively maintained, and at one point thought of starting up a fork, but I just don't feel like I have good coverage of the expertise to do it well. I know some things about cross platform library development and CMake, but I'm no PRNG expert, I tend only to use the more recent language standards, and mostly only build on Linux. If I were to fork, those limitations and biases/preferenes of mine would definitely show. Someone on reddit mentioned they started an effort at https://github.com/brt-v/pcg-cpp.

I guess I'm just hoping for a magical scenario where someone(s) who crosses my personal threshold of trustworthiness, is fairly competent, and shares similar library concerns to me starts maintaining a fork. I did try to look into who jkarVN is or what track record they have, and found the same things you did. I share similar feelings about AI, and the writing style here (and around the new commits in the fork, and in this person's post and reply comments on reddit) did raise flags for me. I think it's positive that people want to contribute an actively maintained fork of the repo, but honestly, I'm sceptical about this one (especially with recent supply-chain, real-life horror stories like with xz-utils). I guess time will tell. While tempting, I don't think I'm going to be switching over to this in my own project.

Very tangentially, (remember that I'm no PRNG expert), I wonder how Philox in C++26 compares to PCG.

[bhaller]

I also emailed Melissa this year and got no reply. I'd really like for this project to be actively maintained, and at one point thought of starting up a fork, but I just don't feel like I have good coverage of the expertise to do it well. I know some things about cross platform library development and CMake, but I'm no PRNG expert, I tend only to use the more recent language standards, and mostly only build on Linux. If I were to fork, those limitations and biases/preferenes of mine would definitely show. Someone on reddit mentioned they started an effort at https://github.com/brt-v/pcg-cpp.

Yeah, I don't know much about PRNGs either. I just glanced at that other fork you linked; it looks like more of a complete overhaul of the code, whereas this Total-Random fork seems like quite a minimal approach of just fixing bugs (which I prefer, unless I know that the maintainer really comprehensively understands the code they're rewriting!). Also, that other fork explicitly targets C++17, so it's unusable for me; I'm on C++11 and have no intention of moving forward for a while yet, since I have a large number of users and some of them are doubtless on very old platforms.

It's a real shame that Melissa is gone. Like I said, I hope she's OK. :-<

I guess I'm just hoping for a magical scenario where someone(s) who crosses my personal threshold of trustworthiness, is fairly competent, and shares similar library concerns to me starts maintaining a fork. I did try to look into who jkarVN is or what track record they have, and found the same things you did. I share similar feelings about AI, and the writing style here (and around the new commits in the fork, and in this person's post and reply comments on reddit) did raise flags for me. I think it's positive that people want to contribute an actively maintained fork of the repo, but honestly, I'm sceptical about this one (especially with recent supply-chain, real-life horror stories like with xz-utils). I guess time will tell. While tempting, I don't think I'm going to be switching over to this in my own project.

Well, I'm switching over for now since it does provide a couple of bug fixes – although it leaves out various other fixes in PRs here that also seem good, so I wonder how @JkarVN chose which PRs to merge. If it starts to go off the rails, I can always switch back; I'm not actually dependent on any of the changes in the fork yet. For now, I wanted to adopt it to express support for the idea of someone making a well-maintained fork of the project.

Very tangentially, (remember that I'm no PRNG expert), I wonder how Philox in C++26 compares to PCG.

Interesting, I wasn't aware of that. Since I'm stuck on C++11, it's not an option for me, of course.

[JkarVN]

@bhaller @david-fong
Tôi: Được rồi tôi xin lỗi mọi người trước Tôi không giỏi tiếng anh. Tất cả các câu mọi ngưới thấy điều do AI dịch như tôi xin khắn định lại tôi chỉ dùng AI để dịch từ ngôn ngữ của mình sang tiếng việt Cảm ơn mọi người đã chỉ ra tôi sẽ cối rắng ơn cảm ơn vì tất cả!

Gemin: Alright, first of all, I apologize for my English. Everything you see here is translated by AI. To be clear, I'm using AI to translate from my native language. Thank you for pointing out the mistakes; I will try my best to improve. Thanks for everything!

[bhaller]

@bhaller @david-fong Tôi: Được rồi tôi xin lỗi mọi người trước Tôi không giỏi tiếng anh. Tất cả các câu mọi ngưới thấy điều do AI dịch như tôi xin khắn định lại tôi chỉ dùng AI để dịch từ ngôn ngữ của mình sang tiếng việt Cảm ơn mọi người đã chỉ ra tôi sẽ cối rắng ơn cảm ơn vì tất cả!

Gemin: Alright, first of all, I apologize for my English. Everything you see here is translated by AI. To be clear, I'm using AI to translate from my native language. Thank you for pointing out the mistakes; I will try my best to improve. Thanks for everything!

Don't worry. I chose to have this conversation in public because I thought you should know. But I still think you are doing a good and useful thing, and I thank you for it. We just have some questions and concerns that it would be good for you to address when you have time. But it's OK; please continue to do this work, I support it.

[david-fong]

I appreciate the invite to join the org, but without rapport, I'm not interested in just giving you my IP address (which apparently is part of the package when joining a GH org). I don't know if I want to invest in this at this point. But I hope what you do comes to good for others.

[david-fong]

Apologies for hijacking the ticket, but out of curiosity, @bhaller what's the reason you / your users are stuck on C++11? Are you stuck to a situation that just don't allow for compilers and standard library implementations that support those language versions? Is there some sort of upstream library ABI break that you can't do?

[bhaller]

Hi @david-fong,

Apologies for hijacking the ticket, but out of curiosity, @bhaller what's the reason you / your users are stuck on C++11? Are you stuck to a situation that just don't allow for compilers and standard library implementations that support those language versions? Is there some sort of upstream library ABI break that you can't do?

I work on a simulator (https://messerlab.org/slim/) that is widely used by research groups around the world. Many, perhaps most, of its users are not computational people, but rather biologists, and they're often using my software on platforms that they don't have much control over – university-supplied machines such as computing clusters. Systems like that are often way behind the times, because their administrators are very conservative. This is for understandable reasons – they don't want to break the existing workflows of their many users. And that fact kind of forces me into the same mode, of being very conservative so that I don't break the existing workflows of my many users. If I pushed forward to C++17, I'm sure that it would cause some of my users considerable difficulties, since they might be using a very old compiler etc. that is not compatible with C++17. Especially since they wouldn't know how to fix the problem (and I wouldn't really either – I mostly work on macOS, but many of my users are on Linux or Windows, so providing support can be challenging). Probably I will do it anyway, eventually, since there would be benefits to being on C++17; but I am waiting for a strong reason to justify the transition. That fork of PCG that requires C++17 is not nearly a strong enough reason. :->

[david-fong]

@bhaller Thanks for your reply! That makes sense. Seems unfortunate to me though :P

[bhaller]

@bhaller Thanks for your reply! That makes sense. Seems unfortunate to me though :P

@david-fong A little bit unfortunate. So far not significantly limiting, really.