Age | Commit message (Collapse) | Author |
|
Defaults to two threads right now. This
can be changed in the Simulator constructor
for the time being. An interface will be
added for this soon.
For an example I tried, I got the following times on 500 simulations in a
macOS release build:
* Quackle 1.0.3 - 26 seconds
* master branch, 1 thread - 27 seconds
* master branch, 2 threads - 19 seconds
* master branch, 4 threads - 15 seconds
This isn't the most efficient use of threads.
It distributes all of the plays being simmed
into a thread pool, but only for one simulation.
Then it comes up for air and tries again.
This was the easiest to implement robustly
given the current architecture.
|
|
The code running the simulation is now
disconnected from the Simulation class,
with appropriate members being copied into
a SimmedMoveConstants field (read-only,
thread-safe) and a SimmedMoveMessage
(the class for communicating per-sim data
to and from external threads).
The newly added static function,
Simulate::simulateOnePosition(), should now
be thread-safe and usable as a run function
for a thread.
|
|
Break out things that are effectively constant
into a separate struct so we don't have to
keep initializing them. Also, ensure that all
of the things I forgot are abstracted so I
can break out the per-move simulation into
a different function.
|
|
|
|
In prep for allowing sims to be handed off to a thread
pool.
|
|
Also, extend copyright to 2019.
|
|
Also, while reading through this, found one bug where a vector
was being rearranged via erase/insert while an iterator was
still pointing to the element being erased.
|
|
Also, fix a typo and remove dead code.
|
|
* Fix compiler warnings
* Add Visual Studio 2013 solution
* Tweak .pro files
* Most importantly, rename main 'quackle' project to
'libquackle' to avoid solution-level name conflict. This
only affects the VS build.
|
|
Not a very interesting commit...only changes in comments.
|
|
|