You wrote: "... note that `malloc/free` are not hard real time either, you basically cannot have any sort of memory allocation for that. "
It is an old myth, that you cannot have any memory allocation for hard real-time applications. For me, and probably also for other people who do real-time simulations or audio processing, lower latencies are always welcome. Julia 0.4 is already much better then Julia 0.3, but the garbage collector of Lua has still at least one order of magnitude less latency and is suitable for "Hard real-time Control and Coordination of Robot Tasks". Having (optionally) such a garbage collector in Julia would increase the user base of Julia in the control community a lot. For more details see: https://github.com/JuliaLang/julia/issues/8543 On Friday, October 23, 2015 at 4:49:17 PM UTC+2, Yichao Yu wrote: > > On Fri, Oct 23, 2015 at 10:40 AM, Jonathan Malmaud <[email protected] > <javascript:>> 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. > >> > >> > > >
