Menu
Search

Forums

Forum Index

Jump to page: 1 2
Thread overview
Library associative array project v0.0.1
May 11, 2022
templatedperson
May 11, 2022
rikki cattermole
May 11, 2022
templatedperson
May 11, 2022
rikki cattermole
May 11, 2022
templatedperson
May 11, 2022
ikod
May 11, 2022
ikod
May 11, 2022
kinke
May 12, 2022
H. S. Teoh
May 12, 2022
H. S. Teoh
May 11, 2022
Gravatar of Steven SchveighofferPosted by Steven SchveighofferReply
Steven Schveighoffer
Gravatar of Steven Schveighoffer


Reply

I just spent a couple hours making a library AA solution that is binary compatible with druntime's builtin AA.

The benefits:

  1. Proves that a library implementation is possible, also shows where shortcomings are.
  2. Usable at compile time to make an AA that can be used at runtime.
  3. Much more approachable code than the AA runtime, does not require "faking" a typeinfo, dealing with typeinfo in general, or deal with magic compiler hooks. This gives a good base to start experimenting with.

For the future:

  1. Implement all the things that AAs can do (which are possible, some are not).
  2. Look at alternatives to GC for allocation/deallocation.
  3. Possible use with betterC?

Anyway, enjoy!

https://code.dlang.org/packages/newaa

-Steve

May 11, 2022
Gravatar of templatedpersonPosted by templatedperson
in reply to Steven Schveighoffer		Reply
templatedperson
Gravatar of templatedperson
Posted in reply to Steven Schveighoffer


Reply

On Wednesday, 11 May 2022 at 15:31:02 UTC, Steven Schveighoffer wrote:

>

I just spent a couple hours making a library AA solution that is binary compatible with druntime's builtin AA.

The benefits:

  1. Proves that a library implementation is possible, also shows where shortcomings are.
  2. Usable at compile time to make an AA that can be used at runtime.
  3. Much more approachable code than the AA runtime, does not require "faking" a typeinfo, dealing with typeinfo in general, or deal with magic compiler hooks. This gives a good base to start experimenting with.

This is great!

>
  1. Look at alternatives to GC for allocation/deallocation.

Maybe add @nogc overloads that take std.experimental.allocators? That could be the best way to accomplish this.

May 12, 2022
Gravatar of rikki cattermolePosted by rikki cattermole
in reply to templatedperson		Reply
rikki cattermole
Gravatar of rikki cattermole
Posted in reply to templatedperson


Reply
On 12/05/2022 3:54 AM, templatedperson wrote:
>> 2. Look at alternatives to GC for allocation/deallocation.
> 
> Maybe add `@nogc` overloads that take `std.experimental.allocator`s? That could be the best way to accomplish this.

That won't help much. The virtual types are not @nogc, and for a good reason, the default is the GC.
May 11, 2022
Gravatar of templatedpersonPosted by templatedperson
in reply to rikki cattermole		Reply
templatedperson
Gravatar of templatedperson
Posted in reply to rikki cattermole


Reply

On Wednesday, 11 May 2022 at 16:07:07 UTC, rikki cattermole wrote:

>

The virtual types are not @nogc ....

By "the virtual types", do you mean interfaces? If so, that could be solved by doing an enum isAllocator(T) = ... like ranges do, right? Or, I believe Atila's concepts library enable people to use interfaces with structs.

>

for a good reason, the default is the GC.

Good reason or not, people sometimes need to do manual memory management.

I usually use the GC and like that we have it, but if you care about performance you gotta drop down to manual managements sometimes. If libraries don't let users decide what sort of memory management pattern they want to use we have two languages essentially.

I'd rather all of phobos had overloads with allocator arguments, but sadly it doesn't.

May 12, 2022
Gravatar of rikki cattermolePosted by rikki cattermole
in reply to templatedperson		Reply
rikki cattermole
Gravatar of rikki cattermole
Posted in reply to templatedperson


Reply
On 12/05/2022 4:55 AM, templatedperson wrote:
>> for a good reason, the default is the GC.
> 
> Good reason or not, people sometimes need to do manual memory management.
> 
> I usually use the GC and like that we have it, but if you care about performance you gotta drop down to manual managements sometimes. If libraries don't let users decide what sort of memory management pattern they want to use we have two languages essentially.
> 
> I'd rather all of phobos had overloads with allocator arguments, but sadly it doesn't.

They are classes hidden inside structs.

I'm well aware of the issues, I have my own -betterC allocator library (that will hopefully be available soon-ish) that does not have these issues.

```d
struct RCAllocator {
    private {
        void delegate() @safe @nogc pure nothrow refAdd_;
        void delegate() @safe @nogc pure nothrow refSub_;

        void[]delegate(size_t, TypeInfo ti = null) @safe @nogc pure nothrow allocate_;
        bool delegate(scope void[]) @safe @nogc pure nothrow deallocate_;
        bool delegate(scope ref void[], size_t) @safe @nogc pure nothrow reallocate_;
        Ternary delegate(scope void[]) @safe @nogc pure nothrow owns_;
        bool delegate() @safe @nogc pure nothrow deallocateAll_;
        bool delegate() @safe @nogc pure nothrow empty_;
    }

@safe @nogc pure nothrow:
```
May 11, 2022
Gravatar of templatedpersonPosted by templatedperson
in reply to rikki cattermole		Reply
templatedperson
Gravatar of templatedperson
Posted in reply to rikki cattermole


Reply
On Wednesday, 11 May 2022 at 16:58:27 UTC, rikki cattermole wrote:
>
> I'm well aware of the issues, I have my own -betterC allocator library (that will hopefully be available soon-ish) that does not have these issues.

That's exciting to hear! I'll watch for that.
May 11, 2022
Gravatar of ikodPosted by ikod
in reply to Steven Schveighoffer		Reply
ikod
Gravatar of ikod
Posted in reply to Steven Schveighoffer


Reply

On Wednesday, 11 May 2022 at 15:31:02 UTC, Steven Schveighoffer wrote:

>

I just spent a couple hours making a library AA solution that is binary compatible with druntime's builtin AA.

The benefits:

For the future:

  1. Implement all the things that AAs can do (which are possible, some are not).
  2. Look at alternatives to GC for allocation/deallocation.
  3. Possible use with betterC?

Anyway, enjoy!

I don't know if this compatible with your approach, but for my hashmap I added goals like:

  • allow @nogc and/or @safe operations on hashmap if key and value types allow this
  • add some methods returning a copy of the value instead of a pointer to value

Regards!

May 11, 2022
Gravatar of Steven SchveighofferPosted by Steven Schveighoffer
in reply to ikod		Reply
Steven Schveighoffer
Gravatar of Steven Schveighoffer
Posted in reply to ikod


Reply

On 5/11/22 2:13 PM, ikod wrote:

>

I don't know if this compatible with your approach, but for my hashmap I added goals like:

  • allow @nogc and/or @safe operations on hashmap if key and value types allow this

I believe everything is attributed or inferred as it should be (it is a template, so inference should happen on all the methods). I copied all the attributes from the aaA.d file, and assignment/opEquals for the value/key should be inferred based on the appropriate calls. Everything should be correct, because now the language is doing it for me, instead of having to infer this with weird wrappers (e.g. here).

>
  • add some methods returning a copy of the value instead of a pointer to value

I return a reference to the value (via opIndex). Can you elaborate on why you would need it to be a copy? What is your API?

-Steve

May 11, 2022
Gravatar of Steven SchveighofferPosted by Steven Schveighoffer
in reply to templatedperson		Reply
Steven Schveighoffer
Gravatar of Steven Schveighoffer
Posted in reply to templatedperson


Reply

On 5/11/22 11:54 AM, templatedperson wrote:

>

On Wednesday, 11 May 2022 at 15:31:02 UTC, Steven Schveighoffer wrote:

>

I just spent a couple hours making a library AA solution that is binary compatible with druntime's builtin AA.

The benefits:

  1. Proves that a library implementation is possible, also shows where shortcomings are.
  2. Usable at compile time to make an AA that can be used at runtime.
  3. Much more approachable code than the AA runtime, does not require "faking" a typeinfo, dealing with typeinfo in general, or deal with magic compiler hooks. This gives a good base to start experimenting with.

This is great!

Thanks!

> >
  1. Look at alternatives to GC for allocation/deallocation.

Maybe add @nogc overloads that take std.experimental.allocators? That could be the best way to accomplish this.

Technically, we don't need attributes, if the allocator doesn't use the GC, it will infer @nogc.

Adding an allocator template parameter is a definite plan. However, once you go outside the standard AA implementation, you can no longer be binary compatible.

But the overall goal is to provide a base for future improvement (both in the language and as an alternative to AAs), so please, if you have more ideas, file some github issues!

-Steve

May 11, 2022
Gravatar of kinkePosted by kinke
in reply to Steven Schveighoffer		Reply
kinke
Gravatar of kinke
Posted in reply to Steven Schveighoffer


Reply

On Wednesday, 11 May 2022 at 15:31:02 UTC, Steven Schveighoffer wrote:

>

I just spent a couple hours making a library AA solution that is binary compatible with druntime's builtin AA.

The benefits:
[...]

Much appreciated, thanks!

« First   ‹ Prev
1 2
Next ›   Last »