Java IO compared to NIO
in [Java Programming]
|
From: John B. Matthews on 27 Jul 2010 22:00 This presentation compares Java synchronous (java.io.*) to asynchronous (java.nio.*) I/O in a high volume SMTP application, finding a measurable benefit for the former with modern threading libraries and multi-core machines. <http://www.mailinator.com/tymaPaulMultithreaded.pdf> Some discussion may be found here: <http://developers.slashdot.org/story/10/07/27/1925209> The few times the choice has come up, we implemented synchronous I/O, profiled it, found it met the requirements and declared victory. Lacking much experience in this area, I'd welcome critical comments. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Arved Sandstrom on 28 Jul 2010 05:50 John B. Matthews wrote: > This presentation compares Java synchronous (java.io.*) to asynchronous > (java.nio.*) I/O in a high volume SMTP application, finding a measurable > benefit for the former with modern threading libraries and multi-core > machines. > > <http://www.mailinator.com/tymaPaulMultithreaded.pdf> > > Some discussion may be found here: > > <http://developers.slashdot.org/story/10/07/27/1925209> > > The few times the choice has come up, we implemented synchronous I/O, > profiled it, found it met the requirements and declared victory. Lacking > much experience in this area, I'd welcome critical comments. > Yeah, I was just reading about this Paul Tyma discovery myself. I'm not prepared to comment on it other than to say that the presented arguments are plausible. I'll also note that the main argument has been made before - it's not a stunning new revelation. On a related note, if "old" I/O meets your requirements then what more do you need? :-) I've been generally content with "old" I/O in most situations. And as an aside, one thing I noticed with NIO when it came out, specifically concerning use of the Selector, was that the new API promoted a fair bit of black-box copy-paste programming. Admittedly I have only a small set of observations, but quite frankly the only time I ran across a group of people that thoroughly understood their NIO code was when their original code had been C code and they were using the select() call there. It might perhaps be more accurate to say that NIO did not *promote* this copy-paste programming; it simply perpetuated it - it wasn't easier for the average programmer to understand than "old" I/O. AHS -- I'm not a vegetarian because I love animals. I'm a vegetarian because I hate plants. -- AW Brown
From: Daniel Pitts on 28 Jul 2010 15:00 On 7/28/2010 2:50 AM, Arved Sandstrom wrote: > John B. Matthews wrote: >> This presentation compares Java synchronous (java.io.*) to >> asynchronous (java.nio.*) I/O in a high volume SMTP application, >> finding a measurable benefit for the former with modern threading >> libraries and multi-core machines. >> >> <http://www.mailinator.com/tymaPaulMultithreaded.pdf> >> >> Some discussion may be found here: >> >> <http://developers.slashdot.org/story/10/07/27/1925209> >> >> The few times the choice has come up, we implemented synchronous I/O, >> profiled it, found it met the requirements and declared victory. >> Lacking much experience in this area, I'd welcome critical comments. >> > Yeah, I was just reading about this Paul Tyma discovery myself. I'm not > prepared to comment on it other than to say that the presented arguments > are plausible. I'll also note that the main argument has been made > before - it's not a stunning new revelation. > > On a related note, if "old" I/O meets your requirements then what more > do you need? :-) I've been generally content with "old" I/O in most > situations. > > And as an aside, one thing I noticed with NIO when it came out, > specifically concerning use of the Selector, was that the new API > promoted a fair bit of black-box copy-paste programming. Admittedly I > have only a small set of observations, but quite frankly the only time I > ran across a group of people that thoroughly understood their NIO code > was when their original code had been C code and they were using the > select() call there. It might perhaps be more accurate to say that NIO > did not *promote* this copy-paste programming; it simply perpetuated it > - it wasn't easier for the average programmer to understand than "old" I/O. It was never meant to be easier, it was meant to reduce the number of threads required for handling multiple "streams" of data. It is actually far more complicated to get correct, often requiring a state machine. For a single stream, I suspect there is no speed benefit. As far as efficiency goes, my guess is that there is a sweet-spot for the number of streams-per-thread which outperforms regular IO. This sweet-spot would depend on many factors, including overall system-load, threading implementation, low-level select implementation, and stream throughput. Just a thought. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: John B. Matthews on 29 Jul 2010 00:30 In article <%6%3o.30711$xZ2.22194(a)newsfe07.iad>, Daniel Pitts <newsgroup.spamfilter(a)virtualinfinity.net> wrote: > On 7/28/2010 2:50 AM, Arved Sandstrom wrote: > > John B. Matthews wrote: > >> This presentation compares Java synchronous (java.io.*) to > >> asynchronous (java.nio.*) I/O in a high volume SMTP application, > >> finding a measurable benefit for the former with modern threading > >> libraries and multi-core machines. > >> > >> <http://www.mailinator.com/tymaPaulMultithreaded.pdf> > >> > >> Some discussion may be found here: > >> > >> <http://developers.slashdot.org/story/10/07/27/1925209> > >> > >> The few times the choice has come up, we implemented synchronous > >> I/O, profiled it, found it met the requirements and declared > >> victory. Lacking much experience in this area, I'd welcome > >> critical comments. > >> > > Yeah, I was just reading about this Paul Tyma discovery myself. I'm > > not prepared to comment on it other than to say that the presented > > arguments are plausible. I'll also note that the main argument has > > been made before - it's not a stunning new revelation. > > > > On a related note, if "old" I/O meets your requirements then what > > more do you need? :-) I've been generally content with "old" I/O in > > most situations. > > > > And as an aside, one thing I noticed with NIO when it came out, > > specifically concerning use of the Selector, was that the new API > > promoted a fair bit of black-box copy-paste programming. Admittedly > > I have only a small set of observations, but quite frankly the only > > time I ran across a group of people that thoroughly understood > > their NIO code was when their original code had been C code and > > they were using the select() call there. It might perhaps be more > > accurate to say that NIO did not *promote* this copy-paste > > programming; it simply perpetuated it - it wasn't easier for the > > average programmer to understand than "old" I/O. > It was never meant to be easier, it was meant to reduce the number of > threads required for handling multiple "streams" of data. It is > actually far more complicated to get correct, often requiring a state > machine. For a single stream, I suspect there is no speed benefit. > > As far as efficiency goes, my guess is that there is a sweet-spot for > the number of streams-per-thread which outperforms regular IO. This > sweet-spot would depend on many factors, including overall > system-load, threading implementation, low-level select > implementation, and stream throughput. Thanks, both, for commenting on this. I also found this thread helpful: <http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/dd8005f33b883d02> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Esmond Pitt on 29 Jul 2010 04:28
On 29/07/2010 2:30 PM, John B. Matthews wrote: > Thanks, both, for commenting on this. I also found this thread helpful: > > <http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/dd8005f33b883d02> You should also have a look at 'Taming the NIO Circus' at forums.sun.com: http://forums.sun.com/thread.jspa?threadID=459338&start=0 |