Re: Porting Clojure to Native Platforms

On Monday, April 25, 2016 at 4:12:13 PM UTC-4, JvJ wrote: > > > > The main motivation would be performance gains. > Sounds like competing performance-wise with the JVM is extremely difficult. My best guess is that a successful new Clojure implemention will have these qualities: * be interpret

Re: Porting Clojure to Native Platforms

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.04.2016 16:29, Jason Felice wrote: > > > On Tue, Apr 26, 2016 at 7:42 PM, Plínio Balduino > mailto:pbaldu...@gmail.com>> wrote: > > > * Is there a way to compile C++ code at runtime? This would be > essential for the REPL and for Macros. -

Re: Porting Clojure to Native Platforms

Relatedly, Chez Scheme was just released as open source: https://github.com/cisco/chezscheme which is a native code optimizing scheme compiler. Maybe there are some ideas that can be drawn from this. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To

Re: Porting Clojure to Native Platforms

That could be hidden from the user by tooling though, perhaps by recompiling the previous version of the namespace with just the form the user wants to load modified. That would also fix one serious problem with per-form evaluation, which is that the line numbers for subsequent forms get messed up

Re: Porting Clojure to Native Platforms

Racket has this feature. On Wed, Apr 27, 2016 at 11:29 AM, Jason Felice wrote: > > > On Tue, Apr 26, 2016 at 7:42 PM, Plínio Balduino > wrote: > >> >> * 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 nat

Re: Porting Clojure to Native Platforms

He happens to be one of the original Erlang authors/designers. There's also a side project of LFE that attempts to make things more clojur'esque in LFE https://github.com/lfex/clj. As for right now LFE shares more similarities with Common Lisp than with Clojure or Racket (lfe is a Lisp2). Person

Re: Porting Clojure to Native Platforms

On Tue, Apr 26, 2016 at 7:42 PM, Plínio Balduino wrote: > > * 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 alm

Re: Porting Clojure to Native Platforms

You can watch Robert Virding's talk about creating Lisp Flavored Erlang (LFE). https://www.youtube.com/watch?v=Br2KY12LB2w It is really informative. It tells you a lot about Erlang and the BEAM. And it explains why LFE is not Clojure and why Clojure would not work. Virding really likes his Erl

Re: Porting Clojure to Native Platforms

Colin Fleming writes: > Unit of compilation is the module, not sure how that all plays out with > the Elixir repl, but it's not optimal. From what I can tell, re-deffing a > defn would require re-loading an entire namespace (module)... > > Reloading a whole namespace on an evaluation

Re: Porting Clojure to Native Platforms

> > Unit of compilation is the module, not sure how that all plays out with > the Elixir repl, but it's not optimal. From what I can tell, re-deffing a > defn would require re-loading an entire namespace (module)... > Reloading a whole namespace on an evaluation doesn't seem like a show-stoppingly

Re: Porting Clojure to Native Platforms

Thanks for the detailed write up! I guess a carefully chosen subset of Clojure can make sense then, but definitely not all of Clojure. On Tue, Apr 26, 2016 at 5:45 PM, Timothy Baldridge wrote: > >> would you consider a Clojure port to Erlang VM a viable idea for > production workloads? I know El

Re: Porting Clojure to Native Platforms

LISP Flavoured Erlang: http://lfe.io/ On Tue, Apr 26, 2016 at 9:45 PM, Timothy Baldridge wrote: > >> would you consider a Clojure port to Erlang VM a viable idea for > production workloads? I know Elixir comes pretty close, but I still prefer > Lisp : ) . > > I looked into that at one point, but

Re: Porting Clojure to Native Platforms

>> would you consider a Clojure port to Erlang VM a viable idea for production workloads? I know Elixir comes pretty close, but I still prefer Lisp : ) . I looked into that at one point, but sadly the Erlang VM is a really poor platform for a Clojure port. Here are a few reasons why: Unit of comp

Re: Porting Clojure to Native Platforms

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

Re: Porting Clojure to Native Platforms

Of course, most people using Lua seriously use LuaJit, which is surprisingly fast. However it's very prone to the branching problems you described earlier for complex application code. I believe LuaJit does optimise hashmaps when they're used as arrays etc. LuaJit really shines when used for someth

Re: Porting Clojure to Native Platforms

tbc++ - given your experience, would you consider a Clojure port to Erlang VM a viable idea for production workloads? I know Elixir comes pretty close, but I still prefer Lisp : ) . On Monday, April 25, 2016 at 1:50:45 PM UTC-7, tbc++ wrote: > > As someone who has spent a fair amount of time pla

Re: Porting Clojure to Native Platforms

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25.04.2016 22:02, Jason Felice wrote: > There was talk of an LLVM backend a while back, but I believe LLVM > was deemed too low-level to be useful. That was, in fact, why I > signed the contributor agreement. So, I'd love to see some > movement on

Re: Porting Clojure to Native Platforms

I wouldn't underestimate ClojureScript running on V8. That's another platform that's quite fast. And there are a lot of people trying very hard to make JS engines fast, could consider leveraging that. On Tue, Apr 26, 2016 at 3:09 PM, Raoul Duke wrote: > > Sorry, never heard of horses for courses

Re: Porting Clojure to Native Platforms

> Sorry, never heard of horses for courses. Does it mean sth like different > strokes for different folks? yessir. -- 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

Re: Porting Clojure to Native Platforms

On Apr 26, 2016 3:30 PM, "Raoul Duke" wrote: > > Horses for courses. Ask all the game people who use Lua big time. :-) > Sorry, never heard of horses for courses. Does it mean sth like different strokes for different folks? Re: big time users of Lua, I don't know any. I guess performance isn't s

Re: Porting Clojure to Native Platforms

> Ask all the game people who use Lua big time See that's the problem. When we say "horses for courses" we have to actually dig down into what we're saying there. The reason Lua is used in the gaming community is that it's quite fast, very very small, and simple for what it does. It also has a

Re: Porting Clojure to Native Platforms

Horses for courses. Ask all the game people who use Lua big time. :-) -- 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

Re: Porting Clojure to Native Platforms

On Apr 26, 2016 12:19 AM, "Mars0i" wrote: > > On Monday, April 25, 2016 at 3:50:45 PM UTC-5, tbc++ wrote: >> >> As someone who has spent a fair amount of time playing around with such things, I'd have to say people vastly misjudge the raw speed you get from the JVM's JIT and GC. In fact, I'd chall

Re: Porting Clojure to Native Platforms

RC & GC might complement. Don't throw out RC. Also, there are different kinds of 'performance'. Horses for courses, you know. https://www.google.com/search?q=bacon+gc+reference+counting+equation -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post

Re: Porting Clojure to Native Platforms

On Tuesday, April 26, 2016 at 12:23:48 AM UTC-5, Mars0i wrote: > > On Tuesday, April 26, 2016 at 12:19:23 AM UTC-5, Mars0i wrote: >> >> I was going to say that I'd be surprised if Clojure were as fast as SBCL >> (overall, on average, depends on your application, depends on how you code >> it, ym

Re: Porting Clojure to Native Platforms

My 2¢ on the subject, Ferret is not dead, I've been working on it for sometime now. Latest builds/docs are available at [1]. > Can the Immutable Persistent Data Structures be implemented with a reference-counting scheme rather than a garbage collector? This may improve performance. That is what

Re: Porting Clojure to Native Platforms

A scala native port is due to be announced soon. It would be interesting to see whats their approach and performance characteristics are: http://www.scala-native.org/ Cheers, Aleksander On 26 April 2016 at 09:47, Mikera wrote: > I would definitely second Tim's points. The JVM is very hard to b

Re: Porting Clojure to Native Platforms

On Tuesday, April 26, 2016 at 5:53:42 AM UTC+2, puzzler wrote: > > On Mon, Apr 25, 2016 at 1:50 PM, Timothy Baldridge > wrote: > >> As someone who has spent a fair amount of time playing around with such >> things, I'd have to say people vastly misjudge the raw speed you get from >> the JVM's

Re: Porting Clojure to Native Platforms

I would definitely second Tim's points. The JVM is very hard to beat once you factor in the GC and JIT requirements. Worth noting that persistent data structures with structural sharing are used pretty much ubiquitously in Clojure and that these are *exactly* the kinds of data structures that b

Re: Porting Clojure to Native Platforms

This is true of a lot of those benchmarks, especially for functional languages. I haven't looked recently, but back in the day Haskell seemed very fast on the shootout game. However the code that actually runs that fast is very very far from idiomatic. Again, I haven't looked at the Clojure version

Re: Porting Clojure to Native Platforms

The only conclusion I can draw from these benchmarks over the years is that the speed of Clojure is inversely proportional to it's idiomaticity On Tuesday, April 26, 2016 at 7:23:48 AM UTC+2, Mars0i wrote: > > On Tuesday, April 26, 2016 at 12:19:23 AM UTC-5, Mars0i wrote: >> >> I was going to say

Re: Porting Clojure to Native Platforms

On Tuesday, April 26, 2016 at 12:19:23 AM UTC-5, Mars0i wrote: > > I was going to say that I'd be surprised if Clojure were as fast as SBCL > (overall, on average, depends on your application, depends on how you code > it, ymmv, etc. ...). Then I stopped back to check the little benchmarks on >

Re: Porting Clojure to Native Platforms

On Monday, April 25, 2016 at 3:50:45 PM UTC-5, tbc++ wrote: > > As someone who has spent a fair amount of time playing around with such > things, I'd have to say people vastly misjudge the raw speed you get from > the JVM's JIT and GC. In fact, I'd challenge someone to come up with a > general u

Re: Porting Clojure to Native Platforms

I have no first-hand experience with it, but isn't Excelsior JET what you're looking for? They claim to provide AOT compilation to native binaries. > > > I've been wondering lately about getting Clojure to compile to native > code, and so I've been doing some loo

Re: Porting Clojure to Native Platforms

On Mon, Apr 25, 2016 at 1:50 PM, Timothy Baldridge wrote: > As someone who has spent a fair amount of time playing around with such > things, I'd have to say people vastly misjudge the raw speed you get from > the JVM's JIT and GC. In fact, I'd challenge someone to come up with a > general use, d

Re: Porting Clojure to Native Platforms

Not JVM based but I've been wondering about ClojureCLR on top of the new CoreCLR might be a potential path for native. There's a native compiler in the works (a brief mention a couple weeks ago in the standup https://youtu.be/cfxuJsZIK4A?t=1h13m32s). I have to say with the MIT license, tail ca

Re: Porting Clojure to Native Platforms

On Apr 25, 2016 3:50 PM, "Timothy Baldridge" wrote: > > As someone who has spent a fair amount of time playing around with such things, I'd have to say people vastly misjudge the raw speed you get from the JVM's JIT and GC. In fact, I'd challenge someone to come up with a general use, dynamic lang

Re: Porting Clojure to Native Platforms

Interesting point about the performance of JIT and GC on JVM. I didn't realize that they could be so highly performant. Also, I had thought "Metal Clojure" would have been a good name for this project, but you went ahead and stole it before I even thought of it! On Monday, 25 April 2016 14:49:

Re: Porting Clojure to Native Platforms

I wrote Pixie and did a fair amount of benchmarking on it. As it stands tracing JITs work well on tight loops. That means in a perfect world you would only have one hot trace through a given set of functions. That's actually harder to pull off than it sounds. Take for instance the PersistentHashMa

Re: Porting Clojure to Native Platforms

Hi Tim, > On Apr 25, 2016, at 3:50 PM, Timothy Baldridge wrote: > > A LLVM/C++/RPython based version of Clojure would on a good day come in at > about 1/10 the speed of Clojure on the JVM for general use cases. Whoa! The RPython one is particularly interesting; are those the figures you saw

Re: Porting Clojure to Native Platforms

As someone who has spent a fair amount of time playing around with such things, I'd have to say people vastly misjudge the raw speed you get from the JVM's JIT and GC. In fact, I'd challenge someone to come up with a general use, dynamic language that is not based on the JVM and comes even close to

Re: Porting Clojure to Native Platforms

> The main motivation would be performance gains. blah? so many impedance mismatches and layers of indirection that i don't think it will gain much? i mean, it would probably be better to spend time tuning gc parameters or something. just a rant / guess. e.g. robovm is for some use cases perfectly

Re: Porting Clojure to Native Platforms

things like robovm are another possible approach. -- 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. T

Re: Porting Clojure to Native Platforms

I wasn't trying to solve any particular problem. I was just wondering about the possibility of it. The main motivation would be performance gains. On Monday, 25 April 2016 12:55:20 UTC-7, Dan Girellini wrote: > > Not knowing the problem you’re specifically trying to solve, would using > using

Re: Porting Clojure to Native Platforms

There was talk of an LLVM backend a while back, but I believe LLVM was deemed too low-level to be useful. That was, in fact, why I signed the contributor agreement. So, I'd love to see some movement on a C back-end. Gambit Scheme has a special form that emits C (or C++) code. It's very useful.

Re: Porting Clojure to Native Platforms

Not knowing the problem you’re specifically trying to solve, would using using the GNU java compiler work to take byte code to native? On April 25, 2016 at 12:47:37 PM, JvJ (kfjwhee...@gmail.com) wrote: I've been wondering lately about getting Clojure to compile to native code, and so I've b