Time to merge memory?
-
That's effectively what a RAMDisk IS :p Just a user-friendly way for an end-user to directly interface with the RAM itself, as last I checked, you can't simply copy-paste files onto your RAM using Windows any other way ^_^
-= Reelix =-
For your prorgram to access these pasted data, it would have to be informed about that pasted file - the fact that it is there, and its name - and then use rather CPU-consuming operations to access it. If you rather pasted the file name into the application, it could map the original file into its memory space and access it like any other (pageable) RAM, without the file system overhead. The parts of the file not accessed would never even be brought into RAM. For the exercize of copying files, I can see the point of getting some really good figures to impress people with, but I don't see any good use case, at the end user level. For what purposes would it be valuable to drag a file from a disk drive to a RAM drive, and then have an application use the file system to copy those RAM data to its own RAM area, rather than having the application reading the original disk file directly as a memory mapped RAM segment?
-
- The question is not whether to push it fo flash or not, but whether to push it out at all. Why do you want to add the (significant) overhead of paging if you've got more RAM? Leave it in RAM as ordinary working storage! 2) Huh? If you've got 16 GB (or less) as RAM, and then introduce paging, you are creating a virtual RAM space greater than 16 GB - flat as the earth (locally, that is). If you are able to make good use of a virtual RAM address space >16 GB, why would it be more difficult to make good use of >16 non-virtual RAM space? 3) Very few if any photo/video editors are even close to a 16 GB working set, no matter what material you are editing. Even when you process video, you do it clip by clip. Clips >16 GB are exceptional. Practically all such processing is sequential; it doesn't consider all the video information of a clip as a whole. Double buffering and DMA has been established techniques for ages, and when your CPU churns HD video (or higher), every modern disk is fast enough to provide data for the CPU.
Member 7989122 wrote:
- Very few if any photo/video editors are even close to a 16 GB working set, no matter what material you are editing. Even when you process video, you do it clip by clip. Clips >16 GB are exceptional. Practically all such processing is sequential; it doesn't consider all the video information of a clip as a whole. Double buffering and DMA has been established techniques for ages, and when your CPU churns HD video (or higher), every modern disk is fast enough to provide data for the CPU.
But very few video editors actually load the full movie into main memory... most of them decode the video into an uncompresed format such as avi and leave it in the temp folder, then they edit on that part. Imagine like a 2 hr h.264 encoded mp4 @ 1080p, that takes about 6 gb is decoded into a 32 gb avi, then I choose to sepia-tone it... again 32 gb write, then again encode back to h.264 et al... So, how many writes did I do? My OCZ vector has a recommended at most 10 GB of writes per day.