Hi, J Based on my yet small experience:
Can the Immutable Persistent Data Structures be implemented with a reference-counting scheme rather than a garbage collector? This may improve performance. - Yes, using Smart Pointers. I'm trying something like this, but I'm still in the very beginning. I don't have any info about the behavior of these structures under heavy usage yet. In a similar vein, can the allocation strategy be controlled for these structures in such a way as to optimize cache locality? - AFAIK, not with the default memory allocator. There are some custom memory allocators for C/C++, but I never used it. Can we take advantage of tail-call optimization in existing C++ compilers? - Since you can't control by default the call stack, in a first moment you can't do it. You could do it writing your own way to control the call stack, where it surely will make you develop your own virtual machine or your own compiler with this optimization. Two herculean tasks IMHO. Or you can repeat the Clojure approach and use explicit loop/recur implementing it internally as a loop. It wouldn't have to depend on an existing runtime environment like JVM or JavaScript. * Could this reduce reliance on reflection and increase performance? - You will need to implement your own way to control reflection. There's no guarantee that this could improve performance. * Could a new, clojure-optimized runtime be created that improves performance? - No idea * Could certain anonymous functions be optimized or inlined in a way that improves performance over JVM/JS implementations? - Since the compiler is yours, yes. But I don't know how much effort it would take. * Is there a way to compile C++ code at runtime? This would be essential for the REPL and for Macros. - I never heard about on demand native code generation and execution. I think it could be a paradise for viruses, but I know almost nothing about this field. Unless of course you're generating code for (your own|a) virtual machine, so the rules are different. I hope I helped and I really would like to see this project, if you start to develop it. Regards Plínio On Mon, Apr 25, 2016 at 4:47 PM, JvJ <kfjwhee...@gmail.com> wrote: > > > I've been wondering lately about getting Clojure to compile to native > code, and so I've been doing some looking around. > > There are a few projects that are on the right track, such as TinyClojure > <https://github.com/WillDetlor/TinyClojure> and Ferret > <http://nakkaya.com/2011/06/29/ferret-an-experimental-clojure-compiler/>, > but they are incomplete and don't seem to be under active development any > more. > > I'm wondering about the requirements, how much work it would take, and > whether or not it would be worth it. My current thinking is of a > Clojure->C/C++ compiler. > > So far, I have a few topics for discussion that I'm unclear about that > might be necessary for this kind of project: > > - Can the Immutable Persistent Data Structures be implemented with a > reference-counting scheme rather than a garbage collector? This may > improve performance. > - In a similar vein, can the allocation strategy be controlled for > these structures in such a way as to optimize cache locality? > - Can we take advantage of tail-call optimization in existing C++ > compilers? > - It wouldn't have to depend on an existing runtime environment like > JVM or JavaScript. > - Could this reduce reliance on reflection and increase performance? > - Could a new, clojure-optimized runtime be created that improves > performance? > - Could certain anonymous functions be optimized or inlined in a way > that improves performance over JVM/JS implementations? > - Is there a way to compile C++ code at runtime? This would be > essential for the REPL and for Macros. > > > Let me know if anyone has any thoughts on the matter. > > Thanks > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
