Efficiency?
Kreyren opened this issue · 17 comments
I would love to use this for scripting of downstream items on my package manager.
@Wafelack Will you handle the efficiency so that it's not so slow?
Hello,
I plan to make it run over a Virtual Machine in the future, so the performance could be improved a lot.
Why a virtual machine?
For two majors reasons, the first is learning how to make a language vm, the second is because i think that it is easier to have good performances on a VM.
Do you think that you can make it more efficient then lisp using VM?
FWIW I would suggest handling to LLVM https://llvm.org/ which is what rustlang is doing as i see it having a bigger potential to be more efficient and the value from learning it is also more significant or going the lisp way and compiling everything into a binaries that are then executed.
Hey guys, I was thinking of having a transpiler for Orion because going through "interpreter.rs", it seems like Orion can be transpiled quite efficiently to a dynamically typed language like Lua or perhaps even to a statically typed functional one such as OCaml/Haskell. This could provide a solid middle ground between @Wafelack's suggestion of writing a VM and @Kreyren's suggestion of using LLVM. I might even be able to contribute to such a project since I have also created a purely functional, dynamically typed language but the only major difference(other than it not being a LISP) is that it's lazily evaluated.
Meh kinda loses its meaning if its just stupid translator to a different lang imho. O.o
I was hoping to integrate it into my package manager along side of rlisp tbh
But FWIW i aint agains it being a cargo feature to be used on demand during compilation
What language is this package manager written in? And more specifically what integration do you plan? Since writing a straight compiler to LLVM seems difficult for a language that has closures and other insanely high-level constructs but I feel like transpiling to C/Rust/another language would be easier and would also provide benefits similar to AOT compilation to LLVM. JIT though, is just another beast.
Also, why would transpiling make it lose its meaning?
What language is this package manager written in? @ameerwasi001
Designed to be rewritten in all langs with custom file hierarchy and builder (expected to build itself as a package manager for programming langs) to allow cherrypicking of lang per component with preference for rustlang.
And more specifically what integration do you plan? @ameerwasi001
Ideally i want to make an interpretor to which i can parse a file with processing instructions and link it to a functions from library that has orion built-in and that calls orion from the system depending on choices made during compilation.
I don't think that LLVM is difficult to integrate here, but i agree that it takes more resources to integrate compared to lang translator that in it's simplest form is just optimizing regular expression.
Also, why would transpiling make it lose its meaning?
LISP is a unique lang that compiles itself, this is lisp-inspired lang, so i would argue it being better if it follow these steps instead of wasting time with transpiling that would just make it into "another generic lang" as the uniqueness, efficiency and compatibility of this lang is what is making me interested in it. ^-^
If Orion doesn't do any runtime modifications to the AST then I would argue that all of the merits you list can be kept while transpiling to another programming language but for your specific case, I do agree that transpiling would make integration difficult.
I think if we limit AST modifications to macros at the compile-time, we can effectively compile it to most programming languages without changing any of its design. As you point out, LLVM would not be difficult but it would not be an easy task either and I do not see a very good reason to go with it over something like transpiling to C.
i personally do not tolerate any inefficiency in my code thus why i think that LLVM would be more efficient compared to C or even making a custom thing, but in general the more efficient orion is the more usable it is.
Just for the lambda system in the language, it would require a rewrite of the parser or at least of another big part of the core in order to be able to linearize everything (I'm thinking in particular of the problem of closures when I refer to lambdas). Anyway, all this to say that it's not that easy to prepare the language for compilation.
Unless LLVM can handle this easily, I have never been interested in closures and their compilation with LLVM..
@Kreyren So I moved Orion to a VM, and that improved efficiency a lot. You can check the compiler branch and take a look at the benchmarks.
Ehh based on your benchmarks that seems to make it less efficient in comparison to old orion?
FWIW would prefer orion to be more efficient then python at least, note low-power devices being a concern for my use.
Ehh based on your benchmarks that seems to make it less efficient in comparison to old orion?
I talked about the compiler branch. https://github.com/orion-lang/orion/tree/compiler#ack-3-3
That looks better. Still too slow for me, but that makes it usable.
If it is too slow for you, don't use a toy interpreted language.