Java's performance far better that optimized C++

[Mark A. Gibbs]

it's almost a lost cause to try and educate an dogmatist. when one is
determined enough in one's faith, trivialities like rationalization and
blatant, incontrovertable facts are merely annoyances, and can be
readily assumed to be nonsense. still... the idealist in me has to try...

You don't make sense here. C++/Java are not the best candidates for
real-time programming indeed. But real-time system and OS are different
notions. Any program can be accomplished using memory-access only (ports and
special machine instructions are rate). What is the definition of "complete
program"?

ports and special machine instructions are rare, eh? dude, if you're
willing to sacrifice ports and special machine instructions, your
programs are no longer capable of:
- reading keyboard input (via interrupts).
- reading mouse input (via port-access instructions).
- multithreading (via context-switching instructions).
- video display (via device drivers, which require ports and interrupts).
- accessing storage devices (more of the same).
etc.

in short, you're now the proud new owner of a javaâ„¢ powered paperweight.

I was asked not to call you C programmers but this is C code. It will fail
executing on a modern OS.

that would depend on the os, now wouldn't it?

as for that being 'c' code, how about:

int* screen = static_cast<int*>(0xA0000000); // ^_^

jerry coffin's code is perfectly valid, and may be the expected way to
access some hardware resource.

Any byte-array acces in java is a subject of boundry check indeed. However,
a cgi dll attached to a WEB sever is located in its address space. The
option for unlimited memory access, enabes your to fail the server
(unintentionally). As a designer, I will choose a tool that allows me to
accomplish faster (C/C++ compilers are slow, stupid and produce code often
slower than say Delphi compiler). Java sandbox targets reliable modules
which cannot distroy the rest of the system. Furthermore, Java allows for
exceptions which when not handeled show you a sensible error message with
the line of source code caused the error. Which is not possible in the case
of unlimited memory access (you get mem access violation dialog, don't
you?). These consiferations are often more preferred over direct memory
access in the modern SW design, espesially enterprise programming.

uh huh. i don't program the enterprise, i just make sure she has enough
power, sir. boudary checks sound nice on paper, but if you can't turn
them off, they are a problem. anything that gets between you and the
hardware and refuses to move when you need it to is a problem. this is
not opinion, this is common sense.

being able to actually access console hardware and make it do stuff is
more preferred over the other consiferations you mentioned in my little
multi-billion dollar corner of SW enterprise.

So, my point is that C/C++ programmers are convinced they are best operating
on pointers. What is a problem to write that line of code in, say Pascal?
TurboPascal even defines a special word for accessing abolute mem locations:
var screen: array[0..N] of byte absolute $A000:$C000;

good for pascal. can java do it?

Finally, ANY memory access (say assigning a variable) is direct memory
access. Furthermore, don't you know about java HW processors? How will you
access HW in a Java-bytecodes-only system?
Real-time Low-power Java Processor aJ-100
http://www.systronix.com/jstamp/reality.htm

no sir, not every memory access is direct memory access. in fact, few of
them are these days. when you do an allocation in windows and it returns
memory address 0x12345678, do you seriously think that any variable you
put in there will actually be at physical address 0x12345678 on your ram
chip? if you allocate a variable at 0x10000004 in one process, then
another at 0x10000008 in another, do you seriously think that you could
add 4 to 0x10000004 in the first process and access the variable in the
second? honestly, people pay so much damn lip service to memory and
security, but few actually consider what they're talking about.

So, what is your point? Yes, Java is not only just a lang, it is a platform.
How do you implement a platform for C/C++ in these langs? I whould implement
HW in VHDL. Anyway, I can generate HW netlists in Java (manufacturing still
should be done on a factory).

first of all, you don't implement platforms for "c/c++", you implement c
and c++ compilers for platforms. or you implement platforms, then later
port a c++ compiler over.

second of all, you just write it. for the record, you could even
generate a c++ compiler and c++ programs for a system that uses java
bytecode-based hardware, ie, the "java platform".

but the problem isn't that either c++ or java is incapable of creating a
compiler, because they both are. the problem is that c++ compiles to
native code - even is that native code is cross-compiled - whereas java
only generates code for the java operating system.

consider this example. imagine you have two operating systems x and y. x
has both a c++ compiler and a java vm. y has neither. you have been
asked to write a text editor for y. you cannot accomplish this using java.

(aside1 - of course, if you had a java-to-native-code compiler you could
do it. but that would not be generating a java program, now would it?
not unless you also generated the entire vm and all required libraries.
and even if you argued that compiling native code from java was a
legitimate solution, last time i checked, native-ized java programs were
abysmal in size and performance.)

(aside2 - there *is* a way that you could even if you didn't allow for
the existence of a java-to-native-code compiler, but seriously, you
would never find anyone idiotic enough to suggest it. not for a text
editor at least.)

mark

 

[Mark A. Gibbs]

If the only thing the Java programmers are up to is an exponential-time
algorithm while the C++ people can come up with a logarithmic one, I
think this is a pretty reasonable approach! The point is, that people

actually, mr. kuehl, i think you're on to an interesting experiement to
put this to rest. instead of trying to warp the same algorithm into
wildly different languages, why not just come up with a few basic and
realistic design constraints and let the best programmers in each
language have a go at it on the same hardware?

for a simple example, let test 1 be finding all of the prime factors of
some reasonably large (ie, not too large) number, to be supplied at run
time. use any method you like in the language of your choice. timing
starts after the variable is read in, just before it is passed to your
algorithm, and ends after your algorithm has the result(s), if any,
before they are displayed. go nuts. show your work.

or how about, given an equation in 5 dimensions (w, x, y, z and t),
continuous through out the specified 2D range (say w, x, y and z are
(-1.0, 1.0)) and time domain (t from 0.0 to 100.0), calculate and render
in real time a 3D surface map using x, y and z as spatial co-ordinates
and w as a colour factor. specify a tesselation/sampling factor and
screen size. let constant coefficients be specified at run time.

or given a specified transfer function, open and read any specified
input file, translate the contents, and write the results to another
file. you can buffer, or whatever you want to do. just produce correct
results.

for best results, post test specifications and let users submit
solutions. run all solutions, restarting the maching each time and
running each test "virgin" and list the top results for each
language/compiler/whatever.

the result will no longer be reasonably dismissable because the test
author was biased towards/experienced in one language. you should get a
fair idea of the real runtime difference between implementations and/or
the quality of the programmers.

hasn't this ever been done?

mark

 

[Jack Klein]

Not this sub/super set topic of C/C++ again...

Let's face it, for some it is easier to consider C++ a (loose) superset of C,
even though it isn't (although it *once was*) a well-defined 100% superset.

For others, well, I don't know what they call C++ in relation to C, and yes,
there is a well-defined relationship between the two.

Too bad there isn't a term for a superset that encompasses 95+%... Well,
unless someone has a better suggestion, I'm proposing that C++ be called a
'colloquial superset' of C, if the C/C++ set relationship is being discussed.

So:

- C++ is not a mathematical superset of C.

- C++ is a colloquial superset of C.

- Bjarne's discussion on the set/superset nature of C++ in the quote
referenced above is incomplete, unclear, and subject to dissension because of
the strict interpretation of the (implied mathematical) definition of a set.

Just for the record, there is a large common subset of code that can
be compiled as either C or C++ and produce identical results when
executed, barring compiler or library defects of course.

ISO C++ included a fairly large percentage of ISO C95 in this common
subset, but C has not stood still. Almost all of the new features of
ISO C99 are outside of this common subset.

C++ does not have, at least as yet:

- variable length arrays

- long long data type

- new meaning for keyword static in array parameters

- restrict type qualifier

....and many others.

 

[Jerry Coffin]

I've heard such silly statements only from narrow-minded C/C++ programmers.

Apparently you spend too much time talking to hear yourself think.

[ ... ]

You don't make sense here.

You clearly haven't read it carefully yet -- or simply have serious
problems with reading comprehension.

C++/Java are not the best candidates for real-time programming indeed. But
real-time system and OS are different notions.

I hadn't mentioned real-time programming, though it's also an example
of something for which you can't really use Java. One of the tenets
of Java is that properly written Java works correctly on ALL
implementations. Since some implementations clearly can't achieve
real-time response, you can't do it in Java even if some do.

C++ is a whole different story: while it takes some discipline to
write real-time code in C++ (as it does in any other language) there's
nothing whatsoever to prevent it. It is true that real-time code is
typically different from other code, but (again) that's largely true
regardless of language.

Any program can be accomplished using memory-access only (ports and
special machine instructions are rate). What is the definition of "complete
program"?

It's more or less irrelevant because it's trivial to show all sorts of
things that Java (on its own) can't do. I've already pointed out a
couple of them, so trying to nit-pick about the definition is
pointless.

I was asked not to call you C programmers but this is C code. It will fail
executing on a modern OS.

The whole point being discussed here was _writing_ an OS. When you're
writing the OS, you get to do anything the _hardware_ allows. More
importantly, if you want any program ON the OS to be able to do that
thing, the OS has to provide for it somehow.

I wouldn't bring you up personally, except that you did so yourself: I
find it easy to believe that your fellow Java programmers don't wany
you "to call" C programmers on anything -- the muddle-headed thinking
that leads to believing the OS is going to prevent something when the
OS implementation itself is what's being discussed is undoubtedly an
embarassment to them. While I think Java has shortcomings in some
situations, your attempts at defending it make it seem much worse than
it really is.

Any byte-array acces in java is a subject of boundry check indeed. However,
a cgi dll attached to a WEB sever is located in its address space.

We're talking about implementing the OS -- which can't depend upon the
web server, CGI DLL (or any other kind of DLL), etc. Rather the
contrary, the web server, the CGI implementation (in a DLL, shared
library, or whatever) depends on the code under discussion. For that
matter, "DLL" is a concept restricted to one particular family of
OSes, and there's nothing to require that an OS have anything to do
with CGI at all -- in fact, quite a few have no use for CGI or web
servers, or anything similar at all.

The option for unlimited memory access, enabes your to fail the server
(unintentionally). As a designer, I will choose a tool that allows me to
accomplish faster (C/C++ compilers are slow, stupid and produce code often
slower than say Delphi compiler). Java sandbox targets reliable modules
which cannot distroy the rest of the system.

The question at hand had nothing to do with what was advisable for
given purposes, and was instead related to whether one language
provided capabilities absent in the other.

OTOH, given your inability to grasp such simple concepts, I have to
agree with your apparent choice: I'd certainly never run any code
you'd written without something to protect me from it.

Furthermore, Java allows for
exceptions which when not handeled show you a sensible error message with
the line of source code caused the error.

If Java honestly mandates showing source code to end users if there's
an exception, then Java has even worse problems than I realized. I can
hardly imagine that's the case, though and for the sake of anybody
stuck using Java code, I sincerely hope you're wrong.

If you're only talking about what happens during development when you
have source code handy, then this is merely a bare minimum necessary
to make Java reasonably competitive with the usual implementations of
most other languages.

Which is not possible in the case
of unlimited memory access (you get mem access violation dialog, don't
you?).

Neither C nor C++ normally circumvents access restrictions placed by
the environment in which they run -- i.e. if there's unlimited access,
it's because they're running without an underlying OS (e.g. in the
code that implements parts of the OS itself). The diagnostics (if any)
provided in such a situation will depend on what you choose to
implement.

Running C or C++ code in a typical development situation, if you
attempt to access inaccessible memory, you'll land in the debugger at
the line that caused the problem, with a message telling you what
happened. Details of things like the quality of the debugger vary --
just for example, I find gdb's messages less readable than most
others.

These consiferations are often more preferred over direct memory
access in the modern SW design, espesially enterprise programming.

I guess the "consiferations" that are "often more preferred" amount to
valuing programmer time over the efficiency of the final result (or
something on that order). For this to favor Java, you have to start by
showing that (for example) programing in Java provided greater
productivity. I've read many studies on programmer efficiency, but all
I've seen so far have failed to show that.

So, my point is that C/C++ programmers are convinced they are best operating
on pointers.

That sentence isn't even grammatical, not to mention sensible.

What is a problem to write that line of code in, say Pascal?

The obvious problem is that Pascal won't allow it. Perhaps you should
learn the distinction (a major one) between "Pascal" and "Turbo
Pascal".

TurboPascal even defines a special word for accessing abolute mem locations:
var screen: array[0..N] of byte absolute $A000:$C000;

More accurately, SOME versions of Turbo Pascal do so -- others
(admittedly rather old ones) would reject this as a syntax error.

In any case, while it's true that Turbo Pascal provides such access on
a PC, I'm reasonably certain that Turbo Pascal was never available for
the PDP-11, VAX, PowerPC, Alpha, MIPS, ARM, SPARC, etc. I've written
low-level software for all of these and more besides. Java's
theoretically portable, but at the expense that it simply wouldn't
support what I needed at all. Turbo Pascal might have supported most
of what I wanted on PCs, but never would have worked at all on the
others. For the VAX (for example) there was UCB Pascal if you ran
UNIX, but (at best) it would require different syntax to do the job
(and it certainly did NOT compile faster than C -- in fact, it
produced C as its output...)

In any case, Turbo Pascal isn't Java. Your having to resort to Pascal
more or less proves that you realize that (as originally stated) some
of what can be done in C or C++ simply can't be done in Java at all.

Finally, ANY memory access (say assigning a variable) is direct memory
access.

Not true -- in Java on a typical machine, the assignment is done with
a Java byte-code, which is intepreted by the Java machine which does
the actual memory access on behalf of the original code.

IOW, the Java code itself clearly has only INdirect access to the
memory. A definition of "direct" that supports your contention that
this is direct access needs to basically define "direct" to mean "not
necessarily direct", IOW rendering the term utterly meaningless.

Furthermore, don't you know about java HW processors?

Consider that I mentioned them in my post, and try to figure out how I
could have done that if I'd never heard of them.

How will you access HW in a Java-bytecodes-only system?

About the same as usual. I've yet to see a Java processor that did all
the range checking and such in hardware. There's no particular
difficulty in compiling C++ with Java byte-codes as the target. IOW,
as far as code in C or C++ cares, Java byte codes are just another
machine language, differing only in details from the more common
processors.

Real-time Low-power Java Processor aJ-100
http://www.systronix.com/jstamp/reality.htm

This is hardly original. In fact, Sun pushed MicroJava and PicoJava
cores almost from the very beginning of Java. For a while, they even
had a complete processor design (named something like Majic, IIRC) for
executing Java. To all appearances it was mediocre technically, and
there's little question that it was an utter flop in the marketplace
-- in fact, I'm reasonably certain none of the above was ever used in
a real product. About the only way you could figure that Sun might
have profited from it is if you figure that the time spent on this was
harmless, and otherwise those people might have been causing active
harm to something else.

If you're looking for a low-power processor that executes Java in
hardware, I'd advise looking into an ARM with Jazelle.

[ ... ]

So, what is your point? Yes, Java is not only just a lang, it is a platform.
How do you implement a platform for C/C++ in these langs?

The whole point is that you don't have to -- C and C++ are designed so
they can target almost any hardware.

I whould implement HW in VHDL.

How you'd implement hardware is thoroughly irrelevant at very best.

Anyway, I can generate HW netlists in Java (manufacturing still
should be done on a factory).

That brings up an interesting thought: since you want us to believe
that Java is just as fast as C or C++, do this: write a tool in Java
that competes directly with PSpice, and show us how fast it is. This
is an area that Java _could_ do the job, and it's one where
performance really does matter -- even on the fastest machines
available, PSpice simulations can take a LOT of time.

So, stop blaming java, it is much more effective for modern
desktop/enterpricse programming that C/C++. I would still prefer
structural/functional c/pascal to asm/oop writing for real-time tiny micros.

I haven't blamed Java for anything, but if you honestly want to show
us it's as effective as C or C++, show us your tool that does analog
simulations as well as PSpice.

 

[Alex Vinokur]

Interesting. I heard good things about the Intel compiler, so I
downloaded a demo and compiled my code with it (simulation, physics,
lots of object creation/destruction). And I found the code generated by
Intel to be 10% slower than that from GCC 2.95. That was one year ago.
Of course, I used the maximum machine specific optimization flags on
both compilers.

See "C++ Compilers' Comparative Performance":
* Copying files
http://article.gmane.org/gmane.comp.lang.c++.perfometer/38
* Computing very long Fibonacci numbers
http://article.gmane.org/gmane.comp.lang.c++.perfometer/37

 

[Dietmar Kuehl]

actually, mr. kuehl, i think you're on to an interesting experiement to
put this to rest. instead of trying to warp the same algorithm into
wildly different languages, why not just come up with a few basic and
realistic design constraints and let the best programmers in each
language have a go at it on the same hardware?

Well, I didn't volunteer to specify such a benchmark. I merely outlined how
the benchmark looks like somebody else was talking off. If someone sets up
a benchmark like this and the C++ results show mediocre results, I would
certainly kick and see how to solve the respective problem time efficiently.

for a simple example, let test 1 be finding all of the prime factors of
some reasonably large (ie, not too large) number, to be supplied at run
time. use any method you like in the language of your choice. timing
starts after the variable is read in, just before it is passed to your
algorithm, and ends after your algorithm has the result(s), if any,
before they are displayed. go nuts. show your work.

Is this sort of task typical for Java programs? It is not for C++ programs.
In the C++ I'm writing I tend to deal with more complex objects than
integers.

for best results, post test specifications and let users submit
solutions. run all solutions, restarting the maching each time and
running each test "virgin" and list the top results for each
language/compiler/whatever.

the result will no longer be reasonably dismissable because the test
author was biased towards/experienced in one language. you should get a
fair idea of the real runtime difference between implementations and/or
the quality of the programmers.

hasn't this ever been done?

There is another twist to it: it should also be possible to submit benchmark
specifications, e.g. to highlight specific strength of a certain approach to
the solution. Of course, such an objective measure would take all the fun
out language flame wars...

 

[valentin tihomirov]

Have a look at the algorithms in the
standard C++ library to get an idea what I'm talking off. For a more
intriguing example, have a look at the Boost Graph Library (see
<http://www.boost.org/>). Stuff like this is impossible on the basis of
Java generics.

Could you please refer me to hash_set demo example? I understand, I will
need to define some hash-code generator and equality comparitor. The
structure to be stored has an integer field, retreiving an element by
integer will be needed.

 

[Karl Heinz Buchegger]

Could you please refer me to hash_set demo example? I understand, I will
need to define some hash-code generator and equality comparitor. The
structure to be stored has an integer field, retreiving an element by
integer will be needed.

There is no such class like hash_set in the Standard Library.

But when you are at it, why don't you use the WEB to locate what
you are looking for?

http://www.google.com
Search phrase: hash_set C++ example

The 7-th hit seems like what you are looking for.

 

[Dietmar Kuehl]

Could you please refer me to hash_set demo example? I understand, I will
need to define some hash-code generator and equality comparitor. The
structure to be stored has an integer field, retreiving an element by
integer will be needed.

Apparently you do not understand what these libraries are all about (no
offense here: many people fail to see what Generic Programming is about):
the containers are just one part, the unimportant one. I don't know which
hash_set you are using (the standard library actually does not [yet] ship
with one) and I don't care too much about containers. The point is that
algorithms operate on all appropriate data structures, independent on
whether they come from the standard library, are user defined, or whatever.
Actually, it is even possible to use the algorithms with data structures
which were never intended to be used with the algorithms. The algorithms
in the standard C++ library are relatively simple but the same technique
can be applied to more complex algorithms like the graph algorithms from
the BGL.

 

[Julie]

So when was it that C++ had no extra keywords?

?? C++ has always had extra keywords compared to C.

 

[Julie]

When was this?

Brian Rodenborn

In the very beginning when C++ was implemented as a front-end preprocessor that
output C code to a C compiler.

 

[valentin tihomirov]

I do not know much about standard library, I was shure, MS programmers know:
http://msdn.microsoft.com/library/d...s/vcstdlib/html/vclrfhash_set_header_file.asp


I know what are templates. I just have not much experiance and have no ideas
how to implement equality function (int i, srtuct{int j}). As it it stated
on http://www.sgi.com/tech/stl/BinaryPredicate.html , the params of Binary
Predicate should not be homogeneous. I worry about in which position of the
binary predicate will the container put contained element and the key when
calling find(key). I keep in mind that equality should be symmetric.

 

[E. Robert Tisdale]

http://www.sys-con.com/story/print.cfm?storyid=45250

Any comments?

Congratulations on your fantastic troll.
54 responses and counting.
You'd think that subscribers to the comp.lang.c++ newsgroup
would have learned to recognize a troll by now
but you seem to have caught several of our most wary subscribers.

 

[tom_usenet]

?? C++ has always had extra keywords compared to C.

And hence has never been a well-defined superset of C, contrary to
your earlier comment that I've highlighted for clarity. Unless you
have an unusual definition of "well-defined 100% superset" that you'd
like to share?

Tom

 

[Default User]

In the very beginning when C++ was implemented as a front-end preprocessor that
output C code to a C compiler.

C with classes wasn't C++.

I don't believe any version of C++ allowed the following:


#include <stdio.h>


int func();

int main()
{
func(2);
return 0;
}


int func(a)
int a;
{
printf ("%d\n", a);
return a;
}



Brian Rodenborn

 

[Default User]

C++ is a whole different story: while it takes some discipline to
write real-time code in C++ (as it does in any other language) there's
nothing whatsoever to prevent it. It is true that real-time code is
typically different from other code, but (again) that's largely true
regardless of language.

I certainly hope so, our project has been writing real-time embedded
software in C++ for a number of years now.



Brian Rodenborn

 

[tom_usenet]

C with classes wasn't C++.

I don't believe any version of C++ allowed the following:

Or, crucially:

int class;

Tom

 

[JKop]

The following is C:

int Gan(); /*Any number of arguments*/

int Gan(void); /*No arguments*/



The following is C++:

int Gan(); //No arguments

int Gan(void); //No arguments

int Gan(...); //Any number of arguments



The above is the reason why I myself always write:

int main(void);

....I like to be specific.



-JKop

 

[Julie]

C with classes wasn't C++.

CFront, the first C++ compiler initially output C code:

http://www.research.att.com/~bs/bs_faq.html#bootstrapping

 

[Julie]

And hence has never been a well-defined superset of C, contrary to
your earlier comment that I've highlighted for clarity. Unless you
have an unusual definition of "well-defined 100% superset" that you'd
like to share?

I don't know what C++ having extra keywords over C implies that C++ isn't a
superset --

As I responded in a previous thread, originally CFront was essentially a
preprocessor that output C code. Unless CFront specifically restricted allowed
C constructs (I don't know the answer), C++ was a well-defined (complete)
superset of C.

Honestly, the minutiae of the super/subset argument of C++/C really doesn't
have any value. Conversationally (colloquially) speaking, C++ is a superset of
C. Exactly speaking, it currently isn't.