Wow I can't believe my silly question actually led to a whole independent
project!
On Friday, February 10, 2012 9:36:53 AM UTC-6, tbc++ wrote:
>
> >> I have some set of algorithms that needs such-and-such operations to
> be as fast as possible. Can I create a VM that is tailored for that?
>
> Yes
>> I have some set of algorithms that needs such-and-such operations to
be as fast as possible. Can I create a VM that is tailored for that?
Yes, this is basically what PyPy does for Regexes, they have a custom
regex engine that has "can_enter_jit" in it. So basically what you get
is a jitted rege
Another question: can multiple VMs live inside the same process
boundary? So that code in VM1 (clojure-py) can call code in VM2 (pypy)
with no overhead.
There is also a third case, intermediate between optimizing vms for
algorithms and optimizing for full blown languages.
Think about implementing
This stuff is amazing.
The big question for me is how this relates to macros. This sounds
like a metaprogramming ability, where instead of changing the source
code, you are changing the implementation layer.
Here is a concrete use case I'm interested in: optimizing algorithms.
I have some set of
> Will clojure-py allow us to write our own VM's using clojure?
TL/DR: yes
Long version: RPython simply is a restriction on what bytecodes can do
in a given set of branches in a python program. So the cool thing
about RPython is, you define a main(argv[]) function, and then point
the PyPy transla
This article on RPython and PyPy is pretty good, helped me understand
what the fuss is about:
http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time
Pretty cool stuff.
Will clojure-py allow us to write our own VM's using clojure?
On Mon, Nov 28, 2011 at 9:23 AM, Ti
> IMO better to hack on VMKit (llvm) than to start a new one atop of PyPy.
Seeing as VMkit is a method level jit, and PyPy creates tracing JITs,
basing a JVM off of VMKit to run clojure on it kindof defeats the
whole purpose.
Timothy
--
“One of the main causes of the fall of the Roman Empire wa
On Thursday, November 17, 2011 5:09:49 PM UTC+1, tbc++ wrote:
>
> > I also felt that sticking with the official Java implementation of
> Clojure would be more practical. It would certainly be fun to put Clojure
> on PyPy, though.
>
> There is one insanely off-the-wall id
On Tuesday, 22 November 2011 12:26:54 UTC+5:30, Andrzej wrote:
>
> On 11/22/2011 02:10 PM, Timothy Baldridge wrote:
> > So I got thinking about clojure pypy tonight, and got thinking how
> > easy it would be to adapt my old code to run as a interpreter. So I
> > pulled in a few files, implemented
On 11/22/2011 02:10 PM, Timothy Baldridge wrote:
So I got thinking about clojure pypy tonight, and got thinking how
easy it would be to adapt my old code to run as a interpreter. So I
pulled in a few files, implemented a few methods, and I have prototype
running (+ 1 2) as interpreted lisp code.
So I got thinking about clojure pypy tonight, and got thinking how
easy it would be to adapt my old code to run as a interpreter. So I
pulled in a few files, implemented a few methods, and I have prototype
running (+ 1 2) as interpreted lisp code.
I slapped it up on github...it's ugly, but it's a
On Monday, November 21, 2011 10:28:18 AM UTC-5, tbc++ wrote:
>
> Rpython is very restrictive. Basically it's garbage collected C++ with
> a different syntax. So this means we can't import modules at runtime.
> So any additional libraries must be added via C FFI. So as an example,
> let's take a l
>I just don't like the workflow of compiling everything. If I want to
use clojure on the comandline i want to write "clojure-pypy
mytool.cljp".
Does this seam resenable?
I was thinking about starting this rather soon. For me it would be a
research type project (at least at first). Would anybody c
I was thinking about this too. I don't really need Clojure-on-pypy but
I want to learn and understand the pypy project. I think that pypy is
an extreamly cool project and I want to learn more about it and it
would be fun to implment Clojure (and I would finally learn python).
The problem Ti
rency, but you have the
ecosystem, but you do loose some performance.
-
Now let me say this: I'm in favor of Clojure on PyPy, it'd take a lot
more work that it looks originally, but it's not impossible. I'm for
this project, and I'd love to help. Sadly, I've go
facilities. But then you're really re-defining what clojure is and how
> it runs. PyPy has a very advanced JIT that works well with dynamic
> typing, but if you implement stock Clojure on PyPy you'd be ignoring
> all that. Look at RT.java, you'll see tons of "
>Although implementing Clojure-in-Clojure no doubt should be done, that
>does not make lein work on other platforms,
Very true. But what it does do is abstract away the core elements of
Clojure. ISeq, IPersistentList, PersistentList, etc. are all cross
platform. All you need is a "emit-class" func
On Nov 17, 10:07 am, Timothy Baldridge wrote:
> > With the clojureclr for example, it
> > supports pretty much everything clojure does sans java, and gains all the
> > .net interop.
>
> True...true, it supports it, but it's still a "2nd class citizen". For
> instance, we don't have lein, ring, p
On Nov 17, 2011, at 11:09 AM, Timothy Baldridge wrote:
>> I also felt that sticking with the official Java implementation of Clojure
>> would be more practical. It would certainly be fun to put Clojure on PyPy,
>> though.
>
> There is one insanely off-the-wall idea
s and how
it runs. PyPy has a very advanced JIT that works well with dynamic
typing, but if you implement stock Clojure on PyPy you'd be ignoring
all that. Look at RT.java, you'll see tons of "if (obj is ISeq)... if
(obj is Array)...". Much of that could be thrown away in a PyPy
On Nov 17, 2011, at 10:45 AM, Brent Millare wrote:
> ...The main point the poster should take away is the lack of any
> library/runtime tools, you have to build from the ground up many things you
> take for granted when targeting the JVM.
I've thought about Clojure on PyPy to
> I also felt that sticking with the official Java implementation of Clojure
> would be more practical. It would certainly be fun to put Clojure on PyPy,
> though.
There is one insanely off-the-wall idea I've been thinking about
recently, however:
1) Implement a full JVM in
Couple of clarifications. My main point is the maturity of the JVM, so when
comparing what is presented in the article (which isn't much), it can do
what is listed. That's not to say the converse isn't true, that PyPy's JIT
can do things the JVM can't do. Like I said, there are a lot of research
I actually started on this at one point. I ended up scrapping the
project for several reasons. But first, I think we must clarify what
we mean by "runs on pypy". There's two ways of attacking such a
project:
1) writing a Clojure interpreter in RPython, and then having PyPy
generate a JIT for you.
The JVM is an advanced, mature JIT compiler. PyPy's generated JIT compilers
are not as mature. As a result, the JVM does many of the things in the
article and more. From what I see, the benefits of Clojure targetting PyPy
would be exploring the performance advantages of very experimental work.
Would Clojure have anything to gain by having something like PyPy's
JIT-generator create a custom JIT for it, a'la
http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html?
Or does the JVM already do the stuff that is mentioned in that
article? (Or does none of that stuff apply to Cloj
26 matches
Mail list logo
