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

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

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

- Sing# (C# 2.0 with extensions for Singularity)


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

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.

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

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

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

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

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

 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.