Slashdot Mirror
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."
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.
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
And it mostly shows that NIO is deficient. I encountered similar problems in my tests. Solved them by using http://mina.apache.org/ .
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.
Reserved Word.
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.
.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.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
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.
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.
It's not in the C Standard Library, but there most certainly is async IO for C. See 'aio.h' in POSIX for example.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
FYI: Java will run on platforms that support C. Please see GNU gcj and the Classpath project.
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.
I don't care if it's 90,000 hectares. That lake was not my doing.
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.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
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.