I would say a good rule of thumb is indeed just as was mentioned above. 2 times the physical memory. Something to consider here, while it is possible to use a smaller swap partition, and it will suffice under most normal circumstances, if you want this system to be rock solid stable, I would indeed follow the 8 GB recommendation. In fact I recommend 2 * RAM + 1 MB so that there is absolutely room to swap out 2 entire copies of memory. This avoids the "shell game" scenario which can have negative performance repercussions. What this will do for you is guarantee a level of resiliency should you encounter an extraordinary event with your system.
I've seen scenarios where applications behave badly in unattended environments and before you know it, your system starts slowing down to a crawl.
Depending on what you are doing, you might even be able to dispense with the swap file entirely. The extra space for the OS is handy when running many applications at once. However if you only intend to run a few processes, do not intend to interact with the GUI disabling the swap file might be appropriate.
But if you are going to have a swap file I always use the sizing formula below.
[(2 x RAM) + 1 MB] = Swap File Size
I also recommend putting your swap file on a seperate disk whenver possible as this will increase performance as the OS can swap in and out at the same time as read/writes from the data disk.
I hope this is helpful.
Well, the problem is a bit more complicated.
First, the assumption expressed in the question is false. Hard disks and flash memories do not actually need partitions at all! You can simply write raw data on a hard disk and then read it back and it will work fine. Some relatively simple computer systems aren't using partitions even today, because there's no need to use them. For example I have right here right now on my desk a computer which is based on ATmega 162 microcontroller and it uses flash fine with no partitions.
Basically, what partitions do is enable separation of labor responsibilities among system designers. On my 162, I need to know where each bit of data is stored and how many times is each flash cell accessed, so I can implement wear leveling. To do that, I don't even need files. The problem however is that my miniature computer has only 16 KiB of flash and that amount can be managed by hand and source code comments. It's like having a desk with a single drawer. I can put anything there and it will be easy to reach and access.
On a large computer system, such as today's desktop computers, software is a product of work of thousands of programmers working separately. They need to have some way of storing data and that's why we need files and partitions. When we have them, programmer can focus only on data he needs to work with and doesn't need to worry about damaging other data. He can let programmers working on filesystem programming worry about physical storage of data. To continue my drawer example, that's like having a system of warehouses and trying to find one single item if you have hundreds of thousands of items in stock. So while you could just reach into the simple drawer and get a pencil for example, in warehouse case, the pencil would be in warehouse 3, section P, shelf 273, level 3, box 5.
I hope I made it clearer why we use partitions even if we actually don't need them.
Now to move to RAM. It's also untrue that there are no partitions in RAM. The basic reason why we use partitions is organization and RAM is organized too. In RAM's case, however, it's system's kernel which decides where each bit of information is going to go and it keeps track of space usage.
Let's compare how a program on my simple ATmega 162 works and how a program on a modern operating system like Windows works. On 162, program is preprogrammed with addresses of memory locations which it is going to use to store data. Since 162 only has one program, I don't need to worry about overwriting data used by another program or about allocation of memory. I can just write whatever I want into each memory cell and it will remain there while the computer is running.
On the other hand, on Windows we can have large number of programs running at the same time and all of them would be writing and reading data into and from the memory. That is we we can't allow individual programs to directly access memory cells (and the fact that the programmer would have to know how to access memory on that particular computer and how much RAM that computer has and so on. At this point we get back to thousands vs. one programmer discussion.). Instead, when each program starts, kernel allocates memory for it and to the program, it looks as if it's the only program running on the computer. Kernel is there to make sure that our program doesn't try to read or write memory given out to other programs and that it doesn't try to execute memory marked as data and that it doesn't bring entire system into danger. So basically on Windows and many many other modern operating systems each program gets its own partition of RAM. It's also interesting o note that on 32bit systems, each program could take only up to 2 GiB of RAM, because that was the upper limit of the "partition"'s size.
I'd like to make a small digression here. There are some programs which are hurt by partitions in RAM. For example, there were programs called trainers which would allow cheating in computer games. They worked by finding memory location where game stores its data on for example number of lives or health and then they would directly access the data and change it. On the other hand we also had viruses which worked by trying to access memory used by important system services and corrupting it to enable them to do their nefarious deeds.
Another thing worth brining up is pagefile or swap partition. To a programmer writing an application, it's not important if the program is in pagefile or if it is in RAM, because kernel takes care of that. On my ATmega 162, situation is a bit more complicated. When I need to use more RAM than it is available, I must first detect by hand situation when I have used up all RAM, after that I need to manually copy data from RAM to flash, free up the RAM, use it for whatever I need to use it for, free it up again, move data from flash to RAM and then free up taken space in flash memory. On a desktop computer, program can't even see if it has been swapped onto disk and then moved back into RAM.
One more interesting thing is performance. Let's go back to the drawer and warehouse example. Let's take all items from our warehouses and dump them at one pile. So if we need to take one pencil from the drawer, we'll just open the drawer and take the pencil. If we need to take one particular pencil from a pile of thousands of other pencils, notebooks, rulers, candy bars, erasers and what not, we'll have to spend considerable time searching for it. That time (in average case) is much longer compared to time needed to find the same pencil in a well organized warehouse. On the other hand the time needed to find pencil in an organized warehouse is much longer than time needed to find pencil in a drawer. So some methods work well on small amounts of data and some work well on large amounts of data. Filesystems improve performance by storing data in a logical way on the disk in which each individual datum can be easily found. Some filesystems also provide other benefits. In case of JFFS2, a filesystem designed for flash memories, filesystem implements wear leveling so that user or hardware designed don't have to.
Yet another interesting thing is that we can use standard filesystems for RAM too! There are programs which will take up RAM and organize it just like a filesystem and allow programs to use it as if it was disk space.
Some interesting links:
Wikipeda Memory management article describes how and why is data in RAM partitioned.
Operating system article, memory secction explains why we need things like memory segmentation, virtual memory paging and so on.
Best Answer
You probably only need a small amount of swap. When you have sufficient RAM for your computer's typical working set, which I'm pretty sure you do, you only need swap for two things:
You need swap to get information that will likely never be accessed out of RAM to free up more space for disk cache. Many applications run on system startup and will never be accessed again. You don't want any pages they dirtied stuck in RAM forever. So you need swap to hold them.
You need swap to cover allocations that will never be filled. This space simply has to be available, even though it will not be used. Without it, the system will have to refuse to allocate memory even when it has plenty of free physical RAM because it has insufficient backing store to permit all of its allocations to be used at once.
Neither of these requires a large amount of swap. 16GB, for example, should be more than enough. The purpose is not to let you run bigger working sets at the cost of speed. The purpose is to let you use your 64GB effectively and not have to clog it with junk or reserve it for edge cases that will never happen.
(I agree with Bert that 4GB is quite likely to be sufficient.)