Skip to content

v2.8.0
Compare
Choose a tag to compare
@sorenhein sorenhein released this 01 Dec 09:48
· 417 commits to master since this release
v2.8.0
f033c93

Introduction

v2.8.0 is the first DDS release that was developed on git and was not retro-fitted into git. Thanks to Brian Dickens (@hostilefork) for his tireless help!

Soren Hein officially became a co-author as of this release and is the person responsible day-to-day at the moment.

Contributions are welcome. Please follow this branching model. In particular, use branches for units of change (new features etc); don't merge them into your own develop branch but submit them; and then sync your develop to the DDS develop when it advances.

Speed

DDS v2.8.0 is about 15% faster than DDS v2.7.0 on one benchmark. Because of new functions and because of a dependence on input data, it is becoming increasingly difficult to quantify the speed with a single number.

Interface

  • No changes to any of the bridge functions.
  • SetMaxThreads() does not have to be called on Windows. On some Linux systems it is not necessary, but we recommend that you call it explicitly on all non-Windows systems to be on the safe side. You can use an argument of 0 for auto-configuration.
  • ErrorMessage() was added for convenience. If you get a numerical error message from DDS, you can call this function to get a text message.

Functions and modes

  • We now recommend that you use SolveAllBoards() and not SolveAllChunksBin(), SolveAllChunks() or SolveAllChunksBin(). See below for an explanation.
  • The mode parameter in SolveBoard(), SolveBoardPBN() and in the boards and boardsPBN structs remains available, and DDS does broadly do what it used to do with this parameter. However, the transposition tables are now deemed an internal implementation issue that the user should not have to worry about. The mode parameter may stop working or may do something different in the future. It is recommended always to set it to 0. If you think you need it, please let us know why.
  • CalcAllTables() now can be called with up to 32 DD tables in one batch, rather than 10. Please always use the largest batch size that you have available, for this and other functions.

Platforms

DDS now comes with Makefiles for six systems:

  • The Microsoft Visual C++ compiler (we believe the 2010 and 2013 versions).
  • The mingw compiler (on Windows).
  • The cygwin g++ compiler (on Windows).
  • The g++ compiler on Linux.
  • The clang compiler on the Mac.
  • The g++ compiler on the Mac.

The code has provisions for multi-threading using:

  • The Windows API.
  • OpenMP.

It can also be compiled single-threaded.

The Makefiles are set to have a very high level of warnings and to fail on warnings and not just on errors. This is easy enough to switch off, but we'd prefer if you let us know what needs to be fixed in the code to pass your system.

Binaries

An unofficial DLL for Windows is attached, compiled with the Microsoft Visual C++ compiler version 18.00.21005.1. The official and probably absolute fastest DLL is distributed on Bo Haglund's website.

Distribution structure

Please see the README.md file in the top directory. DDS is now distributed with a test program (including input files and expected results), a set of simple example programs for all major interface functions, and a documentation directory.

DDD is not a direct part of the distribution. DDD has not been updated for many years, but as part of this version, DDD was updated minimally in order to compile on the same six platforms as above (Makefiles supplied).

Internals

The move generation code has been re-implemented (as an object) and is much faster.

A scheduler object has been added which attempts to run the hands in a batch in an order that minimizes execution time. This requires predicting which hands are going to be hard, which turns out to be a difficult problem. We've made a start, and ideas are welcome.

The scheduler detects duplicate hands anywhere within a batch, and not just if they are perfectly aligned in groups as required by the chunk functions. Therefore there is little reason to use the chunk functions anymore.

The code for initialization and the SolveBoard() interface functions have been restructured. This led to a particular speed-up for the AnalysePlay function family which is now very fast indeed.

Bugs were fixed.

Assets 5
Loading