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 and might nullify any performance gains you were expecting 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