CODEWITHSUNDEEP
dml-lang
Aleks
Aleks

Reputation: 1

Limitations of params, saved and session DML declarations

How much data can be processed using params, saved and session declarations? How do these declaration affect performance and memory allocation/consumption (stack usage, data copy, etc.)? What methods can be used in case of static/dynamic arrays with 10k-100k elements?

Upvotes: 0

Views: 50

Answers (1)

Erik Carstensen
Erik Carstensen

Reputation: 898

Params

An untyped param is expanded like a macro any time it is referenced, so resource consumption depends on its use. If you have a param with a large amount of data, then it usually means that the value is a compile-time list ([...]) with many elements, and you use a #foreach loop to process it. A #foreach loop is always unrolled, which gives long compile times and large generated code.

If a param is typed in a template, then that template evaluates the param once and stores a copy in heap-allocated memory. The data is shared between all instances of the device. Cost should be negligible.

Session

Data is heap-stored, one copy per device instance.

Saved

Pretty much like data, but adds a presumably negligible small per-module cost for attribute registration.

There's two more variants of data:

Constant C tables

header %{ const int data[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}; %}
extern const int data;

Creates one super-cheap module-local instance.

Independent startup memoized method

independent startup memoized method data() -> (const int *) {
  int *ret = new int[10];
  for (local int i = 0; i < 10; i++) {
    ret[i] = i;
  }
  return ret;
}

The data will be heap-allocated, initialized once, and shared across instances. Initialization is done by code, which saves size if it's easy to express the data programmatically, but can be cumbersome if it's just a table of irregular data.

Upvotes: 1

Related Questions