Add the wtx project

[c410-f3r]

wtx is a RFC7541 and RFC9113 implementation written in Rust with built-in support for gRPC connections.

Here goes a local benchmark comparing java_vertex_grpc, dotnet_grpc and tonic_mt.

[c410-f3r]

Erhhh... That is strange... Didn't encounter these CI errors in my local run.

I will investigate

[c410-f3r]

Should probably be fine now

Although the new results are not as interesting as before.

[LesnyRumcajs]

Thanks for the contribution! I left some comments.

[c410-f3r]

Thanks for the review

[LesnyRumcajs]

Let's omit this flag. The reason it is not in other Rust implementations is that it:

1. May result in an illegal instruction segfault in some CPUs.
2. Image built on one machine may crash on another one.

There shouldn't be an assumption that the binary will be run on the exact same CPU where it was built. In practice, it's rarely the case.

[c410-f3r]

grpcio/tonic explicitly use this compiler flag and wtx performs manual vectorization when processing HPACK headers.

let mut iter = ArrayChunks::new(hpack_bytes);
for [a, b, c, d] in iter.by_ref() {
  // Process a...
  // Process b...
  // Process c...
  // Process d...
}

So target-cpu=native does have a great impact in the final generated assembly.

Trying a middle ground, I renamed everything from native to x86-64-v3. OK?

[LesnyRumcajs]

To my understanding, the fact that libraries use a certain parameter doesn't matter much when using them in external projects. The flags that matter are defined in the target binary settings, e.g., here.

If we are to use this optimisation, it should be used across the board in all projects that have this option (all Rust ones, likely C/C++ as well). This can be potentially a follow-up PR.

[c410-f3r]

In trifectatechfoundation/zlib-rs#123, a benchmark that should have been tied resulted in a performance difference of 80% due to the lack of rustflags = [ "-C", "target-cpu=native" ] (https://www.phoronix.com/news/Gentoo-x86-64-v3-Binaries).

Rustc, as well as gcc/clang, defaults to a conservative set of x86 instructions and while the performance difference may not be as huge as the linked issue, some slowdown is likely going to occur.

$ rustc --print target-cpus

    x86-64                  - This is the default target CPU for the current build target (currently x86_64-unknown-linux-gnu).
    x86-64-v2
    x86-64-v3
    x86-64-v4

But yeah, I will just remove this parameter from all projects to make things more fair. Is that OK?

[LesnyRumcajs]

Oh, it's my bad. I think I didn't check through the hidden directories it seems. Sorry for that!

Let's have it they way you had it originally, with the native in wtx.

[c410-f3r]

Sure, no problem!

[LesnyRumcajs]

It's likely not needed.

❯ docker run --rm rust:1.76 gcc --version
gcc (Debian 12.2.0-14) 12.2.0

Suggested change

RUN apt-get update && apt-get install gcc -y

[c410-f3r]

Removed

[LesnyRumcajs]

Is this supposed to utilize multiple threads as well? If so, I recommend setting the thread workers count manually, same as in https://github.com/LesnyRumcajs/grpc_bench/blob/66229fa6aae1f832b8f4642ea894131372a6ffd0/rust_tonic_mt_bench/src/main.rs#L31C9-L40. Otherwise, the app will likely see host CPUs and distribute the workload suboptimally.

[c410-f3r]

My goodness, thank you for spotting this oversight.

[LesnyRumcajs]

LGTM, thanks!

[c410-f3r]

Thank you @LesnyRumcajs