News:

Happy New Year! Yes, the current one, not a previous one; this is a new post, we swear!

Main Menu

Check this please

Started by Hdx, November 02, 2008, 01:44:37 AM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

Camel

Quote from: Hdx on November 07, 2008, 04:31:06 PM
Now i've finished it and Java runs about 70% faster then the C.

Really? Using -O2?

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!

nslay

Java does have JIT which supposedly generates some native code at run time.  However, I find it hard to believe a highly suggestive and properly structured C code would underperform a Java code.  Please compare your C code with a real compiler (e.g. icc). GCC is utter garbage when it comes to performance.  Also, take advantage of C99 features (e.g. inline and restrict).  Be as suggestive to the compiler as you can (e.g. use register qualifier where appropriate, order code to make vectorization more obvious..."neatness" and "style" have no meaning!).  Also order your C code to mix as many operations as possible to reduce register pressure (compiler can generally do this).  Finally, JIT probably takes advantage of processor-specific features (e.g. SSE for vectorization), please turn these features on when compiling the C code.
Why do you have to do this in C?  Because C is complicated!  The compiler cannot make too many assumptions.  If you can, code the same program in Fortran and use ifort (again, GCC blows!).  Fortran will probably blow both Java and C away because the language is so simple, the compiler can make more aggressive optimizations.
An adorable giant isopod!

Chavo

why stop at fortran? assembly is what performance pros use

Sidoh


nslay

#19
Quote from: Chavo on November 20, 2008, 01:16:34 AM
why stop at fortran? assembly is what performance pros use
Sometimes, but rarely.  You have to know all sorts of details about the processor and machine in order to produce high performance applications in assembler.  So, performance pros don't often use assembler.  There are a few exceptions, as an example: my friend does numerical linear algebra and works on a cluster of PS3s here, the current C/Fortran compilers for Cell cannot take full advantage of the Cell's vector capabilities (i.e. BLAS and LAPACK would suck!).  As a consequence, he wrote some common vector routines in assembler.  Almost nobody writes extensive high performance applications in assembler...its not portable and a human often does a worse job than a compiler.
You know whats sad?  Fortran is crazy simple and it is the language of choice for many high performance numerical codes...written by people older than us with less knowledge about the computer.  You have to know a good deal about what you're doing to do anything high performance in Assembler or C.  Actually, despite my dislike of C++...C++'s templates, inline functions, and reference types (similar to restrict pointers) makes it easier for a C++ application to even outperform a C equivalent!

EDIT: P.S. And with regards to your comment, C is actually lower level than Fortran.  It would have been more appropriate to say "Why stop at C?".
An adorable giant isopod!

Chavo

My comment was not designed to be a serious suggestion as much as a joking comment regarding the silliness of even having the discussion.

Hdx

The main reason I chose C was because I wanted to become more fluent in it. My code right now is by no means optimized/efficient. JBLS uses ~56mbs of memory just idling, and 3/4ths the damn thing isnt even written yet! But, what I figure is i'll optimize things after i get the bulk of it working. There is no release date this is purly for my own enjoyment.

I plan to in the future teach myself other languages Fortran included. But I figured C was a good place to start.
http://img140.exs.cx/img140/6720/hdxnew6lb.gif
09/08/05 - Clan SBs @ USEast
[19:59:04.000] <DeadHelp> We don't like customers.
[19:59:05.922] <DeadHelp> They're assholes
[19:59:08.094] <DeadHelp> And they're never right.

Joe

Quote from: Hdx on November 20, 2008, 12:00:30 PM
The main reason I chose C was because I wanted to become more fluent in it. My code right now is by no means optimized/efficient. JBLS uses ~56mbs of memory just idling, and 3/4ths the damn thing isnt even written yet! But, what I figure is i'll optimize things after i get the bulk of it working. There is no release date this is purly for my own enjoyment.

I plan to in the future teach myself other languages Fortran included. But I figured C was a good place to start.

Are we talking about Java Battle.net Login Server or Just Another Battle.net Login Server?
Quote from: Camel on June 09, 2009, 04:12:23 PMI'd personally do as Joe suggests

Quote from: AntiVirus on October 19, 2010, 02:36:52 PM
You might be right about that, Joe.


Hdx

Java uses like 90 with everything loaded.
C uses 56
http://img140.exs.cx/img140/6720/hdxnew6lb.gif
09/08/05 - Clan SBs @ USEast
[19:59:04.000] <DeadHelp> We don't like customers.
[19:59:05.922] <DeadHelp> They're assholes
[19:59:08.094] <DeadHelp> And they're never right.

Camel

#24
Quote from: nslay on November 20, 2008, 12:41:03 AM
Java does have JIT which supposedly generates some native code at run time.  However, I find it hard to believe a highly suggestive and properly structured C code would underperform a Java code.  Please compare your C code with a real compiler (e.g. icc). GCC is utter garbage when it comes to performance.  Also, take advantage of C99 features (e.g. inline and restrict).  Be as suggestive to the compiler as you can (e.g. use register qualifier where appropriate, order code to make vectorization more obvious..."neatness" and "style" have no meaning!).  Also order your C code to mix as many operations as possible to reduce register pressure (compiler can generally do this).  Finally, JIT probably takes advantage of processor-specific features (e.g. SSE for vectorization), please turn these features on when compiling the C code.
Why do you have to do this in C?  Because C is complicated!  The compiler cannot make too many assumptions.  If you can, code the same program in Fortran and use ifort (again, GCC blows!).  Fortran will probably blow both Java and C away because the language is so simple, the compiler can make more aggressive optimizations.

Hotspot does not do much optimization; what's the point of having code that executes fast if it takes five minutes to JIT compile? Hotspot does have the advantage of already having the bytecode instructions, which are much easierquicker to translate in to machine code than C source, but it is none the less a non-trivial operation, thereby limiting the jitter's ability to consider optimizations. If a block of code is observed to be used very often, Hotspot may bring it up as a candidate for further optimization. However, for a test like this, GCC with -O2 should beat Hotspot-enhanced Java every time.

<Camel> i said what what
<Blaze> in the butt
<Camel> you want to do it in my butt?
<Blaze> in my butt
<Camel> let's do it in the butt
<Blaze> Okay!