Richard Cownie (tich@pobox.com) on 8/21/09 wrote:
---------------------------
>It depends what you mean by "standard library routine".

Library routines that are included with the language as per the standard. They are just as much a part of "C++" as the compiler itself is.

>And furthermore,
>it's a language that really didn't work well (poor
>standards compliance, poor portability, slow compile,
>poor debugging tools) until the last 4 years or so.

How would you know if you didn't use it?

We've been using it without problems for a lot longer than that.

Heck, we've been using stuff from Boost a lot longer than that. Much of which is going to be included in the next standard.

Even the template error messages are readable these days.

>Which is why a lot of projects don't use it and a lot of
>people don't know it, me included.

Well, I consider knowing the standard library to be an integral part of being a programmer. Knowing it and choosing not to use it for a particular reason is one thing, but not even learning it is leaving a lot of potential productivity on the table.

>>me long. Heck, I did exactly that as soon as I got a dual-core and I certainly didn't
>>do it by reading through the source code at 500 lines an hour.
>
>Presumably you did it on the basis of profiling or
>other timing data.

Guided by an educated guess as to where it where to start looking, yes. Knowing the algorithms intimately means having a pretty good idea what can be vectorised (SSE) and what can be parallelised.

>Which would be the way I'd do it as
>well. Not by *randomly* "revisiting assumptions".

Who said anything about randomly revisiting assumptions?

>>I said "measurable", not "significant". It's faster with >the simpler code so I'm taking it out.
>
>Yeah, the question is how you decided that it was worth
>taking it out: was that by "revisiting assumptions", or
>was it by seeing it in the profiling data and deciding it
>was worth changing ?

I was revisiting a particular routine that I know is a code hotspot and seeing if I could speed it up more with some features of the new compiler.

As part of that investigation I tested it with straight casting and found that I got an improvement. Looking at the assembler I could see why so I then made the change universal.

If the float-to-int conversion routine wasn't actually used in that particular function then I might not have noticed the difference at that time; OTOH that particular function has a lot of performance tricks in it because it is so critical so it's not surprising to see the conversion routine in there.

>>Which gets back to my original observation -- it's odd that you are so against
>>using a standard routine rather than rolling-your-own when it comes to sorting,
>>but you would rather rely on the unspecified behaviour of the standard memory allocation routine than roll-your-own.
>
>Because I want the fastest performance possible, and the
>best memory usage possible. Progress in either of those
>dimensions helps us to sell our product against our
>competition. And the "standard" stuff isn't good enough
>in either dimension.

Which are excellent reasons for rolling-your-own allocator and having perfectly well-defined behaviour.

>Actually we do indeed roll our own memory allocator, using
>an algorithm which works great for small blocks, but then
>it hands off big blocks to the normal malloc(), because
>big-block allocations aren't performance-critical in our
>app.

Previously you said you used glibc, and glibc's different implementations of malloc() were responsible for your problems.

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.

>>What, precisely, do you think the alternative is?
>
>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.

That's what good about writing conformant code. Not that it can magically make your program work when someone pulls the plug out of the wall.

>I'm saying anyone who writes a program using malloc()
>is relying on behavior that isn't very well defined.

Only if you mean something different by "relying".

If you mean it in the sense that Michael raised it and I explained it, then "No". As long as you limit yourself to the assumptions I outlined, you aren't relying on the undefined behaviour at all.

If you mean it in the sense that you need it to give you memory for your program to do something useful, then sure, lots of programs fall into that category -- but that's irrelevant to the point at hand, and it would have been a trite observation for anyone to make.

>And everyone is vulnerable to having their program run
>into trouble if malloc() changes under their feet.

No. The program may not be able to do the operation requested, but that's not the same as "running into trouble". If you user's computer doesn't have the resources and they can't free some up, that's life -- but that wasn't your problem. You not only needed those resources, you need them in a particular way that is specifically not guaranteed by the standard (in fact, it even states that you shouldn't rely on it).

>>Then you will not be relying on undefined behaviour at all
>
>Indeed, and my simple char*malloc(size_t n) { return(NULL); } shows how malloc can obey the defined behavior and
>yet be completely useless.

As I said, whether there are sufficient resources to do useful work or not is a completely different proposition.

I also disagree that your malloc() obeys the defined behaviour, because the standard quite clearly states that the malloc() function allocates space for an object whose size is specified by the size parameter and if the space cannot be allocated, a null pointer is returned.

But even your pathological malloc() wouldn't cause undefined behaviour in a conformant program. It would probably severely curtail it's ability to do something useful, but it's behaviour would still be well-defined.

>So if you're using it, you're
>relying on some behavior which is *not* defined - the fact
>that it actually *does* return some non-NULL blocks
>under some circumstances (circumstances which are never
>precisely defined by any implementation ...)

Again, you're using "relying" in a different sense.

>Of course we check the return code. But there's no
>practical way to recover if it craps out, you just print
>a friendly message and stop.

If that's the case then that's the case.

But your problem was that if the addresses it returned didn't have certain characteristics, your programs would "behave weird". That's relying on undefined (or possibly unspecified in this case) behaviour.

>>You responded "Maybe it does, maybe it doesn't.". Well, if you agree that using
>>separate processes is slower than using threads, and if you agree with the proposition
>>that there's no point parallelising the algorithm if it doesn't deliver a performance
>>improvement, we can only conclude that not using threads therefore rules out those
>>operations that would be faster if parallelised using threads but not faster if parallelised using processes.
>
>What's not clear is whether that class is big enough to
>be interesting. Can't tell until I try it.

Well, in our case that class encompasses most of the operations that we have been able to parallelise. Linux IPC may be fast for IPC, but it's still slow compared to what's possible with threading.

>>Now who's trying to second-guess decisions without being aware of the context? :-)
>
>Well, multi-process task farming is well established as
>a parallel-processing paradigm. Heck, it's how we run
>our compiles and links in our build process. If you're
>saying it doesn't work on a fine enough granularity for
>your app, that's one thing: if you're saying it doesn't
>work because everyone has to share the task queue data
>structure, that's just plain wrong.

I did say it was a specific case and the communications overhead would have been an issue. As I showed in my previous post, even ignoring the data copying cost (in particular the 100 MB copied up-front), the 1-byte ping-pong times you got would take up half of the total processing times per work item. Two processors would be slower than a single processor using serial code!

>>Yes -- and the time required is fine when you're loading or saving a project, but
>>again, it rules out a whole class of worthwhile operations that could be profitably
>threaded if this is the only option.
>
>Maybe I know how to do it faster than you do it :-)

Thousands of times faster?