Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ClojureC, a compiler for Clojure that targets C as a backend

github.com

Post reply on HN
Print view View original

61–70 of 89 posts

Re: ClojureC, a compiler for Clojure that targets C as a backend

#61

Post by chc »

pat_punnu wrote: post #21
coldtea wrote: post #17

Earlier quoted context omitted.

What's with this childish "can you prove this, can you prove that" thing? Are you 12 year old? Not everything can (or should) be proved of the drop of a hat in a discussion list -- that doesn't make everything without a formal proof "baseless" opinion. If you cannot see the self-evidentness (sic) of a STRUCTURED API to produce an AST makes it easier to avoid mistakes compared to spitting out text to compile as a C pr…

We work in a technical field. We call ourselves engineers. The academic version is computer SCIENCE. Unsupportable opinions and opinions presented as facts are inexcusable.

Can you prove that? If not, it's just a baseless opinion.

Isn't that just a charming response to get?

Re: ClojureC, a compiler for Clojure that targets C as a backend

#62

Post by masklinn »

densh wrote: post #5

Why C but not llvm? Structured code generation is always better than string-based one.

Generating C is much simpler than LLVM IR (and you can do structured code generation for C: generate and serialize C AST); it's infinitely easier to read and debug; it allows switching compiler; it provides C stdlib to piggyback on with very little overhead.

It's a fine strategy to start with, there are more important things than fucking around with LLVM IR at this point, they can switch to LLVM or a native generator if they get the thing effective and off-the ground.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#63

Post by pi18n »

vidarh wrote: post #38
mullr wrote: post #31

Earlier quoted context omitted.

>E.g. speculatively even looking near call sites by method name That is devious and fantastic. > But to get the most performance out of this you're likely to need to be prepared to do some very basic JIT. Yeah. But the attractive targets here are places where you can't have a JIT: embedded systems and iOS.

When you spend a few years speculating about what it would take to efficiently compile Ruby as statically as possible (I love Ruby, but I hate moving parts), devious becomes second nature... The idea of speculatively looking at method names comes from testing that to create vtables ahead of time for Ruby classes, to avoid hash tables in the common-case. As it turns out, most method on most Ruby classes are the ones i…

That's interesting; Apple's Objective-C runtime has a fast vtable for its most common methods and uses a more expensive lookup for the rest. Doing a static analysis to find other commonly-used methods is like the next step up from there.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#64

Post by AntiRush »

swannodette wrote: post #33
mullr wrote: post #31

Earlier quoted context omitted.

>E.g. speculatively even looking near call sites by method name That is devious and fantastic. > But to get the most performance out of this you're likely to need to be prepared to do some very basic JIT. Yeah. But the attractive targets here are places where you can't have a JIT: embedded systems and iOS.

re: JIT on iOS I've heard of people compiling their own JavaScriptCore (to use Ejecta), is this still an issue? Embedded systems is another story, I'd be far more concerned about Clojure's assumptions about GC.

The JavaScriptCore they are compiling is without the JIT.

You still can't have memory pages marked write+execute, which is what you need for a JIT.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#65

Post by terhechte »

nimrody wrote: post #60
mullr wrote: post #26

This is neat. What worries me about this and similar efforts (like https://github.com/takeoutweight/clojure-scheme ) is that clojure's standard library design assumes that the underlying runtime will be do some kind of polymorphic method inlining. For example: the sequence library is all defined in terms of ISeq, which basically requires a "first" and "rest" to be defined for the data structure in question. These are…

Perhaps you could overcome some of these programs with whole-program-optimization. E.g., the "Stalin" Scheme compiler. It might be interesting to translate Clojure into a subset of Scheme that is widely supported -- and use one of the mature Scheme -> C compilers (Gambit, Chicken, Bigloo) to generate the target executable.

https://github.com/takeoutweight/clojure-scheme

Re: ClojureC, a compiler for Clojure that targets C as a backend

#66

Post by lispm »

pjmlp wrote: post #57
jgalt212 wrote: post #34

As someone who doesn't use Clojure, but watches it fairly closely, I'd say the least appealing part of Clojure is its reliance on the JVM. As such, I'd say efforts such as these are greatly welcomed.

> As someone who doesn't use Clojure, but watches it fairly closely, I'd say the least appealing part of Clojure is its reliance on the JVM. Like it or not, this is what made Clojure successful in the enterprise, at least when compared against other Lisps.

Is that based on numbers or a guess? How many Clojure applications are there in comparison to Lisp or Scheme?

Re: ClojureC, a compiler for Clojure that targets C as a backend

#67

Post by pootch »

Im not a lisper and I likely never will be, but I am encouraged to see the potential for Clojure to move away from the JVM. Its this simple really, I want a 100GB heap with no tuning. That will never happen on the JVM, Since Im not a lisper I dont know what the implications for memory management are, but having lived with JVM GC for over a decade Im done with it and hardware has surpassed JVM's ability to keep up. If it was still a 32 bit world I would have a different opinion. But Im not going to distribute tons of code to clusters just to avoid GC pauses, give me 100GB heap or give me death.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#68

Post by pjmlp »

lispm wrote: post #66
pjmlp wrote: post #57

Earlier quoted context omitted.

> As someone who doesn't use Clojure, but watches it fairly closely, I'd say the least appealing part of Clojure is its reliance on the JVM. Like it or not, this is what made Clojure successful in the enterprise, at least when compared against other Lisps.

Is that based on numbers or a guess? How many Clojure applications are there in comparison to Lisp or Scheme?

Based on guess.

I see lots of Java shops now having Clojure code and talking about it at JUGs and how it enables their business.

You just need to have a look at InfoQ, Skills That Matter, Devoxx or Jax for ongoing talks.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#69

Post by lobster_johnson »

vidarh wrote: post #38
mullr wrote: post #31

Earlier quoted context omitted.

>E.g. speculatively even looking near call sites by method name That is devious and fantastic. > But to get the most performance out of this you're likely to need to be prepared to do some very basic JIT. Yeah. But the attractive targets here are places where you can't have a JIT: embedded systems and iOS.

When you spend a few years speculating about what it would take to efficiently compile Ruby as statically as possible (I love Ruby, but I hate moving parts), devious becomes second nature... The idea of speculatively looking at method names comes from testing that to create vtables ahead of time for Ruby classes, to avoid hash tables in the common-case. As it turns out, most method on most Ruby classes are the ones i…

Out of interest, are you actually working on something like this for MRI? As you say, Ruby is in desperate need of optimization.

Re: ClojureC, a compiler for Clojure that targets C as a backend

#70

Post by pbo »

mullr wrote: post #31
vidarh wrote: post #30

Earlier quoted context omitted.

You can do polymorphic method caching/inlining with a hybrid ahead of time / JIT compiler targeting C reasonably easily. The code fragments required for caching at least will be small, and code to generate them at runtime is not a big deal. I'm playing with a Ruby compiler, and Ruby badly needs these type of optimizations to get fast, so I've spent a fair amount of time looking at it. For a fair amount of cases you c…

>E.g. speculatively even looking near call sites by method name That is devious and fantastic. > But to get the most performance out of this you're likely to need to be prepared to do some very basic JIT. Yeah. But the attractive targets here are places where you can't have a JIT: embedded systems and iOS.

I would love to have a higher-level-than-C language to work with on embedded systems, and Clojure seems good.

However my applications run on systems with very limited resources (and a Harvard-ish architecture, e.g separate data/program memories) and I wonder how far tools like ClojureC could go with regard to these constraints.

Post reply on HN