Good point Timothy - 100% agreed on the value of hard facts / benchmarks.
Though I think it's still useful to have some discussions first, in order
to determine where to start / what to benchmark / where the problems are
likely to be hiding. Good research should start with an understanding of
t
On Wednesday, 9 October 2013 20:29:46 UTC+8, Mikhail Kryshen wrote:
> Nicola Mometto > writes:
>
> > I don't think that's what Mike was talking about.
> > Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an
> > "public long invokePrim()" method.
> >
> > When we do (defn y
One of the problems with these sort of discussions is the total lack of
hard facts. Words such as "could do this" or "doesn't do that" when
referring to HotSpot are very rarely backed up by actual benchmarks, or ASM
printouts. I would imagine that any serious attempt at an optimization
layer will b
Nicola Mometto writes:
> I don't think that's what Mike was talking about.
> Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an
> "public long invokePrim()" method.
>
> When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim
> instead of invoke.
>
> If we red
Yes Nicola, that's exactly the problem I was talking about.
As far as I'm aware, the only way to make this maximally efficient at
runtime on the JVM (and probably any other non-trivial runtime with typed
method dispatch?) is to use some kind of recompilation strategy.
invokedynamic is nice but
I don't think that's what Mike was talking about.
Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an
"public long invokePrim()" method.
When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim
instead of invoke.
If we redefine (defn x [] "") then y won't work
Mikera writes:
> 2) This in turn means we are going to have to "recompile" if we want to
> retain any sort of dynamic behaviour. The current system of independently
> mutable vars won't work (for obvious reasons: changing a var could easily
> violate the previous type inference assumptions)
Hi Mike,
First of all, thanks for the report and sorry for the late reply.
Your "proposal" looks like something that should definitely be tried out
in the long-term, however it implies adding a notable amount of
complexity, moving away from the simple "read top level form -> analyze
-> compile an
Hello Nicola et al.,
I have only learned about your CinC effort during last week with the news
about core.typed.
I have ported the analyzer of the self-hosted cljs compiler to ClojureC:
https://github.com/schani/clojurec/pull/33 and can explore it from the
metacircular scheme REPL already. It
Hi Nicola,
Congratulations - great work!
My main idea/feedback is that I'd love to see the "optimised" mode become
able to emit code that matches Java / Scala performance in all cases. This
would be a huge boost for people (like me) who do a lot of numerical /
realtime work and would love to d
Congratulations Nicola, and thanks for all the hard work - this is a great
project!
On 23 September 2013 14:26, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
> Excellent work! To hear CinC is a long term project is music to my ears!
>
> Ambrose
>
>
> On Mon, Sep 23, 2013 at 4:5
Excellent work! To hear CinC is a long term project is music to my ears!
Ambrose
On Mon, Sep 23, 2013 at 4:59 AM, Nicola Mometto wrote:
>
> For the past 3 months I've been working as part of my GSoC project,
> on a port of the clojure compiler and analyzer to clojure.
>
> Tomorrow the GSoC wil
For the past 3 months I've been working as part of my GSoC project,
on a port of the clojure compiler and analyzer to clojure.
Tomorrow the GSoC will end, so this is a report of what I've accomplished
with this project thus far; note that I'm not going to stop working on
CinC now that the GSoC is
13 matches
Mail list logo
