done

Can't edit top post now, the structure guidelines are here: https://docs.codewars.com/authoring/guidelines/description#structure

• Sample tests noItemsJustMoreTimesDeclared and someNoValuesAsWellAsSomeHaveValuesAssigned are expecting incorrect results
• Please remove unexplained weird special cases like "empty data containers"
• Author's solution occasionally but reproducibly times out. The performance tests need to be more lenient.
• Please provide number of random tests and input size in kata description.
• Please use Markdown formatting and follow kata description [structure guideline]. The current conversational style has a lot of useful information but it's poorly formatted, completely mixed up, and mixed in with a lot of unnecessary words, so it's very difficult to refer to when coding.

Some possible improvements

• Better feedback in random tests: Consider adding a print every, say, 100 tests to let user know how much more to optimize.

More comments in spoilered comment below:

The way AtomicU32 is used here doesn't make sense. Using static mut in multiple threads without other synchronization is straight up undefined behavior, and get_mut completely defeats the purpose of atomics in the first place.

static TESTCHECK: AtomicU32 = ... and fetch_add is probably what was intended. See: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU32.html#method.fetch_add

Anyone reading, feel free to continue discussing, but since this has nothing to do with improving the kata I'm marking this as resolved.

I suppose a slightly more detailed explanation is in order. Neither of the two changes the resulting binary at all; it's purely an aesthetic concern.

For the and/andi one, yes the assembler is being permissive here.

For the li one...

The compressed instruction extension has 16-bit versions of c.mv and c.li. However, the source of c.mv cannot be x0/zero. The assembler here helpfully transforms mv a0, 0 into addi a0, zero, 0 then into c.li a0, 0, but I'd want li here to remind us that this is closer to how the instruction gets encoded.

Nothing really I'd say is wrong here, but some nitpicks:

• and t0, a0, 3 and and t0, t0, 3: and -> andi
• mv a0, zero -> li a0, 0 (twice)

TODO:

• Test against a range of possible lengths
• Check over overwriting past the end
• Seed with getrandom(2)

See test cases for https://www.codewars.com/kata/636b75101b60ba002e3953e2

TODO:

• Test against a range of possible lengths
• Check over overwriting past the end
• Seed with getrandom(2)

See test cases for https://www.codewars.com/kata/636b75101b60ba002e3953e2

TODO:

• Test against a range of possible lengths
• Seed with getrandom(2)

See test cases for https://www.codewars.com/kata/636b75101b60ba002e3953e2

TODO:

• Test against a range of possible lengths
• Check over overwriting past the end
• Seed with getrandom(2)

See test cases for https://www.codewars.com/kata/636b75101b60ba002e3953e2

TODO:

• Test against a range of possible lengths
• Check over overwriting past the end

See test cases for https://www.codewars.com/kata/636b75101b60ba002e3953e2

I've found a standard way to represent (real) floating point values exactly — hex float literals. Can you go over this fork and see if it's satisfactory?

https://www.codewars.com/kumite/6512e3e65bf8500b9aa77a33?sel=6512e3e65bf8500b9aa77a33