how would one go about running code/operations on ram as opposed to the hd?
On most Linux distros, /tmp is a ramdisk.
But with only 1 GB capacity
Tofu – The opposite of a font
11–20 of 66 posts
Re: Tofu – The opposite of a font
#12WARNING: 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.
You're right and I should have added more details. fontforge only accepts file paths and not strings sadly
Re: Tofu – The opposite of a font
#13Earlier quoted context omitted.
It's just that the python library used won't read SVG from a string, online from a file given a filename, so each character must be written to disk, then read back in.
Wow. To me that's definitely in the realm of "fix this if you need to run this program more than once" inefficiency. After looking at the implementation, it doesn't seem like it takes advantage of TTF's "composite glyphs" feature either, which would be the most straightforward way of generating a font like this --- once you define the box and the digit glyphs, each character is then composed entirely of references to…
Yeah I tried looking to see how much I would need to change to fix it, but I'm not too great in C which is what fontforge was written in.
Oh man I gotta look into the composite glyphs. I don't know much about fonts in general. Thanks for this bit of information.
Re: Tofu – The opposite of a font
#14> 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.
Fontforge doesn't have a function for loading svgs as glyphs from strings. Only files paths.
Re: Tofu – The opposite of a font
#15Re: Tofu – The opposite of a font
#16how would one go about running code/operations on ram as opposed to the hd?
On most Linux distros, /tmp is a ramdisk.
I don't think this is nearly universal - certainly none of the systems I use have /tmp as tmpfs.
/dev/shm, on the other hand, is almost always guaranteed to be a tmpfs on glibc systems.
Re: Tofu – The opposite of a font
#17WARNING: 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?
Re: Tofu – The opposite of a font
#18how would one go about running code/operations on ram as opposed to the hd?
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 app because everything was in memory. Imagine your code getting simpler because you don't need to load assets off disk - that's done all in one go at boot time. You want to render an image out? Just do it - a reference to a file is a reference to a file, no loading it or wondering if it's loaded.
Flash storage in phones is fast enough these days that it's probably not worth it, and simply giving traditional phones lots of RAM will probably give 80% of the improvement for 20% of the cost. But I've been curious about the idea for some time.
Re: Tofu – The opposite of a font
#19Earlier quoted context omitted.
It's just that the python library used won't read SVG from a string, online from a file given a filename, so each character must be written to disk, then read back in.
Wow. To me that's definitely in the realm of "fix this if you need to run this program more than once" inefficiency. After looking at the implementation, it doesn't seem like it takes advantage of TTF's "composite glyphs" feature either, which would be the most straightforward way of generating a font like this --- once you define the box and the digit glyphs, each character is then composed entirely of references to…
>To me that's definitely in the realm of "fix this if you need to run this program more than once"
Maybe the programmer doesn't need to use this more than once?
Re: Tofu – The opposite of a font
#20Earlier 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…
Then if the phone had originally 4 gigs of ram, you’d need an extra 4 gigs of ram for each app. I guess you could partition your ram to have 4 gigs as scratch, but that would limit the number of programs you can run.