Java's performance far better that optimized C++

[Default User]

Re: Java's performance far better that optimized C++

Gaurav wrote:


Comparisons with other languages are not topical in comp.lang.c++.




Brian Rodenborn

[valentin tihomirov]

Re: Java's performance far better that optimized C++


"Victor Bazarov" <v.Abazarov@com Acast.net> wrote in message
news:N10Ac.1386 $ri.114317@dfw-read.news.verio .net...[color=blue]
> valentin tihomirov wrote:[color=green]
> > [...]
> > Remember that java is a multiplatform enviroment [...][/color]
>
> That's a very common newbie misconception. Java _is_ a platform.[/color]

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

[color=blue]
> And constructs like
> #ifdef some_platform_o r_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.[/color]
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.



[color=blue]
>[color=green]
> > [...]
> > The most important point, JAVA DOES NOT HAVE INCLUDES!![/color][/color]


[color=blue]
> 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![/color]

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.

[Victor Bazarov]

Re: Java's performance far better that optimized C++

valentin tihomirov wrote:[color=blue][color=green]
>>We're C++ programmers, please do not confuse the two.[/color]
>
>
> C++ is a superset of C. Therefore, to be a valid C++ programmer you need to
> be C programmer(neob hodimoe uslovie), OK?[/color]

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

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

[Bob Hairgrove]

Re: Java's performance far better that optimized C++

On Wed, 16 Jun 2004 16:01:30 -0400, Victor Bazarov
<v.Abazarov@com Acast.net> wrote:
[color=blue]
>C++ is NOT a superset of C.[/color]

You are quite correct:

C++ is a "better C".

(quote from Bjarne Stroustrup)

Cheers,
--
Bob Hairgrove
NoSpamPlease@Ho me.com

[valentin tihomirov]

Re: Java's performance far better that optimized C++

> > C++ is a superset of C. Therefore, to be a valid C++ programmer you need
to[color=blue][color=green]
> > be C programmer(neob hodimoe uslovie), OK?[/color]
>
> Not OK. And do not use the language others won't understand, OK?
>[color=green]
> > The most features of C++ I hate
> > are derived from C.[/color]
>
> It seems that the hate is muddying the waters for you. C++ is NOT
> a superset of C.[/color]

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

[Thore Karlsen]

Re: Java's performance far better that optimized C++

On Wed, 16 Jun 2004 18:45:33 +0200, "Dario (drinking co?ee in the
o?ce…)" <dario@despamme d.com> wrote:
[color=blue][color=green]
>> 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[/color][/color]
[color=blue]
>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...).[/color]

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

--
Be seeing you.

[Rajeev Ayyagari]

Re: Java's performance far better that optimized C++

tom_usenet <tom_usenet@hot mail.com> wrote in message news:<f330d0phf ejk36fpjnq4fkhc tc65oa31an@4ax. com>...[color=blue]
> On 16 Jun 2004 00:45:02 -0700, gaurav_7_7@yaho o.com (Gaurav) wrote:
>[color=green]
> >http://www.sys-con.com/story/print.cfm?storyid=45250
> >
> >Any comments?[/color]
>
> 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).[/color]

What is the flaw in this benchmark, other than not unrolling loops
(which is probably a big flaw)?
[color=blue]
>
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
>
> 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;
> }[/color]

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.

[Jerry Coffin]

Re: Java's performance far better that optimized C++

"Dario (drinking co?ee in the o?ce?)" <dario@despamme d.com> wrote in message news:<capte7$of 7$1@grillo.cs.i nterbusiness.it >...

[ ... ]
[color=blue]
> 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...).[/color]

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.

[Victor Bazarov]

Re: Java's performance far better that optimized C++

X-No-archive: yes
"valentin tihomirov" <valentin_NOSPA M_NOWORMS@abele ctron.com> wrote...[color=blue][color=green][color=darkred]
> > > The most features of C++ I hate
> > > are derived from C.[/color]
> >
> > It seems that the hate is muddying the waters for you. C++ is NOT
> > a superset of C.[/color]
>
> 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.[/color]

Applying well known tactics of incomplete quotes, eh?
[color=blue]
> 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).[/color]

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.

[Mark A. Gibbs]

Re: Java's performance far better that optimized C++


Dario (drinking coffee in the office…) wrote:
[color=blue][color=green]
>> you will see that you can do everything you do in Java in C++ but not
>> viceversa.[/color]
>
>
> 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![/color]

///////////////////////////////////////////////////////////////////////////
[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_fa ctorial
{
public:
static const int return_value =
compile_time_fa ctorial<N - 1>::return_valu e * N;
};

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

#define factorial(n) compile_time_fa ctorial<n>::ret urn_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_wr iter
{
// Leave blank for build time error
// or implement string write(T const&); that throws an
// exception for a compiler time error
};

#define NUMBER_WRITER_C LASS(T) template <> \
class numbers_only_wr iter<T> \
{ \
public: \
static std::string write(T const& t) \
{ \
std::ostringstr eam str; \
str << t; \
return str.str(); \
} \
}

NUMBER_WRITER_C LASS(int);
NUMBER_WRITER_C LASS(float);
NUMBER_WRITER_C LASS(unsigned short);
// etc.

#undef NUMBER_WRITER_C LASS

template <typename T>
inline std::string number_only_wri te(const T& t)
{
return numbers_only_wr iter<T>::write( t);
}

int main()
{
using namespace std;

cout << "int write: " << number_only_wri te(2) << endl;
cout << "float write: " << number_only_wri te(3.14f) << endl;
cout << "unsigned short write: " <<
number_only_wri te(static_cast< unsigned short>(2)) << endl;
//cout << "char write (uh oh!): " << number_only_wri te('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

[Mark A. Gibbs]

Re: Java's performance far better that optimized C++


Gernot Frisch wrote:
[color=blue][color=green]
>>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![/color]
>
>
> 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[/color]

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.Objec t 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_ena bled_)
{
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

[Mark A. Gibbs]

Re: Java's performance far better that optimized C++


valentin tihomirov wrote:
[color=blue][color=green]
>>During my career I've never seen or
>>spoken to anyone who'd "immediatel y dismiss Java". And, believe me,
>>I've spoken to _many_.[/color]
>
>
> I did. All of them are VC++ programmers.[/color]

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

*duck and run*

indi

[josh]

Re: Java's performance far better that optimized C++

Dario (drinking coffee in the office...) wrote:
[color=blue]
> Rainer Hausbach wrote:[color=green][color=darkred]
>>> So there are something that may be do in C++ and not in Java?[/color]
>>
>> writing an OS ( Kernel ) ?[/color]
>
> The "Church Thesis" or "Turing-machine-computable" or ...
> ... means anything to you?[/color]

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

[valentin tihomirov]

Re: Java's performance far better that optimized C++

[color=blue]
> If you don't like it, don't use it.[/color]

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.

[Rainer Hausbach]

Re: Java's performance far better that optimized C++

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

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