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: BGB / cr88192 on 29 Jan 2010 16:42 "Antoninus Twink" <nospam(a)nospam.invalid> wrote in message news:slrnhm6dsm.ria.nospam(a)nospam.invalid... > On 29 Jan 2010 at 8:01, Nick Keighley wrote: >> this isn't on topic on comp.lang.c how C or C++ "links" with java is >> outside the scope of the C or C++ language. > > Utter nonsense. > usual answer by the regulars would be something like "the C standard makes no mention of JNI or JVMTI, or JNA, ..., and hence these features are outside the scope of C" (much like is the position WRT: threads, POSIX, OpenGL, ...). granted, to accomplish much of anything useful in C, one generally has to go outside the narrow bounds that are "the standard". granted, this is not exactly the issue as with the original post. 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). actually, it is worse with non-prgrammers, who are more naturally inclined to either blame the computer or imagine that the task itself is just too complicated, rather than consider that it may be instead that the app is just poorly written... as far as Java vs Flash: actually, Flash is likely to be much slower than Java (or at least, for any tasks where non-trivial code is needed, Flash may be a better choice when much of the basic functionality is already built into the Flash backend, such as for 2D/3D animations or video players...). or such...
From: Antoninus Twink on 29 Jan 2010 17:17 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. 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 to accompany every single object. Therefore, smaller slices of every array can fit in cache ---> performance death. 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. 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.
From: Tim Streater on 29 Jan 2010 18:08 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. -- Tim "That excessive bail ought not to be required, nor excessive fines imposed, nor cruel and unusual punishments inflicted" Bill of Rights 1689
From: BGB / cr88192 on 29 Jan 2010 18:46 "Antoninus Twink" <nospam(a)nospam.invalid> wrote in message news:slrnhm6nkl.2l1.nospam(a)nospam.invalid... > 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. > more often though, this is not the case... "on average" the performance of well-written Java code is not THAT much worse than mediocre C (the one major exception case being that of if it is being run in an interpreter, but anymore this is rarely the case...). usually though, it is not the exact performance (in a benchmark sense), which is particularly important, but rather that the code uses good algorithms. all too often, people will use an O(n^2) or O(n^3) algo somewhere, and then blame the compiler because the code is slow, often when the same task could have easily been performed with an O(n) or O(n log n) algo. granted, micro-optimization may make some difference in many cases, but the micro-scale performance is not the underlying cause of the poor performance in "most" cases... > 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 > to accompany every single object. Therefore, smaller slices of every > array can fit in cache ---> performance death. > I am not sure which part in particular you are referring to... Java stores a bit more info per-class, but per-object there is not likely to be "that" much added overhead (likely, it would be similar to using RTTI or similar in C++). as for per-variable, this would likely depend on the specific VM (as for how Sun's JVM, Apache Harmony, or GCJ work internally, dunno, but this issue is not an intrinsic factor of the design). if you mean using boxed-integers though, yes, this is likely to be a killer. but, keep note that I am referring to well-written code, which is most likely to avoid using boxed-integers, ... if performance is a concern. > 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. > > 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. > yes, but this is not generally "well written" code... if a person doesn't know what they are doing, and the code's performance sucks as a result, it is THEIR fault, not the languages'. one can easily enough write badly performing code in C as well (for example, there are many Win32 API / ... calls, and many of them have not exactly the best performance around...). do we blame C because, for example, the Win32 API provides absurdly slow mutexes and naively using them will kill the performance of an app?... do we blame C because calling 'malloc()' in a loop (with no 'free()'s) will cause the app to eventually crash?... much the same as if the C++ programmer naively believes the STL to be some sort of optimizing diety (and in turn uses it to generate poorely performing code). (sadly, many people do seem to regard the STL as some almost deific entity...). in these cases, bad code is to blame, rather than the particular language in use...
From: BGB / cr88192 on 29 Jan 2010 18:56
"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... 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 to get up-and-going (I suspect this being due to the initial JIT overhead or similar). admittedly, I was not using a performance-sensitive tool, rather this was just a misc observation while looking into C++/CLI (as a possible way to eventually interface C and C# codebases...). note that personally, I am primarily a C developer... |