areusch commented on a change in pull request #7266:
URL: https://github.com/apache/tvm/pull/7266#discussion_r560359820
##########
File path: src/runtime/crt/host/main.cc
##########
@@ -93,6 +94,20 @@ tvm_crt_error_t TVMPlatformTimerStop(double*
elapsed_time_seconds) {
g_utvm_timer_running = 0;
return kTvmErrorNoError;
}
+
+static_assert(RAND_MAX >= (1 << 8), "RAND_MAX is smaller than acceptable");
+unsigned int random_seed = 0;
+tvm_crt_error_t TVMPlatformGenerateRandom(uint8_t* buffer, size_t num_bytes) {
+ if (random_seed == 0) {
+ random_seed = (unsigned int)time(NULL);
+ }
+ for (size_t i = 0; i < num_bytes; ++i) {
+ int random = rand_r(&random_seed);
+ buffer[i] = (uint8_t)random;
Review comment:
this is one of those really tricky areas in embedded. you could imagine
factoring out the logic for that into a library function, but you would be
implicitly relying on:
1. link-time optimization to ensure the common impl gets deleted when not
used
2. a function pointer, which may defeat any inlining
3. an assumption that most platforms can generate 32-bit random numbers,
from the POV of making the conceptual complexity worth adding
so for "glue-like" logic like this, unfortunately my opinion is that it's
best to copy-paste the stub that fits your particular situation. an embedded
transpiler would really help cases like this, but that drags in another debate
:)
I think given the main difference is a linear speedup in random blob
generation on host simulation, and rand_r should not syscall, i'm going to
defer any potential change here to the next PR (which enables autotuning and
relies on this RNG a lot more).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
