Is there method to compile the theano function into a C (or C++) source code so that I can modify it and port it to other platform?
I have a look in ~/.theano. The content there is not really helpful.
The directory consists of a lot of tmpXXXX sub-directories and mod.cpp. They are not really readable.
Basically I just need symbolic differentiation and output the result as C source code. If theano does not help, are there any other framework / libraries that could do the job?
Related
I have some C code I would like to optimize. It turns out the Intel C Compiler (ICC) does a much better job at this than GCC but I don't have a copy of that compiler and it is very expensive. However, I can compile it using ICC and get the assembly online at godbolt.org.
If I copy and paste this assembly into a text file, how can I then convert it into a functioning executable?
You will need to begin by making sure that the runtime environment for which godbolt.org compiles is similar enough to your runtime environment, (good luck with that,) because for example you may be using windows, and godbolt.org may be using linux, (or the other way around,) so when you bring the assembly to your system you might be able to convert it to object code, but it will still not link and it will not run.
Then you will need to find an assembler for your platform which is compatible with the syntax of assembly produced by the intel C compiler of godbolt.org so as to produce object files from the assembly files. (Good luck with that.)
Then you will need to find any and all runtime libraries (redistributables) required by code produced by the intel C compiler. (Good luck with that.)
Finally you will need to obtain a linker to link your resulting object files with the runtime libraries to produce an executable. (Good luck with that.)
Sometimes we need honest answers to our questions just so that we can realize how impossible our ideas are.
Uisng compile, Theano generates C++ code along with Cuda code and compiled lib.
Can we reuse those ones after ?
You could load them as a python module from the cache or just copy the code somewhere else and modify it to have a friendlier name.
Also there is a project to have Theano produce a some C code for a library that I know works for some situations but has never really been finished. If you are interested in that I would ask on the theano-dev mailing list.
Perhaps it's just better to describe my problem.
I'm developing a Haskell library. But part of the library is written in C, and another part actually in raw LLVM. To actually get GHC to spit out the code I want I have to follow this process:
Run ghc -emit-llvm on both the code that uses the Haskell module and the "Main" module.
Run clang -emit-llvm on the C file
Now I've got three .ll files from above. I add the part of the library I've handwritten in raw LLVM and llvm-link these into one .ll file.
I then run LLVM's opt on the linked file.
Lastly, I feed the LLVM bitcode fileback into GHC (which pleasantly accepts it) and produces an executable.
This process (with appropriate optimisation settings of course) seems to be the only way I can inline code from C, removing the function call overhead. Since many of these C functions are very small this is significant.
Anyway, I want to be able to distribute the library and for users to be able to use it as painlessly as possible, whilst still gaining the optimisations from the process above. I understand it's going to be a bit more of a pain than an ordinary library (for example, you're forced to compile via LLVM) but as painlessly as possible is what I'm looking for advice for.
Any guidance will be appreciated, I don't expect a step by step answer because I think it will be complex, but just some ideas would be helpful.
I have a FORTRAN 95 program that needs to make some calls to the LAPACK library. I recently found out that Cygwin because it can install LAPACK as an extra option.
Well, LAPACK exists in the /lib/lapack/ directory as "cyglapack.dll". Having only a very informal training in Fortran programming, I have no idea how to reference a .dll library as opposed to a .mod module.
Any suggestions or directions to articles answering my question are GREATLY appreciated!
(P.S. I did search first.. I don't think I know the proper terms to get a useful article.)
Conceptually calling Lapack should be as easy as calling any other DLL. You just have to figure out what link flags and statements to include in your build statement(s).
From Fortran you would, probably, declare as EXTERNAL the functions from Lapack that you wan't to use. This tells the compiler not to bother looking for a definition of the function in your sources, or in a mod file, but that the definition will be provided at link time. This is where the fun begins, as you try to ensure that the signatures of your calls match the signatures expected by the DLL.
I might be able to provide more help if you provide more information. What is your Windows development environment ? What Fortran compiler are you using ? What compile and link tools are you using ? What does your current link statement look like ?
Search terms: dynamic linking fortran
Take a look at this page:
http://sources.redhat.com/ml/binutils/2001-12/msg00471.html
It mentions using dlltool to generate a .a file from a .dll file. Presumably you should be able to link to that in the normal way (usually a lib switch on the compile command).
Otherwise, consider running a linux Live CD for the sake of avoiding the problem in the first place! If you're a student or an academic, see if you can find a server with fortran installed (the IT staff are usually pretty helpful) where you can compile and run your program.
I'm trying to cheaply and accurately predict all the SystemVerilog dependencies for a build flow. It is ok to over-predict the dependencies and find a few Verilog files that aren't sv dependencies, but I don't want to miss any dependencies.
Do I actually have to parse the Verilog in order to determine all its dependencies? There are tick-include preprocessor macros, but those tick-include don't seem to load all the code currently getting compiled. There is a SYSTEM\_VERILOG\_PATH environment variable. Do I need to parse every SystemVerilog file in that SYSTEM\_VERILOG\_PATH variable in order to determine which modules are defined in which files?
One good way (if this is synthesizable code) is to use your synthesis tool file list (e.g. .qsf for Altera). That tends to be complete, but if it isn't, you can look at the build log for missing files that it found.
From a readily compiled environment it is possible to dump the source files
(e.g. Cadence
-- To list source files used by the snapshot 'worklib.top:snap'
% ncls -source -snapshot worklib.top:snap
)
but if you are starting from scratch I am afraid there is no easy solution. I would go for the pragmatic one: have a config file with all the directories that contain .sv files and then compile everything in it. If your project has a proper file structure, you could also modularize this by supplying config files for every major block.
Hope that helps.
I know Questa has a command line option where it will generate a makefile for you with all the dependencies in it after you have compiled your design. I'm not sure if the other simulators have that.
Another option is to browse and dump your compiled library in your simulator. You probably won't get the actual filenames the modules are compiled from, but it'll be a lot easier to parse all your verilog files for the module names that show up in the compiled library.