On Sunday, 12 August 2018 at 05:24:56 UTC, Mike Franklin wrote:
I wasn't aware of Eugene's implementation. At first glance it looks real nice. It appears to have some dependencies on other features of his Tanya library, so at a minimum, those will have to be removed or replaced.

It depends only on internal libc-free syscalls that can be replaced with mmap/munmap and on copy()/copyBackward() that are just memcpy and memmove respectively.

But, how does it perform? In order to make the case for using these D implementations in druntime, we'll have to gather some metrics on the implementations in terms of performance, memory fragmentation, etc. and ensure they are on par with the C standard library implementations or alternative implementations like jemalloc and tcmalloc?

Some years ago I had a BigInt implementation that allocated and deallocated memory like crazy. I compared how it works with malloc and my own allocator and my allocator was slightly faster than glibc (probably because of thread-safety). But yes, a good implementation needs benchmarks which test it systematically under various conditions.

Tanya's allocator is also tested only on x86-64 Linux, but is trivially to port to Windows and other architectures. I actually had a Windows version before but removed it because I was too lazy to read msdn.

Perhaps, with Eugene's permission, you can use his implementation as a base, take some measurements, and see if it can be improved upon with either more features or better performance.

You can use it as reference when implementing something else or as a starting point for the further work. Anyway feel free to use it as you like.

P.S. In the last weeks I had thoughts to split low-level stuff from tanya and put it into a separate library, kind of native, gc-free x86-64 (and maybe aarch64) Linux runtime for D. Probably I should go for it :)

Reply via email to