On Apr 28, 2016 8:53 AM, "Cedric St-Jean" <[email protected]> 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? >> >>> >> >>> >> >
