It works perfectly on the systems I tested on (windows/linux/android), although I don't have Windows XP so I can not test that.
Your windows executables are about 15% faster than my windows executables, which means that the windows executables are now about as fast as the linux executables. Very nice.
Thanks again.
You're welcome.
It is possible to successfully compile the source with an older, unsupported version of GCC is you use the Boost libraries to handle the c++0x stuff.
Add this to all header files >
--------------------------------------------------
#include <boost/thread.hpp>
#include <boost/thread/thread.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>
#include <boost/chrono.hpp>
#include <cmath>
namespace std {
using boost::mutex;
using boost::recursive_mutex;
using boost::lock_guard;
using boost::condition_variable;
using boost::unique_lock;
using boost::thread;
using boost::this_thread::sleep;
}
#ifndef nanosleep
#define nanosleep sleep
#endif
------------------------------------------------------
In 'enginecontrol.cpp' change to this >
-----------------------------------------------------------------
// std::this_thread::sleep_for(std::chrono::milliseconds(10));
boost::this_thread::sleep(boost::posix_time::microseconds(10000));
--------------------------------------------------------
In 'util.cpp' change to this >
---------------------------------------------------
S64 currentTimeMillis() {
// auto t = std::chrono::system_clock::now();
auto t = boost::chrono::system_clock::now();
auto t0 = t.time_since_epoch();
auto x = t0.count();
typedef decltype(t0) T0Type;
auto n = T0Type::period::num;
auto d = T0Type::period::den;
return (S64)(x * (1000.0 * n / d));
}
--------------------------------------------------------------
It works perfectly on the systems I tested on (windows/linux/android), although I don't have Windows XP so I can not test that.
Your windows executables are about 15% faster than my windows executables, which means that the windows executables are now about as fast as the linux executables. Very nice.
Thanks again.
Ok, Peter- I fell for the joke. When everyone is thru laughing, you can tell me where in hell this engine came from really.
geots wrote:Ok, Peter- I fell for the joke. When everyone is thru laughing, you can tell me where in hell this engine came from really.
george
He rewrote CuckooChess (which was in Java) into C++ from memory, renaming the new engine to Texel. The result was a speed up of 2X, in addition to a rough strength estimate anything up to 140 ELO stronger at fast time controls than the most recent developmental version of CuckooChess that he was using.
It compiles fine on fedora 16 64 bits, but I had to install glibc-devel.i686 (not just glib-devel).
Cheers and thanks again for your program
E Diaz
Two first meanings of the dutch word "leren":
1. leren [vc] (learn, larn, acquire) acquire or gain knowledge or skills.
2. leren [v] (teach, learn, instruct) impart skills or knowledge to.
It works perfectly on the systems I tested on (windows/linux/android), although I don't have Windows XP so I can not test that.
Your windows executables are about 15% faster than my windows executables, which means that the windows executables are now about as fast as the linux executables. Very nice.
Thanks again.
Ok, Peter- I fell for the joke. When everyone is thru laughing, you can tell me where in hell this engine came from really.
george
There is no joke. It may have been a bit inaccurate to call it "new" in the subject line of this thread, but I did explain in the very first post in this thread that Texel is a translation of CuckooChess from java to C++11.
petero2 wrote:
There is no joke. It may have been a bit inaccurate to call it "new" in the subject line of this thread, but I did explain in the very first post in this thread that Texel is a translation of CuckooChess from java to C++11.
Very very nice.
George perhaps misunderstood but for god's sake forgive him 