Downloads, Drivers & Runtimes
Get released executable from here.
If you are using Intel hardware, get your runtime from here. If you are using AMD hardware, get your runtime from here.
Running on GPU is not recommended currently, especially for users of Windows 7 or older operating system. If you want to get GPU support, just install latest graphic card driver from nVidia or AMD.
If you are getting error "Display driver stopped responding and has recovered." or BSoD with bugcheck 0x00000116 0x00000117 when running on GPU, use TDR Manipulator to temporarily disable TDR mechanism of windows, then restart your computer. It is NOT RECOMMENDED to disable TDR for a long term since that may cause damage to your hardware.
Why IreCore?
IreCore is a high performance, event-oriented, heterogeneous simulator written in OpenCL C, models a fury warrior character dealing damage to a single raid boss.
Currently the state-of-the-art simulator SimulationCraft is far more functional than IreCore. But while large-scale theorycrafting (e.g. APLGA & Maxima Climb), the efficiency of SimC cannot meet our needs. For example, APLGA runs billions of sim iterations to generate APL from scratch, for SimC that means approximately 1000 hours CPU time, 41 days without a break. That seems unacceptable.
With IreCore, the simulation speedup skyrocketed 20x relatively for common configurations, and even higher for simplified configurations. What's more, IreCore is able to run on CPU, or GPU, or whatever compute devices support OpenCL, such as Intel Xeon Phi coprocessors. If you run two IreCore processes simultaneously on both CPU and GPU, you would get even 2x more faster.
APLGA needs approximately 50 hours CPU time with IreCore. If we run on both CPU and GPU, it needs just 1 day to get result. Sounds pretty good.
Getting Started
IreCore is a console simulator without graphic user interface. All configurations is done by passing parameters to the command line. Extract the release archive into your working directory (e.g. E:\working_dir\), and you will get 5 files and 1 folder.
- irecore.exe: The simulator frontend. Main executable.
- kernel.c: The kernel source. The kernel includes the whole simulator architecture and the fury spec defines. It is loaded dynamically so you can modify it, to achieve your special simulation goal.
- msvcr120.dll & msvcp120.dll: C++ runtime library. If you already installed 32-bit VC++ 2013 Redistributable, these files is not needed.
- LICENSE: IreCore is distributed under the terms of The MIT License, here is a copy of the license.
- profile\: There is a completed configuration file in this folder. You can write your own configuration files with reference of it.
IreCore is a heterogeneous simulator, so you may want to assign an appropriate compute device (your CPU most of the time) before the simulation start. Run irecore list_available_devices=1 to see the list of available compute devices in your computer.
E:\working_dir\>irecore list_available_devices=1
IreCore 612.1-1-g913360 Apr 23 2015
Query available compute devices ...
Platform :NVIDIA CUDA
Device 0: GeForce GTX 980M
Platform :Intel(R) OpenCL
Device 1: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz
If you have setup your runtime environment successfully, you should see your CPU & GPU listed. If not, go back to the top of this page, and download your runtime via links given in Downloads, Drivers & Runtimes.
When you are ready to start your simulation, add parameter opencl_device_id to the command line to assign a compute device. For example, I want to use CPU as my compute device, and it is listed as "Device 1", so I add opencl_device_id=1 into my command line.
E:\working_dir\>irecore opencl_device_id=1 profile\ic_tg_t17m.txt
IreCore 612.1-1-g913360 Apr 23 2015
Query available compute devices ...
Platform :NVIDIA CUDA
Device 0: GeForce GTX 980M
Platform :Intel(R) OpenCL
Device 1: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz
Execute on Device 1: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz
OK!
JIT ...
Sim <unnamed stat set>...
Report for Stat Set <unnamed stat set>
DPS 47504.3
DPS Range(stddev) 1165.6
DPS Error(95% conf.) 10.4255
......
Now you have your IreCore running on that device, enjoy it!
IreCore Philosophy
Damage dealing process in World of Warcraft is a Fully Observable Markov Process. That means an APL without internal states (Hereinafter referred to as sAPL) can be one of the optimal policy.
sAPL is a mapping from the state set S to the action set A. So if we are at the same state s at different time t1 and t2, we will get exactly the same action a from a sAPL.
So, if we scanned APL at moment t1, and executed nothing, and nothing happened to change system state, at the next moment t2 we will execute nothing, same for the next moment t3, and same for the next moment t4... Until something happened and the system state changed, we may get a different action from sAPL.
Let's see some example. Here stands a warrior "Kylaciela" and she uses a spell called "bump". "bump" has no cooldown, no cost, and have a GCD. We designed a cool policy for Kyla, described as sAPL:
bump, if bump is ready.
otherwise, wait.
We concluded the system states and actions as something like this:
enum {
bump_ready,
bump_not_ready,
} state_set;
enum {
bump,
wait,
} action_set;
And the cool sAPL is a mapping from state set to action set:
bump_ready -> bump
bump_not_ready -> wait
Now let's start the simulation. At initial time 0:00.000, Kyla's bump is ready, we scanned the APL and bumped. The state shifted from bump_ready to bump_not_ready, and will shift back to bump_ready at time 0:01.500.
Time elapsed. The atomic timespan size of SimC is 31ms, so we arrived at 0:00.031, scanned the APL and waited.
Time elapsed. We arrived at 0:00.062, scanned and waited.
Time elapsed. We arrived at 0:00.093, scanned and waited.
......
Stupid simulation, lots of cycles wasted on APL scannning. But SimC is brilliant enough to avoid such repeated meaningless APL scanning. SimC will find Kyla is not ready until 0:01.500, so the next scanning is directly scheduled at 0:01.500.
Time elapsed. We arrived at 0:00.031 and do nothing.
Time elapsed. We arrived at 0:00.062, do nothing.
Time elapsed. We arrived at 0:00.093, do nothing.
......
Time elapsed. We arrived at 0:01.500, player_ready_event occured, scanned and bumped.
If we already know the next bump may occur at 0:01.500, why we have to wait for time elapsing? Have a look at how IreCore deals with Kyla.
At initial time 0:00.000, we scanned the APL and APL told us to bump. So a bump_exec event is scheduled at 0:00.000, and a gcd_ready event is scheduled at 0:01.500. Now we have a event queue looks like:
0:00.000 bump_exec
0:01.500 gcd_ready
7:31.250 simulation_end
bump_exec event is not simply a registered bump, it represents a shifting from state bump_ready to state bump_not_ready. While gcd_ready represents a shifting from bump_not_ready back to bump_ready.
Next step, IreCore takes the first event out of the queue, and tries to execute it. Kyla bumped, and no new events scheduled. Now the event queue looks like:
0:01.500 gcd_ready
7:31.250 simulation_end
Next step, IreCore takes the first event out of the queue, and tries to execute it. So the current time is about to jump from 0:00.000 to 0:01.500. When time jumps, IreCore scans APL immediately before the jump. APL told us to wait, so the current time jumps to 0:01.500 and IreCore executes gcd_ready. gcd_ready is just a dummy event, nothing really happened, no new events scheduled. Now the event queue looks like:
7:31.250 simulation_end
Next step, IreCore takes the first event out of the queue, and tries to execute it.
Wwwww...wait, are you going to end the simulation? Kyla just bumped once!
Don't worry. The current time is about to jump from 0:01.500 to 7:31.250. When time jumps, IreCore scans APL immediately before the jump. APL told us to bump, so bump_exec and gcd_ready event is scheduled again, at 0:01.500 and 0:03:000 respectively. Now the event queue looks like:
0:01.500 bump_exec
0:03.000 gcd_ready
7:31.250 simulation_end
So Kyla will keep bumping, until the expected combat length exceeded (7:31.250).