@Trixie

Quote:

The program accesses a 20MB database of words and reads from it

I recall that back in the Amithlon days (i.e. in OS 3.9), I tried benchmarking a network driver with a large ftp download into RAM:, only to realise that RAM: was so horrifically slow when handling large files that it became the limiting factor.

Hopefully, this has been improved in 4.x. But given AmigaOS's fondness for linked lists, doing random seeks into a 20MB file might just involve a *lot* of pointer chasing....

@umisef

Quote:

umisef wrote: @Trixie Quote: The program accesses a 20MB database of words and reads from it I recall that back in the Amithlon days (i.e. in OS 3.9), I tried benchmarking a network driver with a large ftp download into RAM:, only to realise that RAM: was so horrifically slow when handling large files that it became the limiting factor.

Ah, the good old days

Quote:

Hopefully, this has been improved in 4.x. But given AmigaOS's fondness for linked lists, doing random seeks into a 20MB file might just involve a *lot* of pointer chasing....

You are correct. I had another look at the code, and the seek operations are essentially "optimistic". What works reasonably well is to seek to a position within 100K-200K behind the current seek offset, but for absolute positions relative to the end of the file, or in front of the current seek offset, things will get ugly in large files. And particularly ugly if you repeatedly seek back in a large file, that's when you start tickling the daemon known as O(n^2).

I guess that's the problem right there. The seek operations are built upon the only major ram-handler data structure which scales very poorly. Ouch

recently did some testing on my SAM440ep-mini 667Mhz:
copying 100MB file to RAM happens 41.6MB/s.
(CPU load about 65%)
copying RAM to RAM happens in 58.8MB/s
and filecopy HDD to NIL: happens 71MB/s

So it seems pretty good speed for RAM disk on a low end HW.
(and system responsiveness remain high during all file operations)


But, btw, what was the "problem" with timberwolf installing? IIRC, it should not be copied to RAM because ramdisk.handler does not support all features that it requires??
As it seems we need some new functionality to RAM disk, are they planned / being done?

(I hope we do not have to reduce the RAM disk use ,,, towards the bad mainstream way.)

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

In a shell, diskspeed drive ram: all

Think its part of the scsispeed package, try it.

_________________
Hate tends to make you look stupid...

@Trixie

Quote:

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.

I also seem to rememeber the RAM disk being slower that HD, especially for directory scanning and delete operations. Haven't tested in a while though and the OS4 ram-handler was improved at least at one point.

On OS3 with a FastATA controller it was definately slower than HD. But it also, at least used to be, so also on OS4 with UDMA HDs.

But those claiming that the RAM disk is slow because of this and that still doesn't make sense since exactly the same operation has to be performed for HD file systems as well! They also need to do directory scanning and random file access and seek and there is just no way a disk can ever be faster than RAM if the same algorithms and data structures were used.

@ssolie

Good to hear there will be further improvements.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.