Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2007

Tip: Looking for answers? Try searching our database.

JNI & 64-bit windows = slow?

Thread view: 
Christopher Yeung - 24 Nov 2007 22:55 GMT
Help... I don't know why JDK would introduce such an overhead:

I've a Win 64-bit C++ routine that uses dynamic cast/RTTI heavily. I'm
aware of the fact that pure C++ code that uses RTTI/dynamic cast runs
slower in native 64-bit Windows than WOW. But when I put the same
routine inside a 64-bit JVM, the performance degraded by 300%. Can
somebody explain why the difference? AFAIA the JVM shouldn't introduce
so much overhead.

If the C++ routine is compiled as win32 library and run on WOW, the
benchmark is about 1 sec.
If the same C++ routine is compiled as a win64 library and run as native
64-bit, the benchmark is about 1.4 sec.
If the same win64 compiled library is run inside a 64-bit JDK1.5.0_10,
the benchmark is about >4.2sec. <==== 300% performance degradation!!!

All the timings were collected on the same 64-bit Windows 2003 Server box.

Many thanks in advance.

Chris
Christopher Yeung - 24 Nov 2007 22:56 GMT
More results from testing:

The performance degradation seems to be specific to 64-bit Windows.
There is no statistically significant difference between running the
routine in native C++ or inside a JVM on SPARC machines. In fact there
is no significant difference on 32-bit Windows either.
Just why a 64-bit compiled library uses dynamic casts and running inside
a 64-bit JVM on Windows would incur such an overhead??

> Help... I don't know why JDK would introduce such an overhead:
>
[quoted text clipped - 17 lines]
>
> Chris
Roedy Green - 25 Nov 2007 03:43 GMT
On Sat, 24 Nov 2007 22:55:34 GMT, Christopher Yeung
<chris.yeung@cantab.net> wrote, quoted or indirectly quoted someone
who said :

>Help... I don't know why JDK would introduce such an overhead:

I suspect the problem is in 64-bit windows. It may still contain large
hunks of 32-bit code.  When your 64-bit C calls OS services there is
an overhead to flip to 32 bit code and back.
Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Roedy Green - 25 Nov 2007 10:10 GMT
On Sun, 25 Nov 2007 03:43:11 GMT, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>I suspect the problem is in 64-bit windows. It may still contain large
>hunks of 32-bit code.  When your 64-bit C calls OS services there is
>an overhead to flip to 32 bit code and back.

You can check if I am correct by writing some standalone C code for 32
bit and 64 bit Windows and benchmarking it.
Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.