Refactor/ops step1 : Introduce OpsRegistry to simplify operators development and enable incremental refactoring (#2638)

[imihalcea]

I'm proposing the introduction of an OpsRegistry to manage ONNX operators, along with the implementation of the Sign operator. This change requires minimal modifications but it paves the way for incremental refactoring and the development of a clean, optimized ONNX execution engine separate from individual operations.

Key Changes:

• Introduced OpsRegistry: A registry mapping operator names to their evaluation functions.
• Move the Sign operator: Added the Sign operator using the new registry system.
• 6 new LoC: Modified simple_eval slightly to utilize the OpsRegistry, keeping existing functionality intact.

Impact:

• The modifications are focused and non-disruptive. All current tests pass without changes.
• Sets the stage for further optimizations and refactoring, might lead to a robust and efficient ONNX execution engine.

Next Steps:

If this PR is accepted, I'm committed to:

• Gradually moving other operators to the OpsRegistry.
• Collaborating on enhancements for better execution engine (free obsolete resources, use hardware acceleration if possible etc..).

Regards,

Ionut

[LaurentMazare]

As mentioned in the other issues, I think it would be better to do this in an external crate to start with, this will allow you to iterate quicker rather than having to merge things in the main repo. And if it goes well and end up being a good replacement for the current implementation, we could just deprecate candle-onnx in favor of this other crate.

[LaurentMazare]

You can have it in a repo under your own name to start with, as for the name whatever you feel like :)

[imihalcea]

@LaurentMazare I'll move forward with developing the refactored ONNX runtime engine as an external crate, which I've named candle-onnx-ng (to be disruptive^^). I look forward to sharing updates with you and potentially collaborating down the line.