www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Why mobile web apps are slow

reply Paulo Pinto <pjmlp progtools.org> writes:
A bit off-topic, but well worth reading,

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

--
Paulo
Jul 09 2013
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
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
parent "Oleg Kuporosov" <Oleg.Kuporosov gmail.com> writes:
  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.
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
prev sibling next sibling parent reply "QAston" <qaston gmail.com> writes:
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/

 --
 Paulo
I think that the garbage collection part of the atricle is very relevant to the usage of D on mobile.
Jul 09 2013
parent reply "Joakim" <joakim airpost.net> writes:
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:
 A bit off-topic, but well worth reading,

 http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

 --
 Paulo
I think that the garbage collection part of the atricle is very relevant to the usage of D on mobile.
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.
Jul 09 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 9 July 2013 at 19:44:26 UTC, Joakim wrote:
 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:
 A bit off-topic, but well worth reading,

 http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

 --
 Paulo
I think that the garbage collection part of the atricle is very relevant to the usage of D on mobile.
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.
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. -- Paulo
Jul 10 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
parent reply "Brian Rogoff" <brogoff gmail.com> writes:
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:
 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.
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!
Jul 09 2013
parent reply "qznc" <qznc web.de> writes:
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
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/10/2013 7:52 AM, qznc wrote:
 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
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.
Jul 10 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 10 Jul 2013 10:47:16 -0700
Walter Bright <newshound2 digitalmars.com> wrote:

 On 7/10/2013 7:52 AM, qznc wrote:
 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
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.
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!
Jul 10 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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:

 On 7/10/2013 7:52 AM, qznc wrote:
 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
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.
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!
Ok, I'll concede the cupholder! But I'm holding the line on the 8-track.
Jul 10 2013
parent reply "Jonathan A Dunlap" <jdunlap outlook.com> writes:
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
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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:
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!
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.
Jul 10 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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:
 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!
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 is, but I don't think this was one of those cases. That manifests as an entirely new thread in the forum interface.
Jul 10 2013
parent "Jonathan Dunlap" <jdunlap outlook.com> writes:
 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
prev sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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/
 
 --
 Paulo
Very good article. (Actually, a nice site design, too.)
Jul 09 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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:
- 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.
[...] +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
Jul 09 2013
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 9 July 2013 at 22:40:31 UTC, bearophile wrote:
 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
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. :) -- Paulo
Jul 10 2013
prev sibling next sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
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
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 10 July 2013 at 13:30:26 UTC, bearophile wrote:
 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
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/ -- Paulo
Jul 10 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
prev sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
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:
 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
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/ -- Paulo
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! -- Brian
Jul 10 2013
prev sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
On Wednesday, 10 July 2013 at 13:30:26 UTC, bearophile wrote:
 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.
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.
Jul 11 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 11.07.2013 21:58, schrieb bearophile:
 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 structures. garbage collector helps spread this computation. Bye, bearophile
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. -- Paulo
Jul 11 2013
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
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
parent reply "renoX" <renozyx gmail.com> writes:
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:

 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.
But I think that this is why newer Android phone have a lot of RAM: a GS4 has 2GB of RAM.
 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.. renoX
 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.
Jul 11 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 11 July 2013 at 08:53:07 UTC, renoX wrote:
 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..
It is more about floating garbage than CPU usage. But yes, they have drawbacks.
Jul 11 2013
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
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
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-07-10 19:25, Sean Kelly wrote:
 On Jul 9, 2013, at 11:12 AM, Paulo Pinto <pjmlp progtools.org> wrote:

 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.
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 Carlborg
Jul 10 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 10.07.2013 20:32, schrieb Jacob Carlborg:
 On 2013-07-10 19:25, Sean Kelly wrote:
 On Jul 9, 2013, at 11:12 AM, Paulo Pinto <pjmlp progtools.org> wrote:

 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.
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.
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. -- Paulo
Jul 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 11 July 2013 at 07:34:48 UTC, Jacob Carlborg wrote:
 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?
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."
 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.
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. -- Paulo
Jul 11 2013
parent Jacob Carlborg <doob me.com> writes:
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
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
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:

 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.
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.
Jul 14 2013
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 14.07.2013 09:56, schrieb SomeDude:
 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:

 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.
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 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. -- Paulo
Jul 14 2013
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
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
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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:
 
 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
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. -- Paulo
Jul 15 2013
parent reply "Jonathan Dunlap" <jdunlap outlook.com> writes:
 So before Java was born, I was already convinced a GC was
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."
Jul 16 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 16.07.2013 16:53, schrieb Jonathan Dunlap:
 So before Java was born, I was already convinced a GC was
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."
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. -- Paulo
Jul 16 2013
parent reply "Jonathan A Dunlap" <jdunlap outlook.com> writes:
 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
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 16 July 2013 at 18:21:05 UTC, Jonathan A Dunlap wrote:
 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?
Nope, just plain old malloc and free from core.stdc.stdlib
Jul 16 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 16 July 2013 at 18:21:05 UTC, Jonathan A Dunlap wrote:
 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?
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.
Jul 16 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 16 July 2013 at 14:53:05 UTC, Jonathan Dunlap wrote:
 So before Java was born, I was already convinced a GC was
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.
Good news, you can actually free bunch of memory yourself in D if you need to via GC.free to reduce the GC pressure.
 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."
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
prev sibling parent "Kagamin" <spam here.lot> writes:
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