Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Java IO Faster Than NIO

kdawson posted more than 4 years ago | from the question-conventional-wisdom dept.

Java 270

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

Sorry! There are no comments related to the filter you selected.

Proof (0)

Anonymous Coward | more than 4 years ago | (#33050260)

That one person per coffee cup is the best solution. Or not. It could go either way. :p

And this is news? (4, Insightful)

Just_Say_Duhhh (1318603) | more than 4 years ago | (#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!

Re:And this is news? (5, Insightful)

bolthole (122186) | more than 4 years ago | (#33050330)

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.

Re:And this is news? (1, Interesting)

jellomizer (103300) | more than 4 years ago | (#33050546)

Perl is not New Fangled. I am sorry to say Perl is one of those .COM languages that has sparked peoples interest for a few years but have settled down to niche language. So it is now an Old School Language... Sorry...

Lines of code doesn't equate to easy. I could write almost any program with one line of code of APL. However there is a steep learning curve to APL, Debugging APL code is near impossible and what is worse is trying to add updates to it. Perl can be coded very Dense as well with heavy use of Regular Expressions... However Regular Expressions come at a cost of readability and upgradability as well.

Re:And this is news? (3, Funny)

osu-neko (2604) | more than 4 years ago | (#33050596)

Perl is not New Fangled. I am sorry to say Perl is one of those .COM languages that has sparked peoples interest for a few years but have settled down to niche language. So it is now an Old School Language... Sorry...

:o

GET OFF MY LAWN!

Re:And this is news? (5, Informative)

ShadowRangerRIT (1301549) | more than 4 years ago | (#33050696)

.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:And this is news? (2, Funny)

Titoxd (1116095) | more than 4 years ago | (#33050872)

That still makes it a .COM language. As in COMMAND.COM, though...

Command.com by 3M (0)

tepples (727027) | more than 4 years ago | (#33051168)

That still makes it a .COM language. As in COMMAND.COM, though...

What do strips to hang things on the wall [command.com] have to do with Perl?

But seriously though, Perl is a .exe language not a .com language because its interpreter is bigger than 65536 bytes. So my best guess is that by ".com language" you meant a language in which programs are stored as source code and parsed when they are run, as opposed to compilation ahead of time.

Re:And this is news? (1)

Billly Gates (198444) | more than 4 years ago | (#33051030)

Ease of use?

Look at your sig?

It makes me want to run from Perl like the plague. The new bash shell and command line utilities can do most of perl much easier and there are languages that are strict such as python that are readable by mere regular humans. The powershell and .NET makes it a powerful replacement as well. The fact is you do not need piping text around everywhere and using sed and regex if objects are used instead. I do admit it makes the system administrator more of a .NET programmer than a unix one but Perl is no longer used for CGI scripts for good reason. I had a whole college level book on Perl programming and the first chapter showed there were "3" different ways of printing "hello world" and they all vary on context??

I know its probably your favorite language and I do not mean to bash it. But Perl is not very useful if a team uses it because no one can read each others code as it can very so widely. It was all the rage as was Java a decade ago. Java seems to be living on in its niche of complex serverlet apps.

Re:And this is news? (1)

ArsonSmith (13997) | more than 4 years ago | (#33051308)

Other than he probably meant the last 'c' in the string to be a 'z', the code in his sig is quite simple and little more than a kids decoder ring. How would you do the same thing in your favorite language that would make it so much easier?

Re:And this is news? (0)

Anonymous Coward | more than 4 years ago | (#33051152)

Yet, sed, awk, and /bin/sh (or compatible) are generally easier to use than Perl is. Because I can't think of a unix that doesn't ship with a Bourne compatible shell. (Most of them even have the Bourne Again SHell. Afaik, only HP-UX doesn't include it.)

In that respect, it fails, miserably. (Though it can do all of those things, it's generally more annoying from an administrator's point of view than just using sed and awk. Though admittedly, some swear by Perl.) Comparatively, I would argue Perl is also harder to read than most shell scripts. (I've seen this many times with the newbie test, they can generally read the shell. Perl, they might be able to, but there's a lower percentage.)

Re:And this is news? (1)

KlomDark (6370) | more than 4 years ago | (#33051176)

Yah, forget those .com apps. These days we're only happy with .net apps. But one of these days we'll finally be freed when the days of .exe code are here!

Re:And this is news? (5, Insightful)

ShadowRangerRIT (1301549) | more than 4 years ago | (#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:And this is news? (2, Funny)

Anonymous Coward | more than 4 years ago | (#33051034)

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 $hashref is just the first parameter. Well, part of this, and because it's just a hash reference...there is no encapsulation or protection...no private, no protected..etc.

I was concerned about this, and the book I was reading noted someone might be. It's response was "Perl takes the approach that you should stay out of its living room because you're uninvited, not because it's holding a shotgun."

That's Perl programming in a nutshell :)

Re:And this is news? (1)

Dalcius (587481) | more than 4 years ago | (#33051212)

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.

Re:And this is news? (1)

Locke2005 (849178) | more than 4 years ago | (#33051250)

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!

Re:And this is news? (1)

kenj0418 (230916) | more than 4 years ago | (#33051052)

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:And this is news? (2, Interesting)

slack_justyb (862874) | more than 4 years ago | (#33050340)

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? (4, Informative)

HFXPro (581079) | more than 4 years ago | (#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.

Re:And this is news? (-1, Offtopic)

HFXPro (581079) | more than 4 years ago | (#33050396)

I meant to say java io is not particularly hard to use. I personally find nio harder to use. Does anyone know how to disable the touch pad on a Sony VIAO running Ubuntu? Just disabling the device from System->Preferences doesn't seem to work.

Re:And this is news? (0)

Anonymous Coward | more than 4 years ago | (#33050518)

Most likely your X is configured to use /dev/mice, which is the HID device for "all of the inputs from all of the mice plugged into this computer mixed into one"

The problem is that you'll need to figure out what device the mouse you want to use is, and point X to that device, and hope it doesn't change (ie you never unplug the usb mouse, and it never gets detected first due to a delay etc).

The other choice is to figure out if your touchpad loads through a module (eg synaptic) and blacklist that module to keep it from loading.

Or, rewrite the HID layer so that you can instruct it to disable a specific input on demand. Or, if your touchpad uses the USB HID mouse, rewrite the HID mouse driver to blacklist that USB device ID.

The possibilities are endless!

(The answer is no.)

Re:And this is news? (1)

cynyr (703126) | more than 4 years ago | (#33050722)

you forgot "disable the trackpad in the bios. your best bet is to join the rest of us and use /dev/event/foo and configure X to only use the pointer stick. or your mouse.

Re:And this is news? (1)

PiAndWhippedCream (1566727) | more than 4 years ago | (#33050620)

I use rmmod psmouse . (a line in /etc/modprobe.d/blacklist) It works fine on my Dell D630, it might work for you.

Re:And this is news? (4, Funny)

Ossifer (703813) | more than 4 years ago | (#33050976)

Tape a piece of cardboard over it.

Re:And this is news? (3, Funny)

TommydCat (791543) | more than 4 years ago | (#33050372)

select() sucked the life out of me in the 90s and I don't think I'll ever recover...

Re:And this is news? (3, Insightful)

ShadowRangerRIT (1301549) | more than 4 years ago | (#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:And this is news? (1)

MikeyO (99577) | more than 4 years ago | (#33050412)

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

Anonymous Coward | more than 4 years ago | (#33050434)

TFA really says the old school techniques WERE the fastest techniques in the old school days, but that the advances in hardware and OS management of threads has "flipped the script" as the youngsters might say.

Re:And this is news? (2, Insightful)

djKing (1970) | more than 4 years ago | (#33050438)

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

Anonymous Coward | more than 4 years ago | (#33050500)

Um, No. There is no async. I/O in the standard of either language (and there is no such thing a C/C++).

Re:And this is news? (1)

binarylarry (1338699) | more than 4 years ago | (#33050716)

NIO supports async and is a part of the official class library standard.

You can't have a 1.5+ certified java implementation without it working.

Re:And this is news? (2, Informative)

Sir_Lewk (967686) | more than 4 years ago | (#33050880)

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? (2, Informative)

KiloByte (825081) | more than 4 years ago | (#33051126)

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:And this is news? (4, Insightful)

cosm (1072588) | more than 4 years ago | (#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.

Re:And this is news? (1)

Just_Say_Duhhh (1318603) | more than 4 years ago | (#33050564)

but being old doesn't necessarily guarantee it will always be faster all of the time, as your comment implies.

Yes, being old does guarantee it will always be faster. Now all you kids get off my lawn!

Re:And this is news? (4, Insightful)

CODiNE (27417) | more than 4 years ago | (#33050862)

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.

Re:And this is news? (1)

steelfood (895457) | more than 4 years ago | (#33050892)

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 code does not persist until today.

Today, anybody and everybody who knows how to write "Hello World" is considered a developer. Thus, the bar for entry, and the bar for success is much lower. Hence, code written today on a "modern" programming language is necessarily less efficient, because the language itself was written for an overall less capable group of people.

That is not to say that code developed today cannot be as efficient as code written in the old days, nor is it to say that all of the code written back then is necessarily more efficient as the code written today. But as there hasn't really been any algorithmic breakthroughs in many years for most of the computing science field, the upper limit of the efficiency of the code written today is the same as the upper limit of the efficiency of the code written in the past. And chances are, those upper limits have already been hit.

Re:And this is news? (3, Insightful)

Lunix Nutcase (1092239) | more than 4 years ago | (#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.

Re:And this is news? (1)

MobileTatsu-NJG (946591) | more than 4 years ago | (#33050778)

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

avgapon (1851536) | more than 4 years ago | (#33050864)

I guess those who moderated this insightful are as clueless as the original poster (if not more). Definitely they haven't done any Java NIO code.

Re:And this is news? (2, Insightful)

Monkeedude1212 (1560403) | more than 4 years ago | (#33050950)

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 very-high level language.

The idea they try to convey here is You are trying to efficiently thread for a multicore machine. You can either
A)Use Java's Asynchronous IO (NIO)
or
B) Use regular Java IO, with a modern threading library (like Linux NPTL!)
to achieve this.

Turns out - B is faster.

Re:And this is news? (0)

Anonymous Coward | more than 4 years ago | (#33051134)

Async. is done because of ease or performance. Doing async. operations via polling is more deterministic and much easier to analyze (as a system) than blocking on events (e.g., semaphores and interrupts). That is why it is often preferred in real-time systems.

Re:And this is news? (1)

s2jcpete (989386) | more than 4 years ago | (#33051206)

You haven't used NIO then, it is considerably more complex then using java.io.

Re:And this is news? (1)

rsk (119464) | more than 4 years ago | (#33051266)

I don't know anyone that would say NIO/Selectors is *easier* than straight blocking IO.

I also hate replies that begin with "of course"... makes me want to pour coffee on someone's lap.

Waiting for JDK 7 (4, Informative)

Anonymous Coward | more than 4 years ago | (#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 (3, Informative)

binarylarry (1338699) | more than 4 years ago | (#33050484)

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

Re:Waiting for JDK 7 (2, Informative)

Anonymous Coward | more than 4 years ago | (#33050860)

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:Waiting for JDK 7 (1)

binarylarry (1338699) | more than 4 years ago | (#33050904)

They're all pretty accurate.

Java counterpart to XNA? (0, Troll)

tepples (727027) | more than 4 years ago | (#33051278)

101 Reasons why Java is better than .NET

All of which are null and void if there's no JVM for your (non-PC) target platform. Which Java edition lets the public program for a game console? .NET does; XNA for Xbox 360 is based on the .NET Compact Framework.

Re:Java counterpart to XNA? (1)

binarylarry (1338699) | more than 4 years ago | (#33051320)

So, you're touting .NET's cross platform friendlyness against Java's?

Really?

Re:Java counterpart to XNA? (1)

tepples (727027) | more than 4 years ago | (#33051612)

So, you're touting .NET's cross platform friendlyness against Java's?

It doesn't matter how many platforms language X and library Y run on if the set of such platforms doesn't include platform P, and platform P is the only platform that remotely matches the business plan for your application.

Re:Java counterpart to XNA? (1)

Sarten-X (1102295) | more than 4 years ago | (#33051522)

PropJavelin [wikispaces.com] , for the HYDRA [wikipedia.org] .

Which XNA version lets the public program for the Wii or Playstation?

Re:Java counterpart to XNA? (1)

tepples (727027) | more than 4 years ago | (#33051590)

Which XNA version lets the public program for the Wii or Playstation?

Nintendo and Sony have made the choice not to let the public develop for their platforms. (Even on PS3, the latest firmware will erase your Other OS.) Microsoft is the only game console maker with a public SDK, and the only way to use Java on its platform is through J#, which Microsoft appears to be phasing out.

Re:Java counterpart to XNA? (1)

smidget2k4 (847334) | more than 4 years ago | (#33051528)

I... just... I don't even know what to say to this other than to echo the other comment.

Really? That's your argument?

Re:Java counterpart to XNA? (1)

tepples (727027) | more than 4 years ago | (#33051568)

That's your argument?

Allow me to rephrase: If you're trying to bring an application to a given platform, sometimes the platform forces the language choice. On iPhone, it's Objective-C++; on Windows Phone 7, it's a .NET managed language. I agree that Java is useful on platforms with a JVM, but you may need to reconsider use of Java if your business plan includes expanding to a platform that lacks one.

Re:Waiting for JDK 7 (0)

Anonymous Coward | more than 4 years ago | (#33050636)

FTA:

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.

TFA also notes that when you are using nio for server programming, you basically will end up coding a threading library because you need to restore the states when switching between clients.

Re:Waiting for JDK 7 (2, Informative)

Anonymous Coward | more than 4 years ago | (#33051230)

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. (4, Informative)

Cyberax (705495) | more than 4 years ago | (#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. (3, Informative)

binarylarry (1338699) | more than 4 years ago | (#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. (4, Interesting)

bill_kress (99356) | more than 4 years ago | (#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.

Re:Old news. (1)

Alioth (221270) | more than 4 years ago | (#33051360)

Sounds like Java was the wrong tool for the job. There are other languages designed explicitly for massive concurrency which may have worked out better.

NIO? (1)

mhh91 (1784516) | more than 4 years ago | (#33050348)

never really used the NIO API,and never saw a reason to,it's not even included in the SCJP exam,which is the basis for all Sun certification

Where's Jobs? (1)

grub (11606) | more than 4 years ago | (#33050366)


Now we just need a Sun spokesperson to have a press conference and show that old-school blocking I/O with modern threading libraries affects all languages, not just Java.

Re:Where's Jobs? (1)

skids (119237) | more than 4 years ago | (#33050558)

Probably won't happen. My bet on what's going on here is Java OO being so damn heavy it is heavier than the kernel's thread/task struct.

NIO != lower latency (5, Insightful)

yvajj (970228) | more than 4 years ago | (#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:NIO != lower latency (2, Informative)

medv4380 (1604309) | more than 4 years ago | (#33050708)

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.

Re:NIO != lower latency (1)

pjt33 (739471) | more than 4 years ago | (#33050814)

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:NIO != lower latency (1)

yvajj (970228) | more than 4 years ago | (#33050958)

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.

IO is still "blocking" i.e. requires you to have a thread per connection to wait for incoming data (for your application). This essentially means that you're still limited by the box and the number of connections you can spawn (as well as the nature of the requests).

A couple years back when we tested this (around 3-4 years back I think), we could at most sustain 6k - 7k connections per box using standard IO (this was not HTTP / web traffic). The issues we ran into were spawing new native threads on the box (ran out of handles on linux) as well as running out of memory.

With NIO, we were able to sustain around 10k connections per box. Granted you could probably do a lot better now with the latest JVM and newer multi-core boxes.

Note, these were not pseudo tests... we tested actually "servicing requests" that the servers were designed for. The outcome of the testing may also vary based on what the servers are actually doing (how much memory each request is consuming etc).

Re:NIO != lower latency (1)

GooberToo (74388) | more than 4 years ago | (#33051072)

A couple years back when we tested this (around 3-4 years back I think), we could at most sustain 6k - 7k connections per box using standard IO (this was not HTTP / web traffic). The issues we ran into were spawing new native threads on the box (ran out of handles on linux) as well as running out of memory.

Anyone who wants scalability NEVER uses a 1:1 thread model. This is why Apache specifically uses a hybrid model to avoid such insanity. A 1:1 model is a recipe for strong contention which is completely contrary to the notion of scalability and actively defeats hardware scalability by adding additional cores/CPUs.

The fact that you run out of handles on linux means the box was not properly configured.

The memory issue is easily fixed by either adding more memory or using a sane connection model.

NIO is outdated new version to be released in Fall (1, Informative)

Anonymous Coward | more than 4 years ago | (#33050568)

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:NIO is outdated new version to be released in F (1)

mevets (322601) | more than 4 years ago | (#33050746)

I wonder how much slower nio2 will be...

Re:NIO is outdated new version to be released in F (1)

mwolfe38 (1286498) | more than 4 years ago | (#33051630)

it won't matter, they'll rename nio2 back to nio after realizing that nobody can figure out the java numbering system.

Doesn't scale (0)

Anonymous Coward | more than 4 years ago | (#33050594)

In the case where you have to manage many thousands of connections the select loop is far more efficent than spawning 1 thread per connection. I can multiplex several hundred connections to the same listen port on one thread and let a fixed thread pool do the computations and let the same (connection) thread serve the result.

It depends on what you are trying to do. While I did not go over the article completely I fail to see how asynchronous IO can be faster than NIO with buffers and DMA.

is this what I think it is? (1)

blair1q (305137) | more than 4 years ago | (#33050670)

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

Re:is this what I think it is? (1)

Alex Belits (437) | more than 4 years ago | (#33051422)

No. And you have no idea what are you talking about.

uh...... DUH?! (5, Insightful)

Michael Kristopeit (1751814) | more than 4 years ago | (#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.

Re:uh...... DUH?! (0)

Anonymous Coward | more than 4 years ago | (#33051180)

So use the old faster io stuff in a thread while you do other stuff. No need to get all complicated with NIO garbage.

Re:uh...... DUH?! (1)

tepples (727027) | more than 4 years ago | (#33051346)

AC wrote:

So use the old faster io stuff in a thread

Provided that you have enough threads available to do "the old faster io stuff". Once you start juggling more than a thousand connections to a server, you run into the kind of limit that bill_kress mentioned [slashdot.org] .

Suggestion: Skip to page 21 (2, Insightful)

phantomcircuit (938963) | more than 4 years ago | (#33050752)

You'll laugh, hysterically.

Re:Suggestion: Skip to page 21 (1)

medv4380 (1604309) | more than 4 years ago | (#33050848)

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.

First Post (0)

clintonmonk (1411953) | more than 4 years ago | (#33050762)

First post... ..man, I knew I shouldn't have used that Java interface to post on Slashdot.

Should be using Scatter/Gather +IOCP on windows (2, Informative)

Saint Stephen (19450) | more than 4 years ago | (#33050822)

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:Should be using Scatter/Gather +IOCP on windows (1, Troll)

Alex Belits (437) | more than 4 years ago | (#33050922)

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

No. It's only better if the rest of the system is done according to Microsoft ideology -- that is, never try to look at a bigger picture when designing each piece, then go out of your way to make each piece optimal in face of completely un-cooperating environment. Microsoft developers have no idea how Unix-like systems deal with I/O, scheduler and virtual memory all interacting with each other, so after Microsofties introduce massive amount of complexity everywhere, it seems to them that they have an optimal solution for each and every case they tried to optimize. In reality Unix had system that is more optimized and more straightforward for the developer.

Re:Should be using Scatter/Gather +IOCP on windows (2, Interesting)

PhrostyMcByte (589271) | more than 4 years ago | (#33051242)

Actually, they are better for different things. In Linux you get notified when you can perform an I/O, perform a bunch of non-blocking I/O, and then wait for another notification. In Windows you perform an I/O, and it will either complete immediately or notify you when it does. This means async I/O on Linux can use less memory, while on Windows it can give higher throughput.

Of course, these are merely API advantages -- if the implementation is poor, that won't matter. I'm not aware of any serious tests on this. And even then, Windows lacks an equivalent to Linux's splice(), and its equivalent of sendfile() is crippled on desktop versions to discourage using a desktop as a file server.

Re:Should be using Scatter/Gather +IOCP on windows (1)

Alex Belits (437) | more than 4 years ago | (#33051526)

This means async I/O on Linux can use less memory, while on Windows it can give higher throughput.

No. It means that you don't know how pending I/O controls the scheduler. On Linux processes are almost never "notified" by asynchronously arriving signals, they are either processing a request, or sleeping while performing a syscall, so they are awakened by a scheduler when whatever they are waiting for (usually data arrived or buffer is available) happened. Scheduler takes into account the number of pending I/O requests and priorities, so processes are awakened in the optimal order -- I/O priority dictates whether it will be for latency or throughput.

Windows developers followed their typical "Oh!!! It's an event! It looks like a hardware interrupt! I LOVE EVENT HANDLERS! And VMS has the same mechanism! It must be fast!!!" decision-making process instead of trying to actually design a useful data processing mechanism, and predictably ended up with a fine-tuned, convoluted system that works worse than generalized and straightforward one chosen by Unix/BSD/Linux developers.

Re:Should be using Scatter/Gather +IOCP on windows (1, Funny)

Anonymous Coward | more than 4 years ago | (#33051092)

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.

They're actually WriteFileGather and ReadFileScatter. APIs that scattered data around the disk would not be good for performance ;)

Re:Should be using Scatter/Gather +IOCP on windows (1)

KiloByte (825081) | more than 4 years ago | (#33051196)

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.

Re:Should be using Scatter/Gather +IOCP on windows (0)

Anonymous Coward | more than 4 years ago | (#33051226)

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

Solaris has IO Completion Ports as well.

*BSD has kqueue.

Linux has epoll.

This is not unique to Windows.

Re:Should be using Scatter/Gather +IOCP on windows (1)

thoughtsatthemoment (1687848) | more than 4 years ago | (#33051512)

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.

Re:Should be using Scatter/Gather +IOCP on windows (1)

thoughtsatthemoment (1687848) | more than 4 years ago | (#33051604)

you must call read/write again

I meant the case where the previous call returned with the pending status.

Thread full of fail (0)

Anonymous Coward | more than 4 years ago | (#33050910)

NIO was not created to be faster but rather to be scalable. Those are two completely different things. Fail.

Java X faster than Java Y. (0)

Anonymous Coward | more than 4 years ago | (#33050986)

Yawn ... slow day on Slashdot.

Latency vs throughput (0)

Anonymous Coward | more than 4 years ago | (#33051054)

AIO gives you latency & scale improvements, not throughput. It's not surprising that synchronous I/O has faster throughput since it saves you a bunch of syscalls. AIO though means that you can handle more concurrent I/O operations even though each individual one may have a lower throughput & you offer more consistently low latency (whereas with synchronous I/O calls may block indefinitely, locking up the UI).

No shit Watson (2, Insightful)

Alex Belits (437) | more than 4 years ago | (#33051060)

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.

2008 (1)

StikyPad (445176) | more than 4 years ago | (#33051144)

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?

Who Caaaaarrrrreeeessssss!!!!!! (0)

Anonymous Coward | more than 4 years ago | (#33051194)

Java people desperately crowing about anything performance related are desperate. It doesn't matter what you do, Java people, Java will never be the fastest thing around because a thing running in a thing will never be faster than a single thing. But that's okay! We all understand how it all works and we can just accept it for what it is. Focus on the important stuff, like eliminating the need to find, download, and install piles of stuff before being able to run a Java program. Make it so that I can download a binary and run it and not know whether the source code was written in C, C++, or Java ... since I really don't care anyway.

This is news? (1)

Locke2005 (849178) | more than 4 years ago | (#33051298)

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

Context-Switching fails at high concurrency (1)

Erasmas (1850602) | more than 4 years ago | (#33051430)

I was given the task of handling 10k concurrent connections on a $500 linux box. Standar IO (multi-threaded) quite simply could not cut it - the OS context-switching overhead is prohibitive after a certain number of threads. NIO can handle 10k concurrent connections easily, and keep scaling. At lower-volume, even up to 2000 concurrent connections, regular IO will be fine. But for higher-volume, NIO is a must.

True for JAVA, but not generally true... (4, Interesting)

grmoc (57943) | more than 4 years ago | (#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 ideal method (1)

Zan Lynx (87672) | more than 4 years ago | (#33051552)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?