 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.06.2010 20:34, schrieb Orchid XP v8:
>>> Today if it doesn't fit in RAM, the OS makes the computer
>>> pretend it has more RAM than it does (with the *minor issue* of a vast
>>> slowdown and halving the life of your harddrive).
>>
>> I'd rather put it this way: Today, if it doesn't fit in RAM, the OS
>> helps you "juggling" the memory chunks to work on. (And if it doesn't
>> fit in L1 or L2 cache, the CPU provides essentially the same service.)
>> Which makes life much easier in a world where you don't know how much
>> RAM you'll have when programming the software. (Back then, you /did/
>> know the specs of the one machine you wrote your programs for.) Plus,
>> it allows much easier and faster (and therefore more economical)
>> design of software where runtime performance doesn't matter that much.
>
> Well, there is that, yes. But I (and presumably everybody else) would
> prefer it if we could actually make RAM really, really fast...
... which will never ever again happen for main memory, at least not in
the sense of being equally fast as whatever caches we'll be using then:
We'll always have to live with memory being arranged in multiple tiers
of different speed.
>> (As for harddrive life, I guess that depends on your harddrive.)
>
> If stuff is being swapped out just because it isn't being used right
> now, that's fine. But watch a program trying to random-access several GB
> of data when you don't have multiple GB of RAM. It's an extremely
> efficient way to give your HD a *very* strenuous workout! ;-)
Sure, but some HDs are designed for this type of life.
BTW, it's not harddrive life that worries me in such situations, but the
bare struggle to get the system's attention back. Try killing a
swapping-mad program when it keeps thrashing the task manager out of
main memory... >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> BTW, it's not harddrive life that worries me in such situations, but the
> bare struggle to get the system's attention back. Try killing a
> swapping-mad program when it keeps thrashing the task manager out of
> main memory... >_<
Heh. Fun... Actually, the one I usually have trouble with is Alt+Tab
from a game back to the Windows desktop. Takes several lifetimes in both
directions. No idea why.
One thing I discovered back at uni: If your Java program accidentally
goes into an infinite loop, it dies almost instantly with a stack
overflow. If your Smalltalk program accidentally loops forever, it's
usually a few minutes before you realise that it's actually filling the
entire VM address space with garbage. Now try stopping it. :-)
Literally, it's so determined to follow your instructions as efficiently
as possible that for a while you don't even realise what's wrong. It
just looks like it's "busy".
Of course, infinite loops are much, much more common in Smalltalk. A
very common idiom is to write
#new
super new.
...stuff...
But if, by some slip, you instead write
#new
self new.
...stuff...
...then calling #new immediately calls #new, creating an endless
allocation loop. o_O
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> One thing I discovered back at uni: If your Java program accidentally
> goes into an infinite loop, it dies almost instantly with a stack
> overflow.
That's just because the VM only claims a small amount of RAM to start with...
quite irritating actually, it took me ages to work out I had to increase its
allocation to get my fractal plotter to be able to hold a decent image :-)
(but then it was too slow anyway so I rewrote it in C)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> BTW, it's not harddrive life that worries me in such situations, but the
> bare struggle to get the system's attention back. Try killing a
> swapping-mad program when it keeps thrashing the task manager out of
> main memory... >_<
Hell, even if it's just copying big files, you have the same problem.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Invisible wrote:
>> contains a couple of CPU cores plus (say) 2GB of RAM.
>
> What makes you think nobody has done this?
Au contrare, what makes you think that somebody *has* done this?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> One thing I discovered back at uni: If your Java program accidentally
>> goes into an infinite loop, it dies almost instantly with a stack
>> overflow.
>
> That's just because the VM only claims a small amount of RAM to start with...
> quite irritating actually, it took me ages to work out I had to increase its
> allocation to get my fractal plotter to be able to hold a decent image :-)
>
> (but then it was too slow anyway so I rewrote it in C)
Smalltalk seemed to be very, very good at handling large amounts of
objects in RAM. It didn't complain or anything, it just got on with it.
Unfortunately, usually the only reason for this happening was programmer
error. :-/
Haskell (or rather, GHC) is similar. It will happily eat several GB of
VM very quickly. The difficulty isn't figuring out how to allocate
enough space; it's finding the magic CLI switch that tells it to quit
rather than eat all available RAM!
(There's a switch that makes it die if the program tries to allocate
more than X. If you happen to know that your program can only possibly
require a few MB, set this switch and if there's a bug, the program will
die rather than kill you.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In other news... I get the impression that the world is probably heading
towards NUMA anyway. Not sure precisely how that changes the picture -
other than making it much, much more complicated...
(I'm not sure, but I think it might mean that you have explicit control
over what is stored where and when it gets moved, which could be a win
if compilers are smart enough to do the right thing.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Sure, but just as an example, what's the fastest way to sort a 10 KB array
> when you have 16 KB or RAM?
You just go and do it. I'm sure the sorting algorithm fits in the remaining
6KB.
Or did you get those two numbers backwards?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Darren New wrote:
>> Invisible wrote:
>>> contains a couple of CPU cores plus (say) 2GB of RAM.
>>
>> What makes you think nobody has done this?
>
> Au contrare, what makes you think that somebody *has* done this?
Well, two gig is a bit high, but several hundred meg is not uncommon.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> What makes you think nobody has done this?
>>
>> Au contrare, what makes you think that somebody *has* done this?
>
> Well, two gig is a bit high, but several hundred meg is not uncommon.
Like I said, it seems there's a relationship between capacity and speed,
such that by the time you get to this size, there wouldn't be much speed
advantage to putting it on-chip.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
