Richard Cownie (tich@pobox.com) on 8/22/09 wrote:
---------------------------
>JasonB (no@spam.com) on 8/22/09 wrote:
>---------------------------
>
>>Library routines that are included with the language as per the standard. They
>>are just as much a part of "C++" as the compiler
>
>Yes. But there's a whole lot of stuff in the C++
>standard that we *never* use in our codebase. I expect
>there's a whole lot of stuff in the C++ standard that
>you *never* use in your codebase. "Sesquipedalian" is
>a perfectly good English word, it's in the dictionary,
>but I never use it and I don't know how to use it.

I've mentioned before that there are dark recesses in the language that are best avoided, but they are mostly esoteric language constructs rather than parts of the standard library. I must have used just about all of the containers (plus the hash-based ones that won't be standard until the new standard is out) and most of the algorithms, and generally found that it resulted in cleaner and more readable code that was easier to maintain.

>So really, the set of stuff that's *effectively*
>"standard" is what is in frequent use on a particular
>project. Using other stuff imposes a cost.

No disagreement there, only on what should be in a good C++'s programmer's repertoire.

>>How would you know if you didn't use it?
>
>We had to jump through hoops to use templates at all back
>around 1998. And a colleague went off to a startup
>around 2002 where they chose to use STL and templates
>heavily, and he had a horrible time with the issues
>of compile/link time, executable size, and debugging.
>Maybe that was just g++/gdb, and MSVC++ did better: but
>then we're back to the whole "different cultures" issue.

Seems like it. I always thought that VC6 was bad because of its lack of conformance and missing features, but it sounds relatively utopian.

>>Who said anything about randomly revisiting assumptions?
>
>You suggested it was a good idea to "revisit assumptions"
>at regular intervals. So my question really was, how do
>you decide which assumptions might need to be revisited ?

You decide which assumptions might need to be revisited by knowing the nature of your algorithms, and revisit them when the environment in which those assumptions were made changes.

Examples:

1. The introduction of a new CPU generation that may have different strengths and weaknesses compared to existing CPUs (P4, K8, C2D were all different) and new features (e.g. each iteration of SSE).

2. The introduction of multiple core CPUs, which meant multithreading was going to be widely beneficial.

3. A new generation of graphics cards with more functionality (e.g. double precision floats).

4. Average installed RAM increasing markedly.

5. A new version of the compiler.

Each one of those has occurred at least once over the last 15 years and for each of those I found it pretty clear where I needed to look and what I needed to explore.

>If the answer is "look at the profiling data", then we
>agree. If you had another answer I'd be interested to
>know what it was: but revisiting *all* the assumptions
>just seems like way too much.

You only revisit the assumptions relating to the change that has occurred.

>>Since glibc is open-source, couldn't you have read the source code and kept tabs
>>on that? Even better, you could have modified glibc (or derived your own
>>allocator from it) to suit your needs as long as you published your modifications
>>and linked to your modified version dynamically.
>
>All good suggestions *WITH HINDSIGHT*.

You're missing the point -- the problems you experienced could have been predicted with foresight.

If you're relying on undefined and unspecified behaviour, you simply don't know if that behaviour is real or accidental and under what circumstances it will change. The point about not relying on undefined and unspecified behaviour is not about appeasing language lawyers, it's about avoiding surprises in the future precisely because the behaviour you're relying on is not guaranteed to be maintained -- and because it's undocumented, it's not even guaranteed to be what you think it is.

You want to avoid only seeing these problems with hindsight.

>It wasn't obvious that reading the glibc source code was
>the best use of my time (and regrettably, though we have
>a large number of developers, there wasn't really anyone
>else with expertise in memory allocation).

If you had a policy of only ever writing conformant code then that would probably have prompted you to at least look at glibc's malloc() implementation and make a decision about writing your own. At the very least it would have been worth checking to see if the behaviour you thought you were seeing was guaranteed in the current implementation and what it depended on.

>>>I'm just pointing out that "conformant" isn't a very
>>>helpful concept.
>>
>>It would have saved you a "nasty few weeks" tracking down mysterious behaviour.
>
>Not really.

Yes, it would, because (assuming you didn't bother updating malloc()) you would have known already that its behaviour could be affected by multithreading and had a policy not to use multithreading unless and until you implemented a replacement.

>A trick that reduces our DRAM requirement
>by a factor of about 1.3x is worth a lot to us. Giving
>that up for the (mostly nebulous) benefits of
>"conformance" would be the wrong choice for our
>circumstances. It's worth enough for me to spend that
>"nasty few weeks" if I have to. YMMV.

Where did I say you couldn't reduce your DRAM requirement by 1.3x? I said to make the behaviour defined by implementing your own routine if required. At the very least, looking at glibc's malloc() to see what behaviour it really had would have (a) shown you under what circumstances that behaviour changed and (b) allowed you to keep track of potential breaking changes to its implementation as it evolved.

>>No. The program may not be able to do the operation requested, but that's not the
>>same as "running into trouble".
>
>For us it is. If the customer's problem won't run on
>the size of machine that we specified then procedurally,
>managerially, and financially that's going to get treated
>the exact same way as a bug. And because the curve of
>machine-DRAM-capacity vs cost has some big discontinuities,
>you really don't want to find yourself specifying a
>129GB machine instead of a 96GB machine.
>Again, YMMV.

Why do you keep making this a discussion about how much memory you need? The very post your responded to stated yet again the correct way to avoid undefined behaviour and still get what you want. My very first post on this thread said:

"I'm not familiar enough with Linux programming to know for sure, but I would have thought you could (and probably should) write your own custom allocators that could give you the desired behaviour in a portable and safe way, rather than depend on the implementation details of glibc?"

So why pretend that I'm saying you can't use your pointer compression trick?

>>>Maybe I know how to do it faster than you do it :-)
>>
>>Thousands of times faster?
>
>Depends how slow yours is. I've tackled this problem
>several times, and I'm confident I can do it pretty well.

Ours is less than optimal in order to ensure both backwards and forwards compatibility, but I can guarantee that you wouldn't be able to make it thousands of times faster.

In your other post you mentioned compression; most of the data is stored uncompressed, and loading or storing an entire project normally takes seconds rather than tens of seconds. (For the program that can have 10 GB or more of data in a single project, most of it is not saved by that program -- it's pre-existing data that is only read as-needed, not written.)

But it would still need to be several orders of magnitude faster to not be an issue.