6 ms·
Clojure-Scheme
- radarsat1 15y agoThis is very cool. I like the idea of compiling to scheme. Although: 1.1 seconds for clojure repl, 0.8 seconds for gsc-compiled version. That's actually less of a difference in speed than I'd expected. Not being very familiar with ClojureScript, is this clojure repl running in the JVM or in V8? Edit: on that note, it'd be interesting to compare timing after compiling with Stalin.
- moonchrome 15y agoIIRC it's running JVM/Rhino with the repl you start using scripts/repl.
- swannodette 15y agoClojureScript also ships with a browser REPL which uses a browser's JS engine as the evaluation environment. It's simple to swap in new evaluation environments - I got a basic Node.js ClojureScript REPL working without much effort.
- deleted 15y ago[deleted]
- lukev 15y agoIt's not clear if the 1.1 seconds figure is from the Clojure repl or the ClojureScript repl. They're very different. It says "Clojure" Repl, and in that case it would be running directly on the JVM.
- babebridou 15y agoI wondered, too, so I ran the benchmark on a clojure repl on the JVM on my desktop, it timed at 1028ms.
- amouat 15y agoUnfortunately that doesn't tell us a lot, unless you also do each of the other timings.
- babebridou 15y agoYou're right, that was my plan actually, but I got sidetracked by the cygwin beast, sorry. I timed the fib(36) function from within a clojurescript repl inside a clojure jvm repl, and it returned in 86 seconds. Then I timed the generated js function in a Chrome console with a not-so-minor modification so it would compile, it returned in 13 seconds. The modification in question was inlining the generated cljs.core.truth_(predicate) javascript function. The orders of magnitude don't lie though - for what it's worth, a recursive fibonacci implementation in plain java returns in about 125ms (and depending on jvm warm-up, an array-backed computation is a merry jog of 50 to 300µs, but that's completely off-topic) I have yet to setup gambit and clone the clojure-scheme project. I'm really curious though, I like these 800ms that the author advertises.
- takeoutweight 15y agoI was running in the JVM Clojure repl (and not timing JVM startup time). But this is just a single microbenchmark of the author's choosing so we are right to be suspicious of it! Does anyone know of a collection of Clojure benchmarks that stress various aspects of the runtime? (garbage collection, immutable update, polymorphism, etc.)
- reddit_clone 15y agoI wonder what would be the timing for a small compiled Gambit program doing the same calculation... Clojure is probably bringing in some start-up overhead. If it is indeed just a start-up overhead, it would be less of a problem. Crazy stuff.
- takeoutweight 15y agoI haven't done any rigorous benchmarking, but I suspect clojure-scheme introduces little overhead above what Gambit requires. I'm able to lean on native Gambit gambit constructs for quite a bit (i.e. Gambit records underpin Clojure deftypes).
- losethos 15y agohttp://www.losethos.com/LTHtml/Compiler/BackEnd.html http://www.losethos.com/LTHtml/Compiler/BackEnd.html
- MatthewPhillips 15y agoDo you lose anything by doing this?
- spacemanaki 15y agoClojureScript doesn't have all of Clojure's reference types (just atom, I think) nor STM (yet?) so yes, you do lose something. I would also guess that while (fib 36) might be faster, you would see different results for more realistic programs. Gambit Scheme's garbage collector might not be as strong as HotSpot, which I gather is quite good for long running apps. ClojureScript also doesn't have runtime eval, so you lose that too. For command-line programs, this could be pretty rad, as is ClojureScript on V8. It's also just cool :)
- MatthewPhillips 15y agoI'm already sold on ClojureScript. I can live without runtime eval, so if this is just another compile target I'm in.
- technomancy 15y agoAlso ClojureScript only recently got PersistentVectors; IIUC maps are still copy-on-write.
- takeoutweight 15y agoThe above comments are accurate: clojure-scheme lacks everything that ClojureScript lacks. And clojure-scheme is a month or two behind ClojureScript, so the new structure sharing persistent vectors haven't been ported over yet.
- andrewcooke 15y agoreally cool, but it would be good to see some real benchmarks (ie warm-up time for jvm + correct clojure coding with "recur" etc). also, i wonder how much of clojure is lost through not being able to call down to java?
- chc 15y agoThis is based on ClojureScript, which already doesn't have Java as a runtime dependency.
- julian37 15y agoInteresting, this means you can theoretically run Clojure code on the iPhone: http://jlongster.com/legacy/scheme-iphone-apps.html http://jlongster.com/legacy/scheme-iphone-apps.html
- jlongster 15y agoThat's my old blog, and looks like I broke the link to the newer page with more concise installation instructions. Yikes. I tried to keep those pages around. I'll see if I can fix that soon.
- gukjoon 15y agoThis is awesome, but what gives me pause is the part where you have to write a foreign function interface for every single Carbon API call. Also, I would assume that Cocoa is completely unavailable when going to C. Is that correct? I'm very happy to see the multi-platform vision of Clojure becoming closer to reality. I'm not in the "write once, run everywhere" camp. That goal is a bit ridiculous, but the choice of VM and the choice of language should be independent decisions. I like Erlang's VM a lot, but the language itself is not very nice. When writing iPhone code, I don't want to be forced to use Objective C.
- jlongster 15y agoEvery new language/environment has the problem of needing interfaces into the lower-level system. If this takes off, you can expect the people to build the FFIs and share them. If not, usually it's not too difficult to only wrap the calls that you need. There are also methods for automatically generating FFIs, although that only works with certain APIs. Cocoa is definitely accessible from C. Objective-C is just a superset of C, so if you compile all the generated C files as Obj-C you can write any Cocoa code you want.
- chc 15y agoI think you have it backwards what subsets and supersede are. The subset (C) by definition does not have everything in the superset (Objective-C), and one of the crucial features missing is Objective-C's object model and message passing. This is not intractable (BridgeSupport and the runtime API should be sufficient), but it will definitely be more work than writing Objective-C directly.
- mark_l_watson 15y agoNice idea. I have used Gambit-C over the years when I wanted to use a high level language and be able to produce small and reasonable fast executables. One thing not mentioned was the memory use: I bet that the compiled to Gambit-c and then to a native executable code uses a tiny fraction of the memory of Clojure running in the JVM. That can be important for some applications.
- MatthewPhillips 15y agoEspecially if it gets dead-code elimination like the closure compiler gives ClojureScript for the Clojure->JS target.
- gtani 15y agorelated (last June) http://news.ycombinator.com/item?id=2713463 http://news.ycombinator.com/item?id=2713463
- MatthewPhillips 15y agoThis is my first exposure to gambit scheme. I just compiled this hello world (in scheme, not clojure): (define hello-world (lambda () (display "Hello world!") (newline))) (hello-world) And it compiles to 5mb. Is this the standard library? Can I expect to more complicated applications to not balloon up in size?
- jlongster 15y agoYes, I assume that's the standard library. It's been a while since I've worked with Gambit but it's typically very fast, small, and portable. I wouldn't expect it to balloon.