4 ms·

I blame Benjamin Zorn in this paper: http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-665-93.pdf http://www.cs.colorado.edu/department/publ

by bediger 16y ago

I blame Benjamin Zorn in this paper: http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-665-93.pdf http://www.cs.colorado.edu/department/publications/reports/d... for the whole "programmers shouldn't manage memory" myth. Clearly, if you know what you're doing, you can do better than the OS and/or malloc() does. If you don't know what you're doing, you have bigger problems than writing your own allocator will quickly solve.

gjm11 16y ago
It seems a bit strange to blame Zorn for spreading the myth that "programmers shouldn't manage memory" on the basis of that paper, when at about the same time he was writing a bunch of other papers extolling the virtues of customized memory allocators: http://portal.acm.org/citation.cfm?id=172674 http://portal.acm.org/citation.cfm?id=172674, for instance.
- bediger 16y ago
  Did you read the "CustoMalloc" paper? It's more of the same. Just to illustrate, the paper you referenced has the title "CustoMalloc: efficient synthesized memory allocator". That is, "CustoMalloc" takes a look at memory usage patterns of a particular program, then generates a semi-customized allocator for that program.
  - gjm11 16y ago
    Yes, of course I read it. Yes, the allocators are synthesized; so what? The point is that "synthesize a semi-customized allocator for each program" is a very different thing from "just use what the system provides you with; you won't be able to do better".
kenjackson 16y ago
But the real point isn't "can you do a better job", but is it worth it to a better job? If I can use an OTS memory allocator and get within 2% of my hand-crafted hand-tuned allocator, I think I'd need to be extremely perf sensitive to care.
acqq 16y ago
As far as I see the Zorn's paper is about mallocs vs garbage collector (moreover, specific mallocs and a specific GC), whereas the main article here is about just allocating from VM versus managing your own cache with your own file read / write. And as others already noted, "'just' allocating from VM" can be better (less copying) once you can organize everything right and know how to manage the threads. And the main argument of the main article is "if you can't access it with different threads, VM access can block you everything" (that's the two clients complaint). That much both are right, as long nobody tries to make some too general statements like "just use always X."

by bediger 16y ago

gjm11 16y ago

It seems a bit strange to blame Zorn for spreading the myth that "programmers shouldn't manage memory" on the basis of that paper, when at about the same time he was writing a bunch of other papers extolling the virtues of customized memory allocators: http://portal.acm.org/citation.cfm?id=172674 http://portal.acm.org/citation.cfm?id=172674, for instance.

bediger 16y ago
Did you read the "CustoMalloc" paper? It's more of the same. Just to illustrate, the paper you referenced has the title "CustoMalloc: efficient synthesized memory allocator". That is, "CustoMalloc" takes a look at memory usage patterns of a particular program, then generates a semi-customized allocator for that program.
- gjm11 16y ago
  Yes, of course I read it. Yes, the allocators are synthesized; so what? The point is that "synthesize a semi-customized allocator for each program" is a very different thing from "just use what the system provides you with; you won't be able to do better".

kenjackson 16y ago

But the real point isn't "can you do a better job", but is it worth it to a better job? If I can use an OTS memory allocator and get within 2% of my hand-crafted hand-tuned allocator, I think I'd need to be extremely perf sensitive to care.

acqq 16y ago

As far as I see the Zorn's paper is about mallocs vs garbage collector (moreover, specific mallocs and a specific GC), whereas the main article here is about just allocating from VM versus managing your own cache with your own file read / write. And as others already noted, "'just' allocating from VM" can be better (less copying) once you can organize everything right and know how to manage the threads. And the main argument of the main article is "if you can't access it with different threads, VM access can block you everything" (that's the two clients complaint). That much both are right, as long nobody tries to make some too general statements like "just use always X."