Re: Is Greenspun enough?

George Neuner wrote: 
I've written several custom allocators from scratch for realtime use
on various platforms, including a cute 2 dimensional tiled allocator
for a proprietary image processor, but for desktop/server apps the
most I have ever needed to do is preallocate arrays of objects and do
ring, stack or list management on the arrays [a driver might need the
array memory to be non-pageable].  But I would only bother if the
situation could not be handled by the default language or OS
allocator(s).

Yeah, usually I don't bother, but for instance I sometimes allocate objects with indentical lifetimes in one big chunk, so I can free it all at once ("regions"). For that, malloc wasn't built. In fact I wonder why everybody uses it as if it were general-purpose; it's just a single way to de-/allocate memory, and certainly not suited for small objects, fast allocation, and low space overhead (in the implementations I know of).

I assume a substantial fraction of memory waste (pardon, usage) and runtime originates from mallocing stuff, filling values in, moving them around, and then maybe deleting stuff again (but most programs don't seem to bother, be it in Java, C++, or even Aquamacs; their mem usage increases until I restart them once they reach 100-200 MB). The part of an application that actually *does* something must be a fraction. 

Applications tend to monotonically increase their range of reserved
virtual addresses ... precious few ever bother to release unused pages
back to the system.  Unless the application tracks and reports on its
true memory usage [e.g., logging GC], there is usually no way to tell
how much of the system reported reserved range is really in use.

And that means after a while you'll page out stuff that'd be in fact unused. It's like user applications blocking memory, by caching things. You'd think that caching should be unified in the OS itself, because then the OS can decide when to un-cache (instead of taking up all memory) to free up memory.

Often even the OS cache is stupid, and after having watched a movie at your computer, you notice that everything else was paged out in the process, just so the whole stupid movie could fit into the file cache (as if you ever wanted to cache sequential stream-like files, for using them more than once).

Oh well, people have been throwing more CPU and more RAM at the problem for decades, and today's computers are almost as fast as they were in the late '80s. No need to worry, or do develop something decent. :)

--
Majority, n.: That quality that distinguishes a crime from a law.
.

Relevant Pages

  • Re: Cached memory never gets released
    ... Stock linux 2.4.26 kernel. ... Due to flash bug 3M of memory gets lost due to font memory getting lost ... The output of "free" cache number steadily grows. ... longer to exhaust all of system memory with the cache. ...
    (Linux-Kernel)
  • Re: Problem: Creating a raw binary string
    ... > While its true that a 64-bit cpu will move twice the data per instruction it ... > Memory bus width plays an important role here and unless it too is widened / ... You are forgetting the two levels of cache in the processor. ... The memory chips are addressed in Row col fashion. ...
    (alt.comp.lang.borland-delphi)
  • Re: Is Greenspun enough?
    ... Most OSes memory map executables directly from the file system so code doesn't pollute the file cache or swap space. ...
    (comp.lang.lisp)
  • Re: Superstitious learning in Computer Architecture
    ... Without a LOT of logic or some other better approach, re-executing the instructions requires re-decoding and it ties up the cache memory bus transferring more data as instructions than the instructions are working on. ... The concept of cache is fundamentally flawed in that it STILL restricts access to one word per clock cycle, when a single modern ALU can easily use 5 plus whatever is eaten up with instruction accesses. ... The size of an optimizing compiler is proportional to the SQUARE of the size of the language times the SQUARE of the complexity of the machine - because all interactions must be considered. ...
    (comp.arch.arithmetic)
  • Re: FPGA-based hardware accelerator for PC
    ... I know that in most cases the CPU ... that it contsins no cache, as BRAMs are too precious resources to be wasted ... The BRAMs are what define the opportunity, ... many threads with full associativity of memory lines using hashed MMU ...
    (comp.arch.fpga)