Live data from Hacker News

Tofu – The opposite of a font

github.com

21–30 of 66 posts

Re: Tofu – The opposite of a font

#21
post #10

Earlier quoted context omitted.

On most operating systems you can use part of your RAM as disk. Format it like a regular disk, mount it and save files on it. The data is gone if you restart tho.

I've wondered for a while how fast we could make a phone (or PC) that operated entirely in RAM disk and used flash storage just as a one-to-one backup and storage when powered off. Obviously this would require your phone to have 128GB of RAM. You'd write changes to the flash storage, but it'd mirror RAM as closely as possible without destroying power management or storage life. Imagine if there was no lag opening any…

> I've wondered for a while how fast we could make a phone (or PC) that operated entirely in RAM disk and used flash storage just as a one-to-one backup and storage when powered off. Obviously this would require your phone to have 128GB of RAM. You'd write changes to the flash storage, but it'd mirror RAM as closely as possible without destroying power management or storage life.

PuppyLinux did this for the Eee PC. Worked wonderfully. The only problem was that the distro eventually became outdated, filled with old packages.

http://www.puppylinux.org/wikka/EeePC

Re: Tofu – The opposite of a font

#22

WARNING: PLEASE DO NOT RUN THIS CODE ON A HARD DRIVE, I'M NOT SURE HOW LONG IT WOULD TAKE. I USED A RAM DISK I haven't looked at the implementation, but this seems to imply it is very I/O intensive and already takes a very long time in RAM. Yet, nothing about the problem statement suggests it would be such a task --- it sounds like something that could be very straightforwardly done completely in memory.

Hobbyist-only coder here who hacks together high-level crap, not memory management and such. Question - If this program needed to operate from memory instead of a disk, why didn't the coder just... code it that way? Are they saying to use a RAM disk to ensure you don't encounter automatic paging out to disk by the OS?

I believe it's a requirement of font forge that they're using.

It requires file paths, and it will be doing a large amount of reading. Easiest way of solving this is probably just to fake that your memory is a hard drive.

Re: Tofu – The opposite of a font

#23

WARNING: PLEASE DO NOT RUN THIS CODE ON A HARD DRIVE, I'M NOT SURE HOW LONG IT WOULD TAKE. I USED A RAM DISK I haven't looked at the implementation, but this seems to imply it is very I/O intensive and already takes a very long time in RAM. Yet, nothing about the problem statement suggests it would be such a task --- it sounds like something that could be very straightforwardly done completely in memory.

That warning made me want to try it on my hard disk just to see how long it would take...

It was only a couple minutes. That's a bit disappointing.

Re: Tofu – The opposite of a font

#24

WARNING: PLEASE DO NOT RUN THIS CODE ON A HARD DRIVE, I'M NOT SURE HOW LONG IT WOULD TAKE. I USED A RAM DISK I haven't looked at the implementation, but this seems to imply it is very I/O intensive and already takes a very long time in RAM. Yet, nothing about the problem statement suggests it would be such a task --- it sounds like something that could be very straightforwardly done completely in memory.

Hobbyist-only coder here who hacks together high-level crap, not memory management and such. Question - If this program needed to operate from memory instead of a disk, why didn't the coder just... code it that way? Are they saying to use a RAM disk to ensure you don't encounter automatic paging out to disk by the OS?

[deleted]

Re: Tofu – The opposite of a font

#25
post #6

> WARNING: PLEASE DO NOT RUN THIS CODE ON A HARD DRIVE, I'M NOT SURE HOW LONG IT WOULD TAKE. I USED A RAM DISK How much disk IO does this program generate? Why? In any case, the OS should cache stuff and give similar performance to using a ramdisk, provided you have enough spare ram.

> the OS should cache stuff When I worked at Microsoft back in the 90's I inquired around building 26 as to why I couldn't create a ram disk on what was to become Windows 2000, and this was basically the answer. So yes, if caching doesn't solve this then caching hasn't been implemented correctly.

What if you're using a program that fsyncs? And the filesystem isn't just keeping writes cached and flushing only when full. So if I'm writing GB of temp files, I'm causing tons of disk load which may impact other programs. Can't seek to read while writing all my temp data...

Re: Tofu – The opposite of a font

#26
post #23

WARNING: PLEASE DO NOT RUN THIS CODE ON A HARD DRIVE, I'M NOT SURE HOW LONG IT WOULD TAKE. I USED A RAM DISK I haven't looked at the implementation, but this seems to imply it is very I/O intensive and already takes a very long time in RAM. Yet, nothing about the problem statement suggests it would be such a task --- it sounds like something that could be very straightforwardly done completely in memory.

That warning made me want to try it on my hard disk just to see how long it would take... It was only a couple minutes. That's a bit disappointing.

SSD or spinning platter?

Re: Tofu – The opposite of a font

#27
post #23

Earlier quoted context omitted.

That warning made me want to try it on my hard disk just to see how long it would take... It was only a couple minutes. That's a bit disappointing.

SSD or spinning platter?

Spinning platter. ZFS with compression is probably helping that.

Re: Tofu – The opposite of a font

#29
post #27

Earlier quoted context omitted.

SSD or spinning platter?

Spinning platter. ZFS with compression is probably helping that.

Your OS is probably caching the file at the virtual memory layer, so it doesn't even have to hit the filesystem at all.

Re: Tofu – The opposite of a font

#30
post #6

Earlier quoted context omitted.

> the OS should cache stuff When I worked at Microsoft back in the 90's I inquired around building 26 as to why I couldn't create a ram disk on what was to become Windows 2000, and this was basically the answer. So yes, if caching doesn't solve this then caching hasn't been implemented correctly.

What if you're using a program that fsyncs? And the filesystem isn't just keeping writes cached and flushing only when full. So if I'm writing GB of temp files, I'm causing tons of disk load which may impact other programs. Can't seek to read while writing all my temp data...

That's actually a good point.
Post reply on HN