Embed Theano

[Alberto Orlandi]

Hi,
I'm trying to embed theano in a C++ program and I have question about the CVM. If I have a function that can be compiled to C code, when I execute that function from python, the cvm is called and executes the function directly in C. Am I right? In that case is there a way to call cmv from C code ( using CPyhon and numpy C API)?

Thanks
                     Alberto

[Frédéric Bastien]

Hi,

The CVM do not have a C interface. If you want to use the CVM, you will need to add a c interface or use the python interface from C. This is possible.

The other option is to use a prototype we have that use the C linker instead of the CVM linker. The prototype is more a proof of concept. It allow to generate a c file that can be compiled with as a shared library for one Theano function. This also generate an example C program that use it from C.

I guess the easiest is to use the python interface in the current state of Theano. If you want to use the other option, you probably need to work on Theano:

- to add a C interface to the CVM (probably the second easiest)

- help advance the prototype

If you have questions/comments, do not hesitate.

Fred

--

---
You received this message because you are subscribed to the Google Groups "theano-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to theano-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alberto Orlandi]

Hi,
I have some spare time, I can try to do some work on that prototype. Where I can start?


              Alberto

[Frédéric Bastien]

Hi,

I made an issue with some information of what to do:

https://github.com/Theano/Theano/issues/2722

So the first step would be to rebase my branch with the prototype, then make a user interface to activate it.

After that, I think it would be to add the missing case that you presonaly need. (maybe some work for the Theano gc for example, or add support for constant, or shared variable)

If you have any questions/comments do not hesitate.

Fred

[Alberto Orlandi]

Ok, thanks

            Alberto

[Alberto Orlandi]

Hi,
In the end I had less spare time than I hoped.
First things first, I want to try the prototype. What is the best thing: using directly the branch or merge it?

Thanks
                Alberto

[Frédéric Bastien]

Using the branch should allow to test it faster, but it is based on an old Theano, so less op will be available.

Fred

[Alberto Orlandi]

Hi,
I made some tests, but I had a problem with numpy. If I am right, the code generated by that branch uses the api of version 1.7, but in my environment I have the 1.9. I can use virtualenv and install the 1.7 version, but I think that maybe is more useful to work on merging the branch so now I working on that.

                       Alberto

[Frédéric Bastien]

OK. Thanks for the update.

Fred

[Alberto Orlandi]

Hi,
I merged the shared library branch with the last version of Theano. For 'standard' functions it seems to work. When I compile a function with the CLinker and c callable=True to generate the 'shared library' version ( the 'complete' .so and the corresponding header file) I get an error because this files are created in the same directory of the 'standard' version and so there are to .so files (with different names) in the same directory.
Clearly I made some mistake when I merged the branch.
Now I try to find how the shared_library branch generates two different directories. Maybe you remember / know how it was done.
Thanks!

                                              Alberto

P.S. Why it is needed that there must be only one .so file in a temporary directory?

[Frédéric Bastien]

Hi,

The branch do not generate many directory. It was doing all in the same compiledir. What error do you have?

Fred

[Alberto Orlandi]

Hi,
I solved the problem. It was an error I done when I merged the branch. The CLinker generated an .so file also from the exec.cpp and no the exec binary and so in the same directory there was two .so file.

Now I'm working with the generated c++ code. By the way, you know why in the newer branch there was added anonymous namespace declaration in c++ file? If I remember it right, if we want to use the code as shared library we can't use an anonymous namespace.

               Alberto

[Frédéric Bastien]

Hi,

Can you put a link to your rebase in the issue related to that?

For the namespace, I forgot. If you find, put a comment to explain why:) I needed the prototype to work on Windows. It could be needed there.

I'm sure it was working, so my guess is that the unnamed namespace didn't caused problem in the way I used them (Or I added them very late and didn't test corre that change? Less probably, but still probable)

thanks

Fred

--

[Alberto Orlandi]

Hi,
I deleted the anonymous namespace declaration and I made some changes to the ccmodule.py and It seems to work.

Now my problem is that the exec binary try to use, at runtime, the numpy of my system (1.7) but I compiled it on anaconda with numpy 1.9. It is a linker problem,I am thinking to add an rpath flag.

My branch is at:
https://github.com/AlOa/Theano/tree/embed_theano

The name is no the best and it is not merged with the latest master ( It is merged with the master at 13 of  April ).

                         Alberto

[Frédéric Bastien]

That is great.

About the namespace (see previous email), Arnaud, you know more that. Do you have a comment? Maybe it was you that added it to fix problem on the Mac, but I'm not sure if that is that or not, can you tell something about this?

Fred

--

[Alberto Orlandi]

Hi,
now I'm working on the cache system for the 'c callbable' functions. Every time you compile a function with to generate a shared library a new temporary directory is generated because the cache mechanism not work in that case. When I  will solve that problem I will start to make some real test and to think a possible user interface.

              Alberto

[Arnaud Bergeron]

The anonymous namspace was a change to not expose all symbols on Mac where the modules are loaded with RTLD_GLOBAL and we have symbol collision.  Now we pass -fvisibility=hidden to the compiler so all symbols are hidden by default, so I guess it's not needed anymore.

But I am curious to see why the namespace interferes with the shared library creation. What problems does it create?

--

[Frédéric Bastien]

I'm not sure I understand correctly or it could be my memory that is fuzzy. But I understand you have a problem with the cache. There is no doc for it, (some some high level stuff at the top of the file/class) if you have questions, do not hesitate.

Fred

--

[Alberto Orlandi]

Hi,
the problem is that unnamed namespaces are accessible  only within the file in which  they are created, and we want to use the generated code as shared library. You can use an unnamed namespace only for the "private" implementations and define some public interfaces, but I think that, if it is possible, it's better not to  use them.


                        Alberto

[Alberto Orlandi]

Hi,
I found a  strange problem. I'm trying to add the cache's mechanism to the c_callable function and I get a error because the code tries to add the header file after that  the DynamicModule is finalized ( there is an assert not self.finalized in the DynamicModule add_header_code function) but if I disable the cache's mechanism all work well.
You know if the code generation is called two times if the function to be compiled has a cache key?
Thanks

                    Alberto

[Alberto Orlandi]

With a little debug I found that the problem is due to a different program flow in the two cases: with and without the cache's mechanism. The module_from_key() first calls the DynamicModule code function that set the finalized flag, after that it compiles the code and in that stage the add_include function is called and the assert not self.finalized fails.
I comment out the assert in the add_include and all seems to work fine.
Now I will make some tests....before that, do you think that is necessary to generate exec file? Once you have the library with the corresponding header file you have everything you need. Clearly we must add some examples to show how to call the library's functions from a C programs.

Alberto

[Frédéric Bastien]

I think the commenting of self.finalized should be fixed otherwise, but this can be done later. I don't have time to investigate this. Can you just put a comment with a TODO that this need a beter fix, that way, we shouldn't miss it later.

I think if we can keep the generated of the example, it is better. This also help for tests. But if it get in the way, this could be moved for only the tests.

thanks

Fred

--

[Alberto Orlandi]

Hi,
now I'm working to add the support for scalar constants in the c_callable functions. Looking at the c++ code generated by the 'standard' theano  for the simple function f(x)=x+1, I see that it takes two input tensors, so I think that there is some other part of theano that broadcast the the constant and  then calls  the c function. Am I right? Can you give me some hints of where it happens in the code?

                  Alberto

[Frédéric Bastien]

It is in the node Elemwise that the broadcast is done.

I think you need to put in the c_support_code something like this for constant:

PyArrayObject* contant_name = NULL;

then in the module init code, do something like this:

constant_name = PyArray_SimpleNew(int nd, npy_intp* dims, int typenum)

(dtype_constant_name*)PyArray_DATA(constant_name)[0] = VALUE

Fred

--

[Alberto Orlandi]

Ok, thanks

By the way: I merged the latest branch with my embed_theano branch.I will try to keep it updated.

               Alberto

[Alberto Orlandi]

Hi,
now I have a better understanding of what happen when we compile a function with some constants. For simplicity take f(x)=x+c the value of is unimportant, the c code generated by theano is the same for every value of c. Theano generates two c functions, one for broadcasting the constant to the same dimension of x and the other to do the add.
The problem is that when we compile the function to generate the shared lib version, only the code for the add operation is generated as shared lib, while the broadcast function has the normal form. I don't know this happens
Clearly one can call the add code with the right arguments, modifying the c init function or using directly the op struct init function. But I think it is better to have a shared library for every function, so also for the broadcast. I'll work on this.


                      Alberto

 

[Frédéric Bastien]

Hi,

I don't understand all what you said. But I'll guess some explanation of Theano in case that it help you.

Theano normally compile each apply node in a different module.

But for the shared libarary, I think it is better (at least at start) to use another mechanism that compile the full function graph in one module. This make the generated file easier to compile/move/reuse I think then having 10s or 100s of different shared library that the developer would need to use/compile/link.

Is this version you are working on?

Fred

[Alberto Orlandi]

Yes, in the end, I want to have a single shared library for the function graph. Yesterday I was confused by an error: If I compile:

x = T.vector('x')
linker = theano.gof.CLinker(c_callable=True)
mode = theano.Mode(linker=linker)
f = theano.function([x], x+2, mode=mode)
 
I get two module functions. One is compiled as shared library, the other, the constant folding opt , is compiled as standard module. The c_callable parameter of the Clinker is only used for the add function. If I right the constant folding is called by the graph optimizer, which not uses the c_callable parameter.
So, for start, I tried to find a way to use  the c_callable parameter also in optimize phase. to get a shared lib also for the constant folding.  But maybe I'm looking in the wrong direction.

                      Alberto

[Frédéric Bastien]

Hi,

constant folding happen during graph optimization. It do not reuse the linker the user provided manually. This is normal.

You do not need the module generated by the constant folding optimization. You just need the module for the full function that use your linker. It will use the optimized graph. So, just forget about the modules generated during optimization and look only at the final module.

To know the final optimized graph, you can do:

f=theano.function(...)

theano.printing.debugprint(f)

Fred

[Alberto Orlandi]

Thanks,  now I understand.

In the case that there is a constant in the function only the c_int() function must be changed, adding  the code you suggested to initialized  the constant value.

I tried to do some test initializing the struct directly in my c++ file, but I got a segfault on PyArray_Check macro. I googled it but I did not find a solution, has something to do with  import_array. But if I change the c_int() in the shared library and I recompile it, all works fine.

Now I must find a way to directly generate the right c_int() function if there is some constant in the function to be compiled.

               Alberto

[Alberto Orlandi]

Hi,
I added the management of constants in the generation of the shared library. I modified the c_init function so that the constants are initialized an array of size one. The solution  is no elegant but I did not  want to modify the code generation to be sure that in standard case everything works as before.

The constants are initialized with zero value. In the calling c code one must change this value with the their actual value. A better solution is to initialized them with the value passed to the function, but this solution has a problem. The hash value used by the functions's cache does not use the values of the constants so two functions like f1(x)=x+c1 and f2(x)=x+c2 have the same hash and if I compile f1 and I change the value of c1 Theano does not recompile the function.
I don't if is better to change the how the hash is calculated ( only  for c_callabe functions ) or to use the current solution

                 Alberto
 

[Alberto Orlandi]

Hi,
in the end I chose to initialize the constants with their actual value and I modified the hash generation for c_callabe function so that functions differing only in the value of the constants have different hashes.

This version also manages tensor constants of different shape.

Now I will work on a tentative tutorial for using the shared libraries generated by theano in a C++ program

                Alberto

[Arjun Jain]

This is very cool, I look forward to the tutorial. It will be super useful to call a theano function from a C++ program, looking forward!

Best,

Arjun

[Frédéric Bastien]

Thanks for the updates. I think you took the best solution.

Fred

[Alberto Orlandi]

Hi,
I added a makefile generation. So, when you compile a shared library, in the temp dir you find a makefile that can be used to compile c++ program that use the shared library. I think this can simplify the use of the shared libraries.
.

             Alberto

[Frédéric Bastien]

Good idea.

[Alberto Orlandi]

Hi,
I added a howto on building and using shared libraries. I hope that can be useful.

           Alberto

[Frédéric Bastien]

Can you rebase now or very shortly?

We will do shortly big change to support python 2 and 3 with the same code base. Doing a rebase now will be very useful to help move the code to Theano later.

Thanks.

Fred

--

[Alberto Orlandi]

Hi,

I merged it with master.  I have started to rebase, but it turn out to be a little more complicated that I thought. I hope I will have time to finish in next few days.

           Alberto

[Alberto Orlandi]

Hi,

I had finally rebased the brach.ùù

           Alberto

[Frédéric Bastien]

I think he overrieded the branch in his repo:

https://github.com/AlOa/Theano/commits/embed_theano

Fred

On Sat, Aug 8, 2015 at 12:50 AM, Arjun Jain <arju...@gmail.com> wrote:

How can I find this rebase? Thanks!

[Arjun Jain]

Thanks a lot Fred. When I try to run the exec that Alberto produces, I get the following error. Note this is on OS X (I want to make it run on OS X).

Do you have any idea what is going on? Thanks a lot in advance.

If it helps, nm e34908c1bf4e1be2c3bc98537430b5dd.so |grep _PyCObject_Type 

gives U _PyCObject_Type

------------------------

dyld: Symbol not found: _PyCObject_Type

  Referenced from: /Users/ajain/.theano/compiledir_Darwin-15.0.0-x86_64-i386-64bit-i386-2.7.10-64/tmpTNtZV3/e34908c1bf4e1be2c3bc98537430b5dd.so

  Expected in: flat namespace

 in /Users/ajain/.theano/compiledir_Darwin-15.0.0-x86_64-i386-64bit-i386-2.7.10-64/tmpTNtZV3/e34908c1bf4e1be2c3bc98537430b5dd.so

Trace/BPT trap: 5

------------------------

[Arjun Jain]

And on linux, it seems to be working on tmp dir that does not exist? However, g++ complains of some other error. So, in the error bellow, directory tmp7h6ybX actually does not exist for me. Please let me know if you have any idea what is going on and how can I fix it. Thanks a lot in advance!

python doc/shared_library_howto/function.py 

===============================

00001 #include <Python.h>

00002 #include <iostream>

00003 #include "theano_mod_helper.h"

00004 #include <math.h>

00005 #include <numpy/arrayobject.h>

00006 #include <numpy/arrayscalars.h>

00007 #include <vector>

00008 #include <algorithm>

00009 #include "/home/ajain/.theano/compiledir_Linux-3.16--generic-x86_64-with-Ubuntu-14.04-trusty-x86_64-2.7.6-64/tmp7h6ybX/69b3d6139dc9f89fa029d3ce94ce3b32.h"

00010 //////////////////////

00011 ////  Support Code

00012 //////////////////////

00013

00014 // Mapping: variable name -> struct internal stogare

00015 // x->storage_V7

00016 // y->storage_V13

00017 // Elemwise{mul,no_inplace}.0->storage_V17

00018 // CGemv{inplace}.0->storage_V1

00019

00020 int main(int argc, char *argv[]) {

00021 Py_SetProgramName(argv[0]);  /* optional but recommended */

00022 Py_Initialize();

00023

00024 // Those print are there to help debug import of python module

00025 PyObject * numpy = PyImport_ImportModule("numpy");

00026 printf("After import numpy %p\n", numpy);

00027 PyErr_Print();

00028 //import_array{,1,2} can be called many times without problems.

00029 import_array1(1);

00030 printf("after import_array1()\n");

00031

00032 __struct_compiled_op_69b3d6139dc9f89fa029d3ce94ce3b32 *struct_ptr = cinit();

00033 int run_ret = 0;

00034 if(struct_ptr){

00035    

00036   PyObject* storage_V7_data = PyArray_Arange(0., 12, 1.,NPY_FLOAT64);

00037   npy_intp storage_V7_dims[2] = {3,4};

00038   PyArray_Dims storage_V7_newshape;

00039   storage_V7_newshape.ptr = storage_V7_dims;

00040   storage_V7_newshape.len = 2;

00041   PyObject* storage_V7_value = PyArray_Newshape(

00042   (PyArrayObject*) storage_V7_data,&storage_V7_newshape,NPY_CORDER);

00043   PyList_SetItem(struct_ptr->storage_V7, 0, storage_V7_value);

00044   storage_V7_value = NULL;

00045            

00046   PyObject* storage_V13_data = PyArray_Arange(0., 3, 1.,NPY_FLOAT64);

00047   npy_intp storage_V13_dims[1] = {3};

00048   PyArray_Dims storage_V13_newshape;

00049   storage_V13_newshape.ptr = storage_V13_dims;

00050   storage_V13_newshape.len = 1;

00051   PyObject* storage_V13_value = PyArray_Newshape(

00052   (PyArrayObject*) storage_V13_data,&storage_V13_newshape,NPY_CORDER);

00053   PyList_SetItem(struct_ptr->storage_V13, 0, storage_V13_value);

00054   storage_V13_value = NULL;

00055            

00056   printf("after cinit()\n");

00057   //Function execution

00058   run_ret = struct_ptr->run();

00059   printf("run() from the shared library returned=%d\n", run_ret);

00060

00061   if(run_ret==0){

00062    

00063                 //PyList_GET_ITEM return a borrowed reference

00064                 PyObject *tmp_storage_V17=PyList_GET_ITEM(struct_ptr->storage_V17, 0);

00065                 PyObject_Print(tmp_storage_V17, stdout, Py_PRINT_RAW);

00066                 printf("\n");

00067                

00068                 //PyList_GET_ITEM return a borrowed reference

00069                 PyObject *tmp_storage_V1=PyList_GET_ITEM(struct_ptr->storage_V1, 0);

00070                 PyObject_Print(tmp_storage_V1, stdout, Py_PRINT_RAW);

00071                 printf("\n");

00072                

00073   }else if(run_ret != 0){

00074     // See out_print to know why we can't call PyObject_Print on win32

00075     PyObject *str_err = PyObject_Str(struct_ptr->__ERROR);

00076     //PyString_AsString return a ptr to the internal representation.

00077     printf("Error: %s\n", PyString_AsString(str_err));

00078     Py_CLEAR(str_err);

00079   }

00080 }else{

00081   printf("cinit() failed!\n");

00082   return 1;

00083 }

00084 delete struct_ptr;

00085

00086 printf("main end, before Py_Finalize\n");

00087 Py_Finalize();

00088 return run_ret;

00089 }

00090        

00091

===============================

Problem occurred during compilation with the command line below:

/usr/bin/g++ -g -O3 -fno-math-errno -Wno-unused-label -Wno-unused-variable -Wno-write-strings -march=core-avx2 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=25600 -mtune=generic -D NPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION -m64 -fPIC /home/ajain/.theano/compiledir_Linux-3.16--generic-x86_64-with-Ubuntu-14.04-trusty-x86_64-2.7.6-64/tmp7h6ybX/69b3d6139dc9f89fa029d3ce94ce3b32.so -fvisibility=hidden -I/usr/local/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/python2.7 -I/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/gof -I/usr/local/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/python2.7 -I/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/gof -o /home/ajain/.theano/compiledir_Linux-3.16--generic-x86_64-with-Ubuntu-14.04-trusty-x86_64-2.7.6-64/tmp7h6ybX/exec /home/ajain/.theano/compiledir_Linux-3.16--generic-x86_64-with-Ubuntu-14.04-trusty-x86_64-2.7.6-64/tmp7h6ybX/exec.cpp -L/usr/lib -lpython2.7 -lpython2.7 -lblas

/tmp/cceHgXzL.o: In function `main':

/home/ajain/.theano/compiledir_Linux-3.16--generic-x86_64-with-Ubuntu-14.04-trusty-x86_64-2.7.6-64/tmp7h6ybX/exec.cpp:32: undefined reference to `cinit()'

/home/ajain/.theano/compiledir_Linux-3.16--generic-x86_64-with-Ubuntu-14.04-trusty-x86_64-2.7.6-64/tmp7h6ybX/exec.cpp:58: undefined reference to `__struct_compiled_op_69b3d6139dc9f89fa029d3ce94ce3b32::run()'

collect2: error: ld returned 1 exit status

Traceback (most recent call last):

  File "doc/shared_library_howto/function.py", line 10, in <module>

    f = theano.function([x, y], [2 * x, T.dot(y, x)], mode=mode)

  File "/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/compile/function.py", line 310, in function

    output_keys=output_keys)

  File "/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/compile/pfunc.py", line 523, in pfunc

    output_keys=output_keys)

  File "/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/compile/function_module.py", line 1526, in orig_function

    defaults)

  File "/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/compile/function_module.py", line 1390, in create

    input_storage=input_storage_lists)

  File "/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/gof/cc.py", line 1074, in make_thunk

    keep_lock=keep_lock)

  File "/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/gof/cc.py", line 1014, in __compile__

    keep_lock=keep_lock)

  File "/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/gof/cc.py", line 1576, in cthunk_factory

    key=key, lnk=self, keep_lock=keep_lock)

  File "/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/gof/cmodule.py", line 1116, in module_from_key

    module = lnk.compile_cmodule(location)

  File "/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/gof/cc.py", line 1447, in compile_cmodule

    out_filename='exec')

  File "/usr/local/lib/python2.7/dist-packages/Theano-0.7.0-py2.7.egg/theano/gof/cmodule.py", line 2206, in compile_str

    (status, compile_stderr.replace('\n', '. ')))

Exception: ("Compilation failed (return status=1): /tmp/cceHgXzL.o: In function `main':. /home/ajain/.theano/compiledir_Linux-3.16--generic-x86_64-with-Ubuntu-14.04-trusty-x86_64-2.7.6-64/tmp7h6ybX/exec.cpp:32: undefined reference to `cinit()'. /home/ajain/.theano/compiledir_Linux-3.16--generic-x86_64-with-Ubuntu-14.04-trusty-x86_64-2.7.6-64/tmp7h6ybX/exec.cpp:58: undefined reference to `__struct_compiled_op_69b3d6139dc9f89fa029d3ce94ce3b32::run()'. collect2: error: ld returned 1 exit status. ", "[Elemwise{mul,no_inplace}(TensorConstant{(1, 1) of 2.0}, x), CGemv{inplace}(AllocEmpty{dtype='float64'}(Shape_i{1}(x)), TensorConstant{1.0}, InplaceDimShuffle{1,0}(x), y, TensorConstant{0.0})]")

[Arjun Jain]

Hi again,

For OS X, I figured how to fix it, so please don't bother. On linux I have problems but I don't care about for now. 

However, can you please explain to me the limitation with the shared variables, and why they won't work and what is the way to make it work? Thanks a lot again.

Best,

Arjun

[Alberto Orlandi]

Hi,
in the current implementation, you can use shared variables, the problem is that they are treated as normal input variables, the code does not initialize them. I'm working on this problem in my spare time, but for now I do not find a solution.

              Alberto

[Frédéric Bastien]

Alberto, what about just picking/unpickling Theano shared variables? There this those special dump/load function that make pickle better with numpy ndarray object:

http://deeplearning.net/software/theano/library/misc/pkl_utils.html?highlight=dump#theano.misc.pkl_utils.dump

I think this implementation could be relatively easy to do. What do you think?

Also, I started a quick review and I have a few small comments. Can you make a PR with this branch? This make commenting much easier.

thanks

Fred

--

[Alberto Orlandi]

Hi,
I will merge the branch with the latest master,  make a rebase and then I will make a PR.

For the shared variables. The problem is that in  code_gen (theano/gof/cc.py) I could not find a simple way to differentiate normal inputs variables from the shared ones. They are all in self.input


             Alberto

[Frédéric Bastien]

I think this information isn't available at that place. When I'll check the PR, I'll check where we could take this (or where we should move the information).

thanks

[Alberto Orlandi]

I made the PR.

                Alberto

[Alberto Orlandi]

Hi,
if someone is interested I add the management of shared variables.
The branch with the latest changes can be find in my repo

https://github.com/AlOa/Theano/commits/embed_theano

the documentation on how to use the code can be find in doc/tutorial/shared_library_howto/howto.tx
Remember that this functionality is experimental and use it in your code can be tricky.
 
                                     Alberto

[Frédéric Bastien]

Thanks. I'll try to check that next week. Do you know of this work with the GPU? If not don't work on it, we are moving to the new GPU back end very shortly...

[Alberto Orlandi]

Hi,
I did not test on GPU, so I don't know if it works. Now I'm working on a more realistic example on how to use of the shared library.

             Alberto