In the article they mentioned they implemented custom type system for building UI and for the input/output. Interesting, but I don't understand what that means. Are we talking about data type? Custom compiler? Very very elegant ideas I supposed, but I am just not familiar with the concepts...
> The body of the workflow looks like a normal Python function with calls to several operators, which do the real machine learning work. Despite its normal appearances, FBLearner Flow employs a system of futures to provide parallelization within the workflow, allowing steps that do not share a data dependency to run simultaneously.
"Futures" did they implement this with concurrent.futures (which also has a backport prior to Ptyhon 3.2)?
> Operators: Operators are the building blocks of workflows. Conceptually, you can think of an operator like a function within a program. In FBLearner Flow, operators are the smallest unit of execution and run on a single machine.
> Channels: Channels represent inputs and outputs, which flow between operators within a workflow. All channels are typed using a custom type system that we have defined.
When you think about it. What do NNs fundamentally do (once trained)? Map inputs to outputs, right? So they behave like functions. In type theory functions are intensional and we explicitly construct them. With NNs we have our ML algorithm and construct them based on training data and feedback. With regular functions we have explicitly constructed A -> B. Let's represent NNs as A ~> B. Let's represent channels as A||B. Say we have two operators: E ~> F and G ~> H then to join them,
So E ~> F||G ~> H we'd have to construct a channel F||G.
At least this is how I imagine they mean things! Corrections from FB most welcome!
My understanding is that a @workflow decorated function is required to return a DAG of operators. i.e. no actual "calculations" are performed within the function other than whatever "setup" calculations need to be made to populate the operator parameters.
I could be wrong, but the Facebook team has built an Python internal DSL for building DAGs of operators in a procedural manner, helping maintain type-safeness between the input channels and the input-and-outputs of each operator.
Really cool idea.
Because all the channels and operators have typed interfaces, it means they can then materialize UI for configuring any collection of workflows. React would be ideal for this, mapping types to React components. Would be awesome to know if they built up a GraphQL layer on top of the workflow config parameters to get really elegant frontend-backend binding.
> The body of the workflow looks like a normal Python function with calls to several operators, which do the real machine learning work. Despite its normal appearances, FBLearner Flow employs a system of futures to provide parallelization within the workflow, allowing steps that do not share a data dependency to run simultaneously.
"Futures" did they implement this with concurrent.futures (which also has a backport prior to Ptyhon 3.2)?