Need to recompile a Java Applet as an Executable
Sanny
There are a few functions that are called by the Java Applet. I want
those functions to be run as fast as possible.
One Option is to use Native Support.
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?
I just want a few functions to use fast C/ C++ access?
How to distribute my applet with C/ C++ dll/ That Applet accesses?
I will have 2 versions of Applet. One the slow version the other the
fast version.
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.
Will the Activex/ DLL be 10-20 times faster than an Applet?
So for power users who are looking for better performance I allow them
to use the C/ C++ version.
Will this model work?
Will I have to create different ddl/ ActiveX for different platforms?
Say for Mac os/ Linux/ Windows etc? Do I need to create a different
ActiveX?
I just have a few functions in C/ C++ and the Applets sends the
parameters and returns the output.
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.
Second Question Will an Activex/ DLL on a webpage be as fast as any
executable? I am looking for the fastest options.
Please suggest me a good example or diagram of how to proceed. Will I
need Corba/ XML feature for Applet & Activex communication? Will this
setup work on all web browsers?
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?
Bye
Sanny
Good opportunities for Java/ C/ C++ Experts:
http://www.getclub.com/Experts.php
Tell your Expertise and projects.
Nick Keighley
> 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.
>
> One Option is to use Native Support.
>
> 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?
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.
<snip>
Flash Gordon
<snip>
> Say for Mac os/ Linux/ Windows etc? Do I need to create a different
> ActiveX?
This is about the nearest thing to a C question, and even this is not a
C question...
Of course any compiled C code would have to be compiled for the specific
target it is running on...
<snip>
> 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?
You probably need to ask in a web authoring group/forum, since your
problems are all heavily to do with a web site. However, I would
recommend from my experience that you would be better off looking at a
higher level, ensuring that only what is needed is being downloaded etc.
I've seen sites where as much as 90% of what was downloaded was not
actually needed by the client! How to do this is all about web
authoring, and not Java (which is NOT Javascript) or C.
--
Flash Gordon
Antoninus Twink
> 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.
BGB / cr88192
"Antoninus Twink" <nos...@nospam.invalid> wrote in message
news:slrnhm6dsm...@nospam.invalid...
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...
Antoninus Twink
> 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.
Tim Streater
> 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
BGB / cr88192
"Antoninus Twink" <nos...@nospam.invalid> wrote in message
> 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...
BGB / cr88192
"Tim Streater" <timst...@waitrose.com> wrote in message
news:AOSdnWbOq-f89_7W...@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...
Lew
> 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
Seebs
> 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.
I once had an exponential algorithm (reasonably so -- it really was an
exponential task). I spent a couple of days hand-tuning it to get maximal
performance from a vector unit, and boosted performance by something
around 30%.
Then I noticed that I was generating pairs of points which were identical,
and tweaked it to not generate those extra points, or the collections of
identical points between them on the next iteration... And I could render
a whole order of magnitude* more actual data, in less time.
Nice to know. And I was still using an exponential algorithm.
-s
* base 2. But it wasn't just that I could render the same data faster; it's
that I could render twice as much data before paging out.
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Ben Pfaff
> I once had an exponential algorithm (reasonably so -- it really was an
> exponential task). I spent a couple of days hand-tuning it to get maximal
> performance from a vector unit, and boosted performance by something
> around 30%.
>
> Then I noticed that I was generating pairs of points which were identical,
> and tweaked it to not generate those extra points, or the collections of
> identical points between them on the next iteration... And I could render
> a whole order of magnitude* more actual data, in less time.
I once had an exponential algorithm, implemented by someone
else. I spent a long evening thinking about the algorithm, and
here is what I ended up putting in the commit log when I applied
my improvement:
The performance of this routine was O(2**N). This improves it to
O(N*W). For N=30, W=120 this reduces calculation time from 6m9s
to .002s, which is a 123000x speedup.
That speedup kept me happy for days.
--
Ben Pfaff
http://benpfaff.org
BGB / cr88192
"Ben Pfaff" <b...@cs.stanford.edu> wrote in message
news:87aavwi...@blp.benpfaff.org...
yep, although granted, this is a bit of an extreme case...
however, it is still worth note that, very often, there is the possibility
of algorithmic speedups, yet all too often, rather to working on improving
the overall algorithm, people will resort to ugly micro-optimizations and
writing, in all, very horrid code.
yes, granted, I have fallen into this trap a few times, but this is rarely
the case in general.
for example, although I use some amount of ASM, I very rarely do it for sake
of micro-optimization, and in cases where I have put a lot of effort into
micro-optimizing things, it has often ended up costing a lot more than it
has been worth...
or such...
Richard Heathfield
> "Tim Streater" <timst...@waitrose.com> wrote in message
> news:AOSdnWbOq-f89_7W...@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
BGB / cr88192
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
news:kPCdnemMx8vDTf7W...@bt.com...
> BGB / cr88192 wrote:
>> "Tim Streater" <timst...@waitrose.com> wrote in message
>> news:AOSdnWbOq-f89_7W...@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...).
Nick
> "Antoninus Twink" <nos...@nospam.invalid> wrote in message
> news:slrnhm6dsm...@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".
But what I think we've got here is a problem in the wrong direction.
Calling C from Java, what the OP wants, is very much something for Java
people. If he was asking about how to interface from C to Java then,
while (apart from "system") there's no way to do that within the
strictures of the standards, my feeling is that the group as it's
working at the moment would probably (after pointing out about 8 times,
over a period of about a week) also discuss a few ways that work for
some common implementations (if there are any - I know zilch about the
subject).
In this case I think "go and ask on a Java group" /is/ the right
response, simply because that's where any suitable expertise will lie.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
BGB / cr88192
"Nick" <3-no...@temporary-address.org.uk> wrote in message
news:87eil8x...@temporary-address.org.uk...
granted, however, the original post was a cross-post also to a Java group...
Phil Carmody
I went from O(n^2) to amortized O(1) (no silly constant factor explosion).
The customer was complaining about time-outs with n as small as 60. We'd
promised n=2000 in the specs. I really wouldn't like to see a 4 million
time speed-up, as I really wouldn't want to have to wait weeks to see
the original version complete. (We're talking real-time comms...)
That was the job that taught me to despise /Design Patterns/ and Java.
(It was a C++ gig, for reference, but you can guess at the quality of
the 7 people I eventually replaced, while clocking up a net productivity
measured at _minus_ tens of thousands of lines of code per year on the
dearly beloved metrics. Hearing "I think we'll make a special case for
this" during the yearly review was the only positive thing I remember
about the job!)
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
Seebs
[...]
Actually, not directly related:
Could you email me? (I'm assuming the address you use here is a spamtrap.)
A recent post of yours is getting resubmitted to clcm about every twenty
minutes.
-s
lawrenc...@siemens.com
>
> (It was a C++ gig, for reference, but you can guess at the quality of
> the 7 people I eventually replaced, while clocking up a net productivity
> measured at _minus_ tens of thousands of lines of code per year on the
> dearly beloved metrics.
I always say my most productive days are the ones where my number of
lines of code is negative. The only code that's guaranteed to be bug
free is code that isn't there (any more)!
--
Larry Jones
We don't ATTEND parties, we just CRASH 'em. -- Calvin
Arne Vajhøj
> 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
Arne Vajhøj
No.
JNI is defined by Java not by C.
And that includes both Java calling C and C calling Java.
Arne
Arne Vajhøj
> 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.
I think we can stop reading here.
Anyone that has read "Java for absolute beginners" know that
int's in Java are not objects and use the exact same number
of bytes as C (on platforms where C int is 4 byte).
If you don't like Java, then by all means avoid coding in it,
reading about it or even think about it.
But why post to usenet about something you have not studied????
Arne
Arne Vajhøj
> BGB / cr88192 wrote:
>> 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).
That is not in any way typical.
It is completely off the scale for unlikelihood.
But if I remember correct from last time you gave
the story, then you can not explain exactly what the
code did.
So we can not explain why it was so.
We can just tell you that it is not what you usually see.
Arne
Richard Heathfield
> On 30-01-2010 01:23, Richard Heathfield wrote:
>> BGB / cr88192 wrote:
>>> 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).
>
> That is not in any way typical.
I can accept that, not having any further data with which to contradict you.
> It is completely off the scale for unlikelihood.
Fine, but I was there, and I know what I saw.
> But if I remember correct from last time you gave
> the story, then you can not explain exactly what the
> code did.
Well, "exactly" would take too long and may conceivably breach customer
confidentiality - and in any case it was so long ago that I've possibly
forgotten some important details. But roughly, we were writing
elementary language parsers - not because we find wheel reinvention
particularly exciting, but because we wanted to be able to extract such
dependency information as existed within source code. For example, if
foo.c #included "nice/handy/path/info/foo.h" or fopened "zog.dat", or if
bar.html contained <a href="baz.html">, then we wanted to know. And if
baz.html in turn contained <a href="quux.asp">, then we wanted to know
that, too - recursively, for each dependency for which the source was
available.
We wrote parsers for a number of programming and markup languages - not
fullblown parsers, just enough to get what we needed - in C++. Clearly
these parsers were heavily recursive, which may explain why the .Net
version was so slow.
We didn't test on .Net for the hell of it, but because we were
instructed by the client to move our code to the brand-new just-released
.Net platform. Since we'd written our code with portability in mind,
this wasn't difficult. At this point we re-tested. It was at this point
that we discovered the massive performance hit. (It was so massive that
we had to test twice - the first time, we stopped the test because we
just sort of assumed it had crashed. But it probably hadn't.)
> So we can not explain why it was so.
Neither can I.
> We can just tell you that it is not what you usually see.
Assuming "you" is meant generically, I have no problem believing that.
Keith Thompson
[...]
> Anyone that has read "Java for absolute beginners" know that
> int's in Java are not objects and use the exact same number
> of bytes as C (on platforms where C int is 4 byte).
Since this is cross-posted to comp.lang.java.programmer and
comp.lang.c, let me clarify that point.
C defines an "object" as a "region of data storage in the execution
environment, the contents of which can represent values". This has
nothing to do with object-oriented programming. Thus a declared
variable of type int certain is an "object" if you use the C
definition of the term. (Note that C++ uses a very similar
definition.)
I don't know how "Java" defines the term.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Lew
> Arne Vajhøj <ar...@vajhoej.dk> writes:
> [...]
>> Anyone that has read "Java for absolute beginners" know that
>> int's in Java are not objects and use the exact same number
>> of bytes as C (on platforms where C int is 4 byte).
> [...]
>
> Since this is cross-posted to comp.lang.java.programmer and
> comp.lang.c, let me clarify that point.
>
> C defines an "object" as a "region of data storage in the execution
> environment, the contents of which can represent values". This has
> nothing to do with object-oriented programming. Thus a declared
> variable of type int certain is an "object" if you use the C
> definition of the term. (Note that C++ uses a very similar
> definition.)
>
> I don't know how "Java" defines the term.
That may be, but the context to which Arne replied and that you excised
claimed that Java has tons of memory overhead to represent an 'int' by virtue
of being an object, which is a bloody falsehood. Clearly that poster was
using "object" in the current conventional computer-programming sense of the
word, and not in your more specialized frame.
FYI, and it absolutely freaking *ASTOUNDS* me that anyone presuming to call
themselves a programmer today has not gotten familiar with object-oriented
programming at least enough to know what an object is, I mean, come on,
already! - an object in Java is exactly what it is in any object-oriented
programming environment. Roughly it's a struct with built-in functions.
You really should expand your study. Start with the Wikipedia definition,
perhaps read Grady Booch. Being a C programmer is not a good excuse. In
fact, it's no excuse at all.
--
Lew
Keith Thompson
> Keith Thompson wrote:
>> Arne Vajhøj <ar...@vajhoej.dk> writes:
>> [...]
>>> Anyone that has read "Java for absolute beginners" know that
>>> int's in Java are not objects and use the exact same number
>>> of bytes as C (on platforms where C int is 4 byte).
>> [...]
>>
>> Since this is cross-posted to comp.lang.java.programmer and
>> comp.lang.c, let me clarify that point.
>>
>> C defines an "object" as a "region of data storage in the execution
>> environment, the contents of which can represent values". This has
>> nothing to do with object-oriented programming. Thus a declared
>> variable of type int certain is an "object" if you use the C
>> definition of the term. (Note that C++ uses a very similar
>> definition.)
>>
>> I don't know how "Java" defines the term.
And I don't know why I put quotation marks around "Java".
> That may be, but the context to which Arne replied and that you
> excised claimed that Java has tons of memory overhead to represent an
> 'int' by virtue of being an object, which is a bloody falsehood.
And I'm sure that Arne was correct and the previous poster was wrong
on that point. That just didn't happen to be what I was commenting
on.
> Clearly that poster was using "object" in the current conventional
> computer-programming sense of the word, and not in your more
> specialized frame.
Yes, clearly. But he did so in an article posted to comp.lang.c.
> FYI, and it absolutely freaking *ASTOUNDS* me that anyone presuming to
> call themselves a programmer today has not gotten familiar with
> object-oriented programming at least enough to know what an object is,
> I mean, come on, already! - an object in Java is exactly what it is in
> any object-oriented programming environment. Roughly it's a struct
> with built-in functions.
What makes you think I'm not familiar with object-oriented
programming?
I was making a relatively narrow point, that the term "object" can
have more than one meaning. Since this thread is cross-posted to
comp.lang.c (where we tend to use the C standard's definition of
"object") and comp.lang.java.programmer (where, quite reasonably,
I'm sure they use the Java definition of the term), I thought it
was a point worth making.
I just checked the Java language definition:
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.3.1
An _object_ is a _class instance_ or an array.
So yes, an int variable in Java is not an "object" in the way that
Java defines the term. I'm not at all surprised to learn that,
nor did I say anything that implies otherwise.
And, as I mentioned, C++ (which is often considered to be an
object-oriented language) has a definition of "object" that's very
similar to the C definition; in C++, a variable of type int *is*
an object.
> You really should expand your study. Start with the Wikipedia
> definition, perhaps read Grady Booch. Being a C programmer is not a
> good excuse. In fact, it's no excuse at all.
Excuse for what? (And I happen to program in C++ for a living;
I just don't discuss C++ in comp.lang.c.)
Keith Thompson
> is introduced by the /declaration/ of an object. You can have
> undeclared objects in C++, which thus are objects, but not variables.
Ok. I was using the term "variable" in an informal sense. The C
standard in particular doesn't define the term, and only rarely
uses it.
> In Java, »variable« has yet another meaning, which corresponds
> to the meaning of »object« in C and C++.
The lesson, I think, is that you have to be very careful even with
(or especially with) seemingly fundamental and obvious terms like
"object", "variable", and so forth. They can have different meanings
in different contexts. The meaning of "object" in C and C++ is
clear and unambiguous. The meaning of "object" in Java is likewise
clear and umambiguous. They're just very different meanings.
Arved Sandstrom
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> Keith Thompson <ks...@mib.org> writes:
>>> in C++, a variable of type int *is* an object.
>> No, in C++ an object is a region of storage, while a variable
>> is introduced by the /declaration/ of an object. You can have
>> undeclared objects in C++, which thus are objects, but not variables.
>
> Ok. I was using the term "variable" in an informal sense. The C
> standard in particular doesn't define the term, and only rarely
> uses it.
>
>> In Java, »variable« has yet another meaning, which corresponds
>> to the meaning of »object« in C and C++.
>
> The lesson, I think, is that you have to be very careful even with
> (or especially with) seemingly fundamental and obvious terms like
> "object", "variable", and so forth. They can have different meanings
> in different contexts. The meaning of "object" in C and C++ is
> clear and unambiguous. The meaning of "object" in Java is likewise
> clear and umambiguous. They're just very different meanings.
>
"object" is all that different between C++ and Java. In both cases it's
an instance of a class, which means they are also regions of storage.
The relevant difference as I see it is that in Java object variables are
references - declaring one does not create an object and it doesn't
even necessarily point to one. Copying a reference simply copies the
reference. Whereas in C++ an object variable actually _is_ an object -
the variable declaration calls the ctor, and copying creates a new object.
The meaning of "variable" in Java does not correspond to the meaning of
"object" in C++, not in any meaningful way. A Java object reference - a
variable - that *has been initialized* provides a way of accessing the
object storage by reference, and if anything a C++ pointer to an object
is closer to that idea, since it's not tied to any particular object.
AHS
Roedy Green
<softt...@hotmail.com> wrote, quoted or indirectly quoted someone
who said :
>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.
>
>One Option is to use Native Support.
jni and applet together are a nightmare. It is much easier to use
Java Web Start and JNI.
See http://mindprod.com/jgloss/jni.html
http://mindprod.com/jgloss/javawebstart.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
Computers are useless. They can only give you answers.
~ Pablo Picasso (born: 1881-10-25 died: 1973-04-08 at age: 91)
Keith Thompson
> Keith Thompson wrote:
[...]
>> The lesson, I think, is that you have to be very careful even with
>> (or especially with) seemingly fundamental and obvious terms like
>> "object", "variable", and so forth. They can have different meanings
>> in different contexts. The meaning of "object" in C and C++ is
>> clear and unambiguous. The meaning of "object" in Java is likewise
>> clear and umambiguous. They're just very different meanings.
>>
> Maybe I'm missing something here, but I fail to see how the meaning of
> "object" is all that different between C++ and Java. In both cases
> it's an instance of a class, which means they are also regions of
> storage.
No, an "object" in C++ can be of any type, not just of a class. By
definition, in C++, "An object is a region of storage" (section 1.8 of
the C++ 2003 standard).
As I said, the C++ definition is similar to the C definition: "region
of data storage in the execution environment, the contents of which
can represent values (C99 3.14).
Perhaps the meaning of "class" is different in Java? (After a *very*
a quick at the Java language specification, I don't think so; it
seems to refer only to types declared with the "class" keyword.)
In C++, "classes" are a particular subset of types. For example,
int is not a class, but instances of type int are objects. In Java,
as I understand it, an instance of type int is not an "object",
because int is not a class.
[...]
I understand that the word "object" is widely used to refer to an
instance of a "class", but that meaning is not universal.n
Phil Carmody
> definition, perhaps read Grady Booch. Being a C programmer is not a
> good excuse. In fact, it's no excuse at all.
Keith, no! Please don't do it!
Friends don't let friends read Grady Booch.
Ersek, Laszlo
> Lew <no...@lewscanon.com> writes:
>> Keith Thompson wrote:
> ...
>> You really should expand your study. Start with the Wikipedia
>> definition, perhaps read Grady Booch. Being a C programmer is not a
>> good excuse. In fact, it's no excuse at all.
>
> Keith, no! Please don't do it!
>
> Friends don't let friends read Grady Booch.
I sympathize with the explicit (formalized) distinction of (= giving
names to) composition / aggregation / navigation.
/* composition, filled diamond */
struct a
{
struct b b;
struct c c[10];
};
/* aggregation, hollow diamond */
struct a
{
struct b *b;
};
/* navigation, run-of-the-mill arrow, like -> */
struct a
{
struct b *b;
};
Composition: you're unable to release an instance of "struct a" without
releasing its members.
Aggregation: you have exclusive ownership of *b (if any) and must take
care of releasing it / them.
Navigation: you can access *b, but are not responsible for freeing it.
Unless one disposes over refcounting or garbage collection (that is,
many times in C, I guess), having "usual names" for such
responsibilities is helpful. Recursive destruction is more stressful
than recursive construction, and tagging pointers with "aggregation" /
"navigation" can help (also with determining the order of destruction,
even in addition to "just reverse the order of construction").
Or that's at least how I tend to interpret those words in C.
Cheers,
lacos
Arved Sandstrom
ourselves to classes.
AHS
BGB / cr88192
<lawrenc...@siemens.com> wrote in message
news:8qve37-...@jones.homeip.net...
> Phil Carmody <thefatphi...@yahoo.co.uk> wrote:
>>
>> (It was a C++ gig, for reference, but you can guess at the quality of
>> the 7 people I eventually replaced, while clocking up a net productivity
>> measured at _minus_ tens of thousands of lines of code per year on the
>> dearly beloved metrics.
>
> I always say my most productive days are the ones where my number of
> lines of code is negative. The only code that's guaranteed to be bug
> free is code that isn't there (any more)!
yeah...
how do you define it?...:
very often, a fairly good solution can be found in relatively few lines of
code, and we don't want, say, 10,000 lines of code that sit around doing
hardly anything but make the app bigger and slower.
yet, it is the common practice to estimate complexity in terms of loc, and
programmer productivity in terms of loc/year, thus allowing something
analogous to the "distance=rate*time" method of forming estimates (and, in
the world, where the best way to get something done better and faster is to
throw more money and people at the problem...).
what then are people to do?...
admittedly, my loc output on average is not exactly small either...
and my project is not exactly small either (although, I have also identified
around 400 kloc which could be removed without impacting much, and has
generally been all moved to an "old" directory and can hence be mostly
ignored, I have not as of yet actually deleted it "just in case" I might
want to revive something...)
in another case recently, I wrote a big chunk of code, but it may go back
there as, it was partly based on some of my old code (a standalone tool of
mine from ~2004-2005), but personally I found it "hideous" (the old code it
was based on was hardly cleanly written, and the resultant hacked-on version
is worse...).
(about the time I start having to resort to "magic temporary state stored in
globals" is about the time I no longer want to work on the code...).
or such...
Antoninus Twink
>> 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).
>
> That is not in any way typical.
>
> It is completely off the scale for unlikelihood.
>
> But if I remember correct from last time you gave the story, then you
> can not explain exactly what the code did.
Richard Heathfield is a notorious comp.lang.c fantasist.
It is obvious that he has never done any programming work in the real
world - no shop I've ever known would tolerate his truculent attitude
and his prissy refusal to step beyond a purely academic view of language
purity and get his hands dirty with pragmatic code that might actually
work.
Arne Vajhøj
I don't recognize that description.
He does not seem to have much faith in VM based runtimes.
That does not exclude programming in the real world.
Arne
Nick Keighley
> On 02-02-2010 15:11, Antoninus Twink wrote:
[...]
> > Richard Heathfield is a notorious comp.lang.c fantasist.
>
> > It is obvious that he has never done any programming work in the real
> > world - no shop I've ever known would tolerate his truculent attitude
> > and his prissy refusal to step beyond a purely academic view of language
> > purity and get his hands dirty with pragmatic code that might actually
> > work.
>
> I don't recognize that description.
>
> He does not seem to have much faith in VM based runtimes.
>
> That does not exclude programming in the real world.
twink's a troll with a problem with Richard Heathfield.