make python dependency optional (?)
Closed this issue · 10 comments
need (I think)
- cmake switch to disable python
- tests that construct graphs and run them via means other than python script (dot reader? yaml?)
- pythonless factory pattern for dlopening libraries containing ectomodules and looking up available module types
but it is late right now and I don't recall what we discussed about this...
See also the russian troll's input on closed/duplicate #16
My comment was somewhat misunderstood. I think the issue "make python dependency optional" is obvious to desire, my point goes somewhat deeper- python is just one incarnation of things that get in the way of porting a useful c & c++ core to hardware.
Okay, point well taken. But you don't actually propose to e.g. generate VHDL for a graph containing a module that takes something of type boost::shared_ptr<std::map<std::string, variant<int, float, double> > >?
um, well stuff like shared pointers and even more so boost::variant are a huge pain to try to map to hardware. It makes it really hard to statically discern what memory and clock cycles you actually need. Generating VHDL might be provably impossible, because the main (huge) difference there is explicit timing, you can't have a multi-type object where it might take X or Y operations to free it.
I think consciously saying "Ecto is NOT meant for prototyping for mapping to hardware" is acceptable too btw, I just think its a missed opportunity because slightly less trickiness with the types and scriptable wrappers would allow easy hardware mapping.
Mapping to hardware is way out of scope for ecto.
Anything VHDL or what not is either very device specific or so different from C++ constructs that it would be too constraining for modules not intended for an FPGA.
Also, we're focused currently on single process, synchronous graphs, with the same memory address space. What does it mean to translate this to an FPGA?
Compilers exist that will automatically parallelize "raw ansi C and simple
C++" for statically timed code.
It would be cool if a module that wanted to do this could be tested with
Ecto. As opposed to there being so much overhead that one have to start from
scratch rather than remove the wrapping once prototyping was finished.
I am thinking of something like nlopt; part of the reason why I hesitate to
touch the details is that imposing structure from ecto or nlmagick reduces
low-level reusability.
If I can run nlmagick or routines from "numerical recipes in C++" from
multiple ecto modules connected together, my concern is addressed ;-)
On Jun 7, 2011 9:34 PM, "ethanrublee" <
reply@reply.github.com>
wrote:
Mapping to hardware is way out of scope for ecto.
Anything VHDL or what not is either very device specific or so different
from C++ constructs that it would be too constraining for modules not
intended for an FPGA.Also, we're focused currently on single process, synchronous graphs, with
the same memory address space. What does it mean to translate this to an
FPGA?Reply to this email directly or view it on GitHub:
#10 (comment)
But, when have you ever gone from a PC app, to an FPGA and not rewritten at least most of the code?
Boggles my mind. Costs a shit ton, but its quite magical ...
http://en.wikipedia.org/wiki/Catapult_C
http://www.lisha.ufsc.br/teaching/esl/exercise/catapult_docs/catapult_cpp_hw_gd_uv.pdf
http://users.ece.utexas.edu/~gerstl/ee382v-ics_f09/lectures/lecture_14.pdf
On Tue, Jun 7, 2011 at 10:27 PM, ethanrublee
reply@reply.github.com
wrote:
But, when have you ever gone from a PC app, to an FPGA and not rewritten at least most of the code?
Reply to this email directly or view it on GitHub:
#10 (comment)
The target audience for ecto is vision/perception researchers. Elegance of interface and scriptability very clearly take priority over the theoretical future ability to cross-compile to VHDL or Verilog. Even assuming that we could in fact purchase or write something like "Catapult C", there is absolutely NO chance that we will follow the "recommendations on how to write C++ code" in the "Catapult C Synthesis C++ to Hardware Concepts" document. This is completely out of the question.
Moving beyond VHDL generation from ecto...
It will be valuable to serialize some description of a graph made in python and reconstruct the graph in a c++ program.
The two use cases are, just run a predetermined graph, or use the graph in some custom main program.