Language Benchmarks

Anima

Performance isn't the only thing when it comes to a language though. Personally I do more Java than C++ and I like the enviroment. Its quite forgiving and less problematic than using C or C++. Its only going to get faster also so to me it seems like its worth the slight performance loss in certain situations.

If I was to do an application where performance was absolutely critical then yeah I would use C++ but isn't that kind of obvious? I don't think anyone is saying that Java is definitely faster than C++ because it isn't. It is as fast in some cases, faster sometimes and a lot slower other times.

Martyr

webmonkey wrote:

How would you do it so? We talking about using os primitives for handling signal handlers etc. You clearly know what your talking about.

So i know about a sleep() function or a little about multi-threading, and that makes me "know everything", does it?

I'm not experienced programmer and this is going off topic.
We still haven't answered which is faster, Java or C/C++

For all the time you guys don't have, you seem to have enough arguing over my posts rather than disproving C/C++ is faster than Java at generating machine code.

Martyr

Anima wrote:

I don't think anyone is saying that Java is definitely faster than C++ because it isn't

some Java programmers have claimed this.yet aren't able to produce anything to back it up..just that they know what they're talking about..etc.

i'm willing to test some code myself over the weekend when i get a chance.so i'll post something.

marco_polo

Martyr wrote: »

i do work in a call centre, ask anyone that knows me.

Not on about the Call center. My point was that you have a know it all posting style.

i'm not a programmer by profession, never have been which is why anyone here should feel comfortable proving that Java is faster than C/C++ at generating machine code.

Who ever said that anyway? I am sure that C\C++ is quite faster in many trivial benchmarks than Java or C#. Unbiased benchmarks are hard to come by so it is hard to tell.

I am more curious as to why you are attempting to belittle other posters on here?

Martyr

Not on about the Call center. My point was that you have a know it all posting style.

yes, i know this is what you meant, but you're really no different.

I am more curious as to why you are attempting to belittle other posters on here?

belittle how? like the way some of you have been dismissing my posts?
i'm not allowed to challenge your assertions about what i know?

i was joking in some responses, not serious.

Webmonkey

Martyr wrote: »

So i know about a sleep() function or a little about multi-threading, and that makes me "know everything", does it?

I'm not experienced programmer and this is going off topic.
We still haven't answered which is faster, Java or C/C++

For all the time you guys don't have, you seem to have enough arguing over my posts rather than disproving C/C++ is faster than Java at generating machine code.

You said this:

Martyr wrote:

not very sophisticated..

You don't say things like this without a reason.

Martyr wrote:

For all the time you guys don't have, you seem to have enough arguing over my posts rather than disproving C/C++ is faster than Java at generating machine code.

Same applys to you doesn't it. You are the one in fact with the argument, not me. But it's funny it turned from an opinion into an argument

Martyr wrote:

yep, just an opinion.

Martyr

webmonkey wrote:

You don't say things like this without a reason.

i said it because you were dismissing my posts like you knew it all, only to then go post a loop which you say is used to signal/interrupt something.

so, i'm sorry, was being sarcastic..but you still have to admit, something like that wouldn't be good method of event polling.

webmonkey wrote:

Same applys to you doesn't it. You are the one in fact with the argument, not me. But it's funny it turned from an opinion into an argument

i had a feeling atleast 1 of you would say this.
i'll write both the Java and C/C++ at the weekend.

i've no idea which will be faster.

Webmonkey

Martyr wrote:

i said it because you were dismissing my posts like you knew it all, only to then go post a loop which you say is used to signal/interrupt something.

First of all I didn't post any loop that was used for event handling. I said a loop can include a sleep and go into the sleep queue and wait on interrupts from the OS. Essentially a loop that does nothing, but used to make a program sleep and wait for a signal to get woken up.

How else do you propose so baring in mind I am doing this at low C level. You still seem to claim its bad:

Martyr wrote:

but you still have to admit, something like that wouldn't be good method of event polling.

Martyr wrote:

i've no idea which will be faster.

What has changed, you seem to be convinced a second ago?

Also I've seen similar arguments like this in other threads.

Let's end this whole loop thing now as it gone way off topic. Sorry OP.

ronivek

It doesn't matter what kind of results you get because you still won't be any closer to reaching a conclusion in the "C/C++ faster than Java" discussion.

There are scenarios in which a particular program written in Java will complete faster than that same program written in C/C++. Equally there are scenarios in which the opposite is true; and indeed which neither is true.

If you want to have this discussion and make it in any way meaningul you need to specify a program or at least a type of program; and indeed a hardware platform, compiler version and list of any OS or compiler flags used... and after all your testing and benchmarking you'll still be no closer to answering your initial question or proving the statement; because you've only answered it for a minute number of possible permutations.

Personally I think someone is just bored at their call-centre and has found a bunch of people to troll.

marco_polo

Martyr wrote: »

yes, i know this is what you meant, but you're really no different.



belittle how? like the way some of you have been dismissing my posts?
i'm not allowed to challenge your assertions about what i know?

i was joking in some responses, not serious.

I would have been intrested in doing some genuine unbiased benchmarks until you started posting stuff like this

Martyr wrote: »

if java compensates for being a **** programmer, why can't c/c++ compilers do the same?

Martyr wrote: »

...
(unless you're java programmer, who thinks it would be worth running a loop that does nothing)

Martyr

webmonkey wrote:

First of all I didn't post any loop that was used for event handling. I said a loop can include a sleep and go into the sleep queue and wait on interrupts from the OS. Essentially a loop that does nothing, but used to make a program sleep and wait for a signal to get woken up.

How else do you propose so baring in mind I am doing this at low C level. You still seem to claim its bad:

i don't know.

What has changed, you seem to be convinced a second ago?

i'm appeasing until i test this out for myself seeing as nobody here is willing to play along..just waste time disecting my posts.

Also I've seen similar arguments like this in other threads.

if you want to add your arguement there, please feel free.
not sure what you hope to achieve posting link in here.

ronivek wrote:

Personally I think someone is just bored at their call-centre and has found a bunch of people to troll.

Good night.

towel401

Assembly ftw?

A real programmer is someone who can write a fully featured OS with nothing but a set of punch cards and a needle

marco_polo

towel401 wrote: »

Assembly ftw?

A real programmer is someone who can write a fully featured OS with nothing but a set of punch cards and a needle

Pussy :rolleyes:. Come back to me when you have written a first person shooter in binary. (For bonus points - With no hands )

towel401

marco_polo wrote: »

Pussy :rolleyes:. Come back to me when you have written a first person shooter in binary. (For bonus points - With no hands )

back in the late 70's (1870's for all you young snapperwhippers) I had Doom 0 running on my steam powered computer. we'd gather around and 2 of us would shovel coal while another lad would play. for a screen we had a ceramic plate with lodsa holes like a Super SER and we'd have a different colour flame out of each hole.

when we went to a LAN party it was customary to bring a cart full coal, now you just bring your PC. we'd only have them in the middle of winter cause it would heat up the whole castle to 30 degrees.

this is also the reason most real computer nerds still live in the basement - back in the day computers pumped out so much heat it would be a waste of perfectly good coal otherwise. now the real snobby rich kids usually bought one or two slaves at the market so they wouldn't have to shovel coal and clean the thing after every gaming session

before anyone had telegrams the guys running IPv0 had a network of underground water or air-filled pipes and a huge steam driven machine with a flywheel banging out a change in pressure to send a message down the line with amplitude shift keying at some painfully slow rate but it was faster than the pony express and thats all that mattered

marco_polo

towel401 wrote: »

back in the late 70's (1870's for all you young snapperwhippers) I had Doom 0 running on my steam powered computer. we'd gather around and 2 of us would shovel coal while another lad would play. for a screen we had a ceramic plate with lodsa holes like a Super SER and we'd have a different colour flame out of each hole.

when we went to a LAN party it was customary to bring a cart full coal, now you just bring your PC. we'd only have them in the middle of winter cause it would heat up the whole castle to 30 degrees.

this is also the reason most real computer nerds still live in the basement - back in the day computers pumped out so much heat it would be a waste of perfectly good coal otherwise. now the real snobby rich kids usually bought one or two slaves at the market so they wouldn't have to shovel coal and clean the thing after every gaming session

before anyone had telegrams the guys running IPv0 had a network of underground water or air-filled pipes and a huge steam driven machine with a flywheel banging out a change in pressure to send a message down the line with amplitude shift keying at some painfully slow rate but it was faster than the pony express and thats all that mattered

You had coal? Ooh you lucky bastard.

You lucky, lucky bastard.

towel401

most people did in the winter anyway but when there was no cotton to be picked we had a cheaper source of power.

The screens were too expensive to run for most so for every day stuff youd use the mechanical teletype

Hobbes

Martyr wrote: »

I'm not a programmer at all.

Well that much is evident at least from the Java side.

As I said earlier, and probably repeated myself a few times it that for certain things Java will outperform C++, for others C++. It is very dependent on what it is you are actually coding and how long the application is running and on what.

Both C++ and Java compile to machine code. The whole point of JIT. If you aren't using .NET then the C++ EXE is not optimized on the fly.

if java compensates for being a **** programmer, why can't c/c++ compilers do the same?

Actually Java will not compensate for being a bad programmer. Just because it is easier to create something working in it doesn't mean you automatically write better code.

The only thing I pointed out you were wrong on is your knowledge of Java. This "prove it" appears to be the self-defense mechanism. I mean it is not like you can't google for the numerous tests already done out there.

Martyr

hobbes, here is the full quote:

Martyr wrote:

Can you exploit SIMD features of PowerPC/x86 cpus like Altivec/SSE2?
..yes, i think so but the big question is whether Java would generate more efficient code than C/C++ for this purpose and i'd doubt it very much.

Here is part of what I said you decided to focus on:

Martyr wrote:

I think so but the big question is whether Java would generate more efficient code than C/C++ for this purpose and i'd doubt it very much.

And here is your response:

hobbes wrote:

Again it depends very much on how and what you are doing. JIT will create java code that performs as well or better then C++ depending on what you are coding and how long the application runs. (JIT can rewrite the assembly code on the fly to optimize).

In future, please try to read the whole sentence.

If you, being the expert you are know Java will outperform C++ using Altivec/SSE2, put it to the test with me.
Because talk is cheap.

Webmonkey

It is too early in the morning!

Martyr

hobbes could atleast respond to the full comment i made and not just select the bits he wants to criticise, just because he loves telling everyone how long he's been programming for.

Hobbes

Ok so your falling back to a sentence earlier on when generalisations fail.

I mean you pick something that has two different instruction sets for Java and C++. The Java instruction set is slower in that case because the specification defines accuracy, where as the other instruction set is based on the speed and less focus on accuracy.

So they aren't even making the same call. So that has nothing to do with Java and more to do with Altivec. If you want to go down to instruction set level of performance that is.

Martyr

hobbes wrote:

I mean you pick something that has two different instruction sets for Java and C++. The Java instruction set is slower in that case because the specification defines accuracy, where as the other instruction set is based on the speed and less focus on accuracy.

I'm not sure i fully understand.Altivec is a feature of the PowerPC, SSE2 is a feature of AMD/INTEL cpu's.
These are instruction sets defined by the processor manufacturer, if you want to execute code on their processors, you have to use their instruction set.

i'm not trying to be smart here, but you're making it sound like Java runs itself using its own instruction set, yes?

hobbes wrote:

So they aren't even making the same call. So that has nothing to do with Java and more to do with Altivec.

Altivec is a feature of the CPU, used for vector processing.
i don't know if Java has support for them, i'd imagine they do under the hood.

Is it possible to generate assembly code from a Java file?
Like you would using the -S parameter of GCC?

marco_polo

Been done already

http://heikok.blogspot.com/2008/08/microbenchmark-of-sse-in-c-and-java.html

Hobbes

Martyr wrote: »

i'm not trying to be smart here, but you're making it sound like Java runs itself using its own instruction set, yes?

http://www.mactech.com/articles/mactech/Vol.15/15.07/AltiVecRevealed/

The floating-point sub-unit has two modes of operation: a Java mode and a non-Java mode. The Java mode provides compliance with the Java Language Specification 1. The non-Java mode provides faster results with less numeric accuracy. This latter mode is useful for real-time algorithms where response times are more critical than the data's accuracy.

Is it possible to generate assembly code from a Java file?

The JVM converts the java code into assembly/machine code at runtime.

If you mean create as an ASM file. No. There would be no point. If you mean run assembly within Java the answer is no as it would break the specification. However you can call Assembly programs via JNI calls in Java.

marco_polo

A bit dated, but seem relatively impartial and may be of interest to the OP. Benchmarks for various JVM, .NET and C\C++ implementations.

http://www.shudo.net/jit/perf/

Martyr

i can't access the link you posted, hobbes, will try later.
not sure what the author means by "sub-unit" - assuming for now that Java emulates the Altivec unit using the floating point unit, which would mean its not really using Altivec code, only emulating it..

AFAIK from reading PowerPC manuals, there is only 1 Altivec unit, 32 128-bit vector registers, at most 128 on newer models.

x86 have 8 128-bit vector registers in 32-bit mode, 16 in 64-bit mode.

hobbes wrote:

If you mean create as an ASM file. No. There would be no point

i would like to compare assembly code generated by a selection of C compilers and if possible generated by the JVM on windows/linux..then accurately time the number of cpu cycles it takes for this code to execute..

imho this would be the best way to decide which code was faster.

It would be best way because any code has to run on processor eventually..and it has to use the processors instruction set, the cpu ultimately decides what runs faster.

i'd use the timing macros from Agner Fog who is expert on code optimization.

something like this:

[PHP]memset(buffer,value,sizeof(buffer));[/PHP]

or

[PHP]for(int i = 0;i < sizeof(buffer);i++)
buffer = value;[/PHP]

Depending on the size of buffer, a good compiler like intels would generate vectorized code (use SSE2)

i'll attempt to find out over the weekend in Java does the same..but i seriously doubt it.

Hobbes

Martyr wrote: »

i can't access the link you posted, hobbes, will try later.
not sure what the author means by "sub-unit" - assuming for now that Java emulates the Altivec unit using the floating point unit, which would mean its not really using Altivec code, only emulating it..

The Altivec instructon set has the floating point part written to C++ and Java specifications. When a java instruction is executed the chip uses a different method in handling the floating point.

Which is again is a good example why you can't easily benchmark the two languages.

i would like to compare assembly code generated by a selection of C compilers and if possible generated by the JVM on windows/linux..

Again this is not a real test. The JVM creates the machine code but rewrites it to optimize it further during execution time. So there is no guarantee that machine code you generate the first time is the same machine code when the application finishes.

Martyr

hobbes wrote:

The Altivec instructon set has the floating point part written to C++ and Java specifications. When a java instruction is executed the chip uses a different method in handling the floating point.

Which is again is a good example why you can't easily benchmark the two languages.

The only reason for having java-mode and non-java mode from what i read is that non-java mode code takes longer to execute.

In comparison with x86, since CORE2 models, you can theoretically execute 3 SIMD instructions in 1 cycle so it doesn't require a "java mode"

I won't be using powerpc anyway, since MAC's use intel cpus now

hobbes wrote:

Again this is not a real test. The JVM creates the machine code but rewrites it to optimize it further during execution time. So there is no guarantee that machine code you generate the first time is the same machine code when the application finishes.

You have a good point JVM might optimize code during execution time, but i won't be using any redundant code.

There will be no room to optimize during runtime, what-so-ever.

i simply want to see what assembly the compilers generate then test its execution time.

IMHO thats alot more fair than some of the tests online i've seen to date.

It seems GNU Java compiler can generate assembly output, pity javac can't do likewise.

marco_polo

Martyr wrote: »

The only reason for having java-mode and non-java mode from what i read is that non-java mode code takes longer to execute.

In comparison with x86, since CORE2 models, you can theoretically execute 3 SIMD instructions in 1 cycle so it doesn't require a "java mode"

I won't be using powerpc anyway, since MAC's use intel cpus now



You have a good point JVM might optimize code during execution time, but i won't be using any redundant code.

There will be no room to optimize during runtime, what-so-ever.

i simply want to see what assembly the compilers generate then test its execution time.

IMHO thats alot more fair than some of the tests online i've seen to date.

It seems GNU Java compiler can generate assembly output, pity javac can't do likewise.

It is not a pity javac can't do likewise, the whole point it that a compiled java program should be able to run on any platform, hence it is compiled to bytecode and native code generation is deferred to runtime.

As for whether or not there is room to optimize during runtime, the JIT compiler will decide that, not you . JIT optimization is about optimizing heavily used blocks of code, not just removing redundant code. As benchmark programs are trivial, there will obviously not be much optimizing that can be done by any compiler, it is really comes into its own for much larger programs where you cannot be sure that your code is 'perfect'.

It is possible to see the assembly produced by the JIT compiler. But apparently you will need a debug build of the JVM.

Good article here:

http://www.javaworld.com/community/node/2352

And finally, my current absolute favorite option, which requires a debug build of the JVM:

* -XX:+PrintOptoAssembly dumps to the console a log of all assembly being generated for JITed methods. The instructions are basically x86 assembly with a few Hotspot-specific instruction names that get replaced with hardware-specific instructions during the final assembly phase. In addition to the JITed assembly, this flag also shows how registers are being allocated, the probability of various branches being followed (along with multiple assembly blocks for the different paths), and information about calls back into the JVM. Outside the logging options for the final generated assembly (which requires a separate plugin) this is the best tool for discovering what optimizations are actually happening. I use this at least a couple times a week to investigate JRuby performance enhancements.

Hobbes

Martyr wrote: »

The only reason for having java-mode and non-java mode from what i read is that non-java mode code takes longer to execute.

The Java specification defines how floating points should be handled. That is what Java mode is for. It focuses on accuracy rather then speed. The non-java mode executes faster.

I won't be using powerpc anyway, since MAC's use intel cpus now

*sigh* There is nothing wrong with the mac. Exceptionally good machines. If there was any complaint it would be their price.

i simply want to see what assembly the compilers generate then test its execution time.

Good luck with that so.