libcurl versus JAVA performance

[Robert Iakobashvili]

Hi,

We have been discussing usage of C/C++
for HTTP and HTTPS file transfers versus JAVA.

The JAVA fans were confident, that the modern JDK 1.5 JAVA has at least
the same if not better performance.
Performance issue is essential for multiple parallel transfers.

If somebody on the list has benchmarked or
tried HTTP and HTTPS both with JAVA and libcurl based implementations?

Thank you.

[Kjell Ericson]

Post by Robert Iakobashvili
The JAVA fans were confident, that the modern JDK 1.5 JAVA has at least
the same if not better performance.

Java people keeps saying that and provide theoretical examples and practical
examples like "look, this C program compiled for a 286 processor runs slower
than a JIT compiled Java program on a Pentium XXX".

This "argument war" will continue because C-people and Java-people talks about
different sides of the issue. Java is never faster if:
* The processor is known when compiling a program.
* The program doesn't loop around in the same code so the optimisation is
gained after the JIT.

Post by Robert Iakobashvili
If somebody on the list has benchmarked or tried HTTP and HTTPS both with
JAVA and libcurl based implementations?

I doubt that benchmark exist. But you can always read this page:
http://www.kano.net/javabench/

As almost stated, having a library (as libcurl) on your system gives you
perfect opportunity to have that library compiled for the processor on your
machine. The question is then not to compare C/C++ and Java, but comparing
libcurl code + gcc and JDK code. The differance must be hugh if Java shall
win that battle.

But telling the Java fans this will not convince them. For each and every
program will they find one small "advantage" for Java that will make Java much
better than every other programming language (mostly because Java fans don't
know any other language :-).

// Kjell

[Robert Iakobashvili]

Hi Kjell Ericson,

Post by Kjell Ericson

Post by Robert Iakobashvili
The JAVA fans were confident, that the modern JDK 1.5 JAVA has at least
the same if not better performance.

This "argument war" will continue because C-people and Java-people talks about
* The processor is known when compiling a program.
* The program doesn't loop around in the same code so the optimisation is
gained after the JIT.

Post by Robert Iakobashvili
If somebody on the list has benchmarked or tried HTTP and HTTPS both with
JAVA and libcurl based implementations?

http://www.kano.net/javabench/

Thank you for the link.

Post by Kjell Ericson
But telling the Java fans this will not convince them. For each and every
program will they find one small "advantage" for Java that will make Java much
better than every other programming language (mostly because Java fans don't
know any other language :-).

This is not the case. Dealing with some great people with a profound knowledge
of assemblers C/C++ as well as java at the server side.

I am looking for some really solid data and benchmarking results or personal
experience.
Could it be the the great people of Sun and IBM have optimized so good
HTTP and TLS/SSL stacks in JDK?

[Kjell Ericson]

Post by Robert Iakobashvili
This is not the case. Dealing with some great people with a profound
knowledge of assemblers C/C++ as well as java at the server side.

Just my conclusion when you compared Java with C/C++ instead of libcurl.

Post by Robert Iakobashvili
Could it be the the great people of Sun and IBM have optimized so good
HTTP and TLS/SSL stacks in JDK?

I have no knowledge at all about that. Would surprise/impress me if that was
the case.

I assume the HTTP part is quite small to be optimized. But if any part is
only one cycle faster then it's just a matter of iterate it enough to win the
competition... :-)

// Kjell

[Daniel Stenberg]

Post by Kjell Ericson

Post by Robert Iakobashvili
Could it be the the great people of Sun and IBM have optimized so good
HTTP and TLS/SSL stacks in JDK?

[...]

Post by Kjell Ericson
I assume the HTTP part is quite small to be optimized. But if any part is
only one cycle faster then it's just a matter of iterate it enough to win
the competition... :-)

TLS/SSL certainly is not small and traditionally at least (to allow room for
the claims mentioned in this thread) the java implementations have been
significantly slower than the C-written ones.

(I'm pretty sure I got this info and even read some specific numbers in the
"SSL and TLS" book by Eric Rescorla, but I don't have it here right now to
make sure.)

[Robert Iakobashvili]

Post by Daniel Stenberg
TLS/SSL certainly is not small and traditionally at least (to allow room for
the claims mentioned in this thread) the java implementations have been
significantly slower than the C-written ones.
(I'm pretty sure I got this info and even read some specific numbers in the
"SSL and TLS" book by Eric Rescorla, but I don't have it here right now to
make sure.)

I also studied this great book once also remember
java performance issues mentioned by Eric.

The point is that the book has been published a few JDK-s ago.
:)

[Aleksandar Lazic]

Post by Kjell Ericson

Post by Robert Iakobashvili
If somebody on the list has benchmarked or tried HTTP and HTTPS both
with JAVA and libcurl based implementations?

http://www.kano.net/javabench/

or
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=gpp
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=gcc

maybe with NIO java could be better but is there a NIO http(s) clientlib
for java?!

Cheers

Aleks

[Robert Iakobashvili]

Post by Aleksandar Lazic
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=gpp
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=gcc

Thanks, Aleks.

Post by Aleksandar Lazic
maybe with NIO java could be better but is there a NIO http(s) clientlib
for java?!

Good question.

[Robert Iakobashvili]

Aleks,

Post by Aleksandar Lazic

Post by Kjell Ericson

Post by Robert Iakobashvili
If somebody on the list has benchmarked or tried HTTP and HTTPS both
with JAVA and libcurl based implementations?

http://www.kano.net/javabench/

or
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=gpp
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&lang2=gcc
maybe with NIO java could be better but is there a NIO http(s) clientlib
for java?!

Looks like there are two very interesting NIO projects with http and https:

https://glassfish.dev.java.net/
https://grizzly.dev.java.net/

grizzly is using curl-loader based on libcurl for testing their server side
:)

[Serge Skorokhodov]

Hi,

Sorry for a bit offtopic.

Post by Kjell Ericson
http://www.kano.net/javabench/

<skip>

Well, Java seems to do pretty well with recursion, really. Still I you
switch for more efficient iteration versions of algorithms, C/C++ is
~30% better than Java as expected. And -server does worse than
-client. At least it seems to be so for fibonacci sample. Try
something like this:

<java code>
public static int fib2( int n )
{
int n2 = 0;
int n1 = 1;
for ( int i = n; i > 1; --i ) {
int tmp = n2;
n2 = n1;
n1 += tmp;
}
return n2 + n1;
}
</java code>

<c code>
unsigned fib2( unsigned n )
{
unsigned n2 = 0;
unsigned n1 = 1;
for ( unsigned i = n; i > 1; --i )
{
unsigned tmp = n2;
n2 = n1;
n1 += tmp;
}
return n1 + n2;
}
</c code>

[Cory Nelson]

Post by Serge Skorokhodov
Well, Java seems to do pretty well with recursion, really. Still I you
switch for more efficient iteration versions of algorithms, C/C++ is
~30% better than Java as expected. And -server does worse than
-client. At least it seems to be so for fibonacci sample. Try

My general opinion on the subject:

Java/.NET provide good facilities for rapid development. In general
use, some of these might even be more performant than their standard
C++ counterparts. The difference is: with C++ you can really optimize
the hell out of something if you need to, while with Java it is out of
your hands. Just try implementing page-aligned I/O buffers or a
lock-free arena allocator in Java!

So even if Java's implementation is more efficient than libcurl right
now, we can always do better in the end.

[Alan Wolfe]

I might be mistaken but i thought java was written in C++?

If that is indeed the case, java beating C++ in preformance just shows
that C++ still wins :P

Post by Cory Nelson

Post by Serge Skorokhodov
Well, Java seems to do pretty well with recursion, really. Still I you
switch for more efficient iteration versions of algorithms, C/C++ is
~30% better than Java as expected. And -server does worse than
-client. At least it seems to be so for fibonacci sample. Try

Java/.NET provide good facilities for rapid development. In general
use, some of these might even be more performant than their standard
C++ counterparts. The difference is: with C++ you can really optimize
the hell out of something if you need to, while with Java it is out of
your hands. Just try implementing page-aligned I/O buffers or a
lock-free arena allocator in Java!
So even if Java's implementation is more efficient than libcurl right
now, we can always do better in the end.
--
Cory Nelson

[Lars Nilsson]

Post by Alan Wolfe
I might be mistaken but i thought java was written in C++?
If that is indeed the case, java beating C++ in preformance just shows
that C++ still wins :P

Boy: Do not try and beat Java. That's impossible. Instead only try to
realize the truth.
Neo: What truth?
Boy: There is no Java.

[Aleksandar Lazic]

Hi Robert,

Post by Robert Iakobashvili
Aleks,

Post by Aleksandar Lazic
maybe with NIO java could be better but is there a NIO http(s)
clientlib for java?!

https://glassfish.dev.java.net/
https://grizzly.dev.java.net/
grizzly is using curl-loader based on libcurl for testing their server
side :)

Cool ;-)
Cheers,

aleks

[Daniel Stenberg]

The JAVA fans were confident, that the modern JDK 1.5 JAVA has at least the
same if not better performance. Performance issue is essential for multiple
parallel transfers.

I too would be very eager to study any such results very closely as I have a
hard time believing it without being backuped with detailed data from actual
real-world tests.