F
Frank
Hello,
A while back, when writing some generic io transfer operations, I had a
hankering to fiddle with using a multi-threaded design. This of course
would have little effect if the input and output were directed to a single
half-duplex device (eg a hard disk), but the idea seemed promising for two
devices where the speed of one was not >> the other, or for a full-duplex
device (network socket).
Anyway, wrote the routine, and as expected, slightly slower than bulk
transfer to the same device, but getting ~ 30% performance increase for cd
-> hd xfer on large files. I should note here my tests were designed as
best as possible to force the OS to flush it's cache before running each
transfer. As such, the differences between using bulk byte[] methods on
streams, the newer java.nio.channels.FileChannel.transferTo, and even the
OS's own file copy commands had negligable differences in this light.
This was particularly startling to me, since I really didn't think the
idea of a multi-threaded io was particularly unique... it seemed like a
necessary measure for cd burning, as well as music / video playback.
However, my searching on Google has turned up nothing similar so far,
hence no one else has appearantly done this (since Google knows all!)
At this point, I'ld really be interested in any feedback... if anyone is
aware of an existing approach. If not, I'll probably be spending a little
time cleaning up what I've written and put it on sf.net. One other bias in
my testing I now have to confess: I consider anyone calling a system using
ide / atapi devices by the titles "high performance" or "multitasking" to
be a hipocrite, and keep my own system 100% pure scsi. However, the
technology has continued to improve, so I would be interested to know how
close current consumer level ide and sata devices come to actually being
able to run io in a multithreaded environment, and I will have to expand
my testing shortly.
Thanks for your insight!
-Frank
A while back, when writing some generic io transfer operations, I had a
hankering to fiddle with using a multi-threaded design. This of course
would have little effect if the input and output were directed to a single
half-duplex device (eg a hard disk), but the idea seemed promising for two
devices where the speed of one was not >> the other, or for a full-duplex
device (network socket).
Anyway, wrote the routine, and as expected, slightly slower than bulk
transfer to the same device, but getting ~ 30% performance increase for cd
-> hd xfer on large files. I should note here my tests were designed as
best as possible to force the OS to flush it's cache before running each
transfer. As such, the differences between using bulk byte[] methods on
streams, the newer java.nio.channels.FileChannel.transferTo, and even the
OS's own file copy commands had negligable differences in this light.
This was particularly startling to me, since I really didn't think the
idea of a multi-threaded io was particularly unique... it seemed like a
necessary measure for cd burning, as well as music / video playback.
However, my searching on Google has turned up nothing similar so far,
hence no one else has appearantly done this (since Google knows all!)
At this point, I'ld really be interested in any feedback... if anyone is
aware of an existing approach. If not, I'll probably be spending a little
time cleaning up what I've written and put it on sf.net. One other bias in
my testing I now have to confess: I consider anyone calling a system using
ide / atapi devices by the titles "high performance" or "multitasking" to
be a hipocrite, and keep my own system 100% pure scsi. However, the
technology has continued to improve, so I would be interested to know how
close current consumer level ide and sata devices come to actually being
able to run io in a multithreaded environment, and I will have to expand
my testing shortly.
Thanks for your insight!
-Frank