Re: Support for GC.AddMemoryPressure()
glopes <[email protected]> Tue, 5 Jun 2012 07:56:57 -0700 (PDT)
| Newsgroups | gmane.comp.gnome.mono.garbage-collection |
|---|---|
| Message-ID | <CAGV1SG+ubxbLjNQ1nuWqhBYEuJBJ3Qj5eKrLRJmGVtbCPZhNsg@mail.gmail.com> |
--===============0844365517== Content-Type: multipart/alternative; boundary="----=_Part_16940_19691761.1338908217953" ------=_Part_16940_19691761.1338908217953 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I understand completely why people would think that, I honestly do, but I confess I'm at a loss why it should be a problem at a conceptual level, or why it MemoryPressure shouldn't be used this way. We're talking about highly transient native resources (e.g. images), which are completely tied to a managed representation which I'm using to compose modular high-throughput data processing pipelines. In the end it's not as different from just allocating an array of bytes. Also, from a functional perspective of composability, it's not just a mild convenience, as garbage collection is what allows the immutability of objects to be preserved across calls. In a modular pipeline, there's no one who knows when it's safe to dispose an image, as it depends for how long this image will be thrown around, which in turn depends on the specific pipeline you're running it through. It's the same with LINQ queries, when you handle transient intermediate projections during complex queries, you don't really want to handle responsibility to anyone in particular as to how that projection will end up being used, as this will screw modularity and composability. As to the latency tradeoff, I'm currently processing 1 MB images at 200 images per second with no problem and at a steady pace, at least in my profiling, so I've yet to see where the latency might be, at least using Microsoft's GC. Thanks for the heads-up though, it's good to know the whole GC API will eventually be supported in the future, even if we disagree on how to use it :-) G On 5 June 2012 13:16, Rodrigo Kumpera [via Mono] < [email protected]> wrote: > > > On Tue, Jun 5, 2012 at 6:55 AM, glopes <[hidden email]<http://user/SendEmail.jtp?type=node&node=4649725&i=0> > > wrote: > >> That's very reassuring to hear :-) >> MemoryPressure is definitely a very convenient feature for certain >> wrappers (e.g. image processing), especially when built for functionally >> oriented languages like F# or even C# LINQ, and it's great to know we'll >> have support to make it fully functional in Mono. >> >> Would it be beneficial to have memory behavior tests run in Mono to >> benchmark this? Playing around with MemoryPressure personally has made me >> realize just how aggressive Microsoft's GC is. I've got the same >> application running on Windows .NET with a stable footprint of 80/90 MB and >> on Linux Mono it grows to more than 1 GB in less than a second. Basically >> image processing at high-resolution and fast frame-rates. >> > > This is a classic example of what the memory pressure API is not for. > You're simply not disposing your native resources and the GC has > no business in doing it for you. For forcing it to do for you, you're > trading higher latencies for a mild convenience. > > > >> Is there any place where one could follow/test the roadmap or current >> prototypes/source code for this? >> >> The code sits on a local branch and there is no roadmap when will it hit > mainline. > > > _______________________________________________ > Mono-gc-list maillist - [hidden email]<http://user/SendEmail.jtp?type=node&node=4649725&i=1> > http://lists.ximian.com/mailman/listinfo/mono-gc-list > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://mono.1490590.n4.nabble.com/Support-for-GC-AddMemoryPressure-tp4649713p4649725.html > To unsubscribe from Support for GC.AddMemoryPressure(), click here<http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4649713&code=Z29uY2Fsb2Nsb3Blc0BnbWFpbC5jb218NDY0OTcxM3w1Nzg4Mzk1OTY=> > . > NAML<http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://mono.1490590.n4.nabble.com/Support-for-GC-AddMemoryPressure-tp4649713p4649730.html Sent from the Mono - Garbage Collection mailing list archive at Nabble.com. ------=_Part_16940_19691761.1338908217953 Content-Type: text/html; charset=UTF8 Content-Transfer-Encoding: quoted-printable I understand completely why people would think that, I honestly do, but I c= onfess I'm at a loss why it should be a problem at a conceptual level, = or why it MemoryPressure shouldn't be used this way.<div><br></div><div= > We're talking about highly transient native resources (e.g. images), wh= ich are completely tied to a managed representation which I'm using to = compose modular high-throughput data processing pipelines. In the end it= 9;s not as different from just allocating an array of bytes.</div> <div><br></div><div>Also, from a functional perspective of composability, i= t's not just a mild convenience, as garbage collection is what allows t= he immutability of objects to be preserved across calls. In a modular pipel= ine, there's no one who knows when it's safe to dispose an image, a= s it depends for how long this image will be thrown around, which in turn d= epends on the specific pipeline you're running it through. It's the= same with LINQ queries, when you handle transient intermediate projections= during complex queries, you don't really want to handle responsibility= to anyone in particular as to how that projection will end up being used, = as this will screw modularity and composability.</div> <div><br></div><div>As to the latency tradeoff, I'm currently processin= g 1 MB images at 200 images per second with no problem and at a steady pace= , at least in my profiling, so I've yet to see where the latency might = be, at least using Microsoft's GC.</div> <div><br></div><div>Thanks for the heads-up though, it's good to know t= he whole GC API will eventually be supported in the future, even if we disa= gree on how to use it :-)</div><div><br></div><div>G<br><br><div class=3D"g= mail_quote"> On 5 June 2012 13:16, Rodrigo Kumpera [via Mono] <span dir=3D"ltr"><<a h= ref=3D"/user/SendEmail.jtp?type=3Dnode&node=3D4649730&i=3D0" target=3D"_top= " rel=3D"nofollow" link=3D"external">[hidden email]</a>></span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"> =09<br><br><div class=3D"gmail_quote"><div class=3D"im">On Tue, Jun 5, 2012= at 6:55 AM, glopes <span dir=3D"ltr"><<a href=3D"http://user/SendEmail.= jtp?type=3Dnode&node=3D4649725&i=3D0" rel=3D"nofollow" link=3D"exte= rnal" target=3D"_blank">[hidden email]</a>></span> wrote:<br> <blockquote style=3D"border-left:2px solid #cccccc;padding:0 1em" class=3D"= gmail_quote"> That's very reassuring to hear :-)<div>MemoryPressure is definitely a v= ery convenient feature for certain wrappers (e.g. image processing), especi= ally when built for functionally oriented languages like F# or even C# LINQ= , and it's great to know we'll have support to make it fully functi= onal in Mono.</div> <div><br></div><div>Would it be beneficial to have memory behavior tests ru= n in Mono to benchmark this? Playing around with MemoryPressure personally = has made me realize just how aggressive Microsoft's GC is. I've got= the same application running on Windows .NET with a stable footprint of 80= /90 MB and on Linux Mono it grows to more than 1 GB in less than a second. = Basically image processing at high-resolution and fast frame-rates.</div> </blockquote><div><br></div></div><div class=3D"im"><div>This is a classic = example of what the memory pressure API is not for. You're simply not d= isposing your native resources and the GC has</div><div>no business in doin= g it for you. For forcing it to do for you, you're trading higher laten= cies for a mild convenience.</div> <div><br></div><div>=C2=A0</div></div><blockquote style=3D"border-left:2px = solid #cccccc;padding:0 1em" class=3D"gmail_quote"><div>Is there any place = where one could follow/test the roadmap or current prototypes/source code f= or this?</div> <div><br></div></blockquote><div class=3D"im"><div>The code sits on a local= branch and there is no roadmap when will it hit mainline.</div><div>=C2=A0= </div></div></div> <br><div class=3D"im">_______________________________________________ <br>Mono-gc-list maillist =C2=A0- =C2=A0<a href=3D"http://user/SendEmail.jt= p?type=3Dnode&node=3D4649725&i=3D1" rel=3D"nofollow" link=3D"extern= al" target=3D"_blank">[hidden email]</a> <br><a href=3D"http://lists.ximian.com/mailman/listinfo/mono-gc-list" rel= =3D"nofollow" link=3D"external" target=3D"_blank">http://lists.ximian.com/m= ailman/listinfo/mono-gc-list</a><br> =09 =09<br> =09<br> =09<hr noshade size=3D"1" color=3D"#cccccc"> =09</div><div style=3D"color:#444;font:12px tahoma,geneva,helvetica,arial,s= ans-serif"><div class=3D"im"> =09=09<div style=3D"font-weight:bold">If you reply to this email, your mess= age will be added to the discussion below:</div> =09=09</div><a href=3D"http://mono.1490590.n4.nabble.com/Support-for-GC-Add= MemoryPressure-tp4649713p4649725.html" target=3D"_blank" rel=3D"nofollow" l= ink=3D"external">http://mono.1490590.n4.nabble.com/Support-for-GC-AddMemory= Pressure-tp4649713p4649725.html</a> =09</div><div class=3D"HOEnZb"><div class=3D"h5"> =09<div style=3D"color:#666;font:11px tahoma,geneva,helvetica,arial,sans-se= rif;margin-top:.4em;line-height:1.5em"> =09=09 =09=09To unsubscribe from Support for GC.AddMemoryPressure(), <a href=3D"" = target=3D"_blank" rel=3D"nofollow" link=3D"external">click here</a>.<br> =09=09<a href=3D"http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp= ?macro=3Dmacro_viewer&id=3Dinstant_html%21nabble%3Aemail.naml&base= =3Dnabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNam= espace-nabble.view.web.template.NodeNamespace&breadcrumbs=3Dnotify_subs= cribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_ins= tant_email%21nabble%3Aemail.naml" rel=3D"nofollow" style=3D"font:9px serif"= target=3D"_blank" link=3D"external">NAML</a> =09</div></div></div></blockquote></div><br></div> =09 <br/><hr align=3D"left" width=3D"300" /> View this message in context: <a href=3D"http://mono.1490590.n4.nabble.com/= Support-for-GC-AddMemoryPressure-tp4649713p4649730.html">Re: Support for GC= .AddMemoryPressure()</a><br/> Sent from the <a href=3D"http://mono.1490590.n4.nabble.com/Mono-Garbage-Col= lection-f1553555.html">Mono - Garbage Collection mailing list archive</a> a= t Nabble.com.<br/> ------=_Part_16940_19691761.1338908217953-- --===============0844365517== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mono-gc-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-gc-list --===============0844365517==--