Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> writes:

> On 10/25/13 7:23 AM, Manu wrote:
> Woke up this morning with the following idea.
>
> 1. We add two optional API functions:
>
> void[] alignedAllocate(size_t, uint);
> bool alignedReallocate(ref void[], size_t, uint);

A bit of bikeshedding:

Since you have

allocate()
allocateAll()

I would use

allocateAligned()
reallocateAligned()

to be more consistent.

Jerry

How about a stack allocator like this:
----
enum StackSize = 8192;

struct Stack {
	static Stack it;
	
	void[StackSize] _buffer = void;
	size_t _bufUsage;

	void[] take(size_t N) {
		if ((this._bufUsage + N) <= StackSize) {
			scope(exit) this._bufUsage += N;

			return _buffer[this._bufUsage .. this._bufUsage + N];
		}

		return null;
	}
	
	void reset() {
		this._bufUsage = 0;
	}
}
----
Would that fit in std.allocator?

Awesome!

Since we have SIMD instructions in core it will be nice to have AlignedGCallocator.

Best Regards,
Ilya

Am 07.11.2013 11:32, schrieb Namespace:
> How about a stack allocator like this:
> ----
> enum StackSize = 8192;
>
> struct Stack {
>      static Stack it;
>
>      void[StackSize] _buffer = void;
>      size_t _bufUsage;
>
>      void[] take(size_t N) {
>          if ((this._bufUsage + N) <= StackSize) {
>              scope(exit) this._bufUsage += N;
>
>              return _buffer[this._bufUsage .. this._bufUsage + N];
>          }
>
>          return null;
>      }
>
>      void reset() {
>          this._bufUsage = 0;
>      }
> }
> ----
> Would that fit in std.allocator?

That's std.allocator.InSituRegion, just that is misses the reset() method.

On Thursday, 7 November 2013 at 13:15:03 UTC, Sönke Ludwig wrote:
> Am 07.11.2013 11:32, schrieb Namespace:
>> How about a stack allocator like this:
>> ----
>> enum StackSize = 8192;
>>
>> struct Stack {
>>     static Stack it;
>>
>>     void[StackSize] _buffer = void;
>>     size_t _bufUsage;
>>
>>     void[] take(size_t N) {
>>         if ((this._bufUsage + N) <= StackSize) {
>>             scope(exit) this._bufUsage += N;
>>
>>             return _buffer[this._bufUsage .. this._bufUsage + N];
>>         }
>>
>>         return null;
>>     }
>>
>>     void reset() {
>>         this._bufUsage = 0;
>>     }
>> }
>> ----
>> Would that fit in std.allocator?
>
> That's std.allocator.InSituRegion, just that is misses the reset() method.

Nice! But I suggest two things:
 1. Add a reset function for reusing the same storage
 2. Should that: https://github.com/andralex/phobos/blob/allocator/std/allocator.d#L2907 not be replaced with ubyte[size] _store = void; ?

07-Nov-2013 17:30, Namespace пишет:
> On Thursday, 7 November 2013 at 13:15:03 UTC, Sönke Ludwig wrote:
>> Am 07.11.2013 11:32, schrieb Namespace:
>>> How about a stack allocator like this:
>>> ----
>>> enum StackSize = 8192;
>>>
>>> struct Stack {
>>>     static Stack it;
>>>
>>>     void[StackSize] _buffer = void;
>>>     size_t _bufUsage;
>>>
>>>     void[] take(size_t N) {
>>>         if ((this._bufUsage + N) <= StackSize) {
>>>             scope(exit) this._bufUsage += N;
>>>
>>>             return _buffer[this._bufUsage .. this._bufUsage + N];
>>>         }
>>>
>>>         return null;
>>>     }
>>>
>>>     void reset() {
>>>         this._bufUsage = 0;
>>>     }
>>> }
>>> ----
>>> Would that fit in std.allocator?
>>
>> That's std.allocator.InSituRegion, just that is misses the reset()
>> method.
>
> Nice! But I suggest two things:
>   1. Add a reset function for reusing the same storage
>   2. Should that:
> https://github.com/andralex/phobos/blob/allocator/std/allocator.d#L2907
> not be replaced with ubyte[size] _store = void; ?

Hm... Andrei has just been caught using internal pointers in structs :o)

-- 
Dmitry Olshansky

On 11/7/13 2:32 AM, Namespace wrote:
> How about a stack allocator like this:
> ----
> enum StackSize = 8192;
>
> struct Stack {
>      static Stack it;
>
>      void[StackSize] _buffer = void;
>      size_t _bufUsage;
>
>      void[] take(size_t N) {
>          if ((this._bufUsage + N) <= StackSize) {
>              scope(exit) this._bufUsage += N;
>
>              return _buffer[this._bufUsage .. this._bufUsage + N];
>          }
>
>          return null;
>      }
>
>      void reset() {
>          this._bufUsage = 0;
>      }
> }
> ----
> Would that fit in std.allocator?

It's there!

Andrei

On 11/7/13 5:15 AM, Sönke Ludwig wrote:
> That's std.allocator.InSituRegion, just that is misses the reset() method.

freeAll should take care of it.

Andrei

On 11/7/13 5:30 AM, Namespace wrote:
> Nice! But I suggest two things:
>   1. Add a reset function for reusing the same storage

freeAll().

>   2. Should that:
> https://github.com/andralex/phobos/blob/allocator/std/allocator.d#L2907
> not be replaced with ubyte[size] _store = void; ?

Made the change and pushed, thanks. Unfortunately there's a performance bug in the front-end (if at least one field has initialization, all fields are initialized by bitblasting .init over the object).

https://d.puremagic.com/issues/show_bug.cgi?id=11331


Andrei

On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote:
> Hello,
>
>
> I know it's been a long wait. Hopefully it was worth it. The alpha release of untyped allocators is ready for tire-kicking and a test drive.
>
> Code: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
>
> Dox: http://erdani.com/d/phobos-prerelease/std_allocator.html
>
> Warning: this is alpha quality. Unit tests are thin, and there are no benchmarks. Both would be appreciated, particularly benchmarks to validate the gains (which I speculate can be very sizable) of custom-built, special-purpose allocators compared to traditional allocators.
>
> I acknowledge I'm clearly in no position to evaluate this design. I have been knocking around it for long enough to have no idea how easy it is to get into it from the outside, or how good it is. By all signs I could gather this feels like good design, and one of the best I've ever put together. The allocators defined have an archetypal feeling, are flexible both statically and dynamically, and morph and combine in infinite ways.
>
> CAllocator and CAllocatorImpl make the link between the static and dynamic worlds. Once an allocator is assembled out of pieces and finely tuned, wrapping it in a dynamic API is a snap.
>
> Please destroy! I've literally sweat as I'm sending this :o).
>
>
> Andrei

All I can say is - I can't wait to see it in the run-time library! I read about the jmalloc last year, and your work makes it possible to have something similar in D. Kudos! System developers will definitely like std.allocator, no doubt! :)