I have to stop the experiment. The most surprise is that I use pure C/pthread to implement the similar test, the performance is even bad than the java version. I read some material, it was said that the Linux thread and AIO performance are not so good. I don't know if it can explain the performance problem I met. Can someone continue to dig deeper? I'm afraid I miss something.
On 1/18/07, yueyu lin <[EMAIL PROTECTED]> wrote:
Although the performance is not so good, but I still continue to dig something out today. I have to clear one thing is that currently I only focus on the read performance because our system is some like a search engine. Read performance is the first priority. I add some time statistics in codes to see how long each step takes. The shame is that my list operation cost almost 50% time. That means if we can improve that, it may possibly be quicker than RandomAccessFile. I've done some researches with my colleague, we found Sun did an excellent job for introducing CAS(Compare and Set) into java. That interface is even lack of in Linux's core library. Solaris has atomic_xxx functions to provide the feature. This feature will improve the linked list performance in multiple threads environment much. In Sun's JDK implementation, the assemble codes are for X86. That inspires me to do it! I'll continue to do something. If there is any progress, I will post to the list. On 1/18/07, Mike Heath < [EMAIL PROTECTED]> wrote: > > On Wed, 2007-01-17 at 18:27 +0800, yueyu lin wrote: > > OK, I finally implement a stable version based on the signal call in > > aio_read . > > This is awesome! I'm going to try and integrate some of this into my > AIO framework. Good work. > > > The performance is improved about 70%~100% compared with the thread > > notification way. > > But sadly, it's still slower than Sun's simple implementation. I've > checked > > the codes, it just only call read(2) for any read invokation. No > special > > operations. > > Mentioned by the mail from Sun's employee in OpenJDK, the aio_read is > > aio_read(3) > > instead of aio_read(2). That means that's a lib call, not a syscall. > The > > syscall may benefit from the legacy interrupt to improve > performance. I > > also noted that Linux has already put the aio_read implemented in the > kernel > > in the Kernel 2.5 or later. But it's still a software way to do that. > > Indeed, the asynchronous read may improve the throughput, but it needs > > > current application to change their model to event-driven model. My > idea > > that is to replace the RandomAccessFile may not work. Because our > > application is just work as a block reading way. > > MINA uses an event-driven model which is why I've been looking at using > POSIX AIO with Java. Java has excellent support for event-driven > networking (which MINA takes advantage of) but but Java is still > limited with file AIO. I should point out though that JSR 203 is in > active development and will be released with Java 7. > > I'm hoping to have some solid benchmarks measuring the performance > difference between using AIO and blocking I/O on a server handling > thousands of concurrent network connections. I'll post my results on > this list. I'm also very interested to see the difference in > performance of POSIX AIO between Linux and Solaris. I'll try to > benchmark that as well. > > -Mike > > -- -- Yueyu Lin
-- -- Yueyu Lin
