Am 08.01.2014 20:15, schrieb H. S. Teoh:
> On Wed, Jan 08, 2014 at 11:35:19AM +0000, Atila Neves wrote:
>> http://atilanevesoncode.wordpress.com/2014/01/08/adding-java-and-c-to-the-mqtt-benchmarks-or-how-i-learned-to-stop-worrying-and-love-the-garbage-collector/
>

[snip]

Thanks very much for sharing your experience.

As I shared a few times here, it was Oberon which opened my eyes
to GC enabled systems programming languages, around 1996, maybe.

After that I was curious to learn about the other descendants of
Oberon and Modula-3. Sadly none of them got an uptake outside ETHZ
and Olivetti, except maybe for Modula-3's influence to C#.

While researching for my Oberon article, I have discovered the Cedar
programming language, developed at Xerox PARC as part of their Mesa
system.

A strong typed systems programming language with GC, as well as manual
memory management, modules and functional programming features done in
1981.

My initial though was, how would today's systems look like if Xerox had
better connections to the outside world instead of AT&T.

--
Paulo

Am 08.01.2014 20:15, schrieb H. S. Teoh:
> Manual memory management is a LOT of effort, and to be quite honest,
> unless you're writing an AAA 3D game engine, you don't *need* that last
> 5% performance improvement that manual memory management *might* gives
> you. That is, if you get it right. Which most C/C++ coders don't.
>

The problem is, that with the current D-GC its not 5%. Its 300%.  See: http://3d.benjamin-thaut.de/?p=20
And people who are currently using C++ use C++ for a reason. And usually this reason is performance. As long as D remains with its current GC people will refuse to switch, given the 300% speed impact.
Additionaly programming with a GC often leads to a lot more allocations, and programmers beeing unaware of all those allocations and the possibility that those allocations slow down the program and might even trash the cache. Programmers who properly learned manual memory management are often more aware of whats happening in the background and how to optmize algorithms for memory usage, which can lead to astonishing performance improvements on modern hardware.

Also a GC is for automatic memory management. But memory is just a resource. And there are a lot other resources then just memory. Having a GC does not free you from doing other manual memory management, which still can be annoying and can create the exact same issues as with manual memory management. Having a large C# codebase where almost everything implementes the IDisposeable interface doesn't really improve the situation. It would be a lot better if GCs would focus on automatic resource management in general, so the user is freed of all such tedious tasks, and not just a portion of it.

Additionaly switching away from C++ is also not a option because of other reasons. For example cross plattform compatibility. I don't know any language other then C/C++ which would actually work on all plattforms we (my team at work) currently develop for. Not even D (mostly because of missing ports of druntime / phobos. Maybe even a missing hardware architecture.)

But I fully agree, that if you do some non performance critical business logic or application logic its a lot more productive to use a garbage collected language. Unfortunately C# and Java are doing a far better job then D here, mostly because of better tooling and more mature libraries.

Kind Regards
Benjamin Thaut

On Wed, Jan 08, 2014 at 09:23:48PM +0100, Benjamin Thaut wrote:
> Am 08.01.2014 20:15, schrieb H. S. Teoh:
> >Manual memory management is a LOT of effort, and to be quite honest, unless you're writing an AAA 3D game engine, you don't *need* that last 5% performance improvement that manual memory management *might* gives you. That is, if you get it right. Which most C/C++ coders don't.
> >
> 
> The problem is, that with the current D-GC its not 5%. Its 300%. See: http://3d.benjamin-thaut.de/?p=20

Well, your experience was based on writing a 3D game engine. :) I didn't claim that GCs are best for that scenario. How many of us write 3D game engines for a living?


> And people who are currently using C++ use C++ for a reason. And usually this reason is performance. As long as D remains with its current GC people will refuse to switch, given the 300% speed impact.

I think your view is skewed by your bad experience with doing 3D in D. I've ported (well, more like re-written) compute-intensive code from C/C++ to D before, and my experience has been that the D version is either on par, or performs even better. Definitely nowhere near the 300% slowdown you quote. (Not the mention the >50% reduction in development time compared with writing it in C/C++!) Like I said, if you're doing something that *needs* to squeeze every last bit of performance out of the machine, then the GC may not be for you.

In fact, from what I hear, most people doing 3D engine work don't even *use* memory allocation in the core engine -- everything is preallocated so no allocation / free (not even malloc/free) is done at all. You never know if a particular system's malloc/free relies on linear free lists, which may cause O(n) worst-case performance -- something you definitely want to avoid if you have only 20ms to render the next frame. If so, then it's no wonder you see a 300% slowdown if you start using the GC inside of the 3D engine.


> Additionaly programming with a GC often leads to a lot more allocations, and programmers beeing unaware of all those allocations and the possibility that those allocations slow down the program and might even trash the cache. Programmers who properly learned manual memory management are often more aware of whats happening in the background and how to optmize algorithms for memory usage, which can lead to astonishing performance improvements on modern hardware.

But the same programmers who don't know how to allocate properly on a GC'd language will also write poorly-performing malloc/free code. Freeing the root of a large tree structure can potentially run with no fixed upper bound on time if the dtor recursively frees all child nodes, so it's not that much better than a GC collection cycle. People who know to avoid doing that will also know to write GC'd code in a way that doesn't cause bad GC performance.


> Also a GC is for automatic memory management. But memory is just a resource. And there are a lot other resources then just memory. Having a GC does not free you from doing other manual memory management, which still can be annoying and can create the exact same issues as with manual memory management. Having a large C# codebase where almost everything implementes the IDisposeable interface doesn't really improve the situation. It would be a lot better if GCs would focus on automatic resource management in general, so the user is freed of all such tedious tasks, and not just a portion of it.

True, but having a GC for memory is still better than having nothing at all. Memory, after all, is the most commonly used resource, generically speaking.


> Additionaly switching away from C++ is also not a option because of other reasons. For example cross plattform compatibility. I don't know any language other then C/C++ which would actually work on all plattforms we (my team at work) currently develop for. Not even D (mostly because of missing ports of druntime / phobos. Maybe even a missing hardware architecture.)

That doesn't alleviate the painfulness of coding in C++.


> But I fully agree, that if you do some non performance critical business logic or application logic its a lot more productive to use a garbage collected language.

If you're doing performance-critical / realtime stuff, you probably want to be very careful about how you use malloc/free anyway, same goes for GC's.


> Unfortunately C# and Java are doing a far better job then D here, mostly because of better tooling and more mature libraries.
[...]

I find the lack of strong metaprogramming capabilities in Java (never tried C# before) a show-stopper for me. You have to resort to either lots of duplicated code, or adding too many indirections that hurts performance.  For compute-intensive code, too many indirections can mean the difference between something finishing in 2 days instead of 2 hours.


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, binary trees... and bugs.

Am 08.01.2014 21:57, schrieb H. S. Teoh:
> On Wed, Jan 08, 2014 at 09:23:48PM +0100, Benjamin Thaut wrote:
>
> Well, your experience was based on writing a 3D game engine. :) I didn't
> claim that GCs are best for that scenario. How many of us write 3D game
> engines for a living?

No, this expierence is not only based of this. I observed multiple discussions on the newsgroup, where turning off the GC would speed up the program by factor 3. The most recent one was parsing a text file and filling a associative array with the contents of that text file, which is not really 3d programming. What I'm really trying to say is: I would be willing to use a GC in D to, but only if D actually has a state of the art GC and not some primitive old does work without language support GC.

>
> In fact, from what I hear, most people doing 3D engine work don't even
> *use* memory allocation in the core engine -- everything is preallocated
> so no allocation / free (not even malloc/free) is done at all. You never
> know if a particular system's malloc/free relies on linear free lists,
> which may cause O(n) worst-case performance -- something you definitely
> want to avoid if you have only 20ms to render the next frame. If so,
> then it's no wonder you see a 300% slowdown if you start using the GC
> inside of the 3D engine.

That is a common misconception you can read very often on the internet. That doesn't make it true however. I saw lots of game and engine code in my life already, and its far from preallocating everything. It is tried to keep allocations to a minimum, but they are not avoided at all costs. If its neccessary they are just done (for example when spawning a new object, like a particle effect). It is even common to use scripting languages like lua for some tasks in game development, and lua allocates quite a lot during execution.

>
> But the same programmers who don't know how to allocate properly on a
> GC'd language will also write poorly-performing malloc/free code.
> Freeing the root of a large tree structure can potentially run with no
> fixed upper bound on time if the dtor recursively frees all child nodes,
> so it's not that much better than a GC collection cycle. People who know
> to avoid doing that will also know to write GC'd code in a way that
> doesn't cause bad GC performance.

That is another common argument of pro GC people I have never seen in partice yet. Meaning, I never seen a case where freeing a tree of objects would cause a significant enough slowdown. I however saw lots of cases where a garbage collection caused a significant slowdown.

>
>
> True, but having a GC for memory is still better than having nothing at
> all. Memory, after all, is the most commonly used resource, generically
> speaking.
>

Still it only solves half the problem.

>
>> Additionaly switching away from C++ is also not a option because of
>> other reasons. For example cross plattform compatibility. I don't
>> know any language other then C/C++ which would actually work on all
>> plattforms we (my team at work) currently develop for. Not even D
>> (mostly because of missing ports of druntime / phobos. Maybe even a
>> missing hardware architecture.)
>
> That doesn't alleviate the painfulness of coding in C++.

It was never intended to. I just wanted to make the point, that even if you want, you can't avoid C++.

>
>
>> But I fully agree, that if you do some non performance critical
>> business logic or application logic its a lot more productive to use a
>> garbage collected language.
>
> If you're doing performance-critical / realtime stuff, you probably want
> to be very careful about how you use malloc/free anyway, same goes for
> GC's.

This statement again has been posted hunderts of times in the GC vs manual memory management discussion. And again I never saw that the execution time of malloc or other self written allocators are a problem in partice. I did however see that the runtime of a GC allocation became a problem, to the point where it is avoided entierly. With realtime I didn't really mean that "hard" realtime requirements of embeded systems and alike more like "soft" realtime requirements where you want to avoid pause times as much as possible.

>
>
> I find the lack of strong metaprogramming capabilities in Java (never
> tried C# before) a show-stopper for me. You have to resort to either
> lots of duplicated code, or adding too many indirections that hurts
> performance.  For compute-intensive code, too many indirections can mean
> the difference between something finishing in 2 days instead of 2 hours.
>

I fully agree here. Still when choosing a programming language you also have to pick one that all programmers on the team can and want to use. I fear that the D metaprogramming capabilities will scare of quite a few programmers because it seems to complicated to them. (Its really the same with C++ metaprogramming. Its syntactically ugly and verbose, but gets the job done, and is not so complicated if you are familiar with the most important concepts).

On 08/01/14 23:23, Benjamin Thaut wrote:
> No, this expierence is not only based of this. I observed multiple discussions
> on the newsgroup, where turning off the GC would speed up the program by factor
> 3.

In my experience it seems to depend very much on the particular problem being solved and the circumstances in which memory is being allocated.  Example: I have some code where, at least in the source, dynamic arrays are being created via "new" in a (fairly) inner loop, and this can be run repeatedly apparently without the GC being triggered -- in fact, my suspicion is that the allocated space is just being repeatedly re-used and overwritten, so there are no new allocs or frees.

OTOH some other code I wrote recently had a situation where, as the data structure in question expanded, a new array was allocated, and an old one copied and then deallocated.  This was fine up to a certain scale but above a certain size the GC would (often but not always) kick in, leading to a significant (but unpredictable) slowdown.

My impression was that below a certain level the GC is happy to either over-allocate (leaving lots of space for expansion) and/or avoid freeing memory (because there's plenty of memory still free), which avoids all the slowdown of alloc/free until there's a significant need for it.

On Wed, Jan 08, 2014 at 11:43:26PM +0100, Joseph Rushton Wakeling wrote:
> On 08/01/14 23:23, Benjamin Thaut wrote:
> >No, this expierence is not only based of this. I observed multiple discussions on the newsgroup, where turning off the GC would speed up the program by factor 3.
> 
> In my experience it seems to depend very much on the particular problem being solved and the circumstances in which memory is being allocated.  Example: I have some code where, at least in the source, dynamic arrays are being created via "new" in a (fairly) inner loop, and this can be run repeatedly apparently without the GC being triggered -- in fact, my suspicion is that the allocated space is just being repeatedly re-used and overwritten, so there are no new allocs or frees.
> 
> OTOH some other code I wrote recently had a situation where, as the data structure in question expanded, a new array was allocated, and an old one copied and then deallocated.  This was fine up to a certain scale but above a certain size the GC would (often but not always) kick in, leading to a significant (but unpredictable) slowdown.
> 
> My impression was that below a certain level the GC is happy to either over-allocate (leaving lots of space for expansion) and/or avoid freeing memory (because there's plenty of memory still free), which avoids all the slowdown of alloc/free until there's a significant need for it.

So this proves that the real situation with GC vs manual memory management isn't as simple as a binary "GC is better" or "GC is bad". It depends a lot on the exact use case.

And now that you mention it, there does seem to be some kind of threshold where something happens (I wasn't sure what it was before, but now I'm thinking maybe it's a change in GC behaviour) where there's a sudden change in program performance, that I've observed recently in one of my programs. I might have a look into it sometime -- though I was planning to redo that part of the code anyway, so I may or may not find out the real reason behind this.


T

-- 
Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.

On Wed, Jan 08, 2014 at 11:23:50PM +0100, Benjamin Thaut wrote:
> Am 08.01.2014 21:57, schrieb H. S. Teoh:
[...]
> >I find the lack of strong metaprogramming capabilities in Java (never tried C# before) a show-stopper for me. You have to resort to either lots of duplicated code, or adding too many indirections that hurts performance.  For compute-intensive code, too many indirections can mean the difference between something finishing in 2 days instead of 2 hours.
> >
> 
> I fully agree here. Still when choosing a programming language you also have to pick one that all programmers on the team can and want to use. I fear that the D metaprogramming capabilities will scare of quite a few programmers because it seems to complicated to them.  (Its really the same with C++ metaprogramming. Its syntactically ugly and verbose, but gets the job done, and is not so complicated if you are familiar with the most important concepts).

Coming from a C++ background, I have to say that C++ metaprogramming, while possible, is only so in the most painful possible ways. My impression is that C++ gave template metaprogramming a bad name, because much of the metaprogramming aspects of templates were only discovered after the fact, so the original design was never intended to be used in the way it's used nowadays. As a result, people associate the design flaws in C++ templates with template programming and metaprogramming in general, whereas such flaws aren't an inherent feature of metaprogramming itself.

Unfortunately, this makes people go "ewww" when they hear about D's metaprogramming, whereas the real situation is that metaprogramming is actually a pleasant experience in D, and very powerful if you know how to take advantage of it.

One thing I really liked about TDPL is that Andrei sneakily introduces metaprogramming as "compile-time parameters" early on, so that by the time you get to the actual chapter on templates, you've already been using them comfortably for a long time, and no longer have an irrational fear of them.


T

-- 
Without geometry, life would be pointless. -- VS

On Wednesday, 8 January 2014 at 19:17:08 UTC, H. S. Teoh wrote:
> On Wed, Jan 08, 2014 at 11:35:19AM +0000, Atila Neves wrote:
>> http://atilanevesoncode.wordpress.com/2014/01/08/adding-java-and-c-to-the-mqtt-benchmarks-or-how-i-learned-to-stop-worrying-and-love-the-garbage-collector/
>
> Manual memory management is a LOT of effort

Not in my experience. It only gets ugly if you attempt to write Ruby/Java in C/C++. In C/C++ you do not wildly create short-lived objects all over the place. In embedded C there is often no object allocation at all after initialization. I have written C and C++ code for 15 years and the only real issue was memory safety but you do not need a GC to solve that problem.

> unless you're writing an AAA 3D game engine, you don't *need* that last
> 5% performance improvement that manual memory management *might* gives
> you.

The performance issues of GC are not measured in percentages but in pause times. Those become problematic when - for example - your software must achieve a frame rate of at least 60 frames per second - every second. In future this will get worse because it seems the trend goes towards 120 Hz screens which require a frame rate of at least 120 frames per second for the best experience. Try squeezing D's stop-the-world GC pause times in there.

The D solution is to avoid the GC and fallback to C-style code. That is why Rust creates so much more excitement among C/C++ programmers. You get high-level code, memory safety AND no pause times.

On Wednesday, 8 January 2014 at 23:08:43 UTC, NoUseForAName wrote:
> That is why Rust creates so much more excitement among C/C++ programmers. You get high-level code, memory safety AND no pause times.

let mut x = 4.

Whyyy would anyone want to create such a syntax? I really want to like Rust, but I... just...

On Wednesday, 8 January 2014 at 23:27:39 UTC, Ola Fosheim Grøstad wrote:
> let mut x = 4.
>
> Whyyy would anyone want to create such a syntax? I really want to like Rust, but I... just...

Looks pretty boring/conventional to me. If you know many programming languages you immediately recognize "let" as a common keyword for assignment. That keyword is older than me and I am old (by Silicon Valley standards).

That leaves only the funny sounding "mut" as slightly unusual. It is the result of making immutable the default which I think is a good decision.

It is horribly abbreviated but the vast majority of programmers who know what a cache miss is seem to prefer such abbreviations (I am not part of that majority, though). I mean C gave us classics like "atoi".. still reminds me of "ahoi" every time I read it. And I will never get over C++'s "cout" and "cin". See? Rust makes C/C++ damaged people feel right at home even there ;P