| Time |
Nick |
Message |
| 04:00 |
|
MTDiscord joined #minetest-docs |
| 09:28 |
|
appguru joined #minetest-docs |
| 10:27 |
MTDiscord |
<luatic> We need to decide on how we want benchmarking to work |
| 10:29 |
MTDiscord |
<luatic> 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 |
<luatic> obviously, I would be noting my rough specs, Minetest version & LuaJIT when including this in a doc |
| 10:32 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> Brought https://github.com/minetest/minetest_docs/pull/13 to ready to review state |
| 13:59 |
|
Desour joined #minetest-docs |
| 14:13 |
MTDiscord |
<luatic> If I get one approval, I'll push a commit to master that removes all table styling. |
| 15:45 |
MTDiscord |
<Jonathon> merging https://github.com/minetest/minetest_docs/pull/13 in 10 minnutes |
| 15:45 |
MTDiscord |
<Jonathon> *minutes |
| 15:58 |
MTDiscord |
<luatic> do we really need to announce the merging of PRs? |
| 16:13 |
MTDiscord |
<Jonathon> officially? no |
| 16:14 |
MTDiscord |
<Jonathon> if you dont want it, ill just hit the button from now on when i review something |
| 16:29 |
MTDiscord |
<GreenXenith> @Ubuntu benchmarks are not something that should be a focus in api documentation |
| 16:30 |
MTDiscord |
<GreenXenith> Especially not at the beginning |
| 16:41 |
MTDiscord |
<luatic> 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 |
<GreenXenith> And as for organization, we should probably organize it similar to the modding book |
| 17:04 |
MTDiscord |
<rubenwardy> 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 |
| 17:16 |
|
appguru joined #minetest-docs |
| 18:00 |
|
Desour joined #minetest-docs |
| 20:10 |
|
Desour joined #minetest-docs |
