Number of weak references. That was 7-8 years ago, I can't find a source now. Maybe it was fixed. Maybe I misunderstood - O(N^2) doesn't make much sense. But I clearly remember using them a lot to "add fields" to existing objects, and profiling to see >90% GC time.
On Thursday, April 28, 2016 at 9:35:40 AM UTC-4, Yichao Yu wrote: > > > On Apr 28, 2016 8:53 AM, "Cedric St-Jean" <[email protected] > <javascript:>> wrote: > > > > I'd like to know the cost of weak references / dicts. In SBCL, they had > a catastrophic O(N^2) impact on GC. > > What's N, heap size?live cell?dead cell?num of weak ref? > > > > > On Wednesday, April 27, 2016 at 9:18:20 PM UTC-4, Yichao Yu wrote: > >> > >> On Wed, Apr 27, 2016 at 9:00 PM, Stefan Karpinski <[email protected]> > wrote: > >> > Performance. If you want to be as fast as C, reference counting > doesn't cut > >> > it. > >> > >> With slightly more detail: RC has relatively low latency but also has > >> a low throughput. The issue is that RC adds a lot of overhead to > >> common operations like stack and heap store. (You naively need an > >> atomic increment and an atomic decrement per store, which is a huge > >> cost). > >> > >> Of course there are ways to optimize this. What's interesting though > >> is that tracing collector sometime implement something similar to RC > >> (in the form of write barrier) in order to minimize latency and good > >> RC system implement optimizations that are very similar to tracing > >> collector (effectively delaying RC and do it in batch) in order to > >> improve throughput and handle cyclic reference. > >> > >> > > >> > On Wed, Apr 27, 2016 at 5:36 PM, Jorge Fernández de Cossío Díaz > >> > <[email protected]> wrote: > >> >> > >> >> Why Julia is not reference counted? > >> >> Probably someone has written something explanation about this that I > can > >> >> read, so if anyone can point me in the right direction, that would > be great. > >> >> > >> >> > >> >> On Tuesday, July 8, 2014 at 12:18:37 PM UTC-4, Stefan Karpinski > wrote: > >> >>> > >> >>> Writing `A = nothing` in Julia will not cause the memory used by A > to be > >> >>> freed immediately. That happens in reference counted systems, which > many > >> >>> dynamic languages traditionally have been, but which Julia is not. > Instead, > >> >>> the memory for A will be freed the next time a garbage collection > occurs. > >> >>> This consists of the language runtime stopping everything it's > doing, > >> >>> tracing through the graph of all objects in memory, marking the > ones it can > >> >>> still reach, and freeing all the rest. So if doing `A = nothing` > causes > >> >>> there to be no more reachable references to the object that A used > to point > >> >>> at, then that object will be freed when the next garbage collection > occurs. > >> >>> Normally, garbage collection occurs automatically when the system > tries to > >> >>> allocate something and doesn't have enough memory to do so: it runs > the > >> >>> garbage collector and then tries again. You can, however, call gc() > to force > >> >>> garbage collection to occur now. This is generally not necessary or > >> >>> recommended. > >> >>> > >> >>> > >> >>> On Mon, Jul 7, 2014 at 11:04 PM, Ivar Nesje <[email protected]> > wrote: > >> >>>> > >> >>>> In julia we don't say you shouldn't do something that could give > better > >> >>>> performance (if you really want it). The thing is that Julia uses > automatic > >> >>>> garbage collection because it is a pain to do manually, and then > you have to > >> >>>> live with the semantics of a garbage collector. > >> >>>> > >> >>>> If your program is not really constrained by memory in the second > part, > >> >>>> I would guess that it is unlikely that it would matter to your > program when > >> >>>> the arrays are released. Freeing memory in julia (and other GC > based > >> >>>> languages), is about ensuring that no references remains to the > allocated > >> >>>> object. > >> >>>> > >> >>>> If it is a global variable, you can assign `nothing`, and if it is > a > >> >>>> global constant, you can change the type, so you must reassign it > to a > >> >>>> smaller array with the same dimensionality and type and ensure > that you > >> >>>> don't have local variables that references the same array. > >> >>>> > >> >>>> If it is a local variable, I'm not sure there is other options > than to > >> >>>> arrange the function boundaries, so that the large array goes out > of scope > >> >>>> when it is not needed any more. > >> >>>> > >> >>>> kl. 22:56:35 UTC+2 mandag 7. juli 2014 skrev Pablo Zubieta > følgende: > >> >>>>> > >> >>>>> Let's say I have some large matrices I need to do some > calculations and > >> >>>>> I use them in order to get some results that I will use in a > second part of > >> >>>>> a computation where I not longer need the initial matrices. > Suppose also > >> >>>>> that I preallocate those matrices. > >> >>>>> > >> >>>>> Would it be ok to bind the names of those matrices to nothing (or > >> >>>>> something similar) from the moment I won't be using them anymore, > or should > >> >>>>> I leave the deallocation work to the GC? > >> >>> > >> >>> > >> > >
