> And it's small. Currently the interpreter, JIT, GC, and stdlib clock in at about 10.3MB once compiled down to an executable. Oh how the definition of "small" has changed. I actually would like to know how they managed to make something like this so big . To compare, LuaJIT is about 400 KB, and that includes the Lua standard library, a JIT almost certainly more advanced than Pixie's current one, an incremental GC, a…
Pixie – A small, fast, native Lisp
31–40 of 164 posts
Re: Pixie – A small, fast, native Lisp
#32My largely uninformed armchair opinion as to why, is that the author is very performance-driven, and in the end it's very difficult to beat the JVM performance-wise. Lesson: if you want high-perf Clojure, you already have it on the JVM.
Personally, I think there's room for a simple small native Clojure implementation where performance is not top-priority. Small footprint, quick startup, access to native C libs. Still holding out hope for that one.
Re: Pixie – A small, fast, native Lisp
#33What's the state of development of this? Did somebody use it with Raspberry pi? I want to use this over Clojure(only on pi) because I have read Clojure is slow on Raspberry pi(even 3, not sure how true that is). Also, how fast is this? How does it compare to other lisps(or schemes) in terms of speed? Can someone port the benchmarks to https://benchmarksgame.alioth.debian.org .
I posted the link, but am not one of the developers. This got a little attention a couple of years ago, and I thought to look it up today. It has a nice website now at least. I really like the idea behind it (small install, lightweight, fast), but don't know how effective it will be without a larger community. I can honestly do without a lot of libraries as long as there are decent built-ins. I really wish Pixie just…
Re: Pixie – A small, fast, native Lisp
#34As someone who loves both PyPy and Clojure, I wish Pixie was right up my alley. But I don't understand why the choice was made to be ... sort-of like Clojure, but not all the way, as opposed to just-another-Clojure-implementation. Why can't I have a .cljc file that runs on Pixie? (Not voluntelling halgari to do things! I would just like tn understand.)
I tend to agree... but doesn't 'all the way Clojure' imply at least some exposure of an underlying runtime, be it either Java (Clojure) or JavaScript (ClojureScript)?
I'm admittedly a bit behind the curve wrt the latest developments in the Clojure along these lines.
Re: Pixie – A small, fast, native Lisp
#35I find it very hard to work with a mixture of brackets and parentheses. Does anyone else prefer an all-parentheses syntax for reading and typing?
Re: Pixie – A small, fast, native Lisp
#36Interestingly, this is (some of) the output of running the makefile: https://sr.ht/zMyE.png
Re: Pixie – A small, fast, native Lisp
#37Earlier quoted context omitted.
Such as?
I'll give you another. Laziness. It's built in. It's trivial to create lazy lists that generate their contents as you walk down the list. Even infinite lazy lists. The list of all prime numbers. The list of all fibonacci numbers. You can use map, which if I remember my CL, is like MAPCAR. But instead of map, you can use pmap which will do the processing on all of your cpu cores.
Re: Pixie – A small, fast, native Lisp
#38What's the state of development of this? Did somebody use it with Raspberry pi? I want to use this over Clojure(only on pi) because I have read Clojure is slow on Raspberry pi(even 3, not sure how true that is). Also, how fast is this? How does it compare to other lisps(or schemes) in terms of speed? Can someone port the benchmarks to https://benchmarksgame.alioth.debian.org .
Startup is considerably longer than on other platforms (30 sec or so), but I haven't had any issues with runtime performance, and having a Lisp running on what is essentially an embedded platform is very useful.
(It'd be easy to make the argument that my agent code doesn't do much, but it doesn't diminish the fact that Clojure is able to usefully work on an RPi. :-))
Re: Pixie – A small, fast, native Lisp
#39> And it's small. Currently the interpreter, JIT, GC, and stdlib clock in at about 10.3MB once compiled down to an executable. Oh how the definition of "small" has changed. I actually would like to know how they managed to make something like this so big . To compare, LuaJIT is about 400 KB, and that includes the Lua standard library, a JIT almost certainly more advanced than Pixie's current one, an incremental GC, a…
Back in the day, Smalltalk was criticized as bloated because one ended up with stripped binary+image of about 2MB. Someone around that time got SqueakVM+image down to just under 400k. There were specialized Smalltalks in company R&D that got their image down to 45k.