Instance teardown might fail regardless the result of build
commands. To make CI green in pull-request we need to check the
result of the build commands instead of the whole workflow result.
Doing so ensure a PR could pass branch protection rules even if
the teardown fails.
It seems that boolean output set by user is not coerced into
boolean type by the runner. Rather it checks if the string
associated ("true" or "false") is not empty.
- if a value is computed it will be correct
- if the value is not finite (NaN or infinity) we panic with a message to
the user indicating what course of action they can take
- ideally we would want to use a scientific crate written in rust, xsf-rust
seemed promising but the dependency on clang + libclang is proving more
annoying than not, given we would need a single function from xsf (and it's
hard to translate all the required pieces) we keep a sort of status quo
- statrs issue : https://github.com/statrs-dev/statrs/issues/361
This is done to be able to execute CI in further development.
Also, we won't have to temporary lift the branch protection rules
to be able to merge since this upcoming development is a rework
cargo_build.yml workflow.
- problem arose from a shift being done on an unsigned value which did not
keep the signed characteristics of the represented signed value
- introduce an arithmetic_shift on the UnsignedInteger trait with a blanket
implementation
- add the edge case which revelead the issue
- the asm has been verified to only change for the shift operation being
applied, meaning no performance regression will occurr
Done to circumvent criterion limitation regarding automatic
truncation of long benchmark ID.
Using a println() call we ensure the complete name is displayed
before benchmark execution to ease manual parsing and debugging.
The steps responsible for setting the OP_FLAVOR and ALL_PRECISION
variables were never executed due to usage of non-existing env
variable.
This causes OP_FLAVOR value to be null and thus would trigger
error on benchmarks that doesn't handle unknown values for
BENCH_OP_FLAVOR.
Also fixes filename to parse for additional boolean benchmark.
Following the same pattern as GPU benchmarks, HPU benchmarks rely
on a common workflow. All the manual launches via
workflow_dispatch event are now done in one place. That way, one
doesn't have to browse the workflow tree to find the right HPU
benchmark to trigger.
Following the same pattern as GPU benchmarks, CPU benchmarks rely on a common workflow. Weekly benchmarks are all gathered in one place. Also, all the manual launches via workflow_dispatch event are now done in one place. That way, one doesn't have to browse the workflow tree to find the right CPU benchmark to trigger.
Signed-off-by: David Testé <david.teste@zama.ai>
