Need to recompile a Java Applet as an Executable
in [Java Programming]
|
Prev: How to get an include-path of jni.h that is able to be differenton different platforms.
Next: Read utf-8 file return utf-16 coding hex string ?
From: Lew on 29 Jan 2010 19:06 Antoninus Twink wrote: > To be honest, whatever stories people come up with about how good their > JIT compiler is at optimizing on the fly and such like, the truth is > that for many applications, rewriting the bottleneck in C will gain you > an order of magnitude. And for many, many, many more, it won't. It can most definitely lose you an order of magnitude, also. Java performance in some cases is superior to equivalent C code. In others, it isn't. On average, most CPU-bound stuff seems to be about 50-90% as fast as C code, but the difference is much smaller if memory allocation/deallocation are involved, or if HotSpot converts the code to native code, in which case one can often find the Java code to be faster. As always, predictions in any particular scenario are useless. Measurement will tell. > I believe the principal two reasons for this are: > > 1) No overhead in basic data types. AIUI, Java will take many bytes to > store a simple int, just because of all the OO book-keeping that needs Java takes four bytes to store a simple int. > to accompany every single object. Therefore, smaller slices of every > array can fit in cache ---> performance death. An 'int' in Java is not an object. Some think of this as a flaw. > 2) Java hides what's going on under the hood from the programmer. This > abstraction is great for reducing coding time, but it means people > unwittingly do things that cause lots of temporary variables to be > created (which might themselves depend on constructing half a dozen base > classes), or they keep generating lots of junk on the heap instead of > making one allocation and recycling it themselves, so that GC becomes a > killer. Maybe, but you state this as if it were a sure thing, which is far from the truth. If GC were to be a "killer", as you cutely put it, that would be because you are allocating lots of objects. If you are allocating lots of objects in C or C++, then memory management will be a "killer" there, too. The difference is that the C/C++ code will require much more code to do the trick, it'll actually take longer to manage its memory than the Java program, and the risk of wild pointers or memory leaks is much, much higher. It doesn't do any good to get a bug to crash your C program in half the time it takes a Java program to run correctly. Are you a Java programmer? Because you don't sound like it. > In Java (and C++ for that matter), the possible expansion factor of a > single source line into assembly instructions is essentially unlimited, > whereas with C you generally see what you're getting. B.S. -- Lew
From: Lew on 29 Jan 2010 19:11 Thomas Pornin wrote: > On all other instances I have come across, the speedup offered by C over > Java on pure computational, fit-in-L1-cache-and-no-IO work, is typically > between 2x and 3x (3x for array-intensive work, because of array length > checks upon access), never above 4x. In "-server" mode, the HotSpot compiler will often eliminate array bounds checks. -- Lew
From: Richard Heathfield on 30 Jan 2010 01:23 BGB / cr88192 wrote: > "Tim Streater" <timstreater(a)waitrose.com> wrote in message > news:AOSdnWbOq-f89_7WnZ2dnUVZ8vdi4p2d(a)brightview.co.uk... >> On 29/01/2010 22:17, Antoninus Twink wrote: >>> On 29 Jan 2010 at 21:42, BGB / cr88192 wrote: >>>> anyways, assuming that the browser is not using a poor JVM >>>> implementation (a plain interpreter or similar), Java vs C performance >>>> is not likely to be significant enough to bother worrying about in >>>> this case, and one is instead better off concerning themselves with >>>> writing efficient code (any language will be slow if the programmer >>>> doesn't know what they are doing, and usually the language/compiler is >>>> the first thing to be blamed for the poor performance of badly written >>>> SW). >>> To be honest, whatever stories people come up with about how good their >>> JIT compiler is at optimizing on the fly and such like, the truth is >>> that for many applications, rewriting the bottleneck in C will gain you >>> an order of magnitude. >> Does this include C# or whatever is was that Baldrick was claiming was >> only 10% slower than C? >> >> I'll be damned. >> > > one can also force the C into being compiled as C++/CLI and see what > happens... ....and the results can be startling. > I did this recently for a test... > > actually, for the simple tool I converted, about the only real noticable > differences was that the C++/CLI version took around maybe 100-250 ms longer Perhaps .Net has improved in recent years, then. When I tried this, about six or seven years ago (with the original intent of putting the program into production), it was 50-60 times slower than C (admittedly for a heavily recursive application). -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: BGB / cr88192 on 30 Jan 2010 02:37 "Richard Heathfield" <rjh(a)see.sig.invalid> wrote in message news:kPCdnemMx8vDTf7WnZ2dnUVZ8lVi4p2d(a)bt.com... > BGB / cr88192 wrote: >> "Tim Streater" <timstreater(a)waitrose.com> wrote in message >> news:AOSdnWbOq-f89_7WnZ2dnUVZ8vdi4p2d(a)brightview.co.uk... >>> On 29/01/2010 22:17, Antoninus Twink wrote: >>>> On 29 Jan 2010 at 21:42, BGB / cr88192 wrote: >>>>> anyways, assuming that the browser is not using a poor JVM >>>>> implementation (a plain interpreter or similar), Java vs C performance >>>>> is not likely to be significant enough to bother worrying about in >>>>> this case, and one is instead better off concerning themselves with >>>>> writing efficient code (any language will be slow if the programmer >>>>> doesn't know what they are doing, and usually the language/compiler is >>>>> the first thing to be blamed for the poor performance of badly written >>>>> SW). >>>> To be honest, whatever stories people come up with about how good their >>>> JIT compiler is at optimizing on the fly and such like, the truth is >>>> that for many applications, rewriting the bottleneck in C will gain you >>>> an order of magnitude. >>> Does this include C# or whatever is was that Baldrick was claiming was >>> only 10% slower than C? >>> >>> I'll be damned. >>> >> >> one can also force the C into being compiled as C++/CLI and see what >> happens... > > ...and the results can be startling. > dunno. I didn't notice much (apart from the usual fiddly needed to convert C to C++, mostly going and adding in the needed typecasts, ...). admitted, I didn't exactly try using any of the .NET features in my test (mostly just verifying that I could convert to .NET bytecode and still access the C toplevel, ...). >> I did this recently for a test... >> >> actually, for the simple tool I converted, about the only real noticable >> differences was that the C++/CLI version took around maybe 100-250 ms >> longer > > Perhaps .Net has improved in recent years, then. When I tried this, about > six or seven years ago (with the original intent of putting the program > into production), it was 50-60 times slower than C (admittedly for a > heavily recursive application). > this was a simple tool, and as noted didn't exactly attempt to do much (I was not out to test performance in this case, only to verify that the basics actually worked...).
From: Arne Vajhøj on 30 Jan 2010 22:40
On 29-01-2010 02:53, Sanny wrote: > I have a Java Applet which is quite slow. > > There are a few functions that are called by the Java Applet. I want > those functions to be run as fast as possible. Using applets for CPU intensive work is not an obvious choice. > Does an Applet support native language? > > Can I create a C++ / C function and ask the applet to call that C > function that is run on Users Computer? And get back the output and > display on the Applet? You can certainly call C code from Java using JNI. > How to distribute my applet with C/ C++ dll/ That Applet accesses? If I remember correctly then applet and JNI requires the native dynamic library (.dll, .so or whatever it is called on the specific platform) to already be on the client. Java Web Start may be different. > I want that users who are not satisfied with the slow version. They > will need to use the Signed Applet. Once they allow the Signed applet > to access the Computer. The applet will load the C/ C++ dll / ActiveX > on the Computer / Webpage. > > I want communication between Activex and the Applet for quick > computation. Why an ActiveX plugin? Communication between an ActiveX plugin and an applet sounds both cumbersome and slow. > Will the Activex/ DLL be 10-20 times faster than an Applet? Most likely not. You chances of winning in powerball is probably better. > Will I have to create different ddl/ ActiveX for different platforms? Different JNI native dynamic library for every platform you want to support. ActiveX is Windows only. > Say for Mac os/ Linux/ Windows etc? Do I need to create a different > ActiveX? Does not exist. > Which C/C++ free package should I use to create this function. I just > want a few functions to be executed quickly by native language and > return the output to the applet. So I want a free editor where I can > compile the C/ C++ functions. To use JNI you just need Java and any C/C++ compiler for the platforms you intend to suppport. For ActiveX you should go for some combination of Visual C++ and Platform SDK. > Please suggest me a good example or diagram of how to proceed. Will I > need Corba/ XML feature for Applet& Activex communication? I can not see any reason to also throw CORBA and XML into the mix. Using any technology under the sun will not make your app faster. > Will this > setup work on all web browsers? ActiveX will only work with IE. JNI should work for all browsers on the platforms you create it for. > Does flash works faster than Java? Can I use those functions in Flash. > Wil a function run on Flash as fast as a Native Language? I am far from a Flash expert. But CPU intensive calculations does not seem to be something Flash is used for (excluding video related calculations !), so I very much doubt that Flash is optimized for such. Arne |