Go to the source code of this file.
Defines | |
| #define | SAMPA_DISABLED 0 |
| #define | SAMPA_ENABLED 1 |
| #define | SAMPA_CONFIG_COLD_RESTART SAMPA_ENABLED |
| Store periodic checkpoint of the simulation to resume in second run. | |
| #define | SAMPA_CONFIG_MULTI_THREADED SAMPA_DISABLED |
| Make Sampa multithreaded When using multicore CPU or multiple CPU machine, it can be worth using a separate thread for the IO. | |
| #define | SAMPA_CONFIG_TRACE_CALLS SAMPA_DISABLED |
| Allow logging of call between modules The logging can be activated at runtime however even when not activated it has an overhead so when these traces are not of any use, and only the simulation speed matters, you may decide to disable the trace calls. | |
| #define | SAMPA_CONFIG_DEBUG SAMPA_ENABLED |
| Enable/Disable all traces capabilities when your model is proven and speed if really desired, you can turn off all debugging facilities it is still binary compatible. | |
| #define SAMPA_CONFIG_COLD_RESTART SAMPA_ENABLED |
Store periodic checkpoint of the simulation to resume in second run.
Cold restart stores the simulation state in a file and allows to restart from this state in another run of the process. It can thus be very useful when running long batch regression tests sharing a common initialization. But it comes at a price: Thread stacks can no be stored. This is why Sampa doesn't support SC_THREAD equivalents. But normally the intended models to be written with Sampa shall not require them. This gives some guidelines, and push constraints form the user to fully benefit from it
| #define SAMPA_CONFIG_DEBUG SAMPA_ENABLED |
| #define SAMPA_CONFIG_MULTI_THREADED SAMPA_DISABLED |
Make Sampa multithreaded When using multicore CPU or multiple CPU machine, it can be worth using a separate thread for the IO.
Despites this introduces more cpu usage it can make simulation faster because some IO can be stored and finalized in parallel with the simulation
| #define SAMPA_CONFIG_TRACE_CALLS SAMPA_DISABLED |
1.5.3