31–40 of 65 posts
You aren't running this in the standard language/caching/db setup, then? You're storing EVERYTHING in memory? Isn't this kind of.. well, stupid, frankly.
You could always use Erlang...
You aren't running this in the standard language/caching/db setup, then? You're storing EVERYTHING in memory? Isn't this kind of.. well, stupid, frankly.
Dude, frack no. Having everything in a database means you are tied to the speed of disk, instead of the speed of ram. The biggest issue with being purely ram resident is handling multi-threaded updates across your ram resident dataset. You could always use Erlang...
Earlier quoted context omitted.
Dude, frack no. Having everything in a database means you are tied to the speed of disk, instead of the speed of ram. The biggest issue with being purely ram resident is handling multi-threaded updates across your ram resident dataset. You could always use Erlang...
That's why you use intelligent caching.
I thought 32-bit addressing gave 4GB of addresses…is there some sort of flag that's taking one bit? Not trying to be a smartass, just curious about the discrepancy.
The OS sometimes reserves quite a chunk. For example, Windows XP really only has 2.25GB available. Putting more RAM in is pretty useless unless you switch to 64-bit.
Earlier quoted context omitted.
It does give 4 GB of addressable space, but many things are memory mapped by the OS, and so on a 32-bit system you end up with anywhere from 2.8 to 3.5 GB of addressable memory.
So by 2GB he meant usable, not addressable? I understand that addressable RAM != 4GB due to graphics card memory, BIOS, etc. but 2GB is way less than you could get on a 32-bit server. I just wanted to understand if there's something I'm missing.
Earlier quoted context omitted.
It does give 4 GB of addressable space, but many things are memory mapped by the OS, and so on a 32-bit system you end up with anywhere from 2.8 to 3.5 GB of addressable memory.
So by 2GB he meant usable, not addressable? I understand that addressable RAM != 4GB due to graphics card memory, BIOS, etc. but 2GB is way less than you could get on a 32-bit server. I just wanted to understand if there's something I'm missing.
You aren't running this in the standard language/caching/db setup, then? You're storing EVERYTHING in memory? Isn't this kind of.. well, stupid, frankly.
Dude, frack no. Having everything in a database means you are tied to the speed of disk, instead of the speed of ram. The biggest issue with being purely ram resident is handling multi-threaded updates across your ram resident dataset. You could always use Erlang...
database are not tied to a storage medium. there is no reason why you can't run a DB (key-val or even a full RDBMS) in RAM.
Earlier quoted context omitted.
While the comment above may not have the best manners, it does bring up an interesting point. I certainly wouldn't mind hearing more about HN's setup.
If you're really curious and have the time, you can download the source: http://arclanguage.org/install
Earlier quoted context omitted.
dynamic languages end up using more memory, because extra information has to be stored about each item (I.e. Type, tc info, etc).
Down-voters, he is also right. It's common for dynamic languages to embed typing information in pointers as an optimization. For example, CLISP uses at least 2 bits to distinguish between common types. That way fixnum numbers can be recognized and added without slow memory accesses. The result is that you get less bits for the address. Hence less addressable memory.
I thought 32-bit addressing gave 4GB of addresses…is there some sort of flag that's taking one bit? Not trying to be a smartass, just curious about the discrepancy.
There ends up being only 2GB of heap, which is where all the stories and comments live.
I presume that you're not hitting a melt-down from CPU time, so I'd assume you'd get better performance by letting the system handle paging in data from the disk and figuring out which stuff needs to be in memory (buffers) and lives out on disk.
Also one thing to watch out for when you make the 64-bit jump is that (internally pointer-heavy) applications in dynamic languages tend to use significantly more memory on 64-bit platforms. davidw talked about this some here: