IIRC, it has been said that RAM disk is a lot slower than how it should be.

Is it still so? (for example when compared to MOS implementation)
Is there any development for a improved RAM disk? Third party replacement, perhaps?

I use RAM disk heavily and I would be interested in getting it optimized, if possible.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK

Quote:

Third party replacement, perhaps?

No, never! It is the OS who should care for RAM Disk, not some nasty hack.

Quote:

I use RAM disk heavily and I would be interested in getting it optimized, if possible.

Me too.

@KimmoK

There have been improvements in OS 4.1 for the ram-handler. Especially you can see this on OS 4.1 Classic where deleting paged files is like 5X faster.

_________________
AmigaOS 4.x Beta Tester - Classic Amiga enthusiast - http://www.hd-zone.com is my Amiga Blog, check it out!

@pavlor

Quote:

No, never! It is the OS who should care for RAM Disk, not some nasty hack.

Third party filesystems are not more hacky than ones supplied with the OS. RAM disk is nothing but a filesystem using free RAM as storage space. There are even OS tools to dismount RAM disk.

As far as RAM disk performance is concerned please note that it is not depending only RAM disk filesystem implementation itself. Memory management, CopyMem() performance, task scheduler efficiency and underlying DOS are contributing to results.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@KimmoK

Quote:

KimmoK wrote: IIRC, it has been said that RAM disk is a lot slower than how it should be.

Could you be more specific? The RAM disk operations (as provided by ram-handler) roughly break down into reading/writing/creating files, scanning directories, accessing individual directory entries and modifying directory contents.

Quote:

Is it still so? (for example when compared to MOS implementation)

Maybe, maybe not.

I know from experience that memory management, as needed by the file read/create functionality, used to be a major bottleneck. The 2.x/3.x ram-handler tried its best to save memory where it could, but did so at the expense of making the memory management more complex, and spending more time on the task. It also pushed memory fragmentation, as a side-effect.

Random read/write access to file data was hampered by the choice of data structures used in the 2.x/3.x ram-handler, which strongly favoured sequential access.

Accessing individual directory entries used to be very poor in terms of performance in the 2.x/3.x ram-handler, whose data structures would strongly favour sequential access. Sequential access, i.e. scanning directory contents one entry after another, is rather uncommon. Opening a file is much more prevalent, and the original ram-handler performed poorer as the number of files and directory entries increased.

All these changes were intended to remove "friction", by improving efficiency and scalability. Instead of wasting CPU time because of poor choice of algorithms and data structures, different choices were made.

The original ram-handler design mostly followed rules which may have been appropriate for a computer with relatively little unused RAM (say, less than 512K). Hence, you did not feel the design's limitations as much as you would on a system which stored much more data, or many more directory entries, as more available memory permitted.

Quote:

Is there any development for a improved RAM disk?

As for AmigaOS4, I believe that every aspect of the ram-handler was either tuned or reimplemented years ago.

Quote:

Third party replacement, perhaps?

Well, take you pick Every file system that does what ram-handler does will have to meet the same challenges. Among all file systems RAM: has the smallest latency and requires the most CPU operations to do its job. Because its memory consumption has to grow along with the amount of data stored in it, it has unique responsibilities, too, which contribute to how much CPU load may be used whenever its contents are accessed or modified.

A different implementation of ram-handler may meet these challenges differently, but it is very hard to make a difference performance-wise, once you've taken care of how the internal data structures look like, and how memory is being managed.

In the case of the AmigaOS ram-handler, there were noticeable gains in performance with regard to scalability once the directory management data structures were reimplemented, but the very basic file data read/write operations had little performance to gain.

Quote:

I use RAM disk heavily and I would be interested in getting it optimized, if possible.

There's nothing like trying to find your own solution to the problem. The ram-handler file system being what it is, I daresay it's possible to create an experimental new ram-handler as a testbed for possible performance improvements.

Last edited by olsen on 13-Feb-2012 at 01:35 PM.

Is it possible to combine the ram handler with the MMU so that AOS 4 etc can use the possible 64 Gigabytes of L2 cache on the AXK as a volatile SSD?

Would be nice to hold a BD Iso on the CPU then stream the data like how the A500 can stream audio and video files from the HD asynchronously?

Because of the continuing increase in available Ram, its being called for Linux to support Ram disks for improving performance etc.

_________________
The older and more respected a scientist is, the longer it takes to prove him wrong.

@olsen

Quote:

Could you be more specific? The RAM disk operations (as provided by ram-handler) roughly break down into reading/writing/creating files, scanning directories, accessing individual directory entries and modifying directory contents.

On my Sam, the RAM Disk is significantly slower than my harddisk, and I have a 2.5" laptop HD that is really not a performer. I noticed when testing a WordNet installation. When I install it on the HD, the database lookup is quite slick, when I install in RAM:, the search takes much longer.

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@RodTerl

Quote:

RodTerl wrote: Is it possible to combine the ram handler with the MMU so that AOS 4 etc can use the possible 64 Gigabytes of L2 cache on the AXK as a volatile SSD?

Now that sounds like rocket science to me, to be honest

The ram-handler is a pretty generic, straightforward type of file system when it comes down to how data is being shuffled from one end of the bus to the other. No special preferences for moving the data, no special methods. It's a bit boring, really.

Quote:

Would be nice to hold a BD Iso on the CPU then stream the data like how the A500 can stream audio and video files from the HD asynchronously?

Methinks you'd be better served by a read-ahead cache which feeds a big in-memory cache, specially tailored to the task at hand. Bending and twisting the ram-handler into doing what you want it to accomplish might just be asking for too much. It's just not made for the job.

Quote:

Because of the continuing increase in available Ram, its being called for Linux to support Ram disks for improving performance etc.

Just because you can shove the data into the ram disk doesn't mean you shouldn't look at alternatives, too. Disk caches have been around forever, and they are pretty well-understood by now. I mentioned caching above because, for example, they address the issue of latency. Instead of pulling 64 GBytes into memory (how long does that take? 40 minutes?), you just read what you need, or might need later.

@Trixie

Quote:

Trixie wrote: @olsen Quote: Could you be more specific? The RAM disk operations (as provided by ram-handler) roughly break down into reading/writing/creating files, scanning directories, accessing individual directory entries and modifying directory contents. On my Sam, the RAM Disk is significantly slower than my harddisk, and I have a 2.5" laptop HD that is really not a performer. I noticed when testing a WordNet installation. When I install it on the HD, the database lookup is quite slick, when I install in RAM:, the search takes much longer.

If the RAM disk turns out to be so much slower than a physical disk, I would expect that there are disk accesses involved when you try to access what is supposed to be in RAM. This sounds like your system could be paging its memory to/from disk. Nothing else can slow down the RAM disk access that much.

@KimmoK
Progress has been made. There is no need to waste time on 3rd party implementations.

Last edited by ssolie on 13-Feb-2012 at 05:05 PM.

_________________
ExecSG Team Lead

ramdisk slower than a hd???!! now that would be a major achievement! never ever have i experienced somthing as strange. not even aros68k allows that on my a4k as far as i can tell. im almost tempted to dust off my os4 cd and check that out.

@wawa

Quote:

wawa wrote: ramdisk slower than a hd???!! now that would be a major achievement! never ever have i experienced somthing as strange. not even aros68k allows that on my a4k as far as i can tell. im almost tempted to dust off my os4 cd and check that out.

My best guess is that the system is likely paging data out/in. Either that, or the experimental time machine built into ram-handler is having trouble sending data back from the future because something is gumming up the entropy filter

But, seriously, since the RAM: device binds a lot of memory, the other software running at the same time will have to make do with what is still left. In some cases, that may be so little that software will crash because it ran out of memory, or it may have its memory paged to/from disk at high frequency.

I'm curious to hear how much memory is involved in this especially slow RAM: case.

@ssolie

that's good news :)

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@olsen

but it would only happen if ramdisk acquires more ram than it is safe for whatever operation system is carrying out in parallel. otherwise i dont see any reason to keep physical ram while harddisk is faster anyway. quite revolutionary.

Thanks for the replies.

Did not find a good way to benchmark the RAM disk ... do not remember how I did in 68k days ...On my A4k the RAM disk was slower than RAD.

But I believe when you say that times have changed and RAM drive is "fast enough".

btw. did not manage to test RAM drive speed with scsispeed ... perhaps it's meant to work with real drives ...

humm... some big file copying from RAM: to NIL: ....?

Anyway... RAM drive speed on x1000 would be nice to see.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@RodTerl

Quote:

RodTerl wrote: use the possible 64 Gigabytes of L2 cache

Wow 64GB L2 cache - that's a true monster system!

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@KimmoK

i dont need any benchmarks to be sure that ram disk is definitely faster than any hd on my amigas be it an ssd on csppc.device. i think that figures too.

AXK has 2 Meg on CPU L2 Cache, which is DDR2, benchmarks so far show system Ram has 80% plus speed of transfer of on chip, and the main difference being latency, the delay in first accessing an element of memory, on chip is a quarter the time taken.

Then you have the hardware RAID support for 2 Gigabytes per second to/from hard drive, and a further dual 2 Gigabytes a second network hardware support with hardware reprogrammable cryptography core. It would be a pity if the crypto core couldnt be used fro BD playback, HDMI encryption handling etc.

the PASemi CPU is a massively powerful parralel processing unit. lest hope it gets programmed using multithreaded multiprocessor asynch AOS style, instead of single threaded single processor Wintel style?

If you want anyone to blame, blame teh creators of teh hardawre.. teh makers of teh various chipsets for refusing to cooperate in standards and data availablity. You cant recreate the hightly cooperative Classic Amiga replacement, if all teh sub componants are continously fighting against each other.

Ram disk, being a Ram based hard drive, should be useable with any furtehr file system, it even suports multiple partitions because of not neding the single letter restrictions of Windows? So you can mix and match however many partitions, each with filesystems as you need, all dynamic?

If persistant Ram is used though, how do you gurentee a flush of corrupt code if you cant just switch teh machine off? Youll end up having to physically replace the memory modules.

_________________
The older and more respected a scientist is, the longer it takes to prove him wrong.

@Zylesea

"Wow 64GB L2 cache - that's a true monster system! "

I think the point was that PA6T can address 64GB RAM.
And the RAM transfer on PA6T is faster than what G4 can get from it's L2.

So it "almost" looks like the whole RAM address space of x1000 works as L2.

NEXT: imagine RAM/RAD disk as fast as L2 cache ....
I wonder how fast x1000 boots from RAD????

(but it could be that x1000 can hold ONLY 16GB or 32GB)

Last edited by KimmoK on 13-Feb-2012 at 11:26 PM.
Last edited by KimmoK on 13-Feb-2012 at 11:23 PM.
Last edited by KimmoK on 13-Feb-2012 at 11:22 PM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@olsen

Quote:

I'm curious to hear how much memory is involved in this especially slow RAM: case.

The program accesses a 20MB database of words and reads from it. It's markedly slower when the whole installation is in RAM, even if the system shows enough memory. I never really thought of making more investigations so I don't know what the program does internally. I'll ask someone to check for me.

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition