undefined

points

[-]

Certainly, this is a language where you get the most benefits if you are able to structure your data usage such that things of similar lifetimes sit together in arrays.

For example, you can build up a tree of all variable sized nodes inside a single array.

Where it gets interesting is if you must arbitrarily delete tree nodes, and you can't structure it to do that in stack order. The language has various tools for this, like fixed arrays with capacity, or pools of either single elements or runs of elements.

by 1122335 hours ago|

parent|

[-]

Does it have (or can it in principle support) "parallel" pools? So that structs can be stored in "columnar" fashion, yet accessed without knowing the particular way they are sliced?

by progval14 hours ago|

prev|

[-]

I'm not familiar with Goose, but I'm guessing you could define a single stack and put your dynamically sized values in it. Essentially rewriting a memory allocator on top of Goose's stacks. This is what they seem to be doing here: https://github.com/aardappel/goose/blob/master/samples/13_li...

by malisper14 hours ago|

parent|

[-]

Yeah, that looks like a freelist approach. That will work as long as the values you're allocating are all fixed-size. You'll need something much more complicated if you want arbitrarily sized values

That example implements a linked list of integers. I'm curious how you would do a linked list of strings

by andsoitis14 hours ago|

prev|

[-]

> how would you represent a hash table where the values are strings and at random, the program inserts or deletes a random string?

Goose has a built-in generic hash table called dictionary<K, V>, provided by its standard library.

https://aardappel.github.io/goose/docs/stdlib.html#dictionar...

by malisper14 hours ago|

parent|

[-]

From the link

> Keys and values are fixed-size

so not quite what I'm looking for

by andsoitis14 hours ago|

parent|

[-]

You can store the strings separately and have the dictionary hold references to them.

Conceptually:

dictionary<i64, StringReference>

             |

             +----> "hello"

             +----> "a much longer string"

             +----> "x"

by MeetingsBrowser13 hours ago|

parent|

[-]

Isn’t this just re-inventing the index arena pattern, which nullifies much of the benefit over rust?

> Goose code holds typed references where the equivalent Rust holds u32 indices into an arena — and it is where a good share of the benchmark wins come from.

by andsoitis11 hours ago|

parent|

[-]

In this particular case, you could make the values fixed length strings. Somewhere, performance and memory trades.

by James_K14 hours ago|

prev|

[-]

I think the limit of this would be creating your own allocator that works with the stacks, but you could probably stop short of that in most cases.

It's not entirely mad to do it this way, and I can see some benefits. For one, you might have multiple of these pools across the program for different data-types, which would make allocating to any one of them a cheaper operation. It is much more reference safe since you are only ever freeing stuff in a certain context and you can still never have dangling pointers. When you look at memory safe languages, they all default to this eventually. Like Rust in the advanced case will have you implementing your own allocator, lot's of games use this thing called ECS which is essentially a kind of allocator. Goose would just have it be more common.

by malisper14 hours ago|

parent|

[-]

This is roughly what I do in Rust. I use different static types for values based on how long they'll live. Temporary values get one type; cached values get another. The allocator allocates each value in a different location based on how long the value will live.