You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support for priority levels of kernels in the catalog.
- Situation:
- So far, the DAPHNE compiler selected the kernel for a DaphneIR operation from the kernel catalog based on argument/result types and backend.
- (Besides that, the user can specify a kernel hint in DaphneDSL, which will be respected by the compiler.)
- In case there are multiple applicable kernels, the DAPHNE compiler simply used the first one it finds.
- This commit introduces a priority to kernels registered in the kernel catalog.
- The priority is a signed integer (0 by default).
- If multiple kernels are applicable, the DAPHNE compiler chooses the one with the highest priority (e.g., a priority of 1 is better than 0); if there are multiple kernels with the highest priority, any of them is used.
- All built-in kernels (those mentioned in kernels.json) are registered with the default priority of 0.
- When registering custom kernel extensions, the user can optionally specify a priority on the command line.
- A meaningful use of this feature is to make the DAPHNE compiler use the kernels provided by a custom extension whenever they are applicable (prefer them over the built-in kernels).
- So far, the alternative would have been using manual kernel hints in DaphneDSL, but this approch can be cumbersome/error-prone and is not possible when the custom kernel implements a DaphneIR operation that has to direct counterpart in DaphneDSL.
- Extended the test cases for kernel extensions.
- Updated the documentation on extending DAPHNE (also added it to the navigation, where it was missing so far).
- Other noteworthy changes:
- Errors happening during the population of the kernel catalog at DAPHNE start-up result in a parser error now (with the respective status code).
Copy file name to clipboardExpand all lines: doc/Extensions.md
+30-4Lines changed: 30 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -173,9 +173,12 @@ make
173
173
### Step 3: Using a Kernel Extension
174
174
175
175
The kernels in a kernel extension can be used either automatically by DAPHNE or manually by the user.
176
-
Automatic use is currently restricted to the selection of the kernel based on result/argument data/value types, but in the future we plan to support custom cost models as well.
177
-
Besides that, the manual employment of custom kernels is very useful for experimentation, e.g., to see the impact of the kernel in the context of a larger integrated data analysis pipeline.
178
-
To this end, DaphneDSL [compiler hints](/doc/DaphneDSL/LanguageRef.md#compiler-hints) tell DAPHNE to use a specific kernel, even though DAPHNE's optimizing compiler may not choose the kernel, otherwise.
176
+
The manual use has precedence over the automatic use.
177
+
178
+
#### Manual Use of Custom Kernels
179
+
180
+
The manual employment of custom kernels is very useful for experimentation, e.g., to see the impact of a particular kernel at a certain point of a larger integrated data analysis pipeline.
181
+
To this end, DaphneDSL [compiler hints](/doc/DaphneDSL/LanguageRef.md#compiler-hints) tell DAPHNE to use a specific kernel in a specific place, even though DAPHNE's optimizing compiler may not choose the kernel, otherwise.
179
182
180
183
*Running example:*
181
184
@@ -205,7 +208,7 @@ s = sum::mySumSeq(X);
205
208
print(s);
206
209
```
207
210
208
-
We execute this script with the following command, whereby the argument `--kernel-ext`specified the kernel catalog JSON file of the extension to use:
211
+
We execute this script with the following command, whereby the argument `--kernel-ext`specifies the kernel catalog JSON file of the extension to use:
The automatic use of custom kernels is currently restricted to the selection of a kernel based on its result/argument data/value types and its priority level.
233
+
In the future we plan to support custom cost models as well.
234
+
235
+
*Running example:*
236
+
237
+
Continuing the running example from above, we can make DAPHNE use the custom kernels `mySumSeq()` or `mySumSIMD()` even without a manual kernel hint by specifying a suitable *priority* when registering the `myKernels` extension with DAPHNE.
238
+
239
+
Priority levels can optionally be specified with the `--kernel-ext` command line argument by appending a colon (`:`) followed by the priority as an integer.
240
+
The default priority of `0` is used for all built-in kernels and for extension kernels in case no priority is specified.
241
+
When registering a kernel extension, the given priority is assigned to *all* kernels provided by the extension.
242
+
When multiple kernels are applicable for an operation based on the combination of argument/result data/value types as well as the backend, DAPHNE chooses the kernel with the highest priority.
243
+
If there are multiple kernels with the highest priority, it is not specified which of them is used.
244
+
245
+
By registering a kernel extension with a priority greater than zero, one can enforce that the kernels provided by the extension are always preferred over the built-in ones whenever they are applicable.
246
+
For instance, the following command registers the `myKernels` extension with a priority of `1`.
247
+
As the `myKernels` extension provides two kernels for the same operation, argument/result types, and backend, we cannot tell, based on priorities, which of these kernels will be used, but we can be sure that the built-in kernel will not be employed.
0 commit comments