No, there hasn't been any change on this. It's unclear if anything from the Rust model can actually be leveraged in a dynamic language.
> On May 9, 2015, at 3:46 PM, Michael Louwrens <michael.w.louwr...@outlook.com> > wrote: > > Have you had any further thought on this? It seems like it could be quite > useful for the cases where one intentionally disables the GC for performance > reasons - though you guys are incredibly busy! I also read about having the > compiler automatically insert frees where it can in Julia and was wondering > if that fits at all into this? > >> On Tuesday, 16 December 2014 23:24:08 UTC+2, Stefan Karpinski wrote: >> I would love to figure out a way to bring the kind of automatic resource and >> memory release that Rust has to Julia, but the cost is some fairly finicky >> static compiler analysis that is ok for Rust's target demographic but fairly >> clearly unacceptable for Julia general audience. What we'd need is a more >> dynamic version of something like that. One idea I've had is to indicate >> ownership and enforce it at run-time rather than compile time – and >> eliminate run-time checks when we can prove that they aren't needed. This >> could look something like having "owned references" to values versus >> "borrowed references" and check that the object still exists if the borrowed >> reference is used and raise an error if it doesn't. When an owned reference >> to the thing goes out of scope, immediately finalize it. I'm not sure how to >> indicate this, but it would be great to be able to write: >> >> function foo(...) >> fh = open(file) >> # do stuff with fh >> end # <= fh is automatically before the function returns >> # it's a runtime error to access the fh object after this >> >> Similarly, you could have something like this: >> >> function bar(...) >> a = @local Array(Int,10) >> # do stuff with a >> end # <= a is automatically freed before the function returns >> # it's a runtime error to access the a object after this >> >> Given these semantics, it would be relatively easy to alloca the actual >> memory of the array, and only heap allocate the object itself, which could >> then reference the stack allocated memory. This is tough to implement, >> especially efficiently, but I have a bit of a suspicion that in Julia >> mutable objects – and this only makes sense for mutable objects that are >> inherently associated with a particular place in memory – are rarely >> performance critical in Julia. >> >> >>> On Mon, Dec 15, 2014 at 11:15 PM, John Myles White <johnmyl...@gmail.com> >>> wrote: >>> This is taking the thread off-topic, but conceptually such things are >>> possible. But Rust has a very different set of semantics for memory >>> ownership than Julia has and is doing a lot more analysis at compile-time >>> than Julia is doing. So Julia would need to change a lot to be more like >>> Rust. I've come to really adore Rust, so I'd like to see us borrow some >>> ideas, but my personal sense is that Julia and Rust simply serve different >>> niches and shouldn't really move towards one another too much lest each >>> language wind up forsaking what makes it useful. >>> >>> -- John >>> >>> >>>> On Dec 15, 2014, at 8:43 PM, Eric Forgy <eric....@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> I'm new to Julia and mentioned it to a friend who is more into systems >>>> than mathematical models and he mentioned his current "crush" is Rust, >>>> which is also built on LVVM. I may have totally missed the point, but IF I >>>> understand, Rust does away with garbage collection by "borrow blocking" at >>>> compile time. The question popped into my head whether we could turn off >>>> GC in Julia and check for problems at compile time. A google later, >>>> brought me to this thread. Is that a totally misguided idea? >>>> >>>> Best regards, >>>> Eric >>>> >>>> PS: You can tell I'm coming in with almost no background knowledge about >>>> compilers (or real languages for that matter), but am having fun learning. >>>> LVVM was developed at my alma mater (PhD in ECE - Computational >>>> Electromagnetics - from UIUC 2002). Go Illini! :) >>>> >>>>> On Friday, February 22, 2013 7:11:32 PM UTC+8, Tim Holy wrote: >>>>> Have you played with SProfile in the Profile package? It's rather good at >>>>> highlighting which lines, in your code and in base/, trigger the gc. Note >>>>> that >>>>> in my experience the gc does not seem to be triggered necessarily on big >>>>> allocations; for example, even allocating an array as >>>>> Array(Int, (3,5)) >>>>> rather than >>>>> Array(Int, 3, 5) >>>>> can trigger the gc (I see lots of gc() calls coming from our Lapack code >>>>> for >>>>> this reason). >>>>> >>>>> Because I don't really know how the gc works, I'm not certain that kind >>>>> of >>>>> thing actually reflects a problem; perhaps it was just going to have to >>>>> call gc >>>>> on the next heap-allocation event, and (3,5) just happened to be the >>>>> lucky >>>>> candidate. But there's an open issue about this: >>>>> https://github.com/JuliaLang/julia/issues/1976 >>>>> >>>>> Docs are here: https://github.com/timholy/Profile.jl >>>>> I think they're slightly out of date, but only in very minor ways. >>>>> >>>>> --Tim >>>>> >>>>> >>>>> >>>>> On Thursday, February 21, 2013 03:17:59 PM nathan hodas wrote: >>>>> > Here's the code that benefits from @nogc: >>>>> > >>>>> > Notice the iteration over a Dict and a Set. iscorrect() checks a field >>>>> > of >>>>> > the Attempt type. I can tell by running this particular that the >>>>> > garbage >>>>> > collection is running during the for loop. >>>>> > function meantime(userdata::Dict{Int,Set{Attempt}}) >>>>> > usertimes = Dict{Int,Float64}() >>>>> > sizehint(usertimes,length(userdata)) >>>>> > for (uid,attempts) in collect(userdata) >>>>> > s = 0.0; >>>>> > c = 0.0; >>>>> > ic = 0.0; >>>>> > for a in attempts >>>>> > ic = iscorrect(a) >>>>> > s += (a.tend - a.tstart)*ic; >>>>> > c += ic; >>>>> > end >>>>> > usertimes[uid] = s/c; >>>>> > end >>>>> > usertimes >>>>> > end >>>>> > >>>>> > This code has no benefit from @nogc, regardless of the kernel function >>>>> > k1: >>>>> > >>>>> > function dostuff(input1,input2) >>>>> > output = similar(input1) >>>>> > len = length(input1) >>>>> > for i = 1:len >>>>> > x = input1[i] >>>>> > for j = 1:len >>>>> > y = input2[j] >>>>> > output[i] += k1(x,y) >>>>> > end >>>>> > end >>>>> > output >>>>> > end >>>>> > >>>>> > On Thursday, February 21, 2013 10:37:09 AM UTC-8, Stefan Karpinski >>>>> > wrote: >>>>> > > Can you post some example code? Are you just iterating the Dict >>>>> > > object >>>>> > > with a for loop? >>>>> > > >>>>> > > >>>>> > > On Thu, Feb 21, 2013 at 1:35 PM, Stefan Karpinski >>>>> > > <ste...@karpinski.org<javascript:>> >>>>> > > > wrote: >>>>> > >> That's good information to have. I'll look into it. >>>>> > >> >>>>> > >> >>>>> > >> On Thu, Feb 21, 2013 at 1:13 PM, nathan hodas >>>>> > >> <nho...@gmail.com<javascript:>>> >>>>> > >> > wrote: >>>>> > >>> It's true that @nogc is not a panacea. For my particular function, >>>>> > >>> it >>>>> > >>> produces a robust 20x speed up, even after subsequent collection. >>>>> > >>> For >>>>> > >>> other seemingly similar functions, it has no effect at all. I don't >>>>> > >>> use >>>>> > >>> any >>>>> > >>> temporary arrays *that I'm aware of*, but it seems the iterators of >>>>> > >>> a >>>>> > >>> Dict >>>>> > >>> are doing something in the background. >>>>> > >>> >>>>> > >>> On Wednesday, February 20, 2013 3:44:24 PM UTC-8, Tim Holy wrote: >>>>> > >>>> The other thing you should check is whether you're allocating more >>>>> > >>>> than >>>>> > >>>> you >>>>> > >>>> need to. I find that I can often reuse bits of memory, and that >>>>> > >>>> can >>>>> > >>>> dramatically decrease the need for gc. In the long run that may >>>>> > >>>> help >>>>> > >>>> you a >>>>> > >>>> _lot_ more than temporarily disabling gc, because at some point >>>>> > >>>> you'll >>>>> > >>>> need to >>>>> > >>>> turn it on again. >>>>> > >>>> >>>>> > >>>> There are examples of this kind of thing scattered all over the >>>>> > >>>> Julia >>>>> > >>>> code >>>>> > >>>> tree. Just because it was rather easy for me to find :-), here's >>>>> > >>>> the >>>>> > >>>> patch I >>>>> > >>>> pushed to Zip in iterator.jl today: >>>>> > >>>> https://github.com/JuliaLang/**julia/commit/** >>>>> > >>>> 89ece095e8ea1fa166074306927c6c**c5f90060f7<https://github.com/JuliaLang >>>>> > >>>> >>>>> > >>>> /julia/commit/89ece095e8ea1fa166074306927c6cc5f90060f7> It got rid >>>>> > >>>> of >>>>> > >>>> two array allocations per iteration, by reusing one array and >>>>> > >>>> pre-allocating "scratch space" inside the type for the other. >>>>> > >>>> >>>>> > >>>> You can also reuse bits of memory by writing functions with a >>>>> > >>>> syntax >>>>> > >>>> like >>>>> > >>>> >>>>> > >>>> this: >>>>> > >>>> function myfunc(out::Array, arg1, arg2) >>>>> > >>>> >>>>> > >>>> where out is pre-allocated storage for the output. This helps if >>>>> > >>>> you'll >>>>> > >>>> be >>>>> > >>>> calling the same function many times and always need an array of >>>>> > >>>> the >>>>> > >>>> same type >>>>> > >>>> and dimensions. Our matrix multiplication routines can be used in >>>>> > >>>> this >>>>> > >>>> way. >>>>> > >>>> >>>>> > >>>> --Tim >>
