Dan Creswell wrote:
>FileInputStream read 8M (avg) 6
>FileInputStream read 8M (mean) 7
That's over 1 GB/s. Pretty impressive. It'd be more impressive if it were
really reading a hard disk instead of a RAM cache.
All the results I've seen so far indicate that either:
- writing a file and then reading it, or
- reading a file more than once,
ends up mainly testing the speed and/or capacity of the OS's disk cache.
It probably also shows the limiting speed for read() on any file, since
getting data from storage in the first place can only increase the elapsed
time. That is, cache is reducing the actual "fetch data from storage" time
to zero, which is certainly the best case possible.
On another note, the McDougall test uses a 64 KB buffer on an 8 MB file.
My testing shows that block size makes a measurable difference in
read()/write() speed. This is to be expected, so it's mainly a caution
about hidden factors that can affect measured speed.
As further evidence that these various tests are mainly measuring disk
cache speed, I ran several tests using 25 files of 2 MB each on the
following media:
1) a USB flash-drive, on a USB 1.0 bus.
2) a CompactFlash card in a Firewire reader, on a FW 400 bus.
3) a DVD-RAM drive, on an ATA bus (unknown bus speed).
In all cases, repeated reads or write-then-reads show the same results on
my 500 MHz dual-G4 machine:
about 75 MB/s read speed.
On 1 MB files, the elapsed times to read 1 MB in a single read() range
11-17 ms. That's small enough that a jitter of 1 or 2 ms in precision is
upwards of a 10-20% error. When the test uses 2-5 MB files, though,
throughput is similar enough (75 MB/s), that it seems reasonable to believe
the results from the smaller files. Below 10 ms elapsed time, elapsed-time
precision rapidly degrades. Another caution.
As expected, the "virgin" read performance for different media and
connection bus varies significantly:
USB flash = 0.85 MB/s
CF on FW = 6.4 MB/s
DVD-RAM = 1.3 MB/s (2-side 5.6 GB glass media)
DVD-RAM = 2.5 MB/s (1-side 4.7 GB plastic media)
Virgin reads can be obtained by ejecting the removable volume, then
re-inserting the media. On hard drives with partitions, use Disk
Utility.app to unmount then remount the partition.
On file-writes, it seems closing or flushing a FileOutputStream doesn't
necessarily write all the data to the storage medium at that time. The
test was interesting in that creating 25 files of 1 or 2 MB was quite fast,
a few seconds. Yet a subsequent 'sync' at the command-line then took 30
seconds or so to finish, and Activity Monitor.app showed disk writes.
There's clearly an asynchronous disk-write cache, as expected from a
Unix-like system.
If other files were being read during this time, or if the same file were
being re-read, this might cause reads to block, which could be a source for
widely varying file-read times. This would largely depend on the actual
media write-speed and the disk-cache size.
I also ran some tests using a share mounted over AppleShare (Personal File
Sharing), on a 10/100 ethernet network between two 10/100 machines. Here,
caching plays a lesser role, which makes sense. The remote machine
(server) can modify a file "behind the back" of the sharing machine
(client), so repeated reads HAVE to re-read the file.
The network-share case was the only time where I saw widely varying times
for re-reading the same 25 files of identical size. Sometimes it was about
as fast as the network could move bits. Other times there were huge lags
(over 5 s to read a 1 MB file). There were only 2 machines on the network,
doing nothing else, so I have no idea what could have caused this.
However, the wide variation, including the extreme outliers, suggests that
networked file-systems are more apt to have unpredictable latencies.
>FileInputStream read and check 8K avg 79
>FileInputStream read and check 8K mean 80
Over 10X slower than plain reads. Impressive.
Clearly, the way to win at I/O benchmarks is to read lots of data, then do
nothing at all with it. I think we should call it "iMB/s" -- ignored
megabytes per second.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
