Adding Java and C++ to the MQTT benchmarks or: How I Learned to Stop Worrying and Love the Garbage Collector

[H. S. Teoh]

On Thu, Jan 09, 2014 at 09:49:15AM +0000, Paulo Pinto wrote:
> On Thursday, 9 January 2014 at 09:38:31 UTC, Ola Fosheim Grøstad
> wrote:
> >On Thursday, 9 January 2014 at 09:10:07 UTC, Paulo Pinto wrote:
> >>I have only seen those things work in small AAA class teams.
> >
> >But you have probably seen c programs allocate a bunch of
> >different small structs with a single malloc where it is known
> >that they will be freed in the same location? A compiler needs
> >whole program analysis to do the same.
> >
> >So yes, c programs will have fewer allocs if the programmer cared.
> 
> Yes, I did.
> 
> Not much different than memory pools in Turbo Pascal and Objective-C
> for that matter.
> 
> And even more strange things, where the whole memory gets allocated
> at start, then some "handles" are used with mysterious macros to
> convert back and forth to real pointers.
> 
> I have also seen lots of other storage tricks that go easily out of
> control when the team either grows over a certain size, or
> management decides to outsource part of the development or lowering
> the expected skill set of new team members.
> 
> Then you watch the older guys playing fire brigade to track down
> issues of release X.Y.Z at customer site, almost every week.
[...]

Exactly!! All these tricks are "possible" in C, but that's what they
essentially are: tricks, hacks around the language. You can only keep it
up with a small, dedicated core team. As soon as the PTBs decide to hire
new grads and move people around, you're screwed, 'cos the old guy who
was in charge of the tricky macros is no longer on the team, and nobody
else understands how the macros work, and the new guys are under
pressure to show contribution, so they barge in making assumptions about
how things work -- which usually means naïve C semantics, lots of
strcpy's, direct pointer arithmetic, I don't use these weird macros 'cos
I don't understand what they do. Result: fire brigade. :-)

This is why compiler-enforced type attributes ultimately trumps any kind
of coding convention. It forces everyone to do the Right Thing. This is
why strings (arrays) with built-in length is better, because it allows
slicing without needing to decide whether you should copy or modify
in-place (*someone* will inevitably get it wrong).

C's superiority is keyed on the programmer being perfect -- the
philosophy of the language is to trust the programmer, to believe that
the programmer knows what he's doing. Theoretically speaking, this is a
good thing, because the compiler won't stand in your way and annoy you
when you're trying to do something clever. (This is also what made me
like C in the first place -- I was 19 at the time, so it figures. :-P)
Unfortunately, in practice, humans are fallible -- very much fallible
and error-prone -- so this philosophy only leads to pain and more pain.
With a single-person project you can still somewhat maintain some
semblance of order. But when you have a team of 15+ programmers (at my
job we have up to 50), then it's total chaos, and you start to code by
paranoia, i.e,, assume everyone else will screw up and add every
possible safeguard you can think of in your part of the code, so that
when things go wrong it's not your fault. Which means every string
modification requires copying, which means performance is out the
window. It means adding layers of indirection to shield your code from
the outside world. Which means even more pointers to work with, which in
turn means you start getting into pointer management problems, and start
needing reference counting (which, as I described in an earlier post,
people *still* screw up). At some point, you start wishing C had a GC to
clean up the mess.


T

-- 
Public parking: euphemism for paid parking. -- Flora