Time Nick Message 10:27 MTDiscord We need to decide on how we want benchmarking to work 10:29 MTDiscord For example, I've been benchmarking random: lua collectgarbage"stop" -- we don't want GC heuristics to interfere local n = 1e8 -- number of runs local function bench(name, constructor, invokation) local func = assert(loadstring(([[ local r = %s for _ = 1, %d do %s end ]]):format(constructor, n, invokation))) local t = minetest.get_us_time() func() print(name, (minetest.get_us_time() - t) / n, "µs/call") end 10:29 MTDiscord bench("Lua", "nil", "math.random()") bench("PCG", "PcgRandom(42)", "r:next()") bench("K&R", "PseudoRandom(42)", "r:next()") bench("Secure", "assert(SecureRandom())", "r:next_bytes()") and I get: Lua 0.00385002 µs/call PCG 0.05579729 µs/call K&R 0.05859349 µs/call Secure 0.11211887 µs/call which is quite conclusive (yes, it's kinda an apples-to-oranges comparison with SecureRandom in particular) but obv. this 10:29 MTDiscord benchmark needs to be repeated on different devices, so I'm asking you to repeat it could/should we perhaps involve GitHub CI here? a complexity analysis is useless here, all methods are O(1) 10:31 MTDiscord obviously, I would be noting my rough specs, Minetest version & LuaJIT when including this in a doc 10:32 MTDiscord I want to draw the following conclusion: adoc === Conclusion . *Never use `PseudoRandom`. It is strictly inferior to `PcgRandom`.* . Use `math.random` if you want a fast "non-deterministic" random. . Use `PcgRandom` if you need per-instance seedability and can take the performance hit. . Use `SecureRandom` if and only if you *really need* a cryptographically secure random. which requires the benchmark to prove the strict inferiority 10:32 MTDiscord of PseudoRandom 10:45 MTDiscord Also, another point: I like grouping docs by topic rather than grouping them by how the Minetest API is grouped since that would be quite a mess. I've been working on a doc for random for instance, and I'm documenting & comparing the random classes there. I'm wondering whether I should move the class docs to a subfolder random of the classes folder which would then also contain the "guide" on random in Minetest? 13:58 MTDiscord Brought https://github.com/minetest/minetest_docs/pull/13 to ready to review state 14:13 MTDiscord If I get one approval, I'll push a commit to master that removes all table styling. 15:45 MTDiscord merging https://github.com/minetest/minetest_docs/pull/13 in 10 minnutes 15:45 MTDiscord *minutes 15:58 MTDiscord do we really need to announce the merging of PRs? 16:13 MTDiscord officially? no 16:14 MTDiscord if you dont want it, ill just hit the button from now on when i review something 16:29 MTDiscord @Ubuntu benchmarks are not something that should be a focus in api documentation 16:30 MTDiscord Especially not at the beginning 16:41 MTDiscord Right, I'm probably delving a bit too deep here, but it's definitely crucial. We want mt-docs to be better than just the plain API docs MT already has, and as such, it should contain advice - such as a comparison of random performance. Obviously it's not the focus of the docs, but in this case it is crucial to arrive at the conclusion that K&R's pseudo-random sucks and lacks a raison d'être due to its all-around inferiority. I 16:41 MTDiscord wouldn't have started benchmarks if I hadn't wondered why an inferior random was kept around, so I assumed that it was significantly faster but then realized it... isn't. 16:54 MTDiscord And as for organization, we should probably organize it similar to the modding book 17:04 MTDiscord You need to decide exactly what role you want to play. For a reference, organising by class and entity makes a lot more sense - as you want to group the mods together