Winboard Forum

Hi, new to these forums.

I've been writing an engine for the passed couple of months and chose Java due to other considerations than speed.

I was wondering how these two languages compare in speed. I realize C should be faster since it doesn't require the Java-'translation'.

I've no real intention of writing a super fast engine, and I don't need exceptional speed.

But how much of a difference is there? And is Java reasonable?

When I started, I wanted to use Java over C as well because of the ease of programming in Java with OOP. The speed difference between the two is conciderable. Even if you don't want your program running super fast, I'm sure you don't want it running dead slow . Even though you can't use OOP, you can still do modular programming in C.

Also I'm not quite sure if Java engines can be Winboard compatable. Mabe someone else here could post on this. Here's a Java Chess Library if you are interested in making your own GUI.
http://ictk.sourceforge.net/

I might consider rewriting it in C then. But as you said the ease of programming in Java makes the basic features easier to handle, beginner as I am to chess engines.

Pradu wrote:Also I'm not quite sure if Java engines can be Winboard compatable.

My program is happily running with Winboard so that's not a problem.

With a WinBoard engine it should be possible to compile to a native executable with the GCJ compiler.

Jonatan Pettersson wrote:I might consider rewriting it in C then. But as you said the ease of programming in Java makes the basic features easier to handle, beginner as I am to chess engines.

When you are a beginner, this is more important than anything else. Super fast speed doesn't really matter much until later. Choose a language you feel comfortable with, forget about speed, and concentrate on writing a working program where you can easily experiment with various techniques. When you have gained some experience, you can consider rewriting your program in your favorite low-level language.

Tord

Are there any benchmarks of C# vs. Java for computational speed?

I don't think choosing a language for easier later porting to another one makes sense.

For a long time Spike could be compiled with both C++ and a Java compiler. We mesured, that C++ is about 60% faster (thus making 160 nodes where Jave made 100) than the Java engine. This is only true, if you are using a good Java virtual machine; look for one that is optimizes for Server programs, or one that as a server option. I think there is one from IBM. The most client based Java jit Compiler only get half the speed than the C++ version.

Most cases are handled equally well by the java compiler (jit) as by the c++ compiler. The speed difference comes mainly from the bounds checking of array access that can?t be deactivated in java.

You can get java run with winboard and UCI, Ralf Sch?fer (for an e-mail look at the home page of Spike) has some experiences with it.

Greetings Volker

Gian-Carlo Pascutto wrote:Are there any benchmarks of C# vs. Java for computational speed?

I don't think choosing a language for easier later porting to another one makes sense.

A lot of the benchmarks are well written lies. C++ is faster, and Java and C# about the same. Here is one benchmark I found that looks fairly honest:

http://www.tommti-systems.de/go.html?ht ... marks.html

Any benchmarks you find on C# sites or Java sites are sure to be blatant advocacy crap.

Logically, C# and Java have about the same sorts of overhead. Conceptually, they offer the same advantages and disadvantages.

So if you have a choice between C# and Java and you don't want to use C++, then I would advise to use the one that you know better (unless you want to learn a new language and are not terribly concerned with performance).

Actually i remember a very objective form of testing performed by Omid David Tabibi.

C# versus C versus JAVA.

For simple programs, the result was already shocking, even worse than we had thought.

C# is about factor 3 slower than C.
JAVA has a similar faith. Factor 3 is very accurate.

The examples shown by Sun are not very fair. They compare some old crappy C console driver with totally different new fresh pgo'ed JAVA code in order to show JAVA isn't a lot slower.

The reality is different.

Factor 3 for very well programmed optimized C code versus JAVA is a real good estimate.

I remember a team i led (JAVA team), some years ago, we stumbled upon real big horrors nonstop in JAVA.

JAVA you must not see as a programming language to write speed dependant applications. See it as a programming language which allows to easily make GUI's and which is cross portable over systems.

That's a real huge advantage of it.

But now take our 3d engine in diep for example. That'll run quite a lot slower. In C you can optimize in a way that you can even use SSE2 if a processor has it.

JAVA is great for telecommunications companies who base everything upon Sun and java solutions they use from Sun.

Connectivity with database (Oracle) nowadays has improved dramatically from the days i led that team and we tried to get to work some intranet thing which allowed for researchers of the government institute to lookup all kind of data.

Especially important is that if within some agency you want to share data within departments, like statistical data (such as how many poison there is on each square meter in a certain area), then JAVA is an ideal tool to connect in a safe reliable way the intranet such that only that data can get out of database where the users in question have clearance for.

Because Sun is a big player at the telecommunication, *the biggest player*, JAVA has been promoted a lot by them.

But please be realistic.

Here is if you do some programming in C.

I have a position far away in shared memory. I want to access it.

I just unset a splitpoint for parallel search:

localsplitpoint = localsplitpoint->father;

Now if i would try to do without too many difficult pointers,
that is if i want to do without pointers in shared memory
that already translates to:

splittreeid = procprop[ProcessNumber]->getsplit_splittreeid;
localsplitpoint = &(procprop[(splittreeid&MAXPROCSMASK)]->split_tree[(splittreeid>>MAXPROCSBITS)]);

See this still is with some pointers. Imagine how ugly it looks when i do completely without pointers and work completely array based.

Not only is the above a real slow construction, it's real ugly too.
Java is ugly if code gets complicated.

If pointers get used wisely, you can really avoid a lot of troubles.

Making a programming language where people cannot mess up is wishful thinking anyway.

It is the sheer overhead that JAVA generates that slows things down.

It is because of Sun that JAVA has become a major success.

M$ of course soon after java started with thair c# project.

Whatever you say, Sun was first to figure out a new language and support it.

Honestely if you ask me, i dislike what m$ has done. C# is even worse than JAVA.

Vincent

Jonatan Pettersson wrote:Hi, new to these forums.

I've been writing an engine for the passed couple of months and chose Java due to other considerations than speed.

I was wondering how these two languages compare in speed. I realize C should be faster since it doesn't require the Java-'translation'.

I've no real intention of writing a super fast engine, and I don't need exceptional speed.

But how much of a difference is there? And is Java reasonable?

You know, you just started C++ programming.

It'll get a lot faster in C++ if you learn a tad more.

There is several authors who are in C++ now who i helped speed up their C++ code. Several of them speeded up factor 3.

Vincent

Volker B?hm wrote:For a long time Spike could be compiled with both C++ and a Java compiler. We mesured, that C++ is about 60% faster (thus making 160 nodes where Jave made 100) than the Java engine. This is only true, if you are using a good Java virtual machine; look for one that is optimizes for Server programs, or one that as a server option. I think there is one from IBM. The most client based Java jit Compiler only get half the speed than the C++ version.

Most cases are handled equally well by the java compiler (jit) as by the c++ compiler. The speed difference comes mainly from the bounds checking of array access that can?t be deactivated in java.

You can get java run with winboard and UCI, Ralf Sch?fer (for an e-mail look at the home page of Spike) has some experiences with it.

Greetings Volker

One issue I have with Java is that if you want to use OOP features, you are going to pay a heavy fee in terms of speed. C++, for example when using templates, does not have such a problem when used with a good compiler.

Let's take ArrayList for example. In C++, you can write an implementation with templates that runs exactly as fast as real arrays. You cannot do such a thing in Java.

In an engine I wrote, the difference in speed between ArrayList and real arrays is about a factor 2.5.

This is a hefty enough price that I rewrote the code to use arrays (which got less 'nice' in the process).

On the other hand, writing Java, especially with a good editor, I write code faster, with less mistakes, and it ends up being better understandable and maintainble. I think Java's language design is simply better than C++ in those aspects.

If speed is not the most important thing, coding in Java is currently my preference.

I have to note that some of my collegues, which are much more fluent in what I would consider "expert" C++ features, say the same effect can be reached through use of things like Boost and custom written class libraries.

However, I've not seen any C++ editors with the same kind of capabilities like IntellJ IDEA or Eclipse, so I remain sceptical. The analytical features of those editors are good enough that the vast majority of code I write is bugfree before the first time it is actually compiled. If anyone knows such an editor, I would like to know about it. But I think some of the most interesting features are only possible because of Java language design vs C++, so it's just impossible to make something like that.

Perhaps the code should be prototyped in Java, and then rewritten to C++ for production use. Should be a fairly fast process

I'm also curious how things like GCJ affect the speed debate.

Hi Vincent,

we where a little confused about the results too. Maybe its the architecture of Spike that makes it run very fast in Java.

My C++ programmin skill may not be the best ever seen, but I am a "optimization" fan and I have been writing Intel assembler programs since the existance of the 8086. Many parts of Spikes code is hand optimized c++ until the assembler code looks like I liked it to.

Surely algorithmic speed-improvements are possible for Spike, but they will have an advantage for Java Speed too.


Greetings Volker


[quote="diepeveen"]You know, you just started C++ programming.

It'll get a lot faster in C++ if you learn a tad more.

There is several authors who are in C++ now who i helped speed up their C++ code. Several of them speeded up factor 3.

Vincent

Volker B?hm wrote:Hi Vincent,

we where a little confused about the results too. Maybe its the architecture of Spike that makes it run very fast in Java.

My C++ programmin skill may not be the best ever seen, but I am a "optimization" fan and I have been writing Intel assembler programs since the existance of the 8086. Many parts of Spikes code is hand optimized c++ until the assembler code looks like I liked it to.

Surely algorithmic speed-improvements are possible for Spike, but they will have an advantage for Java Speed too.


Greetings Volker

diepeveen wrote:You know, you just started C++ programming.

It'll get a lot faster in C++ if you learn a tad more.

There is several authors who are in C++ now who i helped speed up their C++ code. Several of them speeded up factor 3.

Vincent

Your assumption might be false that you are also a good speed programmer in C/C++ too, which might not be the case. It usually takes 10 years to get one, if you ever get one.

Vincent

Let me ask for example,

Can you post your C++ code look like for hashtable probing?

Thanks,
Vincent

Hi Vincent,

you got me a little at this point. As I do not probe in Quiescense the hash probe is not much a speed issue and the code is not much optimized there. (Thus I do not probe at leaf nodes).

But nevertheless here is my code to calculate the hash index:
(cInfoPos, cIndexPos, cEntryPos are constants)

There is a possible speed improvement by returning the Entry and not an index into the table. This must be changed at last while building a parallel version of spike.


// Holt einen Hasheintrag,
// Parameter :
// aHIndex : Hash-Index
// aHCheck : ?berpr?fungscode
int Get(int aHIndex, int aHCheck)
{
int aIndex;
aIndex = CalcIndex(aHIndex);
int* aEntry = mEntry + aIndex;

if (*(aEntry + cInfoPos) == 0) return -1;

if ((*(aEntry + cIndexPos) == aHIndex) &&
(*(aEntry + cCheckPos) == aHCheck))
{
return aIndex;
}
if ((*(aEntry + cEntrySize + cInfoPos) != 0) &&
(*(aEntry + cEntrySize + cIndexPos) == aHIndex) &&
(*(aEntry + cEntrySize + cCheckPos) == aHCheck))

{
return aIndex + cEntrySize;
}
return -1;
}

There is a more speed relevant part of code: Building attack tables. Maybe you can find idears for speed improvement here?
This is a part where I keep the attack table up to date. This is the function where I add a piece and delete the attacks that are now blocked by this piece.


// Aktualisiert die Angriffstabellen von Fernangriffsfiguren nach
// Hinzuf?gen einer Figur
// Parameter :
// aPos : Position der Figur
__forceinline
void AdjustAdd(int aPos)
{
int i;
int aDir;
int aCur;
int aDiff;
int aDirBit;
int aFld;
int aBitPos;

// bit mask with one bit set for every attacking direction
aFld = (mAFld[aPos] & cRangeMask) >> cQueenShift;

// loop through the attacking directions
for (i = 0; aFld != 0; i++, aFld >>= 1)
{
// Gets the next attacking direction number
aBitPos = cLastBitPos[aFld];
i += aBitPos;

aFld >>= aBitPos;
// Gets the attacking direction
aDir = cAttackDirs[i];
// Walk through the board to find attacking piece
// as the kind of piece is not known yet
for (aCur = aPos + aDir; IsEmpty(aCur); aCur += aDir);

// Calculates the Bits to delete, piece and attack direction
aDiff = cBitLookup[GetP(aCur)];
aDirBit = cQueenBit << i;
// Walk through the board to delete bits
for (aCur = aPos - aDir; IsEmpty(aCur);
aCur -= aDir)
{
mAFld[aCur] -= aDiff + aDirBit;
}
mAFld[aCur] -= aDiff + aDirBit;
}
}

Some small remarks:

Things like *(aEntry + cInfoPos) can be written like aEntry[cInfoPos] or cInfoPos[aEntry]. This may help readability significantly.

__forceinline: Are you sure you want this? Any compiler with PGO should be able to figure out where inlining brings a gain better than you are statically. Especially as the routine is not small.

You can do some manual CSE by putting aDiff += aDirBit before the loop.

It looks like several things can be precomputed.

Thanks for the tips but...;

Sometimes the compiler behave a bit funny. Thats why I am sometimes using "strange" code:

Usually a Fld[i] is quite fine. Here somehow the compiler made a bad translation.

The (*(Fld + i + c) == a) is translated to
cmp DWORD PTR [ecx+12], ebx
jne SHORT $LN1@Get@3

and the (Fld[i + c] == a) is translated to
cmp DWORD PTR [esi+edx*4+24], ebx
jne SHORT $LN1@Get@3

The first translation is faster. (But you are still right, Fld[i] is better because readability is more important than speed, but hobby is hobby).

For the loop invariant sum of of aDiff + aDirBit, you are not right. Usually it is better to let the compiler decide where to put the invariant code (He is well capable to detect it). In this special case the use of a additional Variable to calculate the sum outside the loop is mesurable slower because of register handling.

Please note, that __forceinline other than expected does not "force" inlining. When you read the documentation you will find out that it is as well only a hint and does not force anything. But you are right it is old and maybe not neccessary if using a profile guided compiler. In my tests with the old compiler it gained a little speed advantage. But this advantage is much dependant from the total size of the code because the decision wether to inline or not to inline is code size dependant.

Geetings Volker

Volker B?hm wrote:For the loop invariant sum of of aDiff + aDirBit, you are not right. Usually it is better to let the compiler decide where to put the invariant code (He is well capable to detect it). In this special case the use of a additional Variable to calculate the sum outside the loop is mesurable slower because of register handling.

That is pretty funny.

But I disagree on the "Usually it is better to let the compiler decide where to put the invariant code (He is well capable to detect it)."

In this case, you are right, because it's obvious. In the general case, obviously looking invariants can be not-quite-so-invariant to the compiler because of aliasing rules. Doing the CSE manually allows you to explicitly tell the compiler it can be cached.

If the compiler then fucks up register allocation, though

Hmm,

my mistake. I coded

int a = term1;
int b = term2;
int c = a + b;

If I code

c = term1 + term2, then he uses the registers well.

And you are right, only for obvious cases sometimes the compiler knows better what to do. And thanks for your hints!


Greetings Volker.