Forgot your password?
typodupeerror
Java Programming

Java IO Faster Than NIO 270

Posted by kdawson
from the question-conventional-wisdom dept.
rsk writes "Paul Tyma, the man behind Mailinator, has put together an excellent performance analysis comparing old-school synchronous programming (java.io.*) to Java's asynchronous programming (java.nio.*) — showing a consistent 25% performance deficiency with the asynchronous code. As it turns out, old-style blocking I/O with modern threading libraries like Linux NPTL and multi-core machines gives you idle-thread and non-contending thread management for an extremely low cost; less than it takes to switch-and-restore connection state constantly with a selector approach."
This discussion has been archived. No new comments can be posted.

Java IO Faster Than NIO

Comments Filter:
  • And this is news? (Score:4, Insightful)

    by Just_Say_Duhhh (1318603) on Tuesday July 27, 2010 @04:30PM (#33050280)
    Of course old school techniques are faster. We don't drop old school because we want better performance, we drop it because we're lazy, and want easier ways to get the job done!
    • by bolthole (122186) on Tuesday July 27, 2010 @04:33PM (#33050330) Journal

      naw, old school gets dropped simply because it's "old" (ie: not trendy/buzzword compliant).
      Many times, the "old school" way is EASIER than the newfangled way.

      Example: the 100-200 line perl scripts that can be done in 10 lines of regular oldfashion shell.

      • by ShadowRangerRIT (1301549) on Tuesday July 27, 2010 @04:51PM (#33050572)

        Example: the 100-200 line perl scripts that can be done in 10 lines of regular oldfashion shell.

        Clearly you're not using Perl the way it was meant to be used. This obsession with coding Perl the way you'd code Java (with classes/objects, libraries to do what shell utilities do, etc.) makes it very verbose. But if you use it the old way (quick and dirty scripts, no compunctions about calling to external shell utilities where they can do the job quicker, not bothering with use strict or use warnings, using the implicit variables shamelessly, etc.), Perl is, almost be definition, just as compact as shell. After all, if shell can do it, so can Perl, you just need to wrap it in backticks (and most of the time, Perl can do it natively with equal or greater compactness). Granted, when you code Perl like that it becomes more fragile and the code is hard to maintain. But then, so was the shell script.

        The problem with a lot of verbose Perl scripts is that the developers were taught to program Perl like C with dynamic typing (as I was initially, before I had to do it for a job and read Learning Perl and Effective Perl Programming cover to cover). I'm not completely insane, so I do code with use strict and warnings enabled, but I don't use the awful OO features, and even with the code overhead from use strict, my Perl scripts are usually equal to or less than 120% the length of an equivalent shell script (and often much shorter). Plus, using Perl means you don't need to learn the intricacies of every one of the dozens of shell utilities, most of your code can transfer to environments without the GNU tools (and heck, it doesn't explode if the machine you run on only offers csh and you wrote in bash), and most of what you're doing runs in a single process, instead of requiring multiple processes, piping text from one to another, constantly reparsing from string form to process usable form.

        • Re: (Score:2, Funny)

          by Anonymous Coward

          With regard to Perl OO, I'm reminded of one of my favorite quotes, I think it's from Advacned Perl Programming. Requires some explanation for those not Perl nerds.

          For those unfamiliar, Perl's idea of "objects" are effectively just an OO framework on top of a procedural model. So you have packages, think C++ namespace. All a Perl object is, is a hash that is "blessed" into the package. You just call bless $hashref,package; and it makes it so you can do neat shit like $hashref->doShit, and then $hashre

          • Re: (Score:2, Informative)

            by loom_weaver (527816)

            Of course there are 3 ways to do this and each has subtle differences.

            Likewise, whether you pass a hash, or a reference to a hash, or you shift single parameters off the stack. It's totally up to you!

            I love using perl for integrating to the shell and other systems plus using its text parsing abilities but man its OO is brutal and I wouldn't use perl in any large projects especially if multiple developers are required.

        • by Dalcius (587481)

          Clearly you're not using Perl the way it was meant to be used.

          I think Larry might disagree [wall.org] with your assertion that Perl was meant to be used in a specific fashion.

          • by sjames (1099)

            He said there's more than one way, he didn't say all of them were good.

        • by Locke2005 (849178)
          But if you use it the old way... Perl is, almost by definition, just as compact as shell. And several orders of magnitude less readable!
      • by kenj0418 (230916)

        Example: the 100-200 line perl scripts

        200 lines of perl ? Isn't that enough to code SkyNet. (While disguising it as simple line noise).

    • Re: (Score:3, Interesting)

      by slack_justyb (862874)
      Mod parent up! There is no better way to sum up this article, other than "Yes, we knew that already, but we don't do it that way anymore because we're all lazy."
    • Re:And this is news? (Score:5, Informative)

      by HFXPro (581079) on Tuesday July 27, 2010 @04:35PM (#33050354)
      Except NIO is usually not as straight forward as java io. It isn't particular hard to use either if you learn to use threads to handle the I/O and pass information through queues.
    • by TommydCat (791543) on Tuesday July 27, 2010 @04:36PM (#33050372) Homepage
      select() sucked the life out of me in the 90s and I don't think I'll ever recover...
    • by ShadowRangerRIT (1301549) on Tuesday July 27, 2010 @04:36PM (#33050374)
      Asynchronous I/O is by no means easier. There's a hell of a lot more to keep track of, and a lot more work to do to make asynchronous I/O work correctly; synchronous I/O is much easier to code, and apparently it's faster on Linux to boot.
      • Re: (Score:3, Interesting)

        by Entrope (68843)

        The extra stuff to take care of is why asynchronous I/O applications tend to have lower throughput than synchronous I/O if you have good OS threading.

        There have only ever been two good reasons to use application-multiplexed I/O: Your OS sucks at threading (like Windows and Solaris the last time I looked at them), or you have more clients than memory. Languages like C and Java require applications to dedicate multiple kilobytes per thread for the thread's stack -- but usually default to megabytes per thread

        • Re:And this is news? (Score:4, Informative)

          by Jeremi (14640) on Tuesday July 27, 2010 @09:57PM (#33052862) Homepage

          but usually default to megabytes per thread, so if you have thousands of concurrent clients, you will soak up memory in fairly large quantities.

          There's an important distinction to make here: a thread's stack will reserve (so many) kilobytes/megabytes of address space, but it won't actually use up very much RAM unless/until the thread starts to actually use a lot of stack space (e.g. by doing a lot of recursion).

          On a 32-bit machine, starting too many threads can allocate all of your process's 2-4 gigabytes of address space, which can cause problems even though you have plenty of RAM still free.

          On a 64-bit machine, on the other hand, the amount of available address space is mind-bogglingly huge, so running out of address space isn't a problem you're likely to run into, even if you run a gazillion threads at once.

    • by MikeyO (99577)

      Except, in this case, the newer version is also not any easier to use, and the old version isn't going to be dropped.

    • Re: (Score:3, Insightful)

      by djKing (1970)

      Except NIO is the old school C/C++ way to do it. One thread per socket was the new Java way. So NIO was new to Java, but still old school.

      • Re: (Score:3, Informative)

        by KiloByte (825081)

        One _thread_ is indeed a new way (for certain values of "new"), but back in the day we used fork() instead of non-blocking IO.

        • And some of us still fork() our way forward. POSIX can be found in many places, even your phone....
        • Re: (Score:3, Insightful)

          by slim (1652)

          fork() is still the way forward in many, many situations. Having every server session in its own protected memory space gives me warm fuzzy feelings. One can segfault and the rest will keep on running, and that's just the tip of the security iceberg.

          select() has advantages, described in other posts here, but it has disadvantages too.

    • by cosm (1072588) <.moc.liamg. .ta. .3msoceht.> on Tuesday July 27, 2010 @04:43PM (#33050470)

      Of course some old school techniques are faster. We don't drop old school because we want better performance, we drop it because we're lazy, and want easier ways to get the job done!

      Minor addition to your comment, for some may get the wrong impression if it gets modded up the chain.

      That is a bit of a generalization, and not necessarily accurate. I would say that heavily tested, tried and true techniques are faster. Libraries that fall into the aforementioned realm tend to be older, and hence more time for testing and refinement, but being old doesn't necessarily guarantee it will always be faster all of the time, as your comment implies.

      • by CODiNE (27417) on Tuesday July 27, 2010 @05:17PM (#33050862) Homepage

        In agreement with your post...

        As a recent article showed, traditional algorithms may be less optimal on modern systems with multiple layers of cache and various speed memory systems. New or old it's always important to benchmark and find the right tool for your particular needs.

      • by steelfood (895457)

        Short of some algorithmic breakthrough, it does imply that older implementations are necessarily faster.

        The answer is that most of the newer methods are merely bloat, developed not for speed and efficiency, but for ease of development and maintenance.

        In the past, successful developers were all highly skilled. It was a necessary trait for success both because development was difficult, and because there were so few ways to make money developing software. Unsuccessful developers stopped developing, and their

        • by Lunix Nutcase (1092239) on Tuesday July 27, 2010 @05:45PM (#33051106)

          In the past, successful developers were all highly skilled. It was a necessary trait for success both because development was difficult, and because there were so few ways to make money developing software. Unsuccessful developers stopped developing, and their code does not persist until today.

          You must not work with much legacy code. I've dealt with shitty code that is both a couple years old to a many decades old (a mix of C, Fortran, Ada, various assembly, etc). This notion that all old programmers were godlike gurus is mostly myth.

          • by Kjella (173770)

            You must not work with much legacy code. I've dealt with shitty code that is both a couple years old to a many decades old (a mix of C, Fortran, Ada, various assembly, etc). This notion that all old programmers were godlike gurus is mostly myth.

            Also a lot of them were gurus in stuff that's not really relevant anymore like saving two bytes of memory here, a function call here and two processor instructions there - at least on the simple C compiler they used in 1987 - at the cost of code clarity, encapsulation and so on. Almost all the spectacular performance failures I see is not due to issues like that, it's that you've created a spaghetti mess and eventually settle for the only solution you found even though it's probably 100x slower than it shou

            • Those things are still relevant, though not to the same extent. I am careful with space when I write networking code, possibly at the level that someone from 1987 was.
    • We don't drop old school because we want better performance, we drop it because we're lazy...

      Hehe yep. Software engineers are lazy and overworked!

    • Re: (Score:3, Insightful)

      Of course old school techniques are faster

      Ha! Hahaha!

      Nonono, that's not the case. You're thinking of language levels. Low Level programming is very close to the hardware and thus, since you are using the very specific instructions, so you don't lose any efficiency unless you wrote your code illogically. A higher level language abstracts it from the hardware, so your commands have to find the proper opcodes to execute.

      Techniques however, are not languages. I can use the same technique I would in C as I would in Assembly or C# or possibly some other

  • Waiting for JDK 7 (Score:4, Informative)

    by Anonymous Coward on Tuesday July 27, 2010 @04:31PM (#33050304)

    JDK7 will bring a new IO API that underneath uses epoll (Linux) or completion port (Windows). High performance servers will be possible in Java too.

    • Re:Waiting for JDK 7 (Score:4, Informative)

      by binarylarry (1338699) on Tuesday July 27, 2010 @04:45PM (#33050484)

      Finally, all the worlds enterprise systems can switch to Java... ....oh wait

      • Re: (Score:2, Informative)

        by Anonymous Coward

        101 Reasons why Java is better than .NET - http://helpdesk-software.ws/it/29-04-2004.htm [helpdesk-software.ws]

        You do more harm than good to Java by comparing it to a 6-8 -year-old version of .NET, since your ignorance gives the impression that we (Java developers) just aren't keeping up with the times. Then again, for as long as you've kept that pageful of crap there in spite of multiple comments like mine, I begin to think that this is your intention.

        How else to explain the fact that in addition to a bunch of invalid arguments, the links to detail for each one bring you to an error page?

      • quiet - you'll make all the python/php/ruby kool-aid drinkers cry....
    • Re: (Score:2, Informative)

      by Anonymous Coward

      JDK7 will bring a new IO API that underneath uses epoll (Linux)

      From TFA:

      To work around not so performant/scalable poll()
      implementation on Linux's we tried using epoll with
      Blackwidow JVM on a 2.6.5 kernel. while epoll improved the
      over scalability, the performance still remained 25% below
      the vanilla thread per connection model. With epoll we
      needed lot fewer threads to get to the best performance
      mark that we could get out of NIO.

  • Old news. (Score:5, Informative)

    by Cyberax (705495) on Tuesday July 27, 2010 @04:33PM (#33050324)

    Look at the timestamp of this presentation :) It's a bit of old news.

    It was discussed here: http://www.theserverside.com/news/thread.tss?thread_id=48449 [theserverside.com]

    And it mostly shows that NIO is deficient. I encountered similar problems in my tests. Solved them by using http://mina.apache.org/ [apache.org] .

    • Re:Old news. (Score:4, Informative)

      by binarylarry (1338699) on Tuesday July 27, 2010 @04:50PM (#33050562)

      Mina is great although the brains behind the project left and started a new project, Netty [jboss.org].

      I've heard from multiple sources that netty tends to outperform mina although I've been using mina with no problems.

    • Re:Old news. (Score:5, Interesting)

      by bill_kress (99356) on Tuesday July 27, 2010 @05:25PM (#33050928)

      I had a problem where the customer wanted to discover a class-b network in a reasonable amount of time.

      Aside from Java's lack of ping causing huge heartaches the limitation was that when using old Java IO it allocated a thread per connection while waiting for a response.

      This limited me to 2-4000 outstanding connection attempts at any time. Since most didn't connect, I needed at least 3 retries on each with progressive back-off times--the threads were absolutely the bottleneck.

      I reduced the time for this discovery process from days (or the machine just locked up) to 15 minutes. With nio I probably could have reduced it significantly more (although at some point packet collisions would have become problematic).

      NIO may not be defective, it just may be solving a problem you haven't conceived of.

  • by yvajj (970228) on Tuesday July 27, 2010 @04:44PM (#33050478)

    I'm not sure where / when NIO got equated to lower latency. The primary benefits of NIO (from my understanding of having designed and deployed both IO and NIO based servers) is that NIO allows you to have better concurrency on a single box i.e. you can service many more calls / transactions on a single machine since you aren't limited by the number of threads you can spawn on that box (and you aren't limited as much by memory, since each thread consumes a fair number of resources on the box).

    For the most part (and from my experimentation), NIO actually has slightly higher latency than standard IO (especially with heavy loaded boxes).

    The question you need to ask yourself is... do you require higher concurrency and fewer boxes (cheaper to run / maintain) at the expense of slightly higher latency (which would work well for most web sites), or are your transactions latency sensitive / real-time, in which case using standard IO would work better (at the cost of requiring more hardware and support).

    • Re: (Score:3, Informative)

      by medv4380 (1604309)
      However, the article and the presentation the article links to point out that IO has better concurrency than NIO. NIO has a Blocking algorithm in it for concurrency and IO has none implemented for Concurrency. The presentation went on to explain what happened because years ago in Java 1.1 and 1.2 it was nasty having to write for concurrency on servers using IO so you'd switch to NIO and be happy. Things have changed because of OS kernel improvements IO is using Non-Blocking algorithms for concurrency wit
      • by pjt33 (739471)

        The presentation went on to explain what happened because years ago in Java 1.1 and 1.2 it was nasty having to write for concurrency on servers using IO so you'd switch to NIO and be happy.

        NIO was new in 1.4, so something's been garbled somewhere.

    • Re: (Score:3, Insightful)

      by kaffiene (38781)

      Exactly!

      It's frustrating to see that 98% of the commentry on this article is clearly from people who don't understand the select vs single thread/poll trade off or who are just out and out ill-informed Java haters. *sigh* This *is* slashdot, I suppose.

  • This looks like polling vs. pending, and if it is, pending won that war about 40 years ago.

  • uh...... DUH?! (Score:5, Insightful)

    by Michael Kristopeit (1751814) on Tuesday July 27, 2010 @05:07PM (#33050744)
    the entire point of asynchronous is to acknowledge you will be waiting for IO, and try to do something else useful rather than just wait... asynchronous will obviously end up taking more time because of the overhead of managing states and performing the switches, but the tradeoff is something useful was getting done while waiting for IO a little longer instead of doing nothing except wait for the IO to complete. which method is best is completely application specific.
  • by phantomcircuit (938963) on Tuesday July 27, 2010 @05:07PM (#33050752) Homepage

    You'll laugh, hysterically.

    • by medv4380 (1604309)
      As funny as it looks it does say not to compare them against each other. They are probably different machines using different hardware, hence the disclaimer on the top. Even though I'd like to believe that Linux 2.6 was 1200% faster then Windows XP I can't bring myself to believe it.
    • by spongman (182339)
      having seen Sun's sources to the win32 part of the JRE, I'm not surprised. not the worst windows code I've ever seen, but close.
  • by Saint Stephen (19450) on Tuesday July 27, 2010 @05:13PM (#33050822) Homepage Journal

    On Windows, the fastest way to do multithreaded I/O with a producer/consumer queue pattern is IO Completion Ports.

    The fastest way to write a bunch of buffers to disk is WriteFileScatter. The fastest way to read a bunch of data from disk is ReadFileGather.

    SQL Server uses these APIS to scale.

    When I used to work at MS in evangelism, there was a big debate about how Unix does things one way, and Microsoft does it a COMPLETELY different way that you just can't #define away - it's just different. A guy named Michael Parkes said "I cannot go to these clients and say REPENT! and use IO completion ports! They do thread per client, because they have fork()".

    When you listen to the technical explanations, the Microsoft way actually IS better - it's just aht it's totally incompatible with evrything else.

    Learn IOCP and watch your context switches drop.

    • by KiloByte (825081)

      This is a problem, not a solution. One of bigger problems with win32 development is the multitude of totally incompatible APIs that do the same thing.

    • IOCP is very similar to edge triggered epoll of Linux. The main difference is, when the wait function is signaled, the data is already available/sent in/from the buffer. While in epoll, you must call read/write again. It is quite easy to write a common interface to abstract both.
  • No shit Watson (Score:3, Insightful)

    by Alex Belits (437) * on Tuesday July 27, 2010 @05:38PM (#33051060) Homepage

    Ff you have multiple cores that do nothing otherwise (like all benchmarks happen to act), multithreading will use them and asynchronous nonblocking I/O won't, so maximum transfer rate for static data in memory over low-latency network will be always faster for blocking threads.

    In real-life applications if you always have enough work to distribute between cores/processors, your nonblocking I/O process or thread will only depend on the data production and transfer rate, not the raw throughput of the combination of syscalls that it makes. If output buffers are always empty, and input buffers are empty every time a transaction happens, then both data transfer speed is maxed out, and adding more threads that perform I/O simultaneously will only increase overhead. If it is not maxed out, same applies to queued data before/after processing -- that is, if there is processing. So if worker threads/processes do more than copying data, then giving additional cores to them is more useful than throwing them on to be used for I/O.

  • by StikyPad (445176)

    This presentation is actually from 2008 (as indicated by every single slide in the PDF -- and thanks for the PDF warning, BTW). Aside from being old, is there any indication that it's still true?

  • IIRC, even in Novell NetWare the old blocking I/O calls which prevented the client from doing anything else while it waited for a response from the server were much faster than the new non-blocking I/O...
  • by grmoc (57943) on Tuesday July 27, 2010 @06:30PM (#33051506)

    This may be true for Java.
    It isn't true for C/C++.

    With C/C++ and NPTL, the many-thread blocking IO style yields slightly lower latency at low IO rates, but offers significant latency variability and sharply decreased thruput at higher IO rates.
    It seems that the linux scheduler is much to blame for this-- the number of times that a thread is scheduled on a different CPU increases dramatically with more threads, and this trashes the caches.
    I've seen order-of-magnitude decreases in performance and order-of-magnitude increases in latency as a result of what appears to be the cache trashing.

  • The best way to write IO is to use one thread or process per CPU core and in that thread use non-blocking IO. I thought everyone knew this.

  • I don't think NIO ever claimed to be faster than old IO. Its primary selling point is (and always has been, IMO), its ability to handle tens of thousands of connections on a single thread. With old IO, ten thousand connections would require ten thousand threads. I don't care how good your context switcher is -- that is a high price to pay, especially if the machine has other high-thread-count processes running as well.
  • by dave87656 (1179347) on Wednesday July 28, 2010 @02:06AM (#33053788)

    My understanding is that it is not supposed to be faster. It is non-blocking and asynchronous which serves a different need.

186,000 Miles per Second. It's not just a good idea. IT'S THE LAW.

Working...