sched: Reverse runqueue order when CLZ is available

[bergzand]

Contribution description

This PR reverses the runqueue_cache bit order when the architecture has a
CLZ (count leading zeros) instruction. When the architecture supports
CLZ, it is faster to determine the most significant set bit of a word
than to determine the least significant bit set. Unfortunately when the
instruction is not available, it is more efficient to determine the
least significant bit set.

Reversing the bit order shaves off another 4 cycles on the same54-xpro.
From 147 to 143 ticks when testing with tests/bench_sched_nop.
Architectures where no CLZ instruction is available are not affected.

Testing procedure

• Binaries without CLZ instruction are not changed.
• scheduling still works on the affected architectures. (It breaks horribly and fast if this doesn't work)
• As mentioned above, a slight increase in scheduling performance should be observed.

Background info

Previously the __builtin_ffs() is used to determine the least significant bit set. On platforms where CLZ is used this is implemented as

unsigned __builtin_ffs(uint32_t v)
{
    return 31 - CLZ(v & -v);
}

Reversing the bitorder allows direct use of the CLZ instruction removes the v & -v, shaving off these cycles.

Issues/PRs references

None

[maribu]

After reading the PR description, I expected pretty messy code. The helper functions however resulted in the distinction being nicely contained, so that the code actually looks quite good :-)

[maribu]

On the Nucleo-F767ZI:

PR:

  text	   data	    bss	    dec	    hex	filename
  13468	    132	   3948	  17548	   448c	/home/maribu/Repos/software/RIOT/tests/bench_thread_yield_pingpong/bin/nucleo-f767zi/tests_bench_thread_yield_pingpong.elf

main(): This is RIOT! (Version: test)
main starting
{ "result" : 304225, "ticks" : 710 }

master:

   text	   data	    bss	    dec	    hex	filename
  13468	    132	   3948	  17548	   448c	/home/maribu/Repos/software/RIOT/tests/bench_thread_yield_pingpong/bin/nucleo-f767zi/tests_bench_thread_yield_pingpong.elf

main(): This is RIOT! (Version: test)
main starting
{ "result" : 325301, "ticks" : 664 }

[bergzand]

On the Nucleo-F767ZI:

Not sure what's going on here for you, I can't reproduce it on my nucleo-f746zg.

On my nucleo-f746zg:
PR:

2020-08-06 22:26:53,865 # main(): This is RIOT! (Version: 2020.10-devel-597-gab1d0b-pr/sched/runqueue_clz)
2020-08-06 22:26:53,866 # main starting
2020-08-06 22:26:54,869 # { "result" : 329053, "ticks" : 656 }
2020-08-06 22:26:57,785 # Exiting Pyterm

Master:

2020-08-06 22:27:15,295 # main(): This is RIOT! (Version: 2020.10-devel-596-g01e6b-HEAD)
2020-08-06 22:27:15,297 # main starting
2020-08-06 22:27:16,300 # { "result" : 302097, "ticks" : 715 }

[bergzand]

On the Nucleo-F767ZI:

I can reproduce these results on a different nucleo-f767ZI though 😢

[kaspar030]

I can reproduce these results on a different nucleo-f767ZI though cry

try cold if cold booting makes a difference.

[bergzand]

try cold if cold booting makes a difference.

Doesn't make a difference on the nucleo-f746zg. I don't have local access to the nucleo-f767zi, I can't power cycle it.

[maribu]

I get reproducible results on the Nucleo-F767ZI. If I use BUILD_IN_DOCKER=1, the ROM gets smaller (my local newlib is more recent and more bloaty), but the performance numbers are identical. Those numbers remain identical after power cycling. Warm boot and cold boot don't make a difference.

If this PR results in better performance for most boards, this shouldn't block this though.

[bergzand]

When I flash my nucleo-f746zg with an ELF file compiled for the nucleo-f767zi I get the same numbers posted earlier by @maribu for the nucleo-f767zi.

[bergzand]

The other way around also holds true. Flashing an nucleo-f767zi with a build for the nucleo-f746zg works perfectly and shows identical numbers as nucleo-f746zg hardware.

I wonder if we're running into a software issue causing these odd results on the stm32f767zi

[bergzand]

tests/bitarithm_timings confirms these numbers:

Nucleo-f746zi:

2020-08-06 23:34:22,979 # START
2020-08-06 23:34:22,984 # main(): This is RIOT! (Version: 2020.10-devel-596-g01e6b-HEAD)
2020-08-06 23:34:22,985 # Start.
2020-08-06 23:34:27,989 # + bitarithm_msb: 4529488 iterations per second
2020-08-06 23:34:32,994 # + bitarithm_lsb: 3793632 iterations per second
2020-08-06 23:34:37,998 # + bitarithm_bits_set: 2145251 iterations per second
2020-08-06 23:34:43,003 # + bitarithm_test_and_clear: 776978 iterations per second
2020-08-06 23:34:43,004 # Done.

Nucleo-f767zg:

2020-08-06 23:34:25,451 # START
2020-08-06 23:34:25,457 # main(): This is RIOT! (Version: 2020.10-devel-596-g01e6b-HEAD)
2020-08-06 23:34:25,457 # Start.
2020-08-06 23:34:30,462 # + bitarithm_msb: 4023283 iterations per second
2020-08-06 23:34:35,466 # + bitarithm_lsb: 4601862 iterations per second
2020-08-06 23:34:40,471 # + bitarithm_bits_set: 395107 iterations per second
2020-08-06 23:34:45,476 # + bitarithm_test_and_clear: 1830507 iterations per second
2020-08-06 23:34:45,477 # Done.

[maribu]

A quick look at the binaries using elf_diff seems that only vectors_cpu differ for those boards, and the remaining diffs are due to different target addresses for branches/jumps/calls due to the different memory layout (due to the different size of vectors_cpu). All other symbols have the same size.

[bergzand]

I've put what I've found out so far in #14728. I don't consider the issue related to this PR and I would prefer not to have that block this PR here.

[kaspar030]

Code looks OK. Seems like a nice optimization. Do we need benchmarks for some boards with / without CLZ? (ignoring the F7 for now)

[bergzand]

Ticks as printed by the tests. The samr21-xpro doesn't have the CLZ instruction and is indeed unaffected by this PR.

Mutex ping-pong:

	Pre	Post
samr21-xpro	735	735
nucleo-f103rb	656	641
same54-xpro	471	463

Sched nop:

	Pre	Post
samr21-xpro	241	241
nucleo-f103rb	209	198
same54-xpro	147	143

[kaspar030]

ACK.

Small improvement. Code not too ugly.

[bergzand]

Thanks!