By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,933 Members | 1,243 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,933 IT Pros & Developers. It's quick & easy.

Java's performance far better that optimized C++

P: n/a
Share this Question
Share on Google+
133 Replies


P: n/a

"Gaurav" <ga********@yahoo.com> schrieb im Newsbeitrag
news:71**************************@posting.google.c om...
http://www.sys-con.com/story/print.cfm?storyid=45250

Any comments?

Thanks
Gaurav


Huhuhu-hahaha...
Java faster ...haha... than C++ ...ha-hahaha...

First of. If you take a close look at the language features you will
see that you can do everything you do in Java in C++ but not vice
versa. Next, if you "optimize" code by the compiler it can't become
any better than the crappy C++ you provide. So, if you want to really
compare the 2, you should get 2 professional prograamers for each
language and let each one do the way their language requires doing.
Next, gcc 3.3 is not really a good optimizing compiler. Better than
2.95, but not as good as say the intel or the codewarrior compilers.
But for a wednesday mornig, a good joke, thank you.

-Gernot
Jul 22 '05 #2

P: n/a
The code in Java cannot be any faster than in C++, because with C++ the
generated code is practically 100% optimal, provided that the program is
written with it in mind, and the compiler is good. And there are good
compilers out there.

Best regards,
Marcin
Jul 22 '05 #3

P: n/a
On 16 Jun 2004 00:45:02 -0700, ga********@yahoo.com (Gaurav) wrote:
http://www.sys-con.com/story/print.cfm?storyid=45250

Any comments?


Whenever I look at inter-language benchmarks in detail, I always find
a flaw in the benchmarking for one language or the other (and often
both), generally based on the author's bias (they generally have
greater expertese in one language than the other).

In the benchmarks you've posted, the compiler options provided to GCC
are sub-optimal, and no functions seem to have been declared inline.
For example, many of the tests would benefit from loop unrolling,
which only happens on -O3 I think. Some of the benchmarks are also
highly synthetic (they don't really do anything except try to bombard
a particular language feature in a way that never happens in a real
program). It's better to set a required output for the input, and then
let the program achieve that output however it wishes to, balancing
code clarity with optimization.

Incidently, I got the fibonacci test down to around 0.1 seconds using
this simple code:

unsigned long fib(unsigned long n) {
unsigned long last = 1;
unsigned long current = 1;
for (unsigned long i = 2; i <= n; ++i)
{
unsigned long newCurrent = last + current;
last = current;
current = newCurrent;
}
return current;
}

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Jul 22 '05 #4

P: n/a
Gaurav wrote:
http://www.sys-con.com/story/print.cfm?storyid=45250

Any comments?


LoL, the guy who wrote that knows absolutely nothing about benchmarking.

br
db
Jul 22 '05 #5

P: n/a
Gaurav wrote:
http://www.sys-con.com/story/print.cfm?storyid=45250

Any comments?


Those tests expose one regularity - the examples where OS support is
extensively used are slower than those where the entire code in
performed in process space. Performance of the former suffers from
user/kernel mode switching and if it is done at least once per loop
iteration the impact must be pretty visible.

So all C++ examples with extensive heap or stack (function calls) memory
allocation must be slower than corresponding Java examples where similar
functionality is performed by the JVM directly in the user process space
(Fibonacci, hash, object creation).

Of course if one is ready to pay with slower startup and bigger memory
consumption then he/she may can have the same in C++ using inlining,
memory pool and other commonly used techniques.

When such handicaps are not introduced (nested loop, random numbers) C++
performs faster as expected.

One thing surprised me. For the reason described above I expected the
method call example to be slower in any case in C++ than in Java, then
after looking at the code it appeared that all member functions were
coded inline and at least some of them were optimized away by the
compiler. So this test does not fulfil its goal. The other ones also
introduce some unnecessary temporary variables etc. and should not be
used as representative C++ code.
Regards,
Janusz
Jul 22 '05 #6

P: n/a

"Gaurav" <ga********@yahoo.com> wrote in message
news:71**************************@posting.google.c om...
http://www.sys-con.com/story/print.cfm?storyid=45250

Any comments?


I was recently part of a team that rewrote an largish C++ app in Java. No
question that for this application the Java version was slower than the C++
version. No doubt the Java version had some advantages (platform
independence for instance) but it was slower and noticeably so.

john
Jul 22 '05 #7

P: n/a
Gaurav wrote:
http://www.sys-con.com/story/print.cfm?storyid=45250

Any comments?


In general, you can find arguments to many unfounded things. Weather
this is correct (which I doubt) or not is irrelevant most of the time.

Don't worry about it unless you need to.

Barely related question.

How many of you guys actually work on projects in which performance is
critical? (Something written in Java is unacceptable)

I see value in both languages, however, it appears as though many people
immediately dismiss Java, regardless of the scope and requirements of
the project.

JLR
Jul 22 '05 #8

P: n/a
How many of you guys actually work on projects in which performance is
critical? (Something written in Java is unacceptable)


When you write a conventional user application for a multitasking system,
your program should accomplish its tasks as fast as possible. Therefore, we
are commited to deliver the fastest software ever. 0.01ms vs. 0.1ms responce
on user button click is much more important for us as opposed to development
time. Therefore, we write huge number of code lines and ignore impressing
IDEs like Intellij Idea and go on wasting our time and writing unreliable
code in order to deliver the best performance. Slow C++ compiler does lots
of things for us including and compiling huge files.
Jul 22 '05 #9

P: n/a
Gernot Frisch wrote:

you will see that you can do everything you do in Java in C++ but not viceversa.


So there are something that may be do in C++ and not in Java?
Interesting...

Please give me your curriculum, so I can hire you in my company!

- Dario
Jul 22 '05 #10

P: n/a
So there are something that may be do in C++ and not in Java?


writing an OS ( Kernel ) ?
Jul 22 '05 #11

P: n/a
Jorge Rivera wrote:
[...]
How many of you guys actually work on projects in which performance is
critical? (Something written in Java is unacceptable)
In every application (unless it's a really simple one) there are critical
parts where performance is paramount. Whether performance takes front
seat in that case is up to the managers. I've worked on systems where
performance-critical parts were written in C++ (and the rest in Java) and
where everything was required to be written in Java (and the performance-
critical parts were licked out as good as it gets in Java).
I see value in both languages, however, it appears as though many people
immediately dismiss Java, regardless of the scope and requirements of
the project.


"All generalisations are wrong" -- unknown author. You would have to
put some numbers showing what you mean by "many". Is 10 out of 100000
-- many? IOW, how many is "many"? During my career I've never seen or
spoken to anyone who'd "immediately dismiss Java". And, believe me,
I've spoken to _many_.

V
Jul 22 '05 #12

P: n/a
Rainer Hausbach wrote:
So there are something that may be do in C++ and not in Java?


writing an OS ( Kernel ) ?


The "Church Thesis" or "Turing-machine-computable" or ...
.... means anything to you?

- Dario
Jul 22 '05 #13

P: n/a

"Gaurav" <ga********@yahoo.com> wrote in message
news:71**************************@posting.google.c om...
http://www.sys-con.com/story/print.cfm?storyid=45250

Any comments?

Thanks
Gaurav


Have you seen the size of the programs he is running? This is no
comparison, as the JVM may be much faster since the environment is already
loaded into memory. If he was medium to large scale projects, I would be
more keen to read the results.
Allan
Jul 22 '05 #14

P: n/a
> >> So there are something that may be do in C++ and not in Java?

writing an OS ( Kernel ) ?
The "Church Thesis"


nope.
or "Turing-machine-computable" or ...
... means anything to you?
partially (that's the way lots of cpu's work)


so please:
-verbose

TIA
Rainer
Jul 22 '05 #15

P: n/a
> So there are something that may be do in C++ and not in Java?
Interesting...

Please give me your curriculum, so I can hire you in my company!


Well, how about:

long a, b, double c;
memcpy(&c, a, 4); memcpy(&c+4, b, 4);

or:

template <class T> T& min(T &tParam1, T &tParam2) ...

or:
#ifndef DONT_WANT_THIS
gagagugu
#endif

Jul 22 '05 #16

P: n/a
In article <2j************@uni-berlin.de>,
"Gernot Frisch" <Me@Privacy.net> wrote:
Next, gcc 3.3 is not really a good optimizing compiler. Better than
2.95, but not as good as say the intel or the codewarrior compilers.


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.
Jul 22 '05 #17

P: n/a
> 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.


I use the GCC 3.4 vs the VS.net 7.1 compiler (which is from intel I
think) and it gives me you experience in reverse...
Maybe this is an ethic question? :)

-Gernot
Jul 22 '05 #18

P: n/a
I use the GCC 3.4 vs the VS.net 7.1 compiler (which is from intel I
think) and it gives me you experience in reverse...
Maybe this is an ethic question? :)


VC++ compiler is from Microsoft and Intel C++ compiler is from.. well,
obviously Intel.
Jul 22 '05 #19

P: n/a
In every application (unless it's a really simple one) there are critical
parts where performance is paramount.
An here is the contradction: "All generalisations are wrong" -- unknown author. You would have to
put some numbers showing what you mean by "many". Is 10 out of 100000
-- many? IOW, how many is "many"?
During my career I've never seen or
spoken to anyone who'd "immediately dismiss Java". And, believe me,
I've spoken to _many_.


I did. All of them are VC++ programmers.
Jul 22 '05 #20

P: n/a

"Rainer Hausbach" <R.********@d-offline.de> wrote in message
news:ca**********@mail1.sbs.de...
So there are something that may be do in C++ and not in Java?


writing an OS ( Kernel ) ?


You, C programmers cannot imagine that C is just one of general purpose
programming languages. It is far from the perfect, dealing with "include"s
we get huge problems with scopes and compilation time takes 1000 times
longer than say Pascal. You console oneself that bad structure of C lang and
slow compiler lead to more optimal code. In fact, kernel can be written in
any general purpose language. The is nothing against laws of the Nature.

In fact, I yould agree with origianl poster, there is one thing. OOP
programming (dynamic memory allocation) enforced by garbage collection makes
it hard to build real-time systems due to non-deterministic responce times.
Jul 22 '05 #21

P: n/a

"Rainer Hausbach" <R.********@d-offline.de> wrote in message
news:ca**********@mail1.sbs.de...
So there are something that may be do in C++ and not in Java?


writing an OS ( Kernel ) ?


What about running java (bytecodes) natively? Haven't heard about it?
http://www.systronix.com/jstamp/reality.htm
Jul 22 '05 #22

P: n/a
> > So there are something that may be do in C++ and not in Java?
Interesting...
long a, b, double c;
memcpy(&c, a, 4); memcpy(&c+4, b, 4);
byte[] a = new byte[100];
byte[] b = new byte[100];
System.arraycopy(a, 0, b, 0, 100);

or:

template <class T> T& min(T &tParam1, T &tParam2) ... You may wonder but since java 1.5 there is support for generics.

or:
#ifndef DONT_WANT_THIS
gagagugu
#endif


Remember that java is a multiplatform enviroment thus constructs like these
never bloat your code:
#ifndef cpp_precompiler_sucks_on_Win
aaa
#endif

Use natural constructions like.
If (false) { }
Any good compiler will optimize unused code out. (I know that C
compiler+precompiler) have many things to do besides compilation.

What about such inveronments like Intellij? I don't like idea writing
programs in Visual notepad in 21st century. C++ will never have such one.
C++ will always get problems with includes, slow compilers and unresolved
references. I hate the idea when compiler cannot show me errorous line of
code. IntelliJ checks synthax yet while you're typing, completes reference
to not imported elements.
Remember, a good programmer writes a good program in C++ and Java. Bad
programmer writes bad programs on C+ and Java. Both make faster on
developer-friendly in Java. C++ will never evelove into something friendly
like Delphi/Java langs/environments.
The most important point, JAVA DOES NOT HAVE INCLUDES!!
Jul 22 '05 #23

P: n/a
Rainer Hausbach wrote:
So there are something that may be do in C++ and not in Java?

writing an OS ( Kernel ) ?


The "Church Thesis"


nope.
or "Turing-machine-computable" or ...
... means anything to you?


partially (that's the way lots of cpu's work)

so please:
-verbose


Every program you can write in C or C++ may be written
in any other-language that can emulate a Turing-machine
(Cobol, Fortran, APL, PL/!, Algol, Ada, Pascal, Java, C#, etc...).

- Dario
Jul 22 '05 #24

P: n/a
Gernot Frisch wrote:
Well, how about:

long a, b, double c;
memcpy(&c, a, 4); memcpy(&c+4, b, 4);

or:

template <class T> T& min(T &tParam1, T &tParam2) ...

or:
#ifndef DONT_WANT_THIS
gagagugu
#endif


C sintactic sugar!

Every program you can write in C or C++ may be written
in any other-language that can emulate a Turing-machine
(Cobol, Fortran, APL, PL/!, Algol, Ada, Pascal, Java, C#, etc...).

- Dario
Jul 22 '05 #25

P: n/a
On Wed, 16 Jun 2004 19:48:28 +0300, "valentin tihomirov"
<va*********************@abelectron.com> wrote:
> So there are something that may be do in C++ and not in Java?
> Interesting...
long a, b, double c;
memcpy(&c, a, 4); memcpy(&c+4, b, 4);


byte[] a = new byte[100];
byte[] b = new byte[100];
System.arraycopy(a, 0, b, 0, 100);

or:

template <class T> T& min(T &tParam1, T &tParam2) ...

You may wonder but since java 1.5 there is support for generics.


It's very basic compared to C++ templates.
What about such inveronments like Intellij? I don't like idea writing
programs in Visual notepad in 21st century. C++ will never have such one.
C++ will always get problems with includes, slow compilers and unresolved
references. I hate the idea when compiler cannot show me errorous line of
code. IntelliJ checks synthax yet while you're typing, completes reference
to not imported elements.
I use IntelliJ, and I agree that it would be very hard to produce a
similar IDE for C++. The CDT project in Eclipse is proving this I
think...
The most important point, JAVA DOES NOT HAVE INCLUDES!!


Modular languages do make writing good IDEs for them much easier. Java
has other problems though, of course, mostly memory usage, start-up
time and performance related.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Jul 22 '05 #26

P: n/a
> I use the GCC 3.4 vs the VS.net 7.1 compiler (which is from intel I
think) and it gives me you experience in reverse...
Maybe this is an ethic question? :)


Some time aho I was inspecting machine code generated by Intel compiler.
Although the compiler did so called "profile based optimizations", it
sometimes failed to apply some some simpler optimizations, like loop
unrolling or use of CPU string instructions. Visual C++ .NET code was
performing significantly faster, although without profile based
optimizations.

Best regards,
Marcin
Jul 22 '05 #27

P: n/a
valentin tihomirov wrote:
"Rainer Hausbach" <R.********@d-offline.de> wrote in message
news:ca**********@mail1.sbs.de...
So there are something that may be do in C++ and not in Java?


writing an OS ( Kernel ) ?

You, C programmers [...]


We're C++ programmers, please do not confuse the two.
Jul 22 '05 #28

P: n/a
valentin tihomirov wrote:
[...]
Remember that java is a multiplatform enviroment [...]
That's a very common newbie misconception. Java _is_ a platform.
And constructs like
#ifdef some_platform_or_other
...
don't bloat _my_ code. They bloat the code of the JVM, and the
necessity to run a JVM _always_ bloats the resulting program.
[...]
The most important point, JAVA DOES NOT HAVE INCLUDES!!


Another common misconception. What's Java's "import" if not
an include? Oh, wait, if it's not spelled "include", but is
spelled "import", it must be something entirely different... NOT!
Jul 22 '05 #29

P: n/a
> We're C++ programmers, please do not confuse the two.

C++ is a superset of C. Therefore, to be a valid C++ programmer you need to
be C programmer(neobhodimoe uslovie), OK? The most features of C++ I hate
are derived from C.
Jul 22 '05 #30

P: n/a
Gaurav wrote:
Comparisons with other languages are not topical in comp.lang.c++.


Brian Rodenborn
Jul 22 '05 #31

P: n/a

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:N1******************@dfw-read.news.verio.net...
valentin tihomirov wrote:
[...]
Remember that java is a multiplatform enviroment [...]
That's a very common newbie misconception. Java _is_ a platform.


- my computer is fast
- no, it is black.
True and false simultaneously. Java is a platform. It runs on multiple
platforms underlying.

And constructs like
#ifdef some_platform_or_other
...
don't bloat _my_ code. They bloat the code of the JVM, and the
necessity to run a JVM _always_ bloats the resulting program. The fact that java is a multiplatfom means it is a sigle platform and such
constructs are not useless in java. I'm not familiar with is the definition
of resulting program. Running is not any way more hard that just to extecute
another program.

[...]
The most important point, JAVA DOES NOT HAVE INCLUDES!!


Another common misconception. What's Java's "import" if not
an include? Oh, wait, if it's not spelled "include", but is
spelled "import", it must be something entirely different... NOT!


The problem is not in spelling, it is in the sence. At first, includes break
your code. Using C++ I've written a class that compiles without any errors.
Once imported, Im' getting compilation errors on the calss. With a STUPID
C++ compiler (after sloooowly analizing my source codes) it is extremely
hard to find source of error. The compiler whether does not jump to a line
produced the error or jumps to a syntactically correct piece of code.
The second problem is compilation time and worknig directory sizes which are
orders of magnitude slower/bigger . May be I'm mistaken associating these
fundamental problems of C to "include" but these problems merely do not
exist on compiles of langs not aware of "include".

BTW, Java's imports are similar to Delphi's units.
Jul 22 '05 #32

P: n/a
valentin tihomirov wrote:
We're C++ programmers, please do not confuse the two.

C++ is a superset of C. Therefore, to be a valid C++ programmer you need to
be C programmer(neobhodimoe uslovie), OK?


Not OK. And do not use the language others won't understand, OK?
The most features of C++ I hate
are derived from C.


It seems that the hate is muddying the waters for you. C++ is NOT
a superset of C.
Jul 22 '05 #33

P: n/a
On Wed, 16 Jun 2004 16:01:30 -0400, Victor Bazarov
<v.********@comAcast.net> wrote:
C++ is NOT a superset of C.


You are quite correct:

C++ is a "better C".

(quote from Bjarne Stroustrup)

Cheers,
--
Bob Hairgrove
No**********@Home.com
Jul 22 '05 #34

P: n/a
> > C++ is a superset of C. Therefore, to be a valid C++ programmer you need
to
be C programmer(neobhodimoe uslovie), OK?


Not OK. And do not use the language others won't understand, OK?
> The most features of C++ I hate
are derived from C.


It seems that the hate is muddying the waters for you. C++ is NOT
a superset of C.


Seems you're right, C isn't a subset of C++ in the strict mathematical
sense. But according to Bjarne Stroustrup:
http://www.research.att.com/~bs/bs_faq.html#C-is-subset :
C++ is as much a superset of ANSI C. The nagative attitude, opposition is
coming from irrationality of the languages and the fact that these ugly
langugages are dictated to the world (english belongs to this group).
Jul 22 '05 #35

P: n/a
On Wed, 16 Jun 2004 18:45:33 +0200, "Dario (drinking co?ee in the
o?ce)" <da***@despammed.com> wrote:
Well, how about:

long a, b, double c;
memcpy(&c, a, 4); memcpy(&c+4, b, 4);

or:

template <class T> T& min(T &tParam1, T &tParam2) ...

or:
#ifndef DONT_WANT_THIS
gagagugu
#endif
C sintactic sugar!

Every program you can write in C or C++ may be written
in any other-language that can emulate a Turing-machine
(Cobol, Fortran, APL, PL/!, Algol, Ada, Pascal, Java, C#, etc...).


Great, then we don't need any of those languages. To hell with
practicality, all we need is machine code.

--
Be seeing you.
Jul 22 '05 #36

P: n/a
tom_usenet <to********@hotmail.com> wrote in message news:<f3********************************@4ax.com>. ..
On 16 Jun 2004 00:45:02 -0700, ga********@yahoo.com (Gaurav) wrote:
http://www.sys-con.com/story/print.cfm?storyid=45250

Any comments?
Whenever I look at inter-language benchmarks in detail, I always find
a flaw in the benchmarking for one language or the other (and often
both), generally based on the author's bias (they generally have
greater expertese in one language than the other).


What is the flaw in this benchmark, other than not unrolling loops
(which is probably a big flaw)?

In the benchmarks you've posted, the compiler options provided to GCC
are sub-optimal, and no functions seem to have been declared inline.
For example, many of the tests would benefit from loop unrolling,
which only happens on -O3 I think.
Yes, -O2 doesn't unroll loops (-O3 doesn't either). The benchmarks
would have been more interesting if the -funroll-loops option was
used. But I think the results are still startling, considering that
Java is interpreted. Maybe the fault is with g++'s optimization.
It's better to set a required output for the input, and then
let the program achieve that output however it wishes to, balancing
code clarity with optimization.
This is not a valid way of benchmarking. To compare the performance,
you need to test the same algorithm coded in both languages. You
can't code a logarithmic time algorithm in C++ and an exponential-time
one in Java for the same problem and use the results to claim that C++
is faster.

Incidently, I got the fibonacci test down to around 0.1 seconds using
this simple code:

unsigned long fib(unsigned long n) {
unsigned long last = 1;
unsigned long current = 1;
for (unsigned long i = 2; i <= n; ++i)
{
unsigned long newCurrent = last + current;
last = current;
current = newCurrent;
}
return current;
}


But this is changing the algorithm. The benchmark algorithm was an
exponential-time algorithm; the one you've written is linear time.
There is a logarithmic-time algorithm as well, but you can't compare
that with the algorithm used in the benchmark. You would have to
compare the above code with the *same* algorithm, coded in Java. The
algorithm used in the benchmarks is well-known to be a particularly
bad one for generating Fibonacci numbers, but the point is moot. In
the benchmark, you have to test the same algorithm in both languages,
not a fast algorithm coded in C++ against a slow one coded in Java.

Regards,
Rajeev.
Jul 22 '05 #37

P: n/a
"Dario (drinking co?ee in the o?ce?)" <da***@despammed.com> wrote in message news:<ca**********@grillo.cs.interbusiness.it>...

[ ... ]
Every program you can write in C or C++ may be written
in any other-language that can emulate a Turing-machine
(Cobol, Fortran, APL, PL/!, Algol, Ada, Pascal, Java, C#, etc...).


That's not really true. It's true that an algorithm that can be
implemented in one Turing complete language can also be implemented in
any other Turing complete language. Implementing an algorithm,
however, is somewhat different from implementing a complete program or
(as was mentioned earlier) something like an OS.

Just for example, somewhere in the OS (hopefully in a device driver)
you need some code that simply displays things on the screen. In C or
C++ that's often quite trivial -- for example, on one popular
platform, some (non-portable) code like this:

int *screen = (int *)0xb80000;

will give you direct access to the machine's text-mode screen buffer.
It's not portable, but for the target hardware it works perfectly
well.

Java doesn't allow things like that. Direct access to the hardware
isn't portable in C or C++, but Java simply doesn't allow it at all.

In the end, there's another major problem: Java is defined as more
than a language. Even if you accept source code that's syntactically
identical to Java's, if you compile it directly to native machine code
(other than for a Java machine) what you have isn't Java anymore.

This means that attempting to implement a Java Virtual Machine in Java
leads directly to infinite recursion -- to work, it HAS to be written
in something else.

Turing was right, but his result means less than you seem to think it
does.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 22 '05 #38

P: n/a
X-No-archive: yes
"valentin tihomirov" <va*********************@abelectron.com> wrote...
> The most features of C++ I hate
are derived from C.
It seems that the hate is muddying the waters for you. C++ is NOT
a superset of C.


Seems you're right, C isn't a subset of C++ in the strict mathematical
sense. But according to Bjarne Stroustrup:
http://www.research.att.com/~bs/bs_faq.html#C-is-subset :
C++ is as much a superset of ANSI C.


Applying well known tactics of incomplete quotes, eh?
The nagative attitude, opposition is
coming from irrationality of the languages and the fact that these ugly
langugages are dictated to the world (english belongs to this group).


Aw, you poor sod, feeling oppressed and forced into using such ugly
languages like English and C++... I am so sorry for you... Get
a grip! If you don't like it, don't use it. Go flip a burger or
something.
Jul 22 '05 #39

P: n/a

Dario (drinking coffee in the office…) wrote:
you will see that you can do everything you do in Java in C++ but not
viceversa.

So there are something that may be do in C++ and not in Java?
Interesting...

Please give me your curriculum, so I can hire you in my company!


///////////////////////////////////////////////////////////////////////////
[answer 1 - fun stuff ^_^]

#include <iostream>

int main()
{
using namespace std;

goto start;

done:
return 0;

last:
cout << "completely backwards! ^_^" << endl;
goto done;

next:
cout << "run a program ";
goto last;

start:
cout << "let's see java ";
goto next;
}

///////////////////////////////////////////////////////////////////////////
[answer 2 - template metaprogramming]

#include <iostream>

template <int N>
class compile_time_factorial
{
public:
static const int return_value =
compile_time_factorial<N - 1>::return_value * N;
};

template<>
class compile_time_factorial<0>
{
public:
static const int return_value = 1;
};

#define factorial(n) compile_time_factorial<n>::return_value;

int main()
{
using namespace std;

cout << "\n!3 = " << factorial(3);
cout << "\n!4 = " << factorial(4);
cout << "\n!5 = " << factorial(5);

return 0;
}

///////////////////////////////////////////////////////////////////////////
[answer 3 - templates period, java generics suck]

#include <iostream>
#include <string>
#include <sstream>

template <typename T>
class numbers_only_writer
{
// Leave blank for build time error
// or implement string write(T const&); that throws an
// exception for a compiler time error
};

#define NUMBER_WRITER_CLASS(T) template <> \
class numbers_only_writer<T> \
{ \
public: \
static std::string write(T const& t) \
{ \
std::ostringstream str; \
str << t; \
return str.str(); \
} \
}

NUMBER_WRITER_CLASS(int);
NUMBER_WRITER_CLASS(float);
NUMBER_WRITER_CLASS(unsigned short);
// etc.

#undef NUMBER_WRITER_CLASS

template <typename T>
inline std::string number_only_write(const T& t)
{
return numbers_only_writer<T>::write(t);
}

int main()
{
using namespace std;

cout << "int write: " << number_only_write(2) << endl;
cout << "float write: " << number_only_write(3.14f) << endl;
cout << "unsigned short write: " <<
number_only_write(static_cast<unsigned short>(2)) << endl;
//cout << "char write (uh oh!): " << number_only_write('c') << endl;

return 0;
}

///////////////////////////////////////////////////////////////////////////
[answer 4 - create executables that cannot be trivially decompiled]

///////////////////////////////////////////////////////////////////////////
[answer 5 - tell me what's in my cpu's edx register]

///////////////////////////////////////////////////////////////////////////
[answer 6 - write device drivers]

///////////////////////////////////////////////////////////////////////////
[answer 7 - run a reasonably interesting game on my gba]

i'll pass on that job offer, though. from what you've demonstrated of
the level of technical expertise there, i'm afraid it won't be around
long enough for me to make the walk over.

indi

Jul 22 '05 #40

P: n/a

Gernot Frisch wrote:
So there are something that may be do in C++ and not in Java?
Interesting...

Please give me your curriculum, so I can hire you in my company!

Well, how about:

long a, b, double c;
memcpy(&c, a, 4); memcpy(&c+4, b, 4);

or:

template <class T> T& min(T &tParam1, T &tParam2) ...

or:
#ifndef DONT_WANT_THIS
gagagugu
#endif


sorry dude, i think you blew it on all three counts. java _can_
technically do both of the first two things, albeit not as efficiently
as c++. especially java generics (which they are very careful not to
call templates, because they are not really). when you create the java
equivalent of template <typename T> class vector, it actually generates
a vector of Object's (that is, a vector of java.lang.Object objects),
and at runtime silently converts whatever you pass it - even integral
types such as int (!) to and from polymorphic descendants of Object.
thus it appears to be a template type, when in reality, it's just a
vector of base class pointers with methods that return and accept only
objects of type T (and its descendents).

as for the last, the java language specification allows the compiler to
strip dead code:

if (false)
{
// this whole block is stripped
}

i cannot recall whether this is common behaviour or required behaviour,
but i believe it is required. thus, you get hackish conditional compilation.

what's really odd is the recently added assert statement. you heard me:
assert STATEMENT.

you use an assert like this:

assert some_test();

or you can specify a message:

assert some_test() : "Message on assertion fail";

on an assertion failure, an exception is thrown. you can theoretically
catch that exception, handle it, and keep on chugging.

what's even weirder is that assertions are not compiled away in a
"release" build. you compile one way every time, and enable or disable
assertions through a command line switch to the vm.

what that means is that an assertion statement actually contains a
runtime check to see if assertions are enabled. if they are, then the
test is run. in other words:

assert some_test() : "Message on assertion fail";

is actually:

if (assertions_enabled_)
{
if (some_test())
{
throw new AssertionError("Message on assertion fail");
}
}

so even if assertions are disabled, there is a performance penalty to
using them. even if the surrounding block is never entered, you pay the
memory cost. and this is a bloody assert.

tell me again that java is faster than c++ ^_^

indi

Jul 22 '05 #41

P: n/a

valentin tihomirov wrote:
During my career I've never seen or
spoken to anyone who'd "immediately dismiss Java". And, believe me,
I've spoken to _many_.

I did. All of them are VC++ programmers.


vc++ programmers? well hell, there's your problem right there.

*duck and run*

indi

Jul 22 '05 #42

P: n/a
Dario (drinking coffee in the office...) wrote:
Rainer Hausbach wrote:
So there are something that may be do in C++ and not in Java?


writing an OS ( Kernel ) ?


The "Church Thesis" or "Turing-machine-computable" or ...
... means anything to you?


That doesn't apply.

I could design a turing-complete language with no IO. Sure, you can
calculate anything, but no matter what you try, you can't print the result.

-josh

Jul 22 '05 #43

P: n/a
If you don't like it, don't use it.


Not so simply. Please take a note, the dictatorship means that everyone must
use them. Speaking shortly, we get many people convinced these are the best
langs and it is not possible to escape the loop.
Jul 22 '05 #44

P: n/a
> Every program you can write in C or C++ may be written
in any other-language that can emulate a Turing-machine
(Cobol, Fortran, APL, PL/!, Algol, Ada, Pascal, Java, C#, etc...).


ACK.

but I was refering to special task like an Operating System (Loader,
Kernel!), device driver etc.
Java as an interpreted language IMHO lacks some needed features here.

Rainer
Jul 22 '05 #45

P: n/a
ar******@cs.umbc.edu (Rajeev Ayyagari) wrote:
What is the flaw in this benchmark, other than not unrolling loops
(which is probably a big flaw)?
I haven't looked to closely at the source code but eg. in "sieve.cpp" the
program is not correct: it causes undefined behavior because an iterator
for a vector is placed beyond the end of the vector (further than the
past the end iterator). No big deal since it will normally work on
typical platforms but I'd think the programs should be correct.
But I think the results are still startling, considering that
Java is interpreted.
It is a misconception that Java is interpreted: it is not. Java is a
compiled language. The major difference to C++ (if you leave out
Microsoft's C++ for .Net) is that it uses some form of platform
independent assembler which is transformed into a platform's native
assembler at run-time (when it is loaded and possible later again when
hotspot optimization is done). The major differences between Java and
C++ are in their respective object models, not that one is compiled and
the other is not. And most of the benchmarks stay clear of the object
model differences operating on the low-level built-in types like 'int'
where the object models are identical. One of the examples where there
is a difference in the object model (methcall.*) the test forces the
Java model on the C++ code while making sure that a Java specific
optimization can and will kick in.
Maybe the fault is with g++'s optimization.
The gcc optimizations are apparently not as good as those of other C++
compilers owing to the needs and history of gcc. However, most of
these objective benchmarks are designed to get a false impression - and
even fail to do so when using more appropriate optimization flags.
It's better to set a required output for the input, and then
let the program achieve that output however it wishes to, balancing
code clarity with optimization.


This is not a valid way of benchmarking. To compare the performance,
you need to test the same algorithm coded in both languages.


This is interesting... I would guess that good functional languages will
optimize eg. the Fibonacci example to effectively avoid the recursion:
although the source looks like the same algorithm is used, the system
effectively does very different things. Is this a valid way of
benchmarking? I could easily contrive a set of benchmarks relying heavily
on recursion most functional programming language would win. Does this
benchmark tell me anything about using the languages for problems for
algorithms which are inherently non-recursive (of course, they can be
formulated recursively but the optimizations I used to win the benchmarks
do not kick in)?
You can't code a logarithmic time algorithm in C++ and an
exponential-time one in Java for the same problem and use the results
to claim that C++ is faster.
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
comfortable in a language should do the best they can for the respective
benchmark. If the algorithms turn out to have different complexities
this might expose flaws in the respective languages and this is exactly
what benchmarks are about: to expose flaws. It is not the point of
benchmarks to tune them to let something particular look good. ... and
other benchmarks don't make any assumption about algorithms. For example,
a typical database benchmark tosses a set of SQL statements at a data
base and determines what it takes to process them. Is this unfair because
some database uses inferior algorithms and thus the others should be
disqualified? The point about the Fibonacci example was not that C++ is
much faster using this other algorithm. The point was that nobody would
implement this computation the way it was done in the first place -
except in a functional language where it is a rather sensible approach
to do.
You would have to
compare the above code with the *same* algorithm, coded in Java.
I don't think so. Substitute "*same*" by "*best*" and we agree.
The
algorithm used in the benchmarks is well-known to be a particularly
bad one for generating Fibonacci numbers, but the point is moot. In
the benchmark, you have to test the same algorithm in both languages,
not a fast algorithm coded in C++ against a slow one coded in Java.


Do you want me to design a few benchmarks particularily suitable for C++
which nobody in their right mind would implement that way in Java?

One of the things this "benchmark" highlights is that the developers for
other languages are working on improving the performance. I think this
should also apply to C++. Especially in the area of the standard C++
library I'm aware of a large potential for improvements. Eg. the fastest
version of the wc-benchmark I could come up with is only fast with my
own implementation of the standard C++ library where for_each() takes
advantage of the "segmented sequence optimization" and this code is not
[yet] available publically (I don't have the resources to finish up this
stuff...).
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting
Jul 22 '05 #46

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

Every program you can write in C or C++ may be written
in any other-language that can emulate a Turing-machine
(Cobol, Fortran, APL, PL/!, Algol, Ada, Pascal, Java, C#, etc...).
That's not really true. It's true that an algorithm that can be
implemented in one Turing complete language can also be implemented in
any other Turing complete language. Implementing an algorithm,
however, is somewhat different from implementing a complete program or
(as was mentioned earlier) something like an OS.

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"?
int *screen = (int *)0xb80000;

will give you direct access to the machine's text-mode screen buffer.
It's not portable, but for the target hardware it works perfectly
well.
Java doesn't allow things like that. Direct access to the hardware
isn't portable in C or C++, but Java simply doesn't allow it at all. I was asked not to call you C programmers but this is C code. It will fail
executing on a modern OS.
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.

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;
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
In the end, there's another major problem: Java is defined as more
than a language. Even if you accept source code that's syntactically
identical to Java's, if you compile it directly to native machine code
(other than for a Java machine) what you have isn't Java anymore.
This means that attempting to implement a Java Virtual Machine in Java
leads directly to infinite recursion -- to work, it HAS to be written
in something else.

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).

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.


Jul 22 '05 #47

P: n/a
Mark A. Gibbs wrote in news:479Ac.292231$Ar.124314
@twister01.bloor.is.net.cable.rogers.com in comp.lang.c++:
assert some_test() : "Message on assertion fail";

is actually:

if (assertions_enabled_)
{
if (some_test())
{
throw new AssertionError("Message on assertion fail");
}
}


Why, when loading the class without asserts enabled can't the loader
just strip the whole thing ?. (rhetorical - of course it can).

Indeed (since were in c.l.c++) can't a C++ compiler compile to the
the java vm (I'm told its turing complete :) and #define assert( x )
as:

#define assert( x ) emit( "assert (%b) : \" #x "\";", x )

Not a fan of java BTW, just bored with this whole nonsense thread.

Rob.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #48

P: n/a
On 16 Jun 2004 14:33:07 -0700, ar******@cs.umbc.edu (Rajeev Ayyagari)
wrote:
tom_usenet <to********@hotmail.com> wrote in message news:<f3********************************@4ax.com>. ..
On 16 Jun 2004 00:45:02 -0700, ga********@yahoo.com (Gaurav) wrote:
>http://www.sys-con.com/story/print.cfm?storyid=45250
>
>Any comments?
Whenever I look at inter-language benchmarks in detail, I always find
a flaw in the benchmarking for one language or the other (and often
both), generally based on the author's bias (they generally have
greater expertese in one language than the other).


What is the flaw in this benchmark, other than not unrolling loops
(which is probably a big flaw)?


Just that the tested code is generally not idiomatic. What's the point
of testing how fast some code is that no one in their right mind would
write?
In the benchmarks you've posted, the compiler options provided to GCC
are sub-optimal, and no functions seem to have been declared inline.
For example, many of the tests would benefit from loop unrolling,
which only happens on -O3 I think.


Yes, -O2 doesn't unroll loops (-O3 doesn't either). The benchmarks
would have been more interesting if the -funroll-loops option was
used. But I think the results are still startling, considering that
Java is interpreted. Maybe the fault is with g++'s optimization.


Part of the fault. I could produce a comparison of VC7.1 and GCC on a
couple of them, just to see.
It's better to set a required output for the input, and then
let the program achieve that output however it wishes to, balancing
code clarity with optimization.


This is not a valid way of benchmarking. To compare the performance,
you need to test the same algorithm coded in both languages. You
can't code a logarithmic time algorithm in C++ and an exponential-time
one in Java for the same problem and use the results to claim that C++
is faster.


No, I agree, but that's not what I suggested. Instead, you'd code
idiomatically for the language in question. You probably would use the
recursive algorithm in a functional programming language that knows
how to optimize it to linear time. However, that's not how C++ or Java
programmers would do it, so what's the point to testing how long it
takes to run?
compare the above code with the *same* algorithm, coded in Java. The
algorithm used in the benchmarks is well-known to be a particularly
bad one for generating Fibonacci numbers, but the point is moot.


Yes the point is moot - seeing how fast bad algorithms run is of no
interest to me.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Jul 22 '05 #49

P: n/a
"Dario (drinking co?ee in the o?ce?)" <da***@despammed.com> wrote:
or "Turing-machine-computable" or ...
... means anything to you?
partially (that's the way lots of cpu's work)


[author of this quote remove to protect the innocent...]

That would be a stretch! A Turing-machine is in its minimal form an
infinite tape on which the machine can write zeros and ones plus a
state machine. In each step the machine can write, read, or move the
tape and make a state transistion. To my knowledge, no CPU works that
way and in any case, none of them has an infinite tape.
Every program you can write in C or C++ may be written
in any other-language that can emulate a Turing-machine
(Cobol, Fortran, APL, PL/!, Algol, Ada, Pascal, Java, C#, etc...).


Actually, this is not the statement of the being Turing-computable. The
statements about Turing-machines are about computability: whatever you
can compute using a Turing-complete device, you can also compute with
any other Turing-complete device. Programming languages supporting a
fairly small set of operations (assignment, condition evaluation, and
counting) are Turing-complete (assuming they can address and use an
infinite amount of memory but this is a marginal detail which is normally
ignored).

This does not address in any way certain practical problems like how to
talk to some hardware device. Although all of the above programming
languages are Turing-complete, not all of them are capable of [without
extensions] to access hardware directly as is necessary for writing an
operating system.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting
Jul 22 '05 #50

133 Replies

This discussion thread is closed

Replies have been disabled for this discussion.