I'm writing an interpreted implementation of a new programming language (just for fun). In this implementation language is first being compiled to an intermediate language, which is then interpreted by an interpreter. Interpreter is written in Mono C#. However I got this idea to translate methods, which return no data to C++ code and then compile this code and launch it at runtime. That way some methods could run faster. Would that be considered as a bad practice/idea?
3 Answers
Would that be considered as a bad practice/idea?
Enh? My first instinct is that you wouldn't gain much in performance. Spinning up a new process and sending in the data is a bit heavyweight.
My second instinct is I'm not sure how general you're going to be able to do it. Just because methods return no data doesn't mean they don't work with data. You're still going to need to be able to turn the interpreter data into some format the C++ code can get at. And since most languages allow side effects, the C++ code will need to be able to make changes and send the data back. No, "then I'll detect if the code has side effects" isn't a viable solution since that's a generally unsolvable problem for languages of any complexity.
If you're going to target a compiled language, you're probably just better off making a compiler to target that language rather than half-interpreting things.
answered Jul 18, 2016 at 17:36
-
The C++ code could be compiled as a shared library, loaded, and executed in process. But still it seems like a remarkably time consuming way of doing it when there are libraries (e.g. LLVM) that are able to it directly without needing to go via C++ as an intermediary. Admittedly, it's a little more complex to generate LLVM bytecode than C++, but only by a tiny amount compared to the rest of the job of writing a language interpreter...– JulesCommented Jul 18, 2016 at 18:14
-
Actually, as @Jules said compiling it as a shared library could be nice looking, but the process of loading this library would be then slower than just interpreting it from c# code. However starting a c++ app from c# to just display "Hello World" is faster than writing Console.WriteLine("Hello World") in c#. The only place c# is faster are loops, where c++ (from c#) has to start many processes, c# runs on just one. And yeah, now it came to my mind that I would have a problem with data sharing.– 107MPCommented Jul 18, 2016 at 20:11
There is a longer history of implementing languages by converting them to a second language and then with compiling it interpting the. C++ and NO were both done this way.
This is what JITters do. It's a good idea, but it won't help performance unless you do it for innermost code - i.e. the code where the program counter is most often found. There's little to be gained by optimizing code that is relatively seldom executed.
It the program spends most of its time waiting for I/O, then optimizing it will also not help, not unless you can eliminate the I/O.
By the way, if you forget writing the interpreter and directly generate C++, that also is a perfectly good way to go. You get both the performance of C++, and access to all of the library functions available for it.
answered Jul 18, 2016 at 18:24
