@mratsim Well, if you call GC_collect manually then it's much worse than manual
allocation and deallocation from memory pool, I guess.
Could you explain further what getOccupiedMem changes in the case we were
talking about (ref to ptr to memory external to thread heap)?
Well, you said "today you can do" as a general advice so I assumed you try to
show us "how simple it is to do it by hand", not "how easy it is to make sth
only for internal usage".
About this object being a ref one --- no, please read my comment again. Long
story short: ref object can be
dataRef to have the deallocation of the data managed by Nim GC.
data for normal use through foo[10] (thanks to UncheckedArray). Yes data is
public because in my use case this is only used internally, and getter/setter
would just add boilerplate for no gain. Same thing for len.
Regarding copy,
@mtrasim I've already said it's a bad idea (even on many architectures on which
it's possible). And even if you don't really have a heap, it doesn't mean you
couldn't use dynamic memory if a language supports custom allocators. You can
provide a memory pool on a stack, that's what I actually
Many microcontroller only have a stack so you just can't use heap .
Also @Varriount, @Udiknedormin today you can do:
type
SharedArray[T] = object
dataRef: ref[ptr T]
data*: ptr UncheckedArray[T]
len*: int
proc deallocSharedArray[T](dataRef:
@Varriount It doesn't? I was pretty sure there was something called shared
heap... Well, whatever. I think GC is much better for functional languages, RAI
seems better for stateful ones.
Oh, by the way --- I didn't really try it, but I guess idiomatic Nim programs
could bring problmes on some
@Udiknedorm: The biggest problem with the current GC is that it doesn't support
shared memory (though, I don't know why we can't do something like Go's
channels).
To me, these changes seem like an effort to reasonably support programs that
don't want to rely on the GC.
@bpr Not in the core (or std, I guess, but's more realistic). But I never said
I was talking about the core.
@rayman22201 I was referring to a GC library for Rust. I can see @mratsim
already mentioned one example (there are more, if my memory serves me well).
There are two main reasons for it
It automatically [frees unreachable
memory](https://aturon.github.io/blog/2015/08/27/epoch/#freeing-memory) for you
and [collect garbage
(thread-safely)](https://aturon.github.io/blog/2015/08/27/epoch/#managing-garbage)
so you know the saying, if it quacks like a duck though the canonical
@mratsim Very interesting read, but that's not a GC?
@Araq, What are your thoughts about [epoch-based
GC](https://aturon.github.io/blog/2015/08/27/epoch/) as crossbeam is doing for
Rust to build a library of lock-free data structures
> I'm not understanding, are you saying that destructors and move semantics are
> the resource management of Nim in the future? If so, what happens to the
> tracing GC, regions, and all that? If not, I don't know which uniform
> solution you are proposing.
Yes, that's what I am saying for the
@Udiknedormin Rust has absolutely no tracing GC at all.
@Araq I'm not understanding, are you saying that destructors and move semantics
are the resource management of Nim in the future? If so, what happens to the
tracing GC, regions, and all that? If not, I don't know which uniform solution
> I remember you always saying people who want to limit GC usage just don't get
> it and it'll be fast anyway so why bother. Of course destructors have
> advantages of their own (like deterministic freeing you mentioned) but if you
> say Nim's GC is so blazingly fast (I don't doubt it, I just
@rayman22201 As far as I know, destructors can be slower in no-single-ownership
environments. That's why some languages (e.x. Rust) do the opposite of what Nim
is doing now --- they introduce optional GC for cases when it's useful / more
natural.
@Araq > Destructors, assignment operators, the
> Specifically your post on write tracking. It's obviously a really old post
> (from 2013), and it looks like it was never fully implemented.
It was implemented and produced impressive results. It makes Nim's effect
system even more complex though and doesn't help much with destructors: It only
@Araq,
I found your earlier blog posts after reading the newest one. (those should
really be more visible btw! they are very interesting!)
Specifically your post on write tracking. It's obviously a really old post
(from 2013), and it looks like it was never fully implemented.
What happened
More thorough tests are required but theoretically speaking the determinism can
cost cycles. Most modern GCs do not emit write barriers for stack slots (this
is true for Nim's GC too) but C++ like overloaded assignments/moves do not
distinguish between stack slots and heap slots... The
@rayman22201 what I have seen is, that each proc that has a var of a type which
is handled by a destructor needs a hidden try finally block (currently even if
the var is not used). This can be a big overhead for small routines. The c
target needs setjump/longjump which is a big overhead. The
@Araq I wanted to "show my appreciation" for this new development, but
BoutySource doesn't let me leave a comment. I'm "skunkiferous" there; I think
"monster" was already taken...
@araq,
I missed the live stream, but watched the recording on youtube. Thank you for
taking the time to do the presentation! Very awesome.
> The really hard part is replacing the existing runtime with one with a
> different performance profile ("yay, deterministic freeing, yay more
>
Thanks @Araq! I'll watch the livestream later.
Is the doc on regions now obsolete? It would seem that destructors now obviate
much of the need for regions.
Ok, blog post is here:
[https://nim-lang.org/araq/destructors.html](https://nim-lang.org/araq/destructors.html)
I will copy the "spec worthy" parts that have been implemented already into a
wiki page.
It's not a presentation, it's Araq live coding the feature, probably
destructors given the number of votes.
It's also him who'll do whatever he wants with the video so pick his mind :p.
Looking forward to the blog, and I hope whatever you come up with will not be
wrong. Destructors have been a topic for a while. I'm also very interested in
seeing where memory regions in Nim go, as per the "Future directions" part of
the manual.
@mratsim, will this Twitch stream presentation
Or vote and watch the Twitch stream
[http://www.strawpoll.me/14163114](http://www.strawpoll.me/14163114)
The implementation and the spec are developed together and I don't want to say
more until I'm sure it's not embarrassingly wrong. But things are starting to
look really good, expect a blog post about this in a couple of days.
I just noticed a burst of GitHub commits on "destructors", but I found nothing
in the docs. Is there some change coming?
How Nim handles destructors (and GC and memory regions, and ...) could be an
interesting selling point. C++ and Rust shows that people are interested in
no-GC approaches
28 matches
Mail list logo
