Conversation
Signed-off-by: Rory Mitchell <[email protected]>
Signed-off-by: Rory Mitchell <[email protected]>
Signed-off-by: Rory Mitchell <[email protected]>
Signed-off-by: Rory Mitchell <[email protected]>
| #endif // !_CCCL_COMPILER(NVRTC) | ||
|
|
||
| private: | ||
| using __uint128_type = unsigned __int128; |
There was a problem hiding this comment.
I still need to implement a fallback int128.
There was a problem hiding this comment.
Do you need this on windows right now? I think it would be easier to guard it by #if _CCCL_HAS_INT128() for now and allow this feature on windows once we have our internal int128 fallback
There was a problem hiding this comment.
From slack it sounded like we wanted to have a complete implementation. I don't think its too hard so I think we can do it here.
There was a problem hiding this comment.
Please, do it in a separate PR
There was a problem hiding this comment.
yeah lets do this as a followup
Signed-off-by: Rory Mitchell <[email protected]>
Signed-off-by: Rory Mitchell <[email protected]>
Signed-off-by: Rory Mitchell <[email protected]>
|
I am a bit unsure about the naming yet and if we would support variants of this engine. I'm thinking as follows: pcg64_engine - PCG XSL RR 128/64 algorithm templated on the multiplier/increment @fbusato maybe you have some thoughts? |
these names are perfectly fine. I'm thinking if there are better names for |
|
/ok to test a628a81 |
|
/ok to test 78e1f4a |
|
/ok to test a289174 |
This comment has been minimized.
This comment has been minimized.
|
/ok to test 5d9cdae |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@davebayer @fbusato please re-review thanks :) |
This comment has been minimized.
This comment has been minimized.
| public: | ||
| using result_type = ::cuda::std::uint64_t; | ||
|
|
||
| private: |
There was a problem hiding this comment.
would be better to keep private members at the end of the class
There was a problem hiding this comment.
Actually not the general advice is to move them to the front, because they are crucial to understand what is in the class
There was a problem hiding this comment.
I normally belong to the "end of class" church, but we can do whatever here :)
There was a problem hiding this comment.
The point being that usually a class implementation starts with constructors and other SMF, so I need to know what are the actual data members. In that case and others I have to jump around to the back of the potentially long definition to know what I am working with
There was a problem hiding this comment.
interesting, I always thought about user perspective. Users are interested to the interface, not implementation details. Also, the implementation rarely changes.
Anyway, I'm fine with both approaches.
| __uint128_t __x_{}; | ||
|
|
||
| public: | ||
| static constexpr result_type default_seed = 0xcafef00dd15ea5e5ULL; |
There was a problem hiding this comment.
| static constexpr result_type default_seed = 0xcafef00dd15ea5e5ULL; | |
| static constexpr result_type default_seed = 0xCAFEF00DD15EA5E5ull; |
There was a problem hiding this comment.
definitely not a rule, but suggested by some c++ secure coding guidelines, e.g. Autosar C++14 Rule A2-13-5 https://www.autosar.org/fileadmin/standards/R18-03_R1.4.0/AP/AUTOSAR_RS_CPP14Guidelines.pdf. ull lowercase to have a clear distinction with uppercase digits
🥳 CI Workflow Results🟩 Finished in 2h 25m: Pass: 100%/88 | Total: 14h 21m | Max: 1h 35m | Hits: 99%/212945See results here. |
|
@fbusato waiting on you :) |
Description
Part of #5679
Depends on #6109