nopeslide

@alrevuelta > If so, that could be the solution, but I liked the idea of preresolving everything before running inference. So lets think a bit more how we can avoid...

Maybe we need another approach? Since the algorithm should not change and only the types change, how about we have create a template implementation using preprocessor defines to choose arithmetic...

the code generator still does not support a type subsets (ignore specific types), which may also mitigate, but not solve this problem.

> Some types like (`int32`, `int16`,...) are stored in the same variable. So if for have `int8`, we would need to read chunks of 8 bits rather than the whole...

Would prefer using the stack or pointer instead of a malloc call, since we wanted to reduce malloc calls in helpers. What do you think about introducing a macro library...

atm the `execute_operator_...` code is just a placeholder until the threading/job handling is generalized. the plan is to create a callback structure for jobs that are passed to some kind...

@Coderitter-GmbH hope you can use this to port your operator. move your operator files someplace, generate an operator template with this frontend and fill in the missing pieces.

> Love the idea. I'm getting an error with: > > ``` > $ ./gen_template.sh ai.onnx Log 1 > > find: -printf: unknown primary or operator > usage: onnx_generator [-h]...

> It works for me so far. The only thing I have to complain, is that it is a bit slow. It takes about 3 seconds on my laptop. How...

> `time ./gen_template.sh` > real 0m3,865s > user 0m4,108s > sys 0m1,675s > > It is true that 4 seconds are not a huge deal. I just didn't expected it...