Lit. Buffer overruns 1678

overcommitting RAM

Depending on the major release, SGI IRIX by default either does or doesn't overcommit, but the exact behaviour can be set at run-time. Their jargon confuses me quite a bit, so I can't comment on the consequences, but there is for example a setting where malloc() always returns true. Scary.

I disagree. I and others have run seriously overcommitted FreeBSD systems continuously, voluntarily and involuntarily, where the performance and responsiveness did not detoriate noticeably.

I prefer to point at well-known examples: ftp.cdrom.com was-is run that way for at a decade.

In contrast, I have now a Suse 9.2 Linux desktop system with a i386 2.6 kernel, and its default responsiveness is uneven and erratic.. But, until I know how to confure the internals, I will postpone my opinion of the latest Linux crop.

And let's not talk about Windows XP, where running more than ~20 applications is actively discouraged by the run-time system, which noticably degrades the responsiveness, and apparently on purpose.

I agree, but the problem is a lot older. For example I and others were writing small graphics demos and small action games for the Intel 386-486. We found out the hard way that the continous construction of 1 MB images in RAM busted the CPU caches, which more behaved like a toilet. For the things we did, it became more important to limit cache trashing (we didn't know how to solve it) than to write optimal tight loops.

scs