Warp wrote:
> You usually want your app to be able to handle as much data as possible.

Yeah. My background tends towards needing to crunch arbitrary amounts of 
data, and hence I look at data structures that cache to disk more 
efficiently. The sorts of stuff I write can't rely on having enough memory 
to hold it all, but also tend to assume you're not going to look at all of 
it at once (like a database of customers, for example, rather than a game, 
where you really want the whole level in memory at once).

>   Also my recent programming history can also have some effect on how I view
> these things, namely programming for handheld systems. 

Cool. Yeah, I'm kind of impressed, actually. I'm writing code for set top 
boxes right now, and the boss has me porting webkit to the machine. He's all 
worried about the performance, and I'm saying "maybe you shouldn't have two 
layers of interpreted language on top of your 100MHz CPU just to draw your 
top-level menus."

Coming from the credit card terminal world, where having 14K of ram was 
pretty much top-of-the-line, it's a little boggling to have a whole 128M of 
RAM. :-)

Handheld machines are definitely still the cutting edge of resource pain, 
tho, yes.  Especially since people expect them to do flashy things 
efficiently and cheaply and responsively.  CC terminals need to be quick, 
but nobody really cares if you have a 16x4 text-only B&W screen on one.

>>  Of course, the killer is the ratio of the number of nodes to the 
>> amount of memory, so sure, when you start getting up in the 2^25 number of 
>> nodes range the size of the nodes is going to be prohibitive on a 32-bit 
>> machine again.
> 
>   Hmm, I'm not so sure. 2^25 nodes, each node taking eg. 16 bytes, would
> require "only" 512 MB of RAM, which is well below the capacity of any
> modern desktop system.

Fair enough. It's getting close to the limit of what you can put in one 
address space conveniently, is all. (On a 32-bit machine, that is.) Of 
course you still have the malloc()/free() space overhead for each blob, and 
whatever the rest of the program is doing, and etc.

You can run into limits either way, with small memories or with google-sized 
data. With my work, I tend to run into problems with google-sized data, 
where the speed of even copying files from one place on the disk to another 
is a significant overhead. I can see how if you're looking at it from a game 
console or handheld device POV, you can see the space problem in a different 
way.

-- 
   Darren New, San Diego CA, USA (PST)
   Insanity is a small city on the western
   border of the State of Mind.

Post a reply to this message