Java IO Faster Than NIO

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."

Waiting for JDK 7

[Anonymous Coward]

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.

Old news.

[Cyberax]

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:And this is news?

[HFXPro]

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.

Re:Waiting for JDK 7

[binarylarry]

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

Re:Old news.

[binarylarry]

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.

NIO is outdated new version to be released in Fall

[Anonymous Coward]

Java NIO is actually rather old at this point and is slated for a huge overhaul with NIO.2 which will be released with Java 7 this Fall.

Re:And this is news?

[ShadowRangerRIT]

.COM languages? You mean a web language? You do realize Perl was written as a replacement for sed, awk and the shell languages (csh, bash, etc.), to make systems administration easier by providing a single language that used a familiar, C-like syntax and made text parsing trivial. The web was a non-entity when Perl was created. The fact that it was an acceptable language for web development is tied to the initial design goal of parsing text quickly, but that was never the purpose of Perl, and the spread of the language was not solely (and not even primarily) due to its use on the web.

Re:NIO != lower latency

[medv4380]

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 without having to be rewritten from scratch. The benchmarks proved it and now NIO has no use if you're using a modern OS with Multicore CPU because IO has better concurrency and throughput then NIO.

Should be using Scatter/Gather +IOCP on windows

[Saint Stephen]

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.

Re:Waiting for JDK 7

[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?

Re:And this is news?

[Sir_Lewk]

It's not in the C Standard Library, but there most certainly is async IO for C. See 'aio.h' in POSIX for example.

Re:And this is news?

[KiloByte]

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.

Re:Waiting for JDK 7

[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.

Re:And this is news?

[loom_weaver]

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.

Re:Java counterpart to XNA?

[SplashMyBandit]

FYI: Java will run on platforms that support C. Please see GNU gcj and the Classpath project.

Re:And this is news?

[Jeremi]

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.

Re:And this is news?

[ShadowRangerRIT]

I don't see how implicit variables are necessarily bad practice. It's a language convention. Programmers write for loops that iterate over variables named 'i' all the time, and it's usually accepted, if not condoned, even if it's just as lacking in descriptiveness as $_ (and $_ has a well defined role, where i is purely by convention). Perl uses $_ as the default loop variable, certain methods process it by default when provided no arguments, etc. If you know Perl well, it's quite natural. Similarly, @_ holds arguments passed to a function (having it be the default storage for return values is deprecated, so you don't see it all that often in other contexts), and shifting off it is standard. Don't assume your lack of familiarity means it's automatically poor style.

Re:And this is news?

[roger_pasky]

Excuse me, COBOL itself is still the COBOL of the 21st century, as it still makes banking, airlines and quite a lot of brick and mortar industrial companies keep on rolling. Maybe average slashdotters are out of this reality, but it is still alive and kicking. Please don't blame me, I've never programmed a line of COBOL in my whole live.

Re:Waiting for JDK 7

[mr_da3m0n]

Not really. Here:

• 1. Yes
• 2. No.
• 3. In practice they're the same.
• 4. Worthless. MORE PEOPLE USING IT MEANS BETTER RIGHT?
• 5. No. It is the /more awesomer/ platform for webservices, but most of the webservices I've seen consumed over the past years were .NET junk that failed SOAP standards and killed my cat.
• 6. That point is highly, highly debatable. I don't like either.
• 7. Irrelevant to technical merits.
• 8. I have seen an equal amount of equally shitty programmers in both languages.
• 9. Codeplex does exist, and I doubt this is still true today, although it is also irrelevant to technical merits.
• 10. I don't understand this one.
• 11. You fail to grasp that you /can/ mix managed and unmanaged hybrid code but you don't /have/ to. By the same logic JNI is such a hybrid and is bad because it exists.
• 12. That was patently wrong before and is only slightly less wrong now.
• 13. That would be a concern if .net wasn't already installed everywhere or so.
• 14. ...

I have up here. I'm annoyed. And I like Java better than .NET, and I argue this point once in a while. But I don't set up a crappy list with lies and fud to do that.

And most importantly you failed to mention the one largest selling point to Java: real multi-platform support. And no, Windows 2000, XP, Vista and 7 don't count as "multiple platforms".