digitalmars.D - [OT] Why mobile web apps are slow
- Paulo Pinto (4/4) Jul 09 2013 A bit off-topic, but well worth reading,
- Sean Kelly (5/8) Jul 09 2013 Thanks for the link. In my experience, mobile networking is slow in =
- Oleg Kuporosov (8/12) Jul 10 2013 Sean is right, this is only one side of problem and very often
- QAston (3/7) Jul 09 2013 I think that the garbage collection part of the atricle is very
- Joakim (7/16) Jul 09 2013 Nobody uses D on mobile, so it's not very relevant. ;)
- Paulo Pinto (11/28) Jul 10 2013 There are embedded devices that can be targeted with GC enabled
- bearophile (7/9) Jul 09 2013 An interesting article, a strong critique of many kinds of
- Brian Rogoff (10/18) Jul 09 2013 It's not just in the limited memory case of mobile devices that
- qznc (4/6) Jul 10 2013 I did not like that analogy at all. Have you seen the user
- Walter Bright (3/8) Jul 10 2013 I always love the utilitarian design of military cockpits. No logos, no ...
- Nick Sabalausky (5/19) Jul 10 2013 No cupholders is all fine and good until the sky gets clogged with
- Walter Bright (2/21) Jul 10 2013 Ok, I'll concede the cupholder! But I'm holding the line on the 8-track.
- Jonathan A Dunlap (4/4) Jul 10 2013 My 2cents: for D to be successful for the game development
- John Colvin (8/13) Jul 10 2013 I've noticed that when you reply to a thread, you reply to the
- H. S. Teoh (8/20) Jul 10 2013 There's a long-standing bug in the mailing list interface to the forum
- John Colvin (3/31) Jul 10 2013 There is, but I don't think this was one of those cases. That
- Jonathan Dunlap (5/7) Jul 10 2013 Your correct John, totally my bad. I'll be more vigilant in which
- Peter Alexander (10/15) Jul 12 2013 What do you mean OpenGL library support is still in alpha
- Nick Sabalausky (3/9) Jul 09 2013 Very good article. (Actually, a nice site design, too.)
- Walter Bright (3/5) Jul 09 2013 It isn't off-topic at all. It's very relevant to D.
- bearophile (19/21) Jul 09 2013 There's a long way from recognizing those problems, to having
- Adam D. Ruppe (20/29) Jul 09 2013 Yes, and options to pass output ranges to more functions too,
- H. S. Teoh (16/21) Jul 09 2013 [...]
- Paulo Pinto (25/47) Jul 10 2013 I agree.
- thedeemon (9/11) Jul 10 2013 The chart of different kinds of GC is very worth looking there.
- bearophile (6/7) Jul 10 2013 I think there is one JavaVM that manages to avoid part of the
- Paulo Pinto (10/17) Jul 10 2013 Yes, the C4 garbage collector in the Azul JVM
- bearophile (5/7) Jul 10 2013 This is very good. (Maybe in the meantime someone has folded
- Brian Rogoff (34/54) Jul 10 2013 Interesting. There was some discussion of adding a 'pauseless' GC
- thedeemon (4/9) Jul 11 2013 HotSpot and, I suppose, other mature JVMs provide generational
- bearophile (7/10) Jul 11 2013 They need a certain amount of seconds for each GB of heap memory
- Paulo Pinto (6/15) Jul 11 2013 I just noticed there is a presentation about G1 at InfoQ,
- Michel Fortin (14/17) Jul 10 2013 What I'm retaining from this is that garbage collectors are wasteful.
- renoX (5/20) Jul 11 2013 But I think that this is why newer Android phone have a lot of
- deadalnix (3/7) Jul 11 2013 It is more about floating garbage than CPU usage. But yes, they
- Sean Kelly (9/12) Jul 10 2013 Oh, regarding ObjC (and I'll qualify this by saying that I'm not an ObjC...
- bearophile (5/6) Jul 10 2013 Of course, it's explained well here:
- Jacob Carlborg (6/11) Jul 10 2013 Objective-C originally used manual reference counting. Then Apple
- Paulo Pinto (13/31) Jul 10 2013 What sometimes goes missed between the lines is that one of the
- Jacob Carlborg (6/13) Jul 11 2013 Wasn't it possible to use the GC with all libraries but not the other
- Paulo Pinto (23/40) Jul 11 2013 No, it depended how you compiled the code.
- Jacob Carlborg (4/6) Jul 11 2013 Guess I didn't know about all these flaws in the GC.
- SomeDude (4/18) Jul 14 2013 C++ has gone te ARC route as well with shared_ptr. I find the
- Paulo Pinto (8/25) Jul 14 2013 The main problem is that C++ compilers are not shared_ptr aware.
- Sean Kelly (16/18) Jul 15 2013 scoped_ptr/shared_ptr combination quite convenient and quite safe =
- Paulo Pinto (18/38) Jul 15 2013 For me it was an experience with Native Oberon in the mid-90's. A
- Jonathan Dunlap (8/9) Jul 16 2013 possible for systems programming.
- Paulo Pinto (27/36) Jul 16 2013 I am just a D follower, so Benjamin and other guys are better indicated
- Jonathan A Dunlap (4/10) Jul 16 2013 Fascinating! I assume the Phobos RefCounted then avoids using the
- John Colvin (2/13) Jul 16 2013 Nope, just plain old malloc and free from core.stdc.stdlib
- deadalnix (5/18) Jul 16 2013 I highly advice not to use the NO_SCAN unless you really know
- deadalnix (7/17) Jul 16 2013 Good news, you can actually free bunch of memory yourself in D if
- Kagamin (5/5) Jul 13 2013 We at work have problems with performance and memory consumption
A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ -- Paulo
Jul 09 2013
On Jul 9, 2013, at 11:12 AM, Paulo Pinto <pjmlp progtools.org> wrote:A bit off-topic, but well worth reading, =20 http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/Thanks for the link. In my experience, mobile networking is slow in = general. When I run Speedtest on my phone vs. a laptop sitting right = next to it, the phone has a fraction of the bandwidth of the laptop. So = there's even more at issue than raw JS performance.=
Jul 09 2013
Thanks for the link. In my experience, mobile networking isslow in general. When I run Speedtest on my phone vs. a laptop sitting right next to it, the phone has a fraction of the bandwidth of the laptop. So there's even more at issue than raw JS performance.Sean is right, this is only one side of problem and very often not a major, another side is mobile network bandwidth and infrastructure load. It is usual for corporate offices/cities (sharing), weak signal conditions and movement you will have quite limited bandwidth even for LTE/3G cases.
Jul 10 2013
On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote:A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ -- PauloI think that the garbage collection part of the atricle is very relevant to the usage of D on mobile.
Jul 09 2013
On Tuesday, 9 July 2013 at 19:27:22 UTC, QAston wrote:On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote:Nobody uses D on mobile, so it's not very relevant. ;) If Intel ever makes a comeback on mobile- Samsung is putting x86 chips in their next generation of Galaxy Tab tablets, so it's possible- it might not take much effort to port D/ldc to Android/x86 though, so maybe it will be relevant someday. Good article, with some good data.A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ -- PauloI think that the garbage collection part of the atricle is very relevant to the usage of D on mobile.
Jul 09 2013
On Tuesday, 9 July 2013 at 19:44:26 UTC, Joakim wrote:On Tuesday, 9 July 2013 at 19:27:22 UTC, QAston wrote:There are embedded devices that can be targeted with GC enabled systems programming languages. For example Oberon-7 for ARM Cortex-M3 and NXP LPC2000 microcontrollers: http://www.astrobe.com/default.htm What happens is that you can also control memory outside the GC if really needed, via the usual stack/global memory allocation and the SYSTEM package. -- PauloOn Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote:Nobody uses D on mobile, so it's not very relevant. ;) If Intel ever makes a comeback on mobile- Samsung is putting x86 chips in their next generation of Galaxy Tab tablets, so it's possible- it might not take much effort to port D/ldc to Android/x86 though, so maybe it will be relevant someday. Good article, with some good data.A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ -- PauloI think that the garbage collection part of the atricle is very relevant to the usage of D on mobile.
Jul 10 2013
On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote:A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/An interesting article, a strong critique of many kinds of garbage collection. Having good enough built-in means to avoid relying on a GC seems quite important to use D where memory is limited. Bye, bearophile
Jul 09 2013
On Tuesday, 9 July 2013 at 20:02:33 UTC, bearophile wrote:On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote:It's not just in the limited memory case of mobile devices that GC is a problem. There are a few domains that come to mind where the ability to escape GC and rely on manual memory management is extremely important. While there was some reference made to an approach to allocators in the closing talk of DConf, I haven't seen much discussion of an approach using D's features. -- Brian PS: That silhouette of the SR-71 at the point allocators are mentioned sets a high bar for the design!A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/An interesting article, a strong critique of many kinds of garbage collection. Having good enough built-in means to avoid relying on a GC seems quite important to use D where memory is limited.
Jul 09 2013
On Tuesday, 9 July 2013 at 20:39:30 UTC, Brian Rogoff wrote:PS: That silhouette of the SR-71 at the point allocators are mentioned sets a high bar for the design!I did not like that analogy at all. Have you seen the user interface of an SR-71? http://www.likecool.com/Gear/Pic/Spy%20Plane%20SR71%20Blackbird%20Cockpit/big/Spy-Plane-SR71-Blackbird-Cockpit.jpg
Jul 10 2013
On 7/10/2013 7:52 AM, qznc wrote:On Tuesday, 9 July 2013 at 20:39:30 UTC, Brian Rogoff wrote:I always love the utilitarian design of military cockpits. No logos, no fake wood grain paneling, no styling, no color scheme, no cupholder. All business.PS: That silhouette of the SR-71 at the point allocators are mentioned sets a high bar for the design!I did not like that analogy at all. Have you seen the user interface of an SR-71? http://www.likecool.com/Gear/Pic/Spy%20Plane%20SR71%20Blackbird%20Cockpit/big/Spy-Plane-SR71-Blackbird-Cockpit.jpg
Jul 10 2013
On Wed, 10 Jul 2013 10:47:16 -0700 Walter Bright <newshound2 digitalmars.com> wrote:On 7/10/2013 7:52 AM, qznc wrote:No cupholders is all fine and good until the sky gets clogged with ariel traffic and you have to put down your coffee. *Then* you'll regret not opting for the deluxe package!On Tuesday, 9 July 2013 at 20:39:30 UTC, Brian Rogoff wrote:I always love the utilitarian design of military cockpits. No logos, no fake wood grain paneling, no styling, no color scheme, no cupholder. All business.PS: That silhouette of the SR-71 at the point allocators are mentioned sets a high bar for the design!I did not like that analogy at all. Have you seen the user interface of an SR-71? http://www.likecool.com/Gear/Pic/Spy%20Plane%20SR71%20Blackbird%20Cockpit/big/Spy-Plane-SR71-Blackbird-Cockpit.jpg
Jul 10 2013
On 7/10/2013 12:40 PM, Nick Sabalausky wrote:On Wed, 10 Jul 2013 10:47:16 -0700 Walter Bright <newshound2 digitalmars.com> wrote:Ok, I'll concede the cupholder! But I'm holding the line on the 8-track.On 7/10/2013 7:52 AM, qznc wrote:No cupholders is all fine and good until the sky gets clogged with ariel traffic and you have to put down your coffee. *Then* you'll regret not opting for the deluxe package!On Tuesday, 9 July 2013 at 20:39:30 UTC, Brian Rogoff wrote:I always love the utilitarian design of military cockpits. No logos, no fake wood grain paneling, no styling, no color scheme, no cupholder. All business.PS: That silhouette of the SR-71 at the point allocators are mentioned sets a high bar for the design!I did not like that analogy at all. Have you seen the user interface of an SR-71? http://www.likecool.com/Gear/Pic/Spy%20Plane%20SR71%20Blackbird%20Cockpit/big/Spy-Plane-SR71-Blackbird-Cockpit.jpg
Jul 10 2013
My 2cents: for D to be successful for the game development community, it has to be possible to mostly sidestep the GC or opt into a minimal one like ARC. Granted, this is a bit premature considering that OpenGL library support is still in alpha quality.
Jul 10 2013
On Wednesday, 10 July 2013 at 21:05:32 UTC, Jonathan A Dunlap wrote:My 2cents: for D to be successful for the game development community, it has to be possible to mostly sidestep the GC or opt into a minimal one like ARC. Granted, this is a bit premature considering that OpenGL library support is still in alpha quality.I've noticed that when you reply to a thread, you reply to the most recent response, irrelevant of context. This is a bit confusing to those of us who view the group in a threaded layout. For example here Walter is talking about not having inflight audio on a discontinued? military recon plane and then there's you listed as a replying to him, talking about ARC and GCs!
Jul 10 2013
On Wed, Jul 10, 2013 at 11:32:29PM +0200, John Colvin wrote:On Wednesday, 10 July 2013 at 21:05:32 UTC, Jonathan A Dunlap wrote:There's a long-standing bug in the mailing list interface to the forum that rewrites message IDs when it shouldn't, thus breaking threads. This problem has been irking me for a long time now, but it seems nobody is interested to fix it. :-( T -- There are four kinds of lies: lies, damn lies, and statistics.My 2cents: for D to be successful for the game development community, it has to be possible to mostly sidestep the GC or opt into a minimal one like ARC. Granted, this is a bit premature considering that OpenGL library support is still in alpha quality.I've noticed that when you reply to a thread, you reply to the most recent response, irrelevant of context. This is a bit confusing to those of us who view the group in a threaded layout. For example here Walter is talking about not having inflight audio on a discontinued? military recon plane and then there's you listed as a replying to him, talking about ARC and GCs!
Jul 10 2013
On Wednesday, 10 July 2013 at 22:22:41 UTC, H. S. Teoh wrote:On Wed, Jul 10, 2013 at 11:32:29PM +0200, John Colvin wrote:There is, but I don't think this was one of those cases. That manifests as an entirely new thread in the forum interface.On Wednesday, 10 July 2013 at 21:05:32 UTC, Jonathan A Dunlap wrote:There's a long-standing bug in the mailing list interface to the forum that rewrites message IDs when it shouldn't, thus breaking threads. This problem has been irking me for a long time now, but it seems nobody is interested to fix it. :-( TMy 2cents: for D to be successful for the game development community, it has to be possible to mostly sidestep the GC or opt into a minimal one like ARC. Granted, this is a bit premature considering that OpenGL library support is still in alpha quality.I've noticed that when you reply to a thread, you reply to the most recent response, irrelevant of context. This is a bit confusing to those of us who view the group in a threaded layout. For example here Walter is talking about not having inflight audio on a discontinued? military recon plane and then there's you listed as a replying to him, talking about ARC and GCs!
Jul 10 2013
There is, but I don't think this was one of those cases. That manifests as an entirely new thread in the forum interface.Your correct John, totally my bad. I'll be more vigilant in which post I reply to as I didn't realize that anyone really read into the reply's source. I'm critical about D's GC as I am super passionate about being able to one day use D for professional game development. =)
Jul 10 2013
On Wednesday, 10 July 2013 at 21:05:32 UTC, Jonathan A Dunlap wrote:My 2cents: for D to be successful for the game development community, it has to be possible to mostly sidestep the GC or opt into a minimal one like ARC. Granted, this is a bit premature considering that OpenGL library support is still in alpha quality.What do you mean OpenGL library support is still in alpha quality? There's several high quality ports of the OpenGL headers and they work like a charm. I've had no problems. Using the GC is fine as long as you aren't allocating every frame. I use GC allocation for all my big systems and anything that isn't created or destroyed during gameplay. It's very convenient for that kind of thing and you can just let the GC run at the end of a level or something.
Jul 12 2013
On Tue, 09 Jul 2013 20:12:25 +0200 Paulo Pinto <pjmlp progtools.org> wrote:A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ -- PauloVery good article. (Actually, a nice site design, too.)
Jul 09 2013
On 7/9/2013 11:12 AM, Paulo Pinto wrote:A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/It isn't off-topic at all. It's very relevant to D. I also agree with what he says about GC.
Jul 09 2013
Walter Bright:It isn't off-topic at all. It's very relevant to D. I also agree with what he says about GC.There's a long way from recognizing those problems, to having good enough solutions in D. Some possible attack strategies for D are: - A less allocating Phobos to produce a bit less garbage; - A more precise GC to avoid some memory leaks; - Perhaps an annotation to disallow heap allocations in a function or a piece of code; - Some good way to allocate variable length arrays on the stack (http://d.puremagic.com/issues/show_bug.cgi?id=9832 ) (so some arrays produce no garbage); - The implementation of "scope" maybe helps a bit; - Multiple alias this opens some opportunities to use structs in more places, avoiding some heap allocations. - Currently Phobos Scoped/emplace are not very good. Is that enough? Rust language designers seem to think that's not enough. Opinions are welcome. Bye, bearophile
Jul 09 2013
On Tuesday, 9 July 2013 at 22:40:31 UTC, bearophile wrote:- A less allocating Phobos to produce a bit less garbage;Yes, and options to pass output ranges to more functions too, instead of always returning gc allocated things.- Perhaps an annotation to disallow heap allocations in a function or a piece of code;I don't think that will often get used, especially when we're already doing safe pure const static void foo(); as it is.- Some good way to allocate variable length arrays on the stack (http://d.puremagic.com/issues/show_bug.cgi?id=9832 ) (so some arrays produce no garbage);These might be cool. Something we can do today is use static arrays as buffers. In my non-gc D experiments, I've made great use of a StackArray!(type, max_capacity) with the convenience operators overloaded. Combined with a solid "scope" implementation, this could be fast, convenient, and safe. Of course it would need to have a statically known max length big enough to store what you want to store without being too wasteful. But I don't think that's particularly hard in most cases - at least we have RangeError so it dies gracefully instead of buffer overflowing like you'd get i C. (It could also automatically grow to the gc heap if the programmer is ok with that.)- The implementation of "scope" maybe helps a bit;Yes.Is that enough? Rust language designers seem to think that's not enough. Opinions are welcome.I think if we do scope well enough, we'll have something similar to Rust that we can flesh out more in the library.
Jul 09 2013
On Wed, Jul 10, 2013 at 01:01:01AM +0200, Adam D. Ruppe wrote:On Tuesday, 9 July 2013 at 22:40:31 UTC, bearophile wrote:[...] +1. I think thus far we've only truly explored the input side of the range concept. We should do more with output ranges -- they are a lot more flexible than returning values (be that gc-allocated or not). You can bypass a lot of unnecessary buffering by doing that (think to!string and std.format, for example), which helps performance and reduces garbage for the GC. We should develop some good idioms for chaining / nesting output ranges, so that what is today a bunch of string appends, say, could be a UFCS-empowered chain of output ranges that basically writes the output directly to its destination instead of sitting around in strings or buffers, etc.. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG- A less allocating Phobos to produce a bit less garbage;Yes, and options to pass output ranges to more functions too, instead of always returning gc allocated things.
Jul 09 2013
On Tuesday, 9 July 2013 at 22:40:31 UTC, bearophile wrote:Walter Bright:I agree. Additionally I think it might be worthwhile to also have a look at other system languages with GC. The ones I had some contact with: - Oberon, Oberon-2, Oberon-7, Component Pascal, Active Oberon (Basically Oberon Family) - Modula-3 The main problem is that they failed to enter the industry, as such for some of them (Modula-3) it is very hard to get proper information nowadays. In the Oberon family for example, GC only works when New or string manipulations are involved. The rest of memory is the usual static allocation at compile time or VLA arrays as bearophile mentions. Both Modula-3 and Active Oberon allow for the declaration of untraced pointers, which boils down to manual memory management with compiler help. In all of them it is also possible to circumvent the type system and do manual memory management via the SYSTEM package/unsafe constructs. Although it is seen as something to do with expert hat on and big red alert. :) -- PauloIt isn't off-topic at all. It's very relevant to D. I also agree with what he says about GC.There's a long way from recognizing those problems, to having good enough solutions in D. Some possible attack strategies for D are: - A less allocating Phobos to produce a bit less garbage; - A more precise GC to avoid some memory leaks; - Perhaps an annotation to disallow heap allocations in a function or a piece of code; - Some good way to allocate variable length arrays on the stack (http://d.puremagic.com/issues/show_bug.cgi?id=9832 ) (so some arrays produce no garbage); - The implementation of "scope" maybe helps a bit; - Multiple alias this opens some opportunities to use structs in more places, avoiding some heap allocations. - Currently Phobos Scoped/emplace are not very good. Is that enough? Rust language designers seem to think that's not enough. Opinions are welcome. Bye, bearophile
Jul 10 2013
On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote:A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/The chart of different kinds of GC is very worth looking there. It shows how much generational GCs are faster than simple scan-whole-heap ones. Without generational GC D will remain rather slow, as each collection cycle with a 1 GB heap of small objects now takes ~5 seconds. And after you've gained 1 GB of data in the heap, each 8 MB of new allocated data cost you another 5 seconds of full scan/collect. No mature GCed languages behave that bad.
Jul 10 2013
thedeemon:No mature GCed languages behave that bad.I think there is one JavaVM that manages to avoid part of the problem you explain (and maybe it needs special kernel support). I think all other JavaVMs suffer it, more or less. Bye, bearophile
Jul 10 2013
On Wednesday, 10 July 2013 at 13:30:26 UTC, bearophile wrote:thedeemon:Yes, the C4 garbage collector in the Azul JVM http://www.azulsystems.com/products/zing/whatisit http://www.azulsystems.com/products/zing/c4-java-garbage-collector-wp They used to have special hardware, but now they use standard kernels. RedHat is also planning to have a go at it for the OpenJDK, http://rkennke.wordpress.com/2013/06/10/shenandoah-a-pauseless-gc-for-openjdk/ -- PauloNo mature GCed languages behave that bad.I think there is one JavaVM that manages to avoid part of the problem you explain (and maybe it needs special kernel support). I think all other JavaVMs suffer it, more or less. Bye, bearophile
Jul 10 2013
Paulo Pinto:They used to have special hardware, but now they use standard kernels.This is very good. (Maybe in the meantime someone has folded their needs inside the standard kernel). Bye, bearophile
Jul 10 2013
On Wednesday, 10 July 2013 at 14:01:51 UTC, Paulo Pinto wrote:On Wednesday, 10 July 2013 at 13:30:26 UTC, bearophile wrote:Interesting. There was some discussion of adding a 'pauseless' GC to Go as well, here https://groups.google.com/forum/#!topic/golang-dev/GvA0DaCI2BU and in that discussion Gil Tene, one of the authors of Azul, opines "Starting with a precise and generational stop-the-world implementation that is robust is a must, and a good launching pad towards a concurrent compacting collector (which is what a "pauseless" collector must be in server-scale environments). Each of those qualities (precise, generational) slaps serious requirements on the execution environment and on the compilers (whether they are pre-compilers or JIT compilers doesn't matter): precise collectors require full identification of all references at code safepoints, and also require a robust safepoint mechanism. Code safepoints must be frequent (usually devolve to being at every method entry and loop back edge), and support in non-compiler-generated code (e.g. library and runtime code written in C/C++) usually involves some form of reference handle support around safepoints. Generational collectors require a write barrier (a ref-store barrier to be precise) with full coverage for any heap reference store operations (in compiler-generated code and in all runtime code). It is my opinion that investing in the above capabilities early in the process (i.e. start now!) is critical. Environments that skip this step for too long and try to live with conservative GC in order to avoid putting in the required work for supporting precise collectors in the compilers and runtime and libraries find themselves heavily invested in compiler code that would need to be completely re-vamped to move forward. ..." Sounds like that precise GC talk at DConf was quite timely. Let's hope that prediction about being too heavily invested in conservative GC dependencies isn't too true! -- Brianthedeemon:Yes, the C4 garbage collector in the Azul JVM http://www.azulsystems.com/products/zing/whatisit http://www.azulsystems.com/products/zing/c4-java-garbage-collector-wp They used to have special hardware, but now they use standard kernels. RedHat is also planning to have a go at it for the OpenJDK, http://rkennke.wordpress.com/2013/06/10/shenandoah-a-pauseless-gc-for-openjdk/ -- PauloNo mature GCed languages behave that bad.I think there is one JavaVM that manages to avoid part of the problem you explain (and maybe it needs special kernel support). I think all other JavaVMs suffer it, more or less. Bye, bearophile
Jul 10 2013
On Wednesday, 10 July 2013 at 13:30:26 UTC, bearophile wrote:thedeemon:HotSpot and, I suppose, other mature JVMs provide generational GCs, so you won't get 5 seconds delay after each 8 MB of allocated data there.No mature GCed languages behave that bad.I think there is one JavaVM that manages to avoid part of the problem you explain (and maybe it needs special kernel support). I think all other JavaVMs suffer it, more or less.
Jul 11 2013
thedeemon:HotSpot and, I suppose, other mature JVMs provide generational GCs, so you won't get 5 seconds delay after each 8 MB of allocated data there.They need a certain amount of seconds for each GB of heap memory (assuming an average amount of pointers in that GB of data and D). The G1 garbage collector helps spread this computation. Bye, bearophile
Jul 11 2013
Am 11.07.2013 21:58, schrieb bearophile:thedeemon:I just noticed there is a presentation about G1 at InfoQ, http://www.infoq.com/presentations/java-g1?utm_source=infoq&utm_medium=videos_homepage&utm_campaign=videos_row1 I am yet to see it, so cannot attest if it is worthwhile to watch. -- PauloHotSpot and, I suppose, other mature JVMs provide generational GCs, so you won't get 5 seconds delay after each 8 MB of allocated data there.They need a certain amount of seconds for each GB of heap memory (assuming an average amount of pointers in that GB of data structures. garbage collector helps spread this computation. Bye, bearophile
Jul 11 2013
On 2013-07-09 18:12:25 +0000, Paulo Pinto <pjmlp progtools.org> said:A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/What I'm retaining from this is that garbage collectors are wasteful. They're viable if you have a lot of RAM to spare. They cause noticeable hiccups at unpredictable times unless you have a battery-hungry overpowered CPU that makes pauses impossible to notice. And while those pauses are not that bad for non-realtime apps, all iOS apps are considered realtime by Apple because you don't want hiccups messing smooth scrolling and animations. Also, non-deterministic deallocation makes it hard for an app to fit within a fixed memory limit. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Jul 10 2013
On Wednesday, 10 July 2013 at 13:33:15 UTC, Michel Fortin wrote:On 2013-07-09 18:12:25 +0000, Paulo Pinto <pjmlp progtools.org> said:But I think that this is why newer Android phone have a lot of RAM: a GS4 has 2GB of RAM.A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/What I'm retaining from this is that garbage collectors are wasteful. They're viable if you have a lot of RAM to spare.They cause noticeable hiccups at unpredictable times unless you have a battery-hungry overpowered CPU that makes pauses impossible to notice.Yes and "pauseless GCs" have even higher CPU usage.. renoXAnd while those pauses are not that bad for non-realtime apps, all iOS apps are considered realtime by Apple because you don't want hiccups messing smooth scrolling and animations. Also, non-deterministic deallocation makes it hard for an app to fit within a fixed memory limit.
Jul 11 2013
On Thursday, 11 July 2013 at 08:53:07 UTC, renoX wrote:It is more about floating garbage than CPU usage. But yes, they have drawbacks.They cause noticeable hiccups at unpredictable times unless you have a battery-hungry overpowered CPU that makes pauses impossible to notice.Yes and "pauseless GCs" have even higher CPU usage..
Jul 11 2013
On Jul 9, 2013, at 11:12 AM, Paulo Pinto <pjmlp progtools.org> wrote:A bit off-topic, but well worth reading, =20 http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/Oh, regarding ObjC (and I'll qualify this by saying that I'm not an ObjC = programmer). My understanding is that ObjC was originally reference = counted (ARC =3D Automatic Reference Counting). Apple then introduced a = mark & sweep GC for ObjC and then in the following release deprecated it = and switched back to ARC for reasons I don't recall. However, reference = counting *is* garbage collection, despite what that slide suggests. It = just behaves in a manner that tends to spread the load out more evenly = across the application lifetime.=
Jul 10 2013
Sean Kelly:However, reference counting *is* garbage collection,Of course, it's explained well here: http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf Bye, bearophile
Jul 10 2013
On 2013-07-10 19:25, Sean Kelly wrote:On Jul 9, 2013, at 11:12 AM, Paulo Pinto <pjmlp progtools.org> wrote:Objective-C originally used manual reference counting. Then Apple created a GC (never available on iOS). Then they implemented ARC in Clang. And now they have deprecated the GC and one should use ARC. -- /Jacob CarlborgA bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/Oh, regarding ObjC (and I'll qualify this by saying that I'm not an ObjC programmer). My understanding is that ObjC was originally reference counted (ARC = Automatic Reference Counting). Apple then introduced a mark & sweep GC for ObjC and then in the following release deprecated it and switched back to ARC for reasons I don't recall. However, reference counting *is* garbage collection, despite what that slide suggests. It just behaves in a manner that tends to spread the load out more evenly across the application lifetime.
Jul 10 2013
Am 10.07.2013 20:32, schrieb Jacob Carlborg:On 2013-07-10 19:25, Sean Kelly wrote:What sometimes goes missed between the lines is that one of the decisions to go ARC instead of GC, is because the Objective-C GC never worked properly and ARC offers a better fit for the current state of Objective-C world. First of all, GC was an opt-in and very few libraries supported it. Then we have the typical issues with a conservative GC in a C based language, which lead to tons of issues if one looks into developer forums. This is, of course, not good PR to explain the real technical reason why they decided to go ARC instead, was that the GC implementation was a failure. -- PauloOn Jul 9, 2013, at 11:12 AM, Paulo Pinto <pjmlp progtools.org> wrote:Objective-C originally used manual reference counting. Then Apple created a GC (never available on iOS). Then they implemented ARC in Clang. And now they have deprecated the GC and one should use ARC.A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/Oh, regarding ObjC (and I'll qualify this by saying that I'm not an ObjC programmer). My understanding is that ObjC was originally reference counted (ARC = Automatic Reference Counting). Apple then introduced a mark & sweep GC for ObjC and then in the following release deprecated it and switched back to ARC for reasons I don't recall. However, reference counting *is* garbage collection, despite what that slide suggests. It just behaves in a manner that tends to spread the load out more evenly across the application lifetime.
Jul 10 2013
On 2013-07-10 20:43, Paulo Pinto wrote:What sometimes goes missed between the lines is that one of the decisions to go ARC instead of GC, is because the Objective-C GC never worked properly and ARC offers a better fit for the current state of Objective-C world. First of all, GC was an opt-in and very few libraries supported it.Wasn't it possible to use the GC with all libraries but not the other way around?Then we have the typical issues with a conservative GC in a C based language, which lead to tons of issues if one looks into developer forums.The GC only worked for the Objective-C part. -- /Jacob Carlborg
Jul 11 2013
On Thursday, 11 July 2013 at 07:34:48 UTC, Jacob Carlborg wrote:On 2013-07-10 20:43, Paulo Pinto wrote:No, it depended how you compiled the code. https://developer.apple.com/legacy/library/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcEssentials.html#//apple_ref/doc/uid/TP40002452-SW1 Using -fobjc-gc-only meant your library could only work with GC enabled applications. Or another quote from the documentation: "Not all frameworks and technologies support garbage collection; for example, iCloud is not supported in applications that use garbage collection."What sometimes goes missed between the lines is that one of the decisions to go ARC instead of GC, is because the Objective-C GC never worked properly and ARC offers a better fit for the current state of Objective-C world. First of all, GC was an opt-in and very few libraries supported it.Wasn't it possible to use the GC with all libraries but not the other way around?True, but you were forced to do manual hacks like calling objc_assign_global() for write barriers in global and static variables. There is the compiler flag -Wassign-intercept to show where write barriers are being generated as a help method if everything is being generated properly. The Core Foundation needs to be used in a slight different way when interacting with GC enabled objects. With ARC all these problems do not exist, because the compiler does what the developers would be expected to do manually anyway. This is way there was such a joy when ARC was announced, not because GC per se is bad. -- PauloThen we have the typical issues with a conservative GC in a C based language, which lead to tons of issues if one looks into developer forums.The GC only worked for the Objective-C part.
Jul 11 2013
On 2013-07-11 10:46, Paulo Pinto wrote:This is way there was such a joy when ARC was announced, not because GC per se is bad.Guess I didn't know about all these flaws in the GC. -- /Jacob Carlborg
Jul 11 2013
On Wednesday, 10 July 2013 at 17:25:31 UTC, Sean Kelly wrote:On Jul 9, 2013, at 11:12 AM, Paulo Pinto <pjmlp progtools.org> wrote:C++ has gone te ARC route as well with shared_ptr. I find the scoped_ptr/shared_ptr combination quite convenient and quite safe overall.A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/Oh, regarding ObjC (and I'll qualify this by saying that I'm not an ObjC programmer). My understanding is that ObjC was originally reference counted (ARC = Automatic Reference Counting). Apple then introduced a mark & sweep GC for ObjC and then in the following release deprecated it and switched back to ARC for reasons I don't recall. However, reference counting *is* garbage collection, despite what that slide suggests. It just behaves in a manner that tends to spread the load out more evenly across the application lifetime.
Jul 14 2013
Am 14.07.2013 09:56, schrieb SomeDude:On Wednesday, 10 July 2013 at 17:25:31 UTC, Sean Kelly wrote:The main problem is that C++ compilers are not shared_ptr aware. So while systems like Objective-C ARC and ParaSail do minimize increment/decrement operations, by removed superfluous pairs of operations, in C++'s case you get some performance lost because of those operations everywhere when pointers ownership changes. -- PauloOn Jul 9, 2013, at 11:12 AM, Paulo Pinto <pjmlp progtools.org> wrote:C++ has gone te ARC route as well with shared_ptr. I find the scoped_ptr/shared_ptr combination quite convenient and quite safe overall.A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/Oh, regarding ObjC (and I'll qualify this by saying that I'm not an ObjC programmer). My understanding is that ObjC was originally reference counted (ARC = Automatic Reference Counting). Apple then introduced a mark & sweep GC for ObjC and then in the following release deprecated it and switched back to ARC for reasons I don't recall. However, reference counting *is* garbage collection, despite what that slide suggests. It just behaves in a manner that tends to spread the load out more evenly across the application lifetime.
Jul 14 2013
On Jul 14, 2013, at 12:56 AM, SomeDude <lovelydear mailmetrash.com> = wrote:=20 C++ has gone te ARC route as well with shared_ptr. I find the =scoped_ptr/shared_ptr combination quite convenient and quite safe = overall. The thing that finally pushed me towards D was one day when I was = looking at my C++ code and I realized just how much effort I'd put into = defining data ownership rules. And while tools like shared_ptr may = automate the reference counting portion of the task in that case, the = pointer type still needs to be defined somewhere and honored by all = users of that API. And shared_ptr isn't even terribly efficient by = default because it has to assume sharing across threads, so you're stuck = with memory synchronization techniques being employed every time a = shared_ptr is copied. Don't get me wrong, I think shared_ptr is a = wonderful thing, but to be really competitive it would have to be truly = automatic and have its behavior informed by a type label like "shared". Sean=
Jul 15 2013
On Tuesday, 16 July 2013 at 00:09:26 UTC, Sean Kelly wrote:On Jul 14, 2013, at 12:56 AM, SomeDude <lovelydear mailmetrash.com> wrote:For me it was an experience with Native Oberon in the mid-90's. A desktop operating system coded in a systems programming language with GC (Oberon) offering a Smalltalk like experience. Sadly only people at Zurich's technical university, or followers from Wirth's work, are aware of it and its successor Blue Bottle (A2). Some years later I also had access to information about Modula-3, Then all the work I did with Smalltalk and Camllight while at the university. So before Java was born, I was already convinced a GC was possible for systems programming. The problem is that the way Java and .NET have been sold in the industry, most people without compiler development background, tend to assume GC == VM. -- PauloC++ has gone te ARC route as well with shared_ptr. I find the scoped_ptr/shared_ptr combination quite convenient and quite safe overall.The thing that finally pushed me towards D was one day when I was looking at my C++ code and I realized just how much effort I'd put into defining data ownership rules. And while tools like shared_ptr may automate the reference counting portion of the task in that case, the pointer type still needs to be defined somewhere and honored by all users of that API. And shared_ptr isn't even terribly efficient by default because it has to assume sharing across threads, so you're stuck with memory synchronization techniques being employed every time a shared_ptr is copied. Don't get me wrong, I think shared_ptr is a wonderful thing, but to be really competitive it would have to be truly automatic and have its behavior informed by a type label like "shared". Sean
Jul 15 2013
possible for systems programming. Can you explain (simply) how D's GC works and what improvements are on the roadmap for it? As it sits, I'm a little hesitant to use it for large applications because of its overhead I've heard about on other threads. http://3d.benjamin-thaut.de/?p=20 "the manual memory managed version runs at 5 ms which is 200 FPS and thus nearly 3 times as fast as the GC collected version."So before Java was born, I was already convinced a GC was
Jul 16 2013
Am 16.07.2013 16:53, schrieb Jonathan Dunlap:I am just a D follower, so Benjamin and other guys are better indicated to speak about it. Having said this, currently D's GC is a stop the world collector with a basic implementation, when compared with Java and .NET offerings. Last year some improvements were made, specially associating some type information via the generation of TypeInfo instances. At D2013 there were some presentations about how to improve the GC. A Precise Garbage Collector for D http://www.youtube.com/watch?v=LQY1m_eT37c Concurrent Garbage Collection for D http://www.youtube.com/watch?v=1MF5bcmvJ0o Now, it all depends on the type of application you are planning to use it. In many cases, even with the current GC implementation, it is possible to achieve good performance if you code in a GC friendly way. You can also make use of library types for reference counting, And if you really, really need, also manual memory management by calling the C functions and letting the GC know not to track that memory. There are some discussions going on about adding reference counting at the compiler level, similar to Rust/ParaSail. Additionally, you can count that the GC will eventually be improved, just that these things take time. -- Paulopossible for systems programming. Can you explain (simply) how D's GC works and what improvements are on the roadmap for it? As it sits, I'm a little hesitant to use it for large applications because of its overhead I've heard about on other threads. http://3d.benjamin-thaut.de/?p=20 "the manual memory managed version runs at 5 ms which is 200 FPS and thus nearly 3 times as fast as the GC collected version."So before Java was born, I was already convinced a GC was
Jul 16 2013
You can also make use of library types for reference counting, And if you really, really need, also manual memory management by calling the C functions and letting the GC know not to track that memory.Fascinating! I assume the Phobos RefCounted then avoids using the GC by utilizing GC.malloc (NO_SCAN) behind the scenes? Has anyone benchmarked an application using D's GC versus using RefCounted for critical paths?
Jul 16 2013
On Tuesday, 16 July 2013 at 18:21:05 UTC, Jonathan A Dunlap wrote:Nope, just plain old malloc and free from core.stdc.stdlibYou can also make use of library types for reference counting, And if you really, really need, also manual memory management by calling the C functions and letting the GC know not to track that memory.Fascinating! I assume the Phobos RefCounted then avoids using the GC by utilizing GC.malloc (NO_SCAN) behind the scenes?
Jul 16 2013
On Tuesday, 16 July 2013 at 18:21:05 UTC, Jonathan A Dunlap wrote:I highly advice not to use the NO_SCAN unless you really know what you are doing. Not that the GC will trigger only when enough memory is allocated, so if you deallocate most memory manually, the GC won't trigger often.You can also make use of library types for reference counting, And if you really, really need, also manual memory management by calling the C functions and letting the GC know not to track that memory.Fascinating! I assume the Phobos RefCounted then avoids using the GC by utilizing GC.malloc (NO_SCAN) behind the scenes? Has anyone benchmarked an application using D's GC versus using RefCounted for critical paths?
Jul 16 2013
On Tuesday, 16 July 2013 at 14:53:05 UTC, Jonathan Dunlap wrote:Good news, you can actually free bunch of memory yourself in D if you need to via GC.free to reduce the GC pressure.possible for systems programming. Can you explain (simply) how D's GC works and what improvements are on the roadmap for it? As it sits, I'm a little hesitant to use it for large applications because of its overhead I've heard about on other threads.So before Java was born, I was already convinced a GC washttp://3d.benjamin-thaut.de/?p=20 "the manual memory managed version runs at 5 ms which is 200 FPS and thus nearly 3 times as fast as the GC collected version."This highlight the poor GC performances, but also the fact that way too much allocation are done when not required, which increase the GC pressure. This is something considered seriously and the amount is decreasing with each version of D.
Jul 16 2013
We at work have problems with performance and memory consumption on x86 hardware. The application uses lots of data from a big database, but it's country-scale government organization, so clients have only XP-class hardware. No unlimited RAM, no unlimited GHz, no unlimited cores.
Jul 13 2013