Hidden Costs of Memory Allocation
randomascii.wordpress.com
randomascii.wordpress.com
http://millcomputing.com/wiki/Memory#Implicit_Zero_and_Virtu...
"The big gain for this is that the OS doesn't have to explicitly zero out new pages, which would be a lot of bandwidth and time, and accesses to uninitialized memory only take the time of the cache and TLB lookups instead of having to do memory round trips."
A similar mechanism zeroes a stackframe upon a function call (and function return, I think), which eliminates most attacks that exploit buffer-overflows.
Why not? The caches will still be coherent.
FWIW, both powerpc and arm64 have a "just zero the damn cacheline" instruction. That's not quite what you want, but it is quite useful.
There are, of course, pathological cases where you touch one byte on a new page, and then don't write anything else before the whole thing gets pushed out, but they are relatively rare in performance-critical contexts.
Uh? Anything which touch main memory is NOT 'an extremely cheap operation': that's why we have registers, L1, L2 (even L3) caches!
I believe Python essentially does this under the hood by allocating buffers and managing its own memory requests on them (allocating more when it needs more, obviously).
I wonder if it is possible to do this kind of thing in C++? It occurs to me that it might be hard to write platform-independent code which mimics the behaviour of the `new` keyword on a preallocated buffer. A quick Google reveals some syntax[1] that I'd not seen before which allows one to do this, although it looks like your call would look something like:
MyType* instance = new (my_malloc(sizeof(MyType))) MyType();
In any case, asking for all your RAM at the beginning, and then re-blanking and re-using it, is certainly much faster for certain problem types (3D games with physics emulation, some scientific problems.)
[1] http://stackoverflow.com/questions/8301043/create-objects-in...
disclaimer: This post is about reinventing too many wheels, and should be taken with a pinch of salt! Moving malloc calls out of loops (and replacing them with hand-written zeroing functions) is probably the most useful tip in practise.
You're really not supposed to do it with macros.
1. Changing the allocator used by the standard library by passing in a special allocator to instantiations of std::vector, std::map, etc.
2. Allocating raw memory elsewhere, and instantiating an object with that memory using the placement syntax for new.
3. Overriding operator new on just a particular class. This does not change the global new; it just means that objects of this class will be allocated with this version of new.
4. Overriding the global definition of new. All objects whose classes do not define their own operator new will be allocated with your own, global new.
More details here: http://en.cppreference.com/w/cpp/memory/new/operator_new
void* operator new ( std::size_t count );
void* operator new[]( std::size_t count );
void operator delete ( void* ptr );
void operator delete[]( void* ptr );
If you do it that way, you do not need to change any of the code that calls new and delete.
And I disagree about the 'relatively' in "I know that in C it is relatively easy to define your own memory management functions"
It is easy to piggy-back on an existing memory allocator, and it is fairly easy to make an implementation that works from a single thread, or an implementation that performs horribly from multiple threads, but it is not easy to make one that performs well from multiple threads and is useful.
[That "and is useful" is from the hacker in me. It is trivial to make what I think is a conforming implementation that multi-threads exceptionally well along the lines of (I am guessing at the prototypes):
void * malloc(size_t t) { return NULL;}
void * calloc(int n, size_t t) { return NULL;}
void free(void *m) {}
void * realloc( void *m, size_t t) { return NULL;}
The example I quoted in Python's implementation, though, seems to hold truer - rather than calling malloc whenever it needs more space it allocates buffers and hands out memory from them, reducing the frequency of calls to malloc, and meaning that its garbage collector sometimes can't free as much RAM as you hoped (since there are some nearly-empty buffers that can't be released.) This makes running python instructions which need a little more RAM much faster, at the expense of complexity when RAM is short, of course. And overall the program should be faster, since it has fewer system calls (assuming that the code which hands out RAM is well optimised, which should be possible since it can be much simpler than the system malloc.)
C++ standard meets modern runtimes. Wheee! :-)
my_type* t = New( MyType ) ;
Where MyType passes information to New() of what to create.
...
I don't know what I'm downvoted.
This clearly works. The naive solution without macros would have MyType be a simple integer and New() has a switch statement. But it is easy to avoid that.
Better to zero memory ahead of time.
And it guarantees that when a process goes to use the pages they will not be in the cache. Ah, tradeoffs.
> And it guarantees that when a process goes to use the pages they will not be in the cache.
There isn't much point in caching a page full of zeros. Let the cache fill when there is actual data.
Deleted comment
It seems that navigational databases, which relational databases largely replaced, would be even more sparing of disk space, which makes me think that claim is rather suspect.
How about another explanation:
Relational databases are to data what structured programming (using for loops and while loops and functions and local variables instead of, you know, not) is to code: It reduces the potential for error by, first, encouraging single-point-of-truth via normalization, and, second, encouraging people to make as many tables as possible automatically via queries which use relational algebra.
In short, every table knows about one kind of thing. Everything your database knows about that kind of thing is in that one table. If you want to know more than one kind of thing at a time, you create a new table automatically with a query.
Compare: Every function does one kind of thing. Everything your program knows about doing that kind of thing is in that function. If you want to do more than one kind of thing, you compose functions and let the details of flow control be handled automatically by the runtime.