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