More radical ideas about gc and reference counting

[Paulo Pinto via Digitalmars-d]

On Wednesday, 7 May 2014 at 20:09:07 UTC, Xavier Bigand wrote:
> Le 07/05/2014 05:58, Manu via Digitalmars-d a écrit :
>> On 7 May 2014 08:07, Xavier Bigand via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>> Le 06/05/2014 13:39, Paulo Pinto a écrit :
>>>>
>>> Android works well, I love my nexus, it proves to me that 
>>> it's possible to
>>> create really smooth applications based completely on Java 
>>> (not 100% of
>>> that) but if we compare the Nexus 5 to iPhone 4 :
>>> Memory : 2 GB RAM vs 512 MB RAM
>>> CPU : Quad-core 2.3 GHz Krait 400 vs 1 GHz Cortex-A8
>>> Battery : Li-Po 2300 mAh battery vs Li-Po 1420 mAh battery
>>>
>>> And compared to an iPhone 5s
>>> Memory : 2 GB RAM vs 1 GB RAM
>>> CPU : Quad-core 2.3 GHz Krait 400 vs Dual-core 1.3 GHz Cyclone
>>> Battery : Li-Po 2300 mAh battery vs Li-Po 1560 mAh battery
>>>
>>> It's maybe not really significant but the majority of Android 
>>> devices that
>>> have acceptable performances have a lot of memory, a quad 
>>> cores CPU and an
>>> heavy battery.
>>>
>>> So that cool Java can run smoothly but at which price? I 
>>> think the margin of
>>> Apple produce is unbelievable.
>>
>> Yeah, these are excellent points that I've tried and perhaps 
>> failed to
>> articulate properly in the past.
>> The amount of 'wasted' resources required to maintain a 
>> significant
>> surplus on Android devices is ridiculous, and that's why I 
>> separated
>> phones from other embedded systems. While phones can, and do, 
>> do this,
>> other embedded systems don't.
>> To say we need to leave half of the xbox/ps4 resources idle to 
>> soak up
>> intermittency is completely unworkable.
>>
>> It's always important to remember too that the embedded market 
>> is by
>> far the largest software market in the world.
>>
> I started to work on Pocket PC and a year later on Nintendo DS 
> have only 4Mo of RAM. I sill was at school at this date, and it 
> was hard to deal with so few memory, ROM and video memory was 
> very limited. The project I worked on was only limited by 
> memory cause of use of precomputed pictures (it was an old 
> adventure game).
> On this console, game vendors have to pay for the ROM and backup
> memories, so we put in place some compressions and data packing 
> logics.
>
> From this time I always take care of avoiding unnecessary 
> absurd allocations.

4MB?! That is a world of pleasure.

Try to cram a Z80 application into 48 KB. :)

The main problem nowadays is not automatic memory management, in
whatever form, be it GC, RC, compiler dataflow, dependent types
or whatever.

The problem is how many developers code like the memory was
infinite without pausing a second to think about their data
structures and algorithms.

Just yesterday I have re-written a Java application that in the
application hot path does zero allocations on the code under our
control.

It requires execution analysis tooling, and thinking how to write 
the said code.
That's it.

..
Paulo