feature request, mmap option

[ouvaa]

@phuslu pls pls pls implement a mmap option that can be shared across golang inter process.
can buy u a few coffees for this. possible to get it done?

maybe with an option to flush to mmap file at regular intervals or something. most importantly so can be used across different separate programs

[phuslu]

I thought it before, here is my roudmap

1. provide a new type cache, e.g. *lru.BytesCache, the key&value both are []byte
2. use mmap/memfd to convert it to offheap
3. make it shareable across golang processes.

[phuslu]

So as we see, I'm reinventing another freecache/fastcache, it seems that a bit sad.

[ouvaa]

@phuslu can you implement it? i know u can make this the fastest for interprocess sharing.

this will be mmapped for inter process golang accessing, which is not available in other solutions

[ouvaa]

@phuslu pls implement it. this will make it work around all the 192 cores issues and more.

[ouvaa]

@phuslu when can you get it done? how can i show my appreciation and thanks for this?

[phuslu]

The reason I haven't start it yet is that I don't have the confidence to do it better than fastcache.

But under your encouragement, let me try reluctantly.

[ouvaa]

@phuslu if you do an mmap version, u already done better than the rest as it'll be the only lru cache that can be accessed across independent and separate processes. please post incomplete code or where u think i can help contribute coz i think i can help u make it faster then.

dont worry about speed for the moment, it's the only mmap lru that is shareable across process.

can u pls start it and i'll help with speeding it up.

[ouvaa]

@phuslu chatgpt may help u out too in certain areas.

[phuslu]

ok, let me push a drafted "BytesCache" commit to poc our ideas today

[ouvaa]

@phuslu i'm not sure how u will have a global mutex to sync for separate golang processes to access it. not sure if u will hit any issues but i have solution. u may come up with a better global mutex lock or similar.

[ouvaa]

@phuslu this is my last bit of performance issue with golang, so i'll be around 24/7 just looking at this issue. i was working on chatgpt with an mmap lru and it's terrible.

i know u definitely will come up with "the best".
seriously will be using across everything, i will refactor all repo and code to use this.

[phuslu]

Found another similar implementation in c/php, https://github.com/happyfish100/libshmcache

The noticeable feature is that it also choose FIFO rather than LRU, this same as fastcache. I think that because of "lock contention" reduction

[ouvaa]

dont worry about them, get it done on your version. in fact, just mapped the variables to the memory mapped memory file e.g. /dev/shm/shm.mmap or something.

as i mentioned, if u found issue with lock, i have solution

[ouvaa]

you can do what u think is best first, i will try the lock issue on my side and send you the code once i verify it can be resolved.

by the way, i think u'll confuse yourself more if you reference others' implementation, that c repo is irrelevant.

your lru will work directly with mmap referencing directly, the only issue u have will be the global lock that's all.

dont need to do the fifo etc and no need to flush writes actually. i've tested mmap file sharing and without flushing it works too as long as you dont reboot the server of course.

p.s. : i mean directly u can just implement a global lock on your lru without any issue. dont do fifo etc. use your version exactly.

2 things need to change only.

1. memory section use mmap file
2. global mutex lock implementation

that's all really.