echoclient: initialize variable to fix building with gcc 12.1

See merge request i4/manycore/emper!388

pulse: only measure time between work creation and dispatching it

See merge request i4/manycore/emper!386

runtime: do not notify workers about termination if they do not sleep

See merge request i4/manycore/emper!387

I stumbled upon this because the no-sleep variants in the pulse evaluation
showed notifications in their stats.

We do not need to measure the work duration which is the known pulse.
This makes comparing the raw data easier because the latency does not
include the pulse duration.

fsearch: add possible semaphore limiting the concurrenct open requests

See merge request i4/manycore/emper!382

add additional mode of introducing work

See merge request i4/manycore/emper!383

The default is Burst mode which inserts new work as fast as possible
sleeping until the next pulse.
Even mode distributes the new work evenly in the duration between two
pulses.

Improve pulse evaluation

See merge request i4/manycore/emper!381

[io] Transform assert() to EMPER_ASSERT_MSG() in GlobalIoContext

See merge request i4/manycore/emper!380

[apps/FibChildStealing] Improve fibNum arg parsing

See merge request i4/manycore/emper!379

We recently saw this assert triggering in our CI. Let's yank up its
verbosity.

Also, don't set an unsigned to -1…

make sleep semaphore threshold configurable

See merge request i4/manycore/emper!378

increase the sleep semaphore threshold

See merge request i4/manycore/emper!377

Pulse: initial pulse evaluation commit

See merge request i4/manycore/emper!376

fsearch: add more fine grained control about the used fiber throttles

See merge request i4/manycore/emper!375

Also remove the negation of the condition (!> equals <=).

We currently use the semaphore of our sleep strategy very greedy.
This is due to skipping the semaphore's V() operation if we are sure
that it does not kill our progress guaranty.

When scheduling new work from within the runtime we skip the wakeup if
we observe nobody sleeping. This is fine in terms of progress and
limits the amount of atomic operations on global state to a minimum.

Using a threshold of 0 (observe nobody sleeping) however introduces a
race between inserting new work and going to sleep which harm the
latency when the worker goes to sleep and is not notified about the
new work.

This race is common and can be observed in the pulse micro benchmark.
A emper with a threshold of 0 shows high latency compared to using
an io-based sleep strategy or when increasing the threshold.

$ build-release/eval/pulse | python -c "<calc mean>"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1721970116.425

$ build-increased-sem-threshold/eval/pulse | python -c "<calc mean"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000023942.15

$ build-pipe-release/eval/pulse | python -c "<calc mean>
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000030557.0861111

$ build-pipe-no-completer/eval/pulse | python -c "<calc mean>"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000021514.1805556

I could not measure any significant overhead due to the more atomics
on my 16 core machine using the fs-eval on a SSD.

$ ./eval.py -r 50 -i emper-vanilla emper-inc-sem-threshold emper-pipe emper-pipe-no-completer
...
$ ./summarize.py results/1599f44-dirty-pasture/<date>/ -f '{target}-{median} (+- {std})'
duration_time:u:
emper-vanilla-0.202106189 (+- 0.016075981812486713)
emper-inc-sem-threshold-0.2049344115 (+- 0.015348506939891596)
emper-pipe-0.21689131 (+- 0.015198438371285145)
emper-pipe-no-completer-0.1372724185 (+- 0.005865720218833998)

add io synchronous option

See merge request i4/manycore/emper!373

Eventfd's does not support seeking. This is also invalid code:

int main() {
    int64_t b = 42;
    int efd = eventfd(0, 0);
    if (efd < 0) err(EXIT_FAILURE, "creating eventfd failed");
    ssize_t res = pwrite(efd, &b, sizeof(b), 0);
    if (res != sizeof(b)) err(EXIT_FAILURE, "pwrite to evfd failed");
}

When EMPER is build with -Dio_synchronous each Future will be
completed synchronously when calling Future::wait().

io: improve recursive_directory_walk

See merge request i4/manycore/emper!374

* Add optional throttle Semaphore pointer to limit the number
  of spawned fn as well as directory walk fibers
* Use const references to the passed functions instead of values
* fsearch: Use max_running as fn and recursion throttle

[EchoServers] improve the callback based echoserver

See merge request i4/manycore/emper!371

* Pass the IO results on the stack instead of storing them in the
  client object.
* Terminate the runtime on quit to print stats.
* Free Client objects.

Run clang tidy in parallel

See merge request i4/manycore/emper!372