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