On Thu, Apr 28, 2016 at 10:10 AM, Cedric St-Jean <[email protected]> wrote: > 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.
The julia impl of weak ref should add a O(number of weak ref) cost to each GC which is already O(number of (young) live object). I'm not sure how a bad implementation would cause the problem you described although I haven't looked at too many gc impl either. Please report a performance bug if you see similar issue. > > 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]> 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? >> >> >>> >> >> >>> >> >> >
