Open osevan opened 9 months ago
JuiceFS only has disk cache, and the index of disk cache is not the bottleneck, so we will not expect much performance improvements from otter.
The S3-FIFO could be better than 2-random (similar to LRU), we need to dig more into that.
@davies Hi there, happy to learn about your experience (and help) if juicyfs decides to use S3-FIFO. In my opinion, if cache hit ratio is important, moving from two random to S3-FIFO would 1. provide a non-trivial hit ratio improvement (it will be workload-dependent though); 2. be more SSD-friendly due to sequential writes and therefore better tail latency; 3. be more scalable when scaling to multiple cores. :)
Hi dear devs,
otter is fastest go build cache system.
https://github.com/maypok86/otter
It could be improve cache hits :-)
If possible, everyone should be set the config with right settings like ram usage. And fine grained flush to disk after every sec or msec will be cool too. And fsync simulating like fsync off will be cool, because applications could receive faster simulated sync signals and can work further.
Here is new hash system outperforming Blake and siphash 5-10 times.
https://medium.com/@frankwessels_nl/highwayhash-fast-hashing-at-over-10-gb-s-per-core-in-golang-fee938b5218a
https://pkg.go.dev/go.shabbyrobe.org/fxhash
Fxhash and gxhash further faster than highwayhash.
You can follow some hash systems here:
https://www.reddit.com/r/rust/comments/17xgn0t/gxhash_a_new_extremely_fast_and_robust_hashing/
Thanks and
Best regards