LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.

[H. S. Teoh via Digitalmars-d]

On Wed, Jul 16, 2014 at 07:14:25PM +0000, via Digitalmars-d wrote:
> On Wednesday, 16 July 2014 at 18:24:11 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >They are just duals of each other, and optimized GC/RC algorithms
> >tend to approach the middle ground, with time/memory tradeoffs as an
> >adjustable parameter.
> 
> Not really. If you are performance conscious you structure your data
> and algorithms to match the tools you are using.
[...]

Well, yes, so what we're saying here is that the set of general memory
management problems is hard to solve, but if we can rewrite our program
so that its particular instance of memory management lies in an "easy"
subset for which there are known superior solutions, then performance
will be better.  This doesn't invalidate the fact that the *general*
memory management problem is hard.  It's like saying that sorting, in
general, cannot perform better than O(n log n), but the subset of
sorting problems where the data is already almost sorted, there are
algorithms that will perform better than O(n log n). The only problem
is, they will suck when given data outside of that "easy" subset.

Is it possible to transform given any arbitrary program into an
equivalent program whose particular instance of memory management lies
in the "easy" subset? I don't know. But even if it's possible, you still
have to "pay" for the cost of memory management -- this time by paying
with program structure rather than runtime performance: you will have to
constrain the way you write the program, otherwise you will have to deal
with a memory management problem instance outside the "easy" set.

This leads back to my idea of some kind of structural matching between
memory lifetime and program structure. If you can somehow structure your
program such that it corresponds with the structure of its memory usage
patterns, then you're in an "easy" subset of the set of general memory
management problems. It doesn't change the fact, though, that when there
is a mismatch, you're back in the "hard" set, and the problem is costly
to solve no matter what algorithm you use.


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs