Mirror of forum.nim-lang.org

6827 :: About arc and orc, would there be a thread-local ref object?

• wt (orginal) [2020-09-17T09:05:36+02:00] view original

  --gc:arc and --gc:orc offers a shared heap. Therefore, a ref object is allocated in a shared heap when it is new. However, allocating memory in a shared heap, which means locking the heap everytime. So, I wonder would there be some special ref object that is allocated from a thread local area and no heap lock is needed.

---

• Araq (orginal) [2020-09-17T09:55:06+02:00] view original

  However, allocating memory in a shared heap, which means locking the heap everytime.

  That's not how modern allocators work. Nim's is currently a notable exception with its single global lock, but '-d:useMalloc' fixes that. See also https://github.com/microsoft/mimalloc

---

• DeletedUser (orginal) [2020-09-17T10:06:46+02:00] view original

  I have done some benchmarks with some gcs. arc and orc seems to work fine with httpbeast. But when I benchmark prologue with many ref objects. It seems to slow down very much.

  With refc, 50k qps

  With arc, 7k qps

  With orc, 18k qps

  Any solutions?

---

• Araq (orginal) [2020-09-17T10:59:24+02:00] view original

  They don't work "fine", they leak memory, I'm working on a fix. As long as they leak benchmarking them is futile.

---

• DeletedUser (orginal) [2020-09-17T11:21:03+02:00] view original

  Thanks.

---

• mratsim (orginal) [2020-09-17T19:42:28+02:00] view original

  Once we have Arc and multithreading fixed we can work on a fast threadsafe allocator. There is this for example that wraps Mimalloc https://github.com/Araq/araqsgc.

  This is also something I noticed in Weave.

  As I do here https://github.com/mratsim/weave/blob/e5a3701/weave/memory/allocs.nim#L47-L57 you can always import system/ansi_c and call c_malloc manually if your use-case allows it (i.e. you don't need the refcounting part).

---