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.
> Java data structures contain many pointers, unlike C# and D). The G1
> 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

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.

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.

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.

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

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

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, which provided a few ideas that made their way into C#.

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

>> 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."

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.

http://dlang.org/phobos/object.html#.TypeInfo

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,

http://dlang.org/phobos/std_typecons.html#.RefCounted

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.

http://dlang.org/phobos/core_memory.html#.GC.BlkAttr.NO_SCAN

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

> You can also make use of library types for reference counting,
>
> http://dlang.org/phobos/std_typecons.html#.RefCounted
>
> 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.
>
> http://dlang.org/phobos/core_memory.html#.GC.BlkAttr.NO_SCAN

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?