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? >>> >>> >
