nopeslide

regarding the necessary void pointer I mentioned: If our typeless operator sets up the execution context (parallelized or not) it makes sense to provide some things to the actual executer....

> Is there a reason that the full set of jobs can't just be split among the threads when they are created? this would make jobs and threads dependant on...

> I think the biggest concern is performance impact, which I suppose we won't really know until it's implemented and tested. Worst-case scenario, if it negatively impacts simple cases, then...

> I'm not sure how much help I could be in coding it up (I'd have to go learn more about ringbuffers) but I'm happy to do some benchmarking once...

> @mdhimes @nopeslide Perhaps a `MULTITHREADING_ENABLED` variable and some `ifdef` magic can satisfy all parties? let's wait until the PR is ready, then we see the code/performance impact and can...

> I might be missing something here, but I see batch parallelism more straight forward. We have the following function. > > ```c > inference(Onnx__ModelProto *model, Onnx__TensorProto **inputs, int nInputs)...

@mdhimes I finished #57 which divides execution of an operator into a prepare and execution stage and would be a valid base for any "job based" threading attempts.

good catch, would you open a merge request?

@alrevuelta the [maxpool](https://github.com/onnx/onnx/blob/master/docs/Operators.md#Maxpool) operator has two constraints (`T` & `I`), therefore both must be resolved. Why even a constraint exists for a single type is beyond my knowledge. I could...

@alrevuelta Leaving out the output constraints is a good idea. If we do so, the resolving needs to happen on demand. We could start by resolving each time the operator...