![[co]](/mwf/v12/flags/co.png "Colombia")
Just out of curiosity, what programming language(s) is Rybka written in?
![[mx]](/mwf/v12/flags/mx.png "Mexico")
I think it's a language that Vas designed himself, based heavily in C/C+. What I remember is that Vas programmed a program that when being run produced a Rybka executable file. But those memories belong to Rybka ~2 times, I have no idea about what Vas does now.
Thank you so much for the information, Vytron.
![[ph]](/mwf/v12/flags/ph.png "Philippines")
Why does Vas have to design another language? Anything wrong with C or C++ ?
Er, perhaps I understood wrong and all he did was adding his own stuff to C++. Labyrinth seems to know more about it.
![[de]](/mwf/v12/flags/de.png "Germany")
> What I remember is that Vas programmed a program that when being run produced a Rybka executable file.
Vas took such programs: a compiler (this is what each developer does) and linker (normaly bound in one system with the compiler)
He 'programmed' it while he was writing C-Code and gave it to the compiler (This is the sense of a compiler and it's very normal use)
And, yes, the compiler-linker-System produces Executables then. :-)
There are several free development systems, including Compiler and linker.
Microsoft's Visual Studio (2008 or 2010) is one of those an it compiles/links very nice Toga and Stokfish for example.
Quap
No, what I meant was different, he compiles a program that when run creates an executable file. In your words:
Vas took such programs: a compiler (this is what each developer does) and linker (normaly bound in one system with the compiler)
He 'programmed' it while he was writing C-Code and gave it to the compiler (This is the sense of a compiler and it's very normal use)
And, yes, the compiler-linker-System produces the executable then.
Then he runs the executable and THAT executable produces the final Rybka 4.exe file.
Or something like that, I recall it was exotic (like, the first program is huge and you can change its parameters, then it produces a much smaller executable.) Otherwise I wouldn't have mentioned it since all programmers use a compiler, etc.
Vas took such programs: a compiler (this is what each developer does) and linker (normaly bound in one system with the compiler)
He 'programmed' it while he was writing C-Code and gave it to the compiler (This is the sense of a compiler and it's very normal use)
And, yes, the compiler-linker-System produces the executable then.
Then he runs the executable and THAT executable produces the final Rybka 4.exe file.
Or something like that, I recall it was exotic (like, the first program is huge and you can change its parameters, then it produces a much smaller executable.) Otherwise I wouldn't have mentioned it since all programmers use a compiler, etc.
![[us]](/mwf/v12/flags/us.png "United States")
Originally he used C++, possibly with some optimizations in assembly.
Later he started to use C#, and uses it still today.
He has stated that the C++ used wouldn't be overly difficult to convert to C.
He has indicated, and it is very likely that, he wrote a massive amount of tools and libraries for engine programming and testing.
He has stated that his programming style would confuse and frustrate others.
He has also mentioned the use of over 800 header files.
Later he started to use C#, and uses it still today.
He has stated that the C++ used wouldn't be overly difficult to convert to C.
He has indicated, and it is very likely that, he wrote a massive amount of tools and libraries for engine programming and testing.
He has stated that his programming style would confuse and frustrate others.
He has also mentioned the use of over 800 header files.
Then is assumed that the source code of Rybka is enormous and virtually different compared to the of many other chess engines?
Well, it is complete speculation since Vas is probably the only one to ever actually lay eyes on the source code, but it might not be the case as you say.
If it were to be structured more like known open source engines it might not appear dramatically different from them.
There's also a lot of relatively standard aspects to chess engines, such as the UCI interface, board representation, move generation (more or less), and others.
If it were to be structured more like known open source engines it might not appear dramatically different from them.
There's also a lot of relatively standard aspects to chess engines, such as the UCI interface, board representation, move generation (more or less), and others.
As a challange, I always wanted to write a chess program in an difficult, unfriendly language, like Fortran.
![[ch]](/mwf/v12/flags/ch.png "Switzerland")
FORTRAN is not a difficult language. Try INTERCAL...
/* Steinar */
/* Steinar */
OMG - A Chess Program in intercal would take forever to reach low plies.
From the page:
http://catb.org/esr/intercal/stross.html
"A Sieve of Eratosthenes benchmark (that computes all the prime numbers less than 65536), when coded in INTERCAL, clocked over seventeen hours on a SPARCStation-1. The same program, in C, took less than 0.5 seconds..."
From the page:
http://catb.org/esr/intercal/stross.html
"A Sieve of Eratosthenes benchmark (that computes all the prime numbers less than 65536), when coded in INTERCAL, clocked over seventeen hours on a SPARCStation-1. The same program, in C, took less than 0.5 seconds..."
Writing one for CUDA that is massively multithreaded is supposed to be effectively impossible. Somehow I think it is possible with some ingenuity. If you can, it stands a chance of a billion positions per second.
It may require an utterly different approach however.
It's certainly possible. Getting reasonable speed from it, OTOH...
/* Steinar */
/* Steinar */
It probably wouldn't be that difficult to write a chess program for CUDA, but from what I understand, it would be highly ineffective, since the GPGPU cores are entirely FPU based, and chess programs are essentially using INT cores for computation.
Could just feed it plenty of floats or doubles instead.
yeah, floating point bitboards should be fun! 
Newer GPU chips have better integer support, so this is less of a problem than it used to be (although certainly not insignificant). The hardest part would be getting any sort of use of the massive data parallelism.
/* Steinar */
/* Steinar */
I don't think "better int support" means that the FPU's will become INT cores, but rather more efficient at handling operations which might have integers in the formula. A far cry from being anthing truely usable for a chess engine.
![[no]](/mwf/v12/flags/no.png "Norway")
So, what do you mean the difference between an “INT core” and “a core efficient at handling operations with integers” is?
/* Steinar */
/* Steinar */
An int core doesn't deal with floating point operations.
I meant that if a math forumula that has floating point operations, the FPU would better handle forumulas with integer math in it. As it stands, when and FPU deals with a pure integer, it often appends a small (statstically insigfinicant) floating point to it.
for example: 2 x 4 = 4. And easy INT operation. An FPU core might end up translating it to 2.00000001 x 2.00000001 = 4.0000000400000001
I meant that if a math forumula that has floating point operations, the FPU would better handle forumulas with integer math in it. As it stands, when and FPU deals with a pure integer, it often appends a small (statstically insigfinicant) floating point to it.
for example: 2 x 4 = 4. And easy INT operation. An FPU core might end up translating it to 2.00000001 x 2.00000001 = 4.0000000400000001
I don't think the distinction is as clear as you're trying to present it. Just to deal with your own example: Several processors (like IA-64, and several x86 implementations) don't have separate integer multiplier chips, but reuse the floating-point one. As long as you have enough mantissa bits, this is completely problem-free — this is, incidentally, why IA-64 had 82-bit floating numbers and not 80 (as x87 has) and 64 (like is common everywhere else), so they could store a 64-bit integer without loss in a float.
A FPU (at least as long as you're talking about IEEE-754, ie. not VAX or the likes) will never translate 2 to 2.00000001. Floating point numbers are not represented like that. 2.1, on the other hand, is a completely different matter.
/* Steinar */
A FPU (at least as long as you're talking about IEEE-754, ie. not VAX or the likes) will never translate 2 to 2.00000001. Floating point numbers are not represented like that. 2.1, on the other hand, is a completely different matter.
/* Steinar */
Try assembly. An entire OS was written in assembly (menuet OS), so a chess engine could be as well.
Here is a relevant post by Vas on 2-17-2007:
"The Rybka code grows in size, the Rybka executable grows in size, and the strength grows. Mostly, I am adding things and elaborating on things. However, it would be quite easy to shrink Rybka while preserving the behavior.
Re. the code size - I have developed my own method (it's a sort of mini-language inside C++), and this method is responsible for much of the size of the executable. If you showed this to any "normal" programmer, he would think that I'm a lunatic :) It's not very efficient from a computer's point of view, but it's efficient from a my-thinking point of view. I don't know the exact source code line count, but there are 858 .h and .cpp files."
Source: http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=2746
So I suppose it was 858 header and cpp files, not just headers.
Was 2007 though, the code has probably changed dramatically since then.
"The Rybka code grows in size, the Rybka executable grows in size, and the strength grows. Mostly, I am adding things and elaborating on things. However, it would be quite easy to shrink Rybka while preserving the behavior.
Re. the code size - I have developed my own method (it's a sort of mini-language inside C++), and this method is responsible for much of the size of the executable. If you showed this to any "normal" programmer, he would think that I'm a lunatic :) It's not very efficient from a computer's point of view, but it's efficient from a my-thinking point of view. I don't know the exact source code line count, but there are 858 .h and .cpp files."
Source: http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=2746
So I suppose it was 858 header and cpp files, not just headers.
Was 2007 though, the code has probably changed dramatically since then.
There is no C# in Rybka (assuming you mean the distributed Rybka executable). Vas has, however, spoken of C# being used in tools that go into making Rybka; presumably for things like testing, evaluation weight tuning etc.
/* Steinar */
/* Steinar */
What is C#? Is that C without the ++ ?
![[za]](/mwf/v12/flags/za.png "South Africa")
> What is C#? Is that C without the ++ ?
C# is C#
What about "D" and "objective C"? Are they effective for chess?
If you are starting out it would be better to use a 'mainstream' language like C or C++, or even C#/Java because there are greater learning resources available.
That being said D language is infinitely more interesting than Objective-C.
That being said D language is infinitely more interesting than Objective-C.
Certainly not as effective as C or C++, at least.
/* Steinar */
/* Steinar */
![[fr]](/mwf/v12/flags/fr.png "France")
I very doubt he is using C#
This is all smoke and mirrors. Most probably, he is using C++ with some clever macro expansions, no more no less.
Now it would have been more interesting if he was using D
As for the compiler, I think he is using the Visual Studio IDE but, maybe, he is using the Intel C++ plugin as, as far as I know,
the Intel compiler is the most efficient one.
All of this is pure speculation of course
This is all smoke and mirrors. Most probably, he is using C++ with some clever macro expansions, no more no less.
Now it would have been more interesting if he was using D
As for the compiler, I think he is using the Visual Studio IDE but, maybe, he is using the Intel C++ plugin as, as far as I know,
the Intel compiler is the most efficient one.
All of this is pure speculation of course
>I very doubt he is using C#
>This is all smoke and mirrors. Most probably, he is using C++ with some clever macro expansions, no more no less.
Probably both, I mean he _has_ said he uses C# as part of the development process.
>as far as I know, the Intel compiler is the most efficient one
I was wondering about the compiler thing myself.
I thought that the intel compiler would only optimize for intel cpus though. In fact there were some controversial articles claiming that it cripples software for amd cpus.
Yeah it is speculation though, although I find it kind of fun. The idea that some guy can sit in front of a computer the way I am now and hammer out a program that is a game-changer in its field is really inspiring.
> Probably both, I mean he _has_ said he uses C# as part of the development process.
Utilities for testing purposes
![[cr]](/mwf/v12/flags/cr.png "Costa Rica")
> I very doubt he is using C#
No, I think he was using now the ь code.
Regards,
Gaмßito.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill