-
Notifications
You must be signed in to change notification settings - Fork 0
Memory Use
Home > Model Development Topics > Memory Use
This topic is a compendium of information about memory use, from the general to the specific.
- Introduction and Background
- Trade-offs in model architecture Population size, interactions, and complexity
- Bag of Tricks What it says
Content to follow.
Content to follow.
This subtopic contains links to sections which describe techniques which can reduce memory use. It is not alwyas appropriate to apply these techniques. It may not be worth the effort or additional model complecxity, or there may be a trade-off which is not worth making. The Entity Member Packing report can help identify which techniques will be fruitful.
- Exploit the resource use report Use the report to focus efforts fruitfully
- Suppress table groups: Use and suppress table groups
-
Change time type to float: Use
time_type
to halve time storage -
Use value_out with flash tables: Use
value_out
instead ofvalue_in
, especially with flash tables -
Enable entity packing: Enable the
entity_member_packing
option -
Use mutable real type: Use
real
for floating point values - Prefer range and classification to int
-
Use bitset instead of bool array: Store large arrays of
bool
efficiently - Purge available entity list: Purge the available list after all entities of a given type are gone
Candidates for the BoT:
- compute rather than store
- use smaller c types, or range and classification
- hook to self-scheduling events, e.g. self_scheduling_int(age)
- be economical with events
- be economical with tables (use tables_retain routinely, repeat a run to probe with detailed tables).
- avoid ordinal statistics
- use a unitary Ticker actor to push common characteristics to the population, e.g. year
Content to follow.
[back to BoT]
[back to topic contents]
Content to follow.
[back to BoT]
[back to topic contents]
The Time
type of a model can be changed from the default double
to float
by inserting the following statement in model code:
time_type float;
The Time
type is ubiquitous in models. It is used in attributes, events, and internal entity members. By default, Time
wraps the C++ type double
, which is a double-precision floating point number stored in 8 bytes. The time_type
statement allows changing the wrapped type to float
, which is stored in 4 bytes. This can reduce memory use. For example, here is the summary report for the 1 million GMM run used to illustrate the Model Resource Use topic where time_type
is double
(the default value):
+---------------------------+
| Resource Use Summary |
+-------------------+-------+
| Category | MB |
+-------------------+-------+
| Entities | 1924 |
| Doppelganger | 552 |
| Person | 1372 |
| Ticker | 0 |
| Multilinks | 10 |
| Events | 80 |
| Sets | 196 |
| Tables | 0 |
+-------------------+-------+
| All | 2213 |
+-------------------+-------+
Here is the report for the same 1 million run with time_type
set to float
:
+---------------------------+
| Resource Use Summary |
+-------------------+-------+
| Category | MB |
+-------------------+-------+
| Entities | 1654 |
| Doppelganger | 515 |
| Person | 1138 |
| Ticker | 0 |
| Multilinks | 10 |
| Events | 80 |
| Sets | 196 |
| Tables | 0 |
+-------------------+-------+
| All | 1943 |
+-------------------+-------+
Memory usage of the Person
entity was 17% smaller.
A float
has a precision of about 7 digits. That means that 2025.123 will be different from 2025.124, a precision of ~8 hours.
Changing time_type
to float
may affect model results due to the reduced precision of Time
values. However, such differences may be purely statistical.
[back to BoT]
[back to topic contents]
Flash tables are entity tables which tabulate at instantaneous points in time. They do that using an attribute like trigger_changes(year)
in the table filter which becomes instantaneously true and then immediately false in a subsequent synthetic event. Because an increment to a flash table is instantaneous it has identical 'in' and 'out' values. That means that a flash table using 'value_in' will produce the same values as 'value_out'. However, value_in
in a table causes the compiler to create an additional member in the entity to hold the 'in' value of an increment. For flash tables, this memory cost can be avoided by using 'value_out' instead of 'value_in'.
[back to BoT]
[back to topic contents]
Members of entities can be packed more efficiently by turning on the entity_member_packing
option, but there is a trade-off. For mode information see Entity Member Packing.
[back to BoT]
[back to topic contents]
Floating point values can be declared in model code using the real
type. By default, real
is the same as the C++ type double
, but it can be changed to the C++ type float
by inserting the following statement in model code:
real_type float;
This single statement will change all uses of real
from double
to float
, which will halve the storage requirements of `real' values.
A float
has a precision of around 7 digits, so can represent a dollar amount of 12345.67 to an accuracy of 1 cent.
Because a single real_type
statement changes the meaning of real
throughout, it is easy to assess to what extent changing real
from double
to float
affects results. This provides more flexibility than changing (say) double
to float
in code.
[back to BoT]
[back to topic contents]
Values of type Range or Classification are automatically stored in the smallest C type which can represent all valid values. This can reduce memory use. For example, if YEAR
is declared as
range YEAR //EN Year
{
0, 200
};
a member year
entity Person {
YEAR year;
};
declared with type YEAR
will be stored efficiently in a single byte. In contrast, of year
was declared as int
it would require 4 bytes.
[back to BoT]
[back to topic contents]
The bool
type takes one byte of storage, even though a byte contains 8 bits. Some models use large arrays of bool
in entity members, e.g.
entity Person {
bool was_primary_caregiver[56][12];
}
which records whether a Person
was a primary caregiver in each month of 56 possible working years during the lifetime. The Model Resource Use report would show that the was_primary_caregiver
array member of Person
consumes 672 bytes of memory in each Person
, a significant amount for a time-based model with a large population.
The same information could be stored in a foreign member of Person
using the C++ standard type std::bitset
. A code sketch follows:
typedef std::bitset<56*12> ym_bools; // flattened bit array of 56 years and 12 months
...
entity Person {
ym_bools was_primary_caregiver;
}
size_t ym_index(std::size_t year, std::size_t month) {
return 12 * year + month;
}
Then model code like
ptCareGiver->was_primary_caregiver[nEarningIndex][nM] = true;
could be replaced by functionally equivalent code
ptCareGiver->was_primary_caregiver[ym_index(nEarningIndex,nM)] = true;
In this example, replacing the array of bool
by a std::bitset
reduces storage requirements from 672 bytes to 84 bytes, a significant saving for each Person
entity.
If the bool
array was 1-dimensional rather than 2-dimensional, the code would be simpler.
Possibly, a general wrapper class bitset2D
could be added to OpenM++ runtime support to avoid changing model code at all, e.g.
#include "bitset2D.h"
...
typedef bitset2D<56,12> ym_bools; // 2-D bit array of 56 years and 12 months
...
entity Person {
ym_bools was_primary_caregiver;
}
Then existing model code like
ptCareGiver->was_primary_caregiver[nEarningIndex][nM] = true;
would require no changes.
[back to BoT]
[back to topic contents]
Depending on the model design, an entity type might be used only at a particular phase of the simulation. For example, an Observation
entity might only be used during the creation of the starting population. OpenM++ maintains pools of entities which have exited the simulation which are available for potential reuse. If there will be no reuse of an entity type, the corresponding pool can be emptied and the memory reclaimed by a function call like
Observation::free_available();
- Windows: Quick Start for Model Users
- Windows: Quick Start for Model Developers
- Linux: Quick Start for Model Users
- Linux: Quick Start for Model Developers
- MacOS: Quick Start for Model Users
- MacOS: Quick Start for Model Developers
- Model Run: How to Run the Model
- MIT License, Copyright and Contribution
- Model Code: Programming a model
- Windows: Create and Debug Models
- Linux: Create and Debug Models
- MacOS: Create and Debug Models
- MacOS: Create and Debug Models using Xcode
- Modgen: Convert case-based model to openM++
- Modgen: Convert time-based model to openM++
- Modgen: Convert Modgen models and usage of C++ in openM++ code
- Model Localization: Translation of model messages
- How To: Set Model Parameters and Get Results
- Model Run: How model finds input parameters
- Model Output Expressions
- Model Run Options and ini-file
- OpenM++ Compiler (omc) Run Options
- OpenM++ ini-file format
- UI: How to start user interface
- UI: openM++ user interface
- UI: Create new or edit scenario
- UI: Upload input scenario or parameters
- UI: Run the Model
- UI: Use ini-files or CSV parameter files
- UI: Compare model run results
- UI: Aggregate and Compare Microdata
- UI: Filter run results by value
- UI: Disk space usage and cleanup
- UI Localization: Translation of openM++
- Authored Model Documentation
- Built-in Attributes
- Censor Event Time
- Create Import Set
- Derived Tables
- Entity Attributes in C++
- Entity Function Hooks
- Entity Member Packing
- Entity Tables
- Enumerations
- Events
- Event Trace
- External Names
- Generated Model Documentation
- Groups
- Illustrative Model
Align1
- Lifecycle Attributes
- Local Random Streams
- Memory Use
- Microdata Output
- Model Code
- Model Documentation
- Model Languages
- Model Localization
- Model Metrics Report
- Model Resource Use
- Model Symbols
- Parameter and Table Display and Content
- Population Size and Scaling
- Screened Tables
- Symbol Labels and Notes
- Tables
- Test Models
- Time-like and Event-like Attributes
- Use Modules
- Weighted Tabulation
- File-based Parameter Values
- Oms: openM++ web-service
- Oms: openM++ web-service API
- Oms: How to prepare model input parameters
- Oms: Cloud and model runs queue
- Use R to save output table into CSV file
- Use R to save output table into Excel
- Run model from R: simple loop in cloud
- Run RiskPaths model from R: advanced run in cloud
- Run RiskPaths model in cloud from local PC
- Run model from R and save results in CSV file
- Run model from R: simple loop over model parameter
- Run RiskPaths model from R: advanced parameters scaling
- Run model from Python: simple loop over model parameter
- Run RiskPaths model from Python: advanced parameters scaling
- Windows: Use Docker to get latest version of OpenM++
- Linux: Use Docker to get latest version of OpenM++
- RedHat 8: Use Docker to get latest version of OpenM++
- Quick Start for OpenM++ Developers
- Setup Development Environment
- 2018, June: OpenM++ HPC cluster: Test Lab
- Development Notes: Defines, UTF-8, Databases, etc.
- 2012, December: OpenM++ Design
- 2012, December: OpenM++ Model Architecture, December 2012
- 2012, December: Roadmap, Phase 1
- 2013, May: Prototype version
- 2013, September: Alpha version
- 2014, March: Project Status, Phase 1 completed
- 2016, December: Task List
- 2017, January: Design Notes. Subsample As Parameter problem. Completed
GET Model Metadata
- GET model list
- GET model list including text (description and notes)
- GET model definition metadata
- GET model metadata including text (description and notes)
- GET model metadata including text in all languages
GET Model Extras
GET Model Run results metadata
- GET list of model runs
- GET list of model runs including text (description and notes)
- GET status of model run
- GET status of model run list
- GET status of first model run
- GET status of last model run
- GET status of last completed model run
- GET model run metadata and status
- GET model run including text (description and notes)
- GET model run including text in all languages
GET Model Workset metadata: set of input parameters
- GET list of model worksets
- GET list of model worksets including text (description and notes)
- GET workset status
- GET model default workset status
- GET workset including text (description and notes)
- GET workset including text in all languages
Read Parameters, Output Tables or Microdata values
- Read parameter values from workset
- Read parameter values from workset (enum id's)
- Read parameter values from model run
- Read parameter values from model run (enum id's)
- Read output table values from model run
- Read output table values from model run (enum id's)
- Read output table calculated values from model run
- Read output table calculated values from model run (enum id's)
- Read output table values and compare model runs
- Read output table values and compare model runs (enun id's)
- Read microdata values from model run
- Read microdata values from model run (enum id's)
- Read aggregated microdata from model run
- Read aggregated microdata from model run (enum id's)
- Read microdata run comparison
- Read microdata run comparison (enum id's)
GET Parameters, Output Tables or Microdata values
- GET parameter values from workset
- GET parameter values from model run
- GET output table expression(s) from model run
- GET output table calculated expression(s) from model run
- GET output table values and compare model runs
- GET output table accumulator(s) from model run
- GET output table all accumulators from model run
- GET microdata values from model run
- GET aggregated microdata from model run
- GET microdata run comparison
GET Parameters, Output Tables or Microdata as CSV
- GET csv parameter values from workset
- GET csv parameter values from workset (enum id's)
- GET csv parameter values from model run
- GET csv parameter values from model run (enum id's)
- GET csv output table expressions from model run
- GET csv output table expressions from model run (enum id's)
- GET csv output table accumulators from model run
- GET csv output table accumulators from model run (enum id's)
- GET csv output table all accumulators from model run
- GET csv output table all accumulators from model run (enum id's)
- GET csv calculated table expressions from model run
- GET csv calculated table expressions from model run (enum id's)
- GET csv model runs comparison table expressions
- GET csv model runs comparison table expressions (enum id's)
- GET csv microdata values from model run
- GET csv microdata values from model run (enum id's)
- GET csv aggregated microdata from model run
- GET csv aggregated microdata from model run (enum id's)
- GET csv microdata run comparison
- GET csv microdata run comparison (enum id's)
GET Modeling Task metadata and task run history
- GET list of modeling tasks
- GET list of modeling tasks including text (description and notes)
- GET modeling task input worksets
- GET modeling task run history
- GET status of modeling task run
- GET status of modeling task run list
- GET status of modeling task first run
- GET status of modeling task last run
- GET status of modeling task last completed run
- GET modeling task including text (description and notes)
- GET modeling task text in all languages
Update Model Profile: set of key-value options
- PATCH create or replace profile
- DELETE profile
- POST create or replace profile option
- DELETE profile option
Update Model Workset: set of input parameters
- POST update workset read-only status
- PUT create new workset
- PUT create or replace workset
- PATCH create or merge workset
- DELETE workset
- POST delete multiple worksets
- DELETE parameter from workset
- PATCH update workset parameter values
- PATCH update workset parameter values (enum id's)
- PATCH update workset parameter(s) value notes
- PUT copy parameter from model run into workset
- PATCH merge parameter from model run into workset
- PUT copy parameter from workset to another
- PATCH merge parameter from workset to another
Update Model Runs
- PATCH update model run text (description and notes)
- DELETE model run
- POST delete model runs
- PATCH update run parameter(s) value notes
Update Modeling Tasks
Run Models: run models and monitor progress
Download model, model run results or input parameters
- GET download log file
- GET model download log files
- GET all download log files
- GET download files tree
- POST initiate entire model download
- POST initiate model run download
- POST initiate model workset download
- DELETE download files
- DELETE all download files
Upload model runs or worksets (input scenarios)
- GET upload log file
- GET all upload log files for the model
- GET all upload log files
- GET upload files tree
- POST initiate model run upload
- POST initiate workset upload
- DELETE upload files
- DELETE all upload files
Download and upload user files
- GET user files tree
- POST upload to user files
- PUT create user files folder
- DELETE file or folder from user files
- DELETE all user files
User: manage user settings
Model run jobs and service state
- GET service configuration
- GET job service state
- GET disk usage state
- POST refresh disk space usage info
- GET state of active model run job
- GET state of model run job from queue
- GET state of model run job from history
- PUT model run job into other queue position
- DELETE state of model run job from history
Administrative: manage web-service state
- POST a request to refresh models catalog
- POST a request to close models catalog
- POST a request to close model database
- POST a request to open database file
- POST a request to cleanup database file
- GET the list of database cleanup log(s)
- GET database cleanup log file(s)
- POST a request to pause model run queue
- POST a request to pause all model runs queue
- PUT a request to shutdown web-service