search

project-oak / oak

Meaningful control of data in distributed systems.
Apache License 2.0
1.32k stars 113 forks source link

benchmarks for Wasm invocations for key value lookup module are too slow #4671

Open tiziano88 opened 10 months ago

tiziano88 commented 10 months ago

https://github.com/project-oak/oak/blob/a91172d3ff1144ebe49bc266c7542b5a350d6ebb/oak_functions/examples/key_value_lookup/module/src/tests.rs#L69-L124

Currently this takes around 10ms, which is way more than expected.

From my investigations, it seems that around 7ms of overhead are caused by the creation of a server encryptor:

https://github.com/project-oak/oak/blob/a91172d3ff1144ebe49bc266c7542b5a350d6ebb/oak_crypto/src/encryptor.rs#L259-L267

I also realised that we may be building the application in dev mode (instead of release).

And @andrisaar suggested:

can you try compiling and running with RUSTFLAGS=-C target-cpu=native?

cc @conradgrobler @ernoc @ipetr0v @pmcgrath17

tiziano88 commented 10 months ago

can you try compiling and running with RUSTFLAGS=-C target-cpu=native?

Unfortunately this didn't work at all; when compiling, I got a long list of this kind of warnings:

'+sse2' is not a recognized feature for this target (ignoring feature)
'+rdseed' is not a recognized feature for this target (ignoring feature)
'+avx512vbmi2' is not a recognized feature for this target (ignoring feature)
'-prefetchi' is not a recognized feature for this target (ignoring feature)
'+rdpid' is not a recognized feature for this target (ignoring feature)
'-fma4' is not a recognized feature for this target (ignoring feature)
'+avx512vbmi' is not a recognized feature for this target (ignoring feature)
'+shstk' is not a recognized feature for this target (ignoring feature)
'+vaes' is not a recognized feature for this target (ignoring feature)
'-waitpkg' is not a recognized feature for this target (ignoring feature)
'-sgx' is not a recognized feature for this target (ignoring feature)
'+fxsr' is not a recognized feature for this target (ignoring feature)
'+avx512dq' is not a recognized feature for this target (ignoring feature)
'-sse4a' is not a recognized feature for this target (ignoring feature)
'tigerlake' is not a recognized processor for this target (ignoring processor)
'tigerlake' is not a recognized processor for this target (ignoring processor)
'tigerlake' is not a recognized processor for this target (ignoring processor)
'tigerlake' is not a recognized processor for this target (ignoring processor)
'tigerlake' is not a recognized processor for this target (ignoring processor)

and also

LLVM ERROR: Do not know how to split the result of this operator!

error: could not compile `oak_stage0_bin` (bin "oak_stage0_bin")
tiziano88 commented 10 months ago

Though maybe I should try doing that only for the Oak Functions binary.

andrisaar commented 10 months ago

Yeah, do it only for the Oak Functions binary. stage0 is special.

conradgrobler commented 10 months ago

If the performance issue is related to crypto impelementaiton I assume this would be because of x25519, so perhaps also look at https://github.com/dalek-cryptography/curve25519-dalek/tree/main/curve25519-dalek#backends and https://github.com/dalek-cryptography/curve25519-dalek/tree/main/curve25519-dalek#simd-backend

tiziano88 commented 10 months ago

It turns out that when I changed to building in release mode, I didn't update the paths in tests, so it was still using the debug binaries anyways :roll_eyes: