Yes, it's a half-baked idea, but I'm curious if it might be worth an experiment. re: a) yea, I suspected this could get pretty bad, and your comment about having to mutate counts while traversing it definitely amplifies the effect of it.
b) real-time is about latency and jitter and such, if throughput is sufficient. I'm curious how bad it would actually be. Something that comes to mind is to simply be careful about sharing data between threads, and to perform full copies in memory when it's worthwhile to avoid cache misses, or some thread-local optimizations if possible (I'll go google some papers before I speculate some more on this). I imagine multi-process python and clojure would have a similar coordination problem. I appreciate the feedback, I've been wistfully interested in the topic for a long time. On Thu, May 30, 2013 at 10:56 AM, Timothy Baldridge <tbaldri...@gmail.com>wrote: > There are two things I see that reduce the viability of ref-count GCs with > Clojure: > > a) Clojure is insanely alloc heavy. Look at the source of the data > structures, merging two hash-maps (for instance) requires about 2-3 > allocations per assoc, per kv in the merged map: > > (merge map1 map2) > allocs = ~((tree-depth of map1) * (count map2) > > b) Every time you transverse a persistent structure's tree you'll need to > increment and decrement the refcounts. Consider multi-core, now the > refcounts have to be thread safe (atomic inc & dec). So if you have two > cores reading (not just writing) from the same hash-map, they'll be > fighting over the cache lines that the refcount is stored in, and that'll > kill performance. > > Timothy > > > On Thu, May 30, 2013 at 8:47 AM, Gary Trakhman <gary.trakh...@gmail.com>wrote: > >> At first glance, those issues seem like they could be mitigated, so I >> think I see room here for some real-time ref-counted clojure. I imagine >> it'd still have a lot of allocations so it wouldn't be that great for >> low-memory systems. >> >> >> On Thu, May 30, 2013 at 9:44 AM, Jean Niklas L'orange < >> jeann...@hypirion.com> wrote: >> >>> >>> >>> On Thursday, May 30, 2013 2:21:36 PM UTC+2, Gary Trakhman wrote: >>>> >>>> I just thought about this recently, but does the value-oriented nature >>>> of clojure mostly void the need for a cycles-aware GC? It seems like you >>>> won't ever have cycles without identities, or pointers (java references). >>>> Maybe this would be a problem only when you need identities, ie deftype or >>>> defprotocol implementing objects. >>>> >>> >>> Sure thing, the value-oriented nature removes a lot of cycles in >>> practice. However, you may for instance have an atom which contain itself, >>> so they are not nonexistant. As such, the GC cannot be completely >>> cycle-ignorant, but perhaps it doesn't have to be efficient at finding them >>> either. >>> >>> Another place where cycles happen are in (mutually) recursive functions, >>> they may be iffy if you define many recursive anonymous functions at >>> runtime. >>> >>> -- Jean Niklas L'orange >>> >>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
