Tuesday, August 26, 2014

RAM disks and page files.

I've run across some bad information on the Internet more than a few times lately, and it prompted me to try to counter this misinformation about optimizing workstation computers with gobs of RAM.

The tl;dr version is: leave your RAM alone, let the operating system manage it. Teams of people smarter than you and I have figured this problem out.

The Problem:

The advice is basically that emulating a hard-drive/ssd with system RAM will speed up your system, and that moving your paging file to the RAM Disk can improve system performance. That is just wrong. Why does this idea never seem to die the death it deserves? I think there is a lot of misunderstanding of what a page file is. There seems to be this idea that the reason a PC is running slow is because it's spending too much time writing to the paging file. 

How paging files work.

All modern desktop operating systems support the idea of a paging file. In short, a page file is the operating system's way allowing programs to ask for more RAM than what actually exists. In the old days, when RAM was used up, the operating system simply returned an error when a program asked for more memory. The purpose of a page file is not to speed up a computer, it is to allow your drivers and applications to have access to more memory than is actually available on the system. Indirectly, a paging scheme can make available more RAM for other uses, which does lead to high performance. 

Mental experiment: a femto computer:

Monday, August 18, 2014

New Domain

I'm trying out Google's new Domain service. It seems Blogger is a little paranoid and throws up a ton of "redirect" warnings. I'm hoping that The Goog figures out that both services are their own, and it's the same person linking this blog to www.bytecruft.com. Either that, or I've got something horribly configured.

I swear by Oden, I shall return to this blog in full strength.

In the mean time, enjoy the fruits of my recent tinkering with Javascript. I'm certain that I probably made a lot of js faux pas, but hey, it's Javascript, the business casual programming language. I want to build a lot of "nano" tools or interactive demos, and using the browser is the best way to get the widest reach. Once I get a little more of a command of it, I think I'll switch to something like TypeScript or Dart.

I'm pretty sure that you'll run into issues if you use anything but the latest browsers, I didn't do any testing of old browsers, and probably will always target the latest stable browsers.

I wrote a calculator tool for determining the target address for an AVR microcontroller relative jump instruction. The motivation was personal, I've spent a lot of time recently staring at hex dumps from AtTiny devices, I wrote a bootloader (more on that in a future post), and debugging it involved memory dumps of a lot of dynamically generated rjmp instructions. (AtTiny device do not have hardware support for bootloaders, so you have to fake it in software). I got tired of calculating it by hand, so I wrote a spreadsheet, and thought, "If I could write it in a web app, it would be there forever, and I'd always have access to it".

Check it out at: