We are mainly using C++ and want to use Mxnet. I found some discussion that C++ prediction or future extraction slower than Python version ?
Is there any experienced Mxnet C++ engineers to expedite this subject including the a decent way to using Python generated Mxnet model in C++?
prediction.cpp in Mxnet is not so user friendly.
MXNet was built with several frontend languages in mind, and I see no reason why prediction made using Python should be faster than predictions made using C++.
There is a gap in documentation on how to use MXNet with C++ at the moment mostly because the majority of the MXNet community is using Python (same holds true for the deep learning/machine learning field in general). One relevant C++ example you could look into is here.
If you would like to contribute more examples on how to work with MXNet using C++, you are more than welcome to submit Pull requests.
Related
I have explored the models offered with the R parsnip package listed at https://www.tidymodels.org/find/parsnip/ but I cannot find how to execute a generic deep learning model (by which I mean a deep-layered neural network). The closest I can find are mlp and bag_mlp.
By contrast, I know that the caret package supports at least two deep learning packages: https://topepo.github.io/caret/available-models.html.
Does parsnip not offer deep learning (yet) or am I missing something?
We don't have it via parsnip (at least not yet) since it is difficult to write a static set of tuning parameters for a network of arbitrary size and architecture.
If you want a tidy way to fit basic neural networks with multiple simple layers, the brulee package is helpful. brulee_mlp() can fit those (via torch) and has a recipes interface for easier preprocessing and feature engineering.
Also, though not part of tidymodels, there is the excellent luz package by Daniel Falbel. It's a nice interface to general deep learning models (also via torch).
Apologies in advance for the perhaps stupid question. Is it possible to integrate into the CHISEL flow a Scala script that generate timing constraint specifications (SDC) for a given design? e.g. press a button and you get your CHISEL design converted to Verilog along with an SDC file, ready for synthesis.
I currently have such a toolflow in place for VHDL (using python to generate the constraints files). But in VHDL the naming conventions are quite clear, not so sure about the CHISEL backend (also I couldn't find any reference on the web doing this)
Is it possible, or this is just not how CHISEL was intended to be used ?
Thanks in advance !
Chisel has an annotation system to support tracking and linking against signals in the emitted Verilog. I've described this system in a previous question here on StackOverflow: Chisel: getting signal name in final Verilog
There is existing work to leverage this support and build physical design flows, see Hammer which is used by Chipyard.
In Chisel2 there's seems to be a way to generate harness judging by this question.
It seems that the simulation mechanism is a bit different between Chisel2 and Chisel3. Quoted from the Chisel3 wiki:
Chisel2 was capable of directly generating a C++ simulation from the Chisel code, or a harness for use with a vcs simulation. Chisel3 relies on verilator to generate the C++ simulation from the Verilog output of firrtl. See the Chisel3 README for directions on installing verilator.
My question is: Is there a way in Chisel3 to generate verilog harness, similar to Chisel2?
I think you might take a look at
src/main/scala/dsptools/tester/VerilogTbDump.scala
in the dsptools project. The tb stands for test-bench. You may be able to find some clues on getting started. Or hopefully someone else will come along with a better answer.
What are the easiest ways to code a VST plugin?
I'm a sophomore in IT education, and I may need to write a VST as an assigment project for Digital Signal Processing course. This means I will probably have to implement an actual DSP algorithm, so if I'm not wrong, that outrules all graphical modular VST maker software.
I currently have C++ (CodeBlocks + MinGW), Java (Eclipse), Python and Octave at my hand. I can also get Visual Studio, Matlab, or some free language/environment for the task. I have also found Faust which is a functional language and I may learn that for this project, because I enjoy learning new languages.
SynthEdit is probably the easiest way to create a working VST plugin while getting the chance to write low-level DSP code. SynthEdit can be extended with custom C++ modules. You could write a module containing your custom DSP code to satisfy your course requirements while using SynthEdit for the GUI and the other VST 'glue' type code. Writing DSP code is only one small part of building a VST plugin from scratch.
If you must write a VST plugin and can't use SynthEdit or similar environments I think the next easiest way would be C++ and JUCE. I don't use either but AFAIK most plugins are written in C++ and JUCE is often praised.
Other VST framework options exist such as VST.NET or Delphi ASIO and VST Library but these are less widely used and you'll likely be more on your own if you run into problems.
I think there are VST modular synths that allow you to custom program the DSP logic, SynthEdit comes to mind but there are more. Search for 'vst modular synth'.
If you like to venture into the .NET world, VST.NET is excellent for beginners. It has a framework that structures and simplifies the VST plugin standard and comes with samples that demonstrate the common plugin scenarios.
There are several packages out there that help in automating the task of writing bindings between C\C++ and other languages.
In my case, I'd like to bind Python, some options for such packages are: SWIG, Boost.Python and Robin.
It seems that the straight forward process is to use these packages to create C\C++ linkable libraries (with mostly static functions) and have the higher language be extended using them.
However, my situation is that I already have a developed working system in C++ therefore plan to embed Python into it so that future development will be in Python.
It's not clear to me how, and if at all possible, to use these packages in helping to extend embedded Python in such a way that the Python code would be able to interact with the various Singleton instances already running in the system, and instantiate C++ classes and interact with them.
What I'm looking for is an insight regarding the design best fitted for this situation.
Boost.python lets you do a lot of those things right out of the box, especially if you use smart pointers. You can even inherit from C++ classes in Python, then pass instances of those back to your C++ code and have everything still work. My favorite resource on how to do various stuff is this (especially check out the "How To" section): http://wiki.python.org/moin/boost.python/ .
Boost.python is especially good if you're using smart pointers or intrusive pointers, as those translate transparently into PyObject reference counting. Also, it's very good at making factory functions look like Python constructors, which makes for very clean Python APIs.
If you're not using smart pointers, it's still possible to do all the things you want, but you have to mess with various return and lifetime policies, which can give you a headache.
To make it short: There is the modern alternative pybind11.
Long version: I also had to embed python. The C++ Python interface is small so I decided to use the C Api. That turned out to be a nightmare. Exposing classes lets you write tons of complicated boilerplate code. Boost::Python greatly avoids this by using readable interface definitions. However I found that boost lacks a sophisticated documentation and dor some things you still have to call the Python api. Further their build system seems to give people troubles. I cant tell since i use packages provided by the system. Finally I tried the boost python fork pybind11 and have to say that it is really convenient and fixes some shortcomings of boost like the necessity of the use of the Python Api, ability to use lambdas, the lack of an easy comprehensible documentation and automatic exception translation. Further it is header only and does not pull the huge boost dependency on deployment, so I can definitively recommend it.