[Announcement] Full Time Streaming

Neo Ar

July 10, 2017

Hey Everyone! As you might already know, I recently left my job at Aker to pursue full-time streaming. The video above covers all the important details.

I'd like to give you guys a little sneak peek at the first commercial software project I'm working on: nwr_mem.h

nwr_mem.h is an stb-style mit/public domain single header C library that will provide custom (user-space) memory allocator building blocks inspired by Andrei Alexandrescu's std.experimental.allocator work in the D programming language. The library will include things such as:

Allocators

Region
Kernighan-Ritchie Allocator
Bitmapped Block
Buddy Allocator

Modifiers

Affix Allocator
Stats Collector
Quantizer

Aggregates

Free Tree
Free List
Fallback Allocator
Bucketizer
Segregator

Additionally, the library is being written as a literate program, and a pdf file describing the design and implementation of the library will be available.

I want people to use and share my software regardless of whether they back me on patreon, which is why nwr_mem.h will be MIT/public domain, but officially I will only be distributing my copies to $5+ patrons. Think of the distribution model as piracy-made-legal!

The first version of nwr_mem.h that I will be releasing will include the first allocator: Region. The api can be seen below:

NWR_INLINE NWR_DEF _Bool nwr_region_grows_down(nwr_region * r);
NWR_INLINE NWR_DEF size_t nwr_region_available(nwr_region * r);
NWR_INLINE NWR_DEF _Bool nwr_region_is_empty(nwr_region * r);
NWR_INLINE NWR_DEF _Bool nwr_region_is_full(nwr_region * r);
NWR_INLINE NWR_DEF _Bool nwr_region_is_subregion(nwr_region * r, void * p, size_t l);
NWR_INLINE NWR_DEF _Bool nwr_region_is_inside(nwr_region * r, void * p);
NWR_INLINE NWR_DEF _Bool nwr_region_is_alive(nwr_region * r, void * p);
NWR_INLINE NWR_DEF _Bool nwr_region_is_subregion_alive(nwr_region * r, void * p, size_t l);
NWR_INLINE NWR_DEF void nwr_region_reset(nwr_region * r);
NWR_INLINE NWR_DEF _Bool nwr_region_dealloc(nwr_region * r, void * p, size_t l);
NWR_DEF nwr_region nwr_region_create(void * ptr, size_t length, const nwr_u32 alignment, const nwr_u32 flags);
NWR_DEF void * nwr_region_alloc(nwr_region * region, size_t n);
NWR_DEF void * nwr_region_aligned_alloc(nwr_region * region, size_t n, nwr_u32 a);
NWR_DEF void * nwr_region_alloc_all(nwr_region * region, size_t * size);
NWR_DEF size_t nwr_region_expand(nwr_region * region, void * ptr, size_t length, size_t delta);

A dedicated topic for the library with more information will be made on the forums when it is ready to be released.

As always, thanks for the support, and stay RISCY!

Kelimion

Jeroen van Rijn, 6 years, 9 months ago

While I've already commented on the video, I wanted to wish you the best of luck with your career switch here as well. Here goes: the best of luck with your career switch!

That allocator library looks like it's going to be interesting.
What's it going to do under the hood to acquire memory itself? Call malloc/realloc/free, use mmap/VirtualAlloc?

neo_ar

Neo Ar, 6 years, 9 months ago

It is purely user-space, you can allocate the memory from whatever system allocator you like. When you call something like nwr_region_create you pass it a pointer and length of the memory it is to use as the backing store.

The api is still subject to change, but you can see the create function for the region allocator here:

1	NWR_DEF nwr_region nwr_region_create(void * ptr, size_t length, const nwr_u32 alignment, const nwr_u32 flags);

nwr_region is a struct that keeps track of the region with 3 pointers, an int holding the alignment, and an int holding flags. The region is able to either grow up or down in memory (this is currently all the flags are for). Growing down is useful if you want the region to use memory on the stack for example. One downside of growing down is that you can't expand an allocation in-place though, so nwr_region_expand is only supported for regions that grow up.

mmozeiko

Mārtiņš Možeiko, 6 years, 9 months ago Edited by Mārtiņš Možeiko on July 11, 2017, 7:08am

What about multi-threaded allocators? Whan you want generic purpose malloc replacement than can be allocated and freed on arbitrary threads without explicitly taking mutex over whole alloc/free function. Any plans for such use case?

neo_ar

Neo Ar, 6 years, 9 months ago

I am interested in providing thread-safe/multi-threading aware variants of my allocators but I don't have any specific plans for this on the current road-map, we should discuss this further once I've got a dedicated topic for the library ready :)