10000 Human Consumable Language Independent DSL · Issue #70 · tensorflow/tensorflow · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Human Consumable Language Independent DSL #70

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, 8000 you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sirinath opened this issue Nov 10, 2015 · 22 comments
Closed

Human Consumable Language Independent DSL #70

sirinath opened this issue Nov 10, 2015 · 22 comments

Comments

@sirinath
Copy link

Is there a possibility to have a human consumable language independent DSL from which a program in any desired language can be generated.

@sirinath
Copy link
Author

@sirinath
Copy link
Author

Also the generated language specific code can be optimised beyond hand written code.

@bhack
Copy link
Contributor

In the Tensorflow white paper they compare this with Halide DSL in some way.

@moshewe
Copy link
moshewe commented Nov 10, 2015

I think it would be better to converge on standard languages in the scientific community such as R and Python.

ML is too general a field for a single DSL.

@sirinath
Copy link
Author

... or we can devise our own syntax. http://www.nextflow.io/ and Akka Streams syntax seams appealing through both are internal DSL.

@sirinath
Copy link
Author

Another old but somewhat similar effort: http://trad4.sourceforge.net/

@moshewe
8000 Copy link
moshewe commented Nov 10, 2015

Maybe we should wait and see if the need for a new DSL arises... Python is easy to extend into a DSL as it is.

For anyone who wants to create a DSL, I recommend XText.

@sirinath
Copy link
Author

XText is a good choice. I think we should aim for a DSL sooner than later before everything becomes too concrete to change without backward compatibility issues. If you look at some of the DSL, they look more nicer and more concise and also more productive.

@moshewe
Copy link
moshewe commented Nov 10, 2015

More productive for who? For ML professionals who have whole ecosystems in Python, for example?

We should first identify our userbase for the DSL, maybe make it a part of a modeling tool rather than translate directly to code.

@jendap
Copy link
Contributor
jendap commented Nov 10, 2015

@sirinath You have already suggested 8 different DSLs. That is a lot!

Feel free to give a try implementing one or two if you want to! It is actually pretty easy with tensorflow. The entire computation graph can be submitted as protobuf message. All you need to do is a DSL to generate proto message. You can generate nice protobuf code for some 30+ languages and in any of them you can implement any DSL you can think off.

If you do, please, share the results with the community. Others may find it useful too!

@sirinath
< 8000 span class="Button-content"> Copy link
Author

I am not suggesting these that tensorflow should support of be in these DSLs. What I am saying is you should study the body of knowledge what is there in the DSL world and design a new DSL such that you have one code base from which you can generate any of the language specific implementation. In the case of language like Python the DSL will be translated to mix of Python with C++ bindings. In case of C++ and maybe some languages you can have the conversion to pure implantation in that language depending on the translation mechanism.

E.g. if you look at Vert.x (see advance section in http://vertx.io/docs/, https://github.com/vert-x3/vertx-codegen, https://github.com/vert-x3/vertx-codetrans) they have tools in place to do translational from one implementation to another in a rather crude way. If this was in a DSL you have one maintainable code base with a cross translating cartilage to do the code conversion.

This will be bug free and also more optimised than hand written code in the generated languages as you can do specific optimisation perhaps which cannot be done in a generic compiler for the language.

@jendap
Copy link
Contributor
jendap commented Nov 10, 2015

Vertx.io makes it 9 suggested DSLs! You should give it a try implement at least one. Especially the "bug free" is a quality not to be found everywhere.

BTW: python_op_gen.cc can help you get started and generate a lot of the code for you if you tweak it for whatever DSL you have in mind.

@sirinath
Copy link
Author

Above references are just examples or projects you can learn from when designating the new DSL for tensorflow. You can just borrow the good parts from each if they are relevant in designing the new DSL. There need to be one through out DSL which is close to DAG / Dataflow concepts and which can represent among other ML algorithms.

@pannous
Copy link
pannous commented Nov 10, 2015

Not for a "program in any desired language" (you want a generic AST for that) but use caffe protobuf DSL for creating artificial neuronal networks:
http://caffe.berkeleyvision.org/model_zoo.html
https://github.com/ethereon/caffe-tensorflow
https://github.com/pannous/tensor-caffe

@sirinath
Copy link
Author

My main interest is to explore on using this as a Dataflow Computing framework than ML capabilities.

@sirinath
Copy link
Author

But thanks I will check them out.

@ajtulloch
Copy link

https://github.com/ajtulloch/dnngraph is an example of a Haskell EDSL that outputs Caffe/Torch/GraphViz ATM, I'll explore a TensorFlow backend as well if that's handy for folks.

@jendap
Copy link
Contributor
jendap commented Nov 14, 2015

@ajtulloch yes, that is indeed very nice haskell dsl! It would be nice add tensorflow support there.

@k0ala
Copy link
k0ala commented Feb 23, 2016

@ajtulloch That sounds good!

ilblackdragon added a commit to ilblackdragon/tensorflow that referenced this issue Mar 9, 2016
@nodirt
Copy link
nodirt commented Mar 15, 2016

I started experimenting with Go support for TensorFlow and stumbled on need for a common DSL too.

Writing a new internal DSL in Go (or C#, or Ruby, etc) is an option, but in that case there would be two or more ways to define a graph. A Go developer who became accustomed to defining graphs in Go may have a trouble understanding a graph definition in Python, and vice versa. So, I don't think each language should define its own way of defining a graph, there should be one way.

At the same time, I see "Graph construction" in Improve support for C++ only users roadmap item. Does this mean C++ will have its own internal DSL for graph construction? That would be unfortunate.

I'd be much more in favor of one DSL that compiles to GraphDef file that can be loaded in Python/C++/Go/etc. Alternatively, the C++ backend could have a dsl parser, so dsl does not need to be compiled.

@girving girving added the triaged label Jun 9, 2016
@aselle aselle removed the triaged label Jul 28, 2016
@bhack
Copy link
Contributor
bhack commented Dec 26, 2016

A partially correlated coming soon https://www.tensorflow.org/versions/master/resources/xla_prerelease

@tatianashp
Copy link
Member

Automatically closing due to lack of recent activity.

@tatianashp tatianashp removed the stat:contribution welcome Status - Contributions welcome label Feb 8, 2018
lissyx added a commit to lissyx/tensorflow that referenced this issue Apr 15, 2018
Force a PYTHON_BIN_PATH to control action_env
cjolivier01 pushed a commit to Cerebras/tensorflow that referenced this issue Dec 6, 2019
…stream-eigen-update-180718

changing the eigen commit pointer to the official bitbucket repo
copybara-service bot pushed a commit that referenced this issue May 17, 2022
PiperOrigin-RevId: 449111398
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

0