Work in progress about onnx-go HOT 5 CLOSED

Tl;DR: onnx-go is working, but the API will change!

• The bug with the Gorgonia backend has been fixed (hidden in the im2col operator Issue 268 of Gorgonia).
  I have modified the test branch directed-graph (which have a vendorer version of GorgoniaThe tweaked version of Gorgonia). This branch is experimental but ok.
• I have started to write a simple backend (simpler but less efficient than Gorgonia without automatic differentiation). This has helped me to setup a more usable API for the interfaces. OperationApplyer and Operation should be replaced by something more elegant:

// OperationCarrier is any graph that can apply operations on its nodes
// regarding the structure of the graph
type OperationCarrier interface {
        NewOp(s string) (Op, error)
        Apply(operation Op, n graph.Node) error
}

// Op represents an operation to be applied on a node N of the graph G.
type Op interface {
        // Make the operation regarding the node's shape and its surrounding
        // elements inside the graph.
        // For example, the Make operation of the Add operator can take care of broadcasting.
        // please take care that within this method you can use shape, type and dimensions of
        // the children nodes, but (most of the time) not their actual values.
        //
        // WARNING: this is not the actual execution of the operation that should be performed
        // with whatever method at runtime while walking the graph. The order of execution
        // of the operators is not guaranteed at the build phase.
        Make(g graph.WeightedDirected, n graph.Node) error
}

I need to adapt Gorgonia to use this new API.

from onnx-go.

Very cool, hope you continue with this. Being able to convert a model from most any framework into ONNX, then compile (or cross-compile to a different GOOS and GOARCH) a pure Go executable to perform inference with the model, would make deploying models significantly easier, even if inference was not optimized for speed.

from onnx-go.

Thank you very much for this message.

Yes, the project is still actively developed, but as I do it on my free time, it goes not as fast as expected the gorgonnx project was the most advanced part but was suffering from a bug I did not find.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Kernighan

From the last two weeks I have decided to change the API; the protobuf conversion is not directly exposed; instead I am exposing an Unmarshal function that takes a pointer to gonum’s GraphBuilder interface (see the branch ˋgraph-builder`).
So far it’s easy to reconstruct the graph (and draw a nice representation with graphviz for example).
It’s also easy to write a backend that will numerically compute the graph.

By now, I am heavily modifying the Gorgonia library to make it compatible with this interface; Gorgonia can do a stable evaluation of the graph and automatic differentiation; it could be able to use it for transfer learning).
On top of that, Gorgonia has Cuda binding; the perf on the CPU is not bad, the perf on the GPU is better ;)

from onnx-go.

A lot of work has been done on onnx-go.

• The API is nearly stable
• onnx-go presents a top-level structure called Model
  • The Model wraps a Backend which is a receiver for the computation graph.
  • The Model fulfills the encoding.BinaryUnmarshaler
• a ComputationBackend is an interface that adds the Run() method to a Backend. This is mandatory for being able to run backend that does symbolic computation (such as Gorgonia)
  • ComputationBackend can be tested thanks to a testbackend package and the onnx test files.
  • Gorgonnx is a special package that fulfills the ComputationBackend interface with Gorgonia.

from onnx-go.

I am closing this issue because the project is now stable enough

from onnx-go.