On Fri, Oct 23, 2015 at 10:40 AM, Jonathan Malmaud <[email protected]> wrote: > > > > On Tuesday, October 20, 2015 at 8:10:07 AM UTC-4, Páll Haraldsson wrote: >> >> >> A. I know Julia had stop the world garbage collection (GC) and changed to >> generational GC in 0.4 that is faster (I've seen 10x mentioned). >> >> As far as I know, there are no knobs to turn (except possible to just to >> turn if off..), and the GC algorithm isn't selectable (except by choosing >> the older 0.3 version, but seems to be no upside to that..). >> >> >> In Go 1.5, they changed their GC (and have some impressive latency (of GC) >> numbers): >> >> "To create a garbage collector for the next decade, we turned to an >> algorithm from decades ago. Go's new garbage collector is a concurrent, >> tri-color, mark-sweep collector, an idea first proposed by Dijkstra in 1978. >> This is a deliberate divergence from most "enterprise" grade garbage >> collectors of today, and one that we believe is well suited to the >> properties of modern hardware and the latency requirements of modern >> software. >> [..] >> At a higher level, one approach to solving performance problems is to add >> GC knobs, one for each performance issue. The programmer can then turn the >> knobs in search of appropriate settings for their application. The downside >> is that after a decade with one or two new knobs each year you end up with >> the GC Knobs Turner Employment Act. Go is not going down that path. Instead >> we provide a single knob, called GOGC" >> >> >> They are not going for hard real-time GC (a hard problem.. there are hard >> real-time JVMs), it seems, but soft real-time. Just do get an overview >> picture, do we have a similar implementation? Generational, pushes down >> latency, but I think the focus in Julia is still throughput more than >> latency (or both?). >> >> >> Without being an expert on Go (or Julia) it seems the languages are >> similar enough, that we could have a GC with the same properties if we just >> wanted. But maybe the Julia community just doesn't want to, or at least as a >> priority.. Would selectable GC algorithms with different properties be >> desirable? >> >> > I don't think the throughput of Go's GC is all that much better than better > than Julia's - it's really its latency that is much better. But latency is > fairly irrelevant for large batch jobs, which I suspect is what most people > using Julia are concerned with. >> >> >> >> >> B. A side question, I've noticed Libc.malloc etc. Say for hard (or just >> soft) real-time stuff. It seems you could use manual memory >> management/malloc/free (and would have to disable the GC I guess?). Is it >> just crazy talk/very naive that you could run Julia without the GC >> continuously (say in a game)? Or is that the intention of Libc.malloc >> access? It seems the D language allows both GC and without, is Julia just >> similar, or "not recommended in Julia"? I do not know about Go, if it allows >> both.. >> >> > > You can use Libc.malloc if you want and it will work for fine: > x=pointer_to_array(convert(Ptr{Float64}, Libc.malloc(10sizeof(Float64))), > 10, false) > x[4]=5.2 > ... > > You don't have disable the GC For this to work: the last parameter to > 'pointer_to_array' indicates to the GC to not touch this memory. >
You probably want to pass `true`, which will let the GC call `free` on it automatically. If you want to manually manage the pointer, you can pass `false`. Note that this will still allocate the `Array` object and pass `false` will probably not make the GC run less frequently. Also note that `malloc/free` are not hard real time either, you basically cannot have any sort of memory allocation for that. > > > > >> >> C. An idea I had, and see the D guys also: >> >> http://dlang.org/garbage.html >> "Garbage collection should be implemented as a basic operating system >> kernel service. But since it is not, garbage collecting programs must carry >> around with them the garbage collection implementation." >> >> I do not really see that happening, even though memory is a global >> resource.., and ideally shouldn't be left to individual programs. Even just >> sharing a GC between say Julia and Go, I see not happening.., if you could >> get Julia and Go to work together. At best I see you could reuse Go code, as >> you can Java/JVM code, by calling it in a different process. Am I wrong? >> Strictly speaking, Python also has a GC and Julia works with Python in the >> same process. I'm not sure, but I think it may have to do with that Python >> uses reference counting (and then only full GC on top of that, is that part >> then effectively disabled by PyCall.jl?). > > > Python is indeed reference-incremented. PyCall.jl manually increments and > decrements the reference count of Python objects as they're created and > freed. > > Nothing in general though stops two different GCs from two different > libraries (eg, libgo and libjulia) from running in the same process, each > responsible for its own objects. >> >> >> -- >> Palli. >> >> >
