On Jul 6, 6:08 pm, Bradbev wrote:
> On Jul 6, 4:30 pm, fft1976 wrote:> On Jul 5, 11:42 pm,
> Bradbev wrote:
>
> > > more to modern x86 chips. After you have the best algorithm for the
> > > job, you very quickly find that going fast is entirely bound by memory
> > > speed (actually latency) -
On Jul 7, 6:23 am, Jon Harrop wrote:
> On Tuesday 07 July 2009 02:08:57 Bradbev wrote:
>
> > On Jul 6, 4:30 pm, fft1976 wrote:
> > > On Jul 5, 11:42 pm, Bradbev wrote:
> > > > more to modern x86 chips. After you have the best algorithm for the
> > > > job, you very quickly find that going fast
On Sunday 05 July 2009 23:19:31 fft1976 wrote:
> On Jul 5, 10:53 am, igorrumiha wrote:
> > I think it's safe to say that once again it's proved that Clojure
> > easily matches the Java level of performance.
>
> I think one shouldn't generalize from one [unverified] example.
>
> Personally, I'll w
On Tuesday 07 July 2009 02:08:57 Bradbev wrote:
> On Jul 6, 4:30 pm, fft1976 wrote:
> > On Jul 5, 11:42 pm, Bradbev wrote:
> > > more to modern x86 chips. After you have the best algorithm for the
> > > job, you very quickly find that going fast is entirely bound by memory
> > > speed (actually
On Jul 6, 4:30 pm, fft1976 wrote:
> On Jul 5, 11:42 pm, Bradbev wrote:
>
> > more to modern x86 chips. After you have the best algorithm for the
> > job, you very quickly find that going fast is entirely bound by memory
> > speed (actually latency) - cache misses are the enemy.
>
> IME (outside
On Jul 5, 11:42 pm, Bradbev wrote:
> more to modern x86 chips. After you have the best algorithm for the
> job, you very quickly find that going fast is entirely bound by memory
> speed (actually latency) - cache misses are the enemy.
IME (outside JVM), this depends strongly on the kind of pro
On Jul 5, 3:18 am, fft1976 wrote:
> On Jul 5, 2:31 am, Nicolas Oury wrote:
>
> > After, when I run the benchmark in -server with a big enough CacheCode area
> > (1000m), and enough iterations to have everything JITed, I get more than
> > 860.000 iterations per second. (I benchmarked 100 000 000
On Jul 5, 10:53 am, igorrumiha wrote:
> I think it's safe to say that once again it's proved that Clojure
> easily matches the Java level of performance.
I think one shouldn't generalize from one [unverified] example.
Personally, I'll wait for Jon Harrop or someone to port the relevant
Shootou
I don't know if it will help, but I used another flag. I have not my
computer at hand but I think it was in the lines of -XX
agressiveoptimizations.
Moreover, the performance goes from 200 000 to 800 000 depending on the size
of the chunks. I tried to launch for 1 or 10 millions iterations to find
On Jul 5, 3:05 pm, Nicolas Oury wrote:
> Actually, that would be so good, that I actually think there is a mistake
> somewhere either in my program or my computation of the speed.
> Let's wait for igorrumiha to check and to test this implementation.
>
OK, I did my tests, I found and fixed two sm
Each iteration contains 266 instructions. So, it is more like 10.5 clock
cycle per instructions.
Probably the cost of the method call, that I had to introduce in order to
have the JIT compile, or the fact that the status register is
not directly in a local variable but with an indirection, because
On Jul 5, 2:31 am, Nicolas Oury wrote:
> After, when I run the benchmark in -server with a big enough CacheCode area
> (1000m), and enough iterations to have everything JITed, I get more than
> 860.000 iterations per second. (I benchmarked 100 000 000 iterations in 121
> sec, on my 2.4GHz comput
Hello,
Thanks to Rich's advices, I managed to make your ICFP program run very fast.
I have made a few modifications:
- changed the code following Rich's advices in order to have primitive array
access everywhere.
- I didn't managed to do it for booleans, so I used a java object
conataining only a
On Sat, Jul 4, 2009 at 4:50 AM, Nicolas Oury wrote:
> Hello,
>
> after experimenting a bit, it seems that you can get a small gain by putting
> things in local variables (25% or so) but not much.
>
> I looked at the implementation and I was assuming something that is not
> true:
> aset-double does
Hello,
after experimenting a bit, it seems that you can get a small gain by putting
things in local variables (25% or so) but not much.
I looked at the implementation and I was assuming something that is not
true:
aset-double does not compile to JVM instructions for setting the array
directly.
It
On Jul 3, 5:52 pm, Jon Harrop wrote:
> On Thursday 02 July 2009 07:58:11 you wrote:
>
> > I wonder if Jon Harrop is still planning to write Clojure for
> > Scientists or Scala for Scientists or both?
>
> I am certainly interested in writing both books. I reviewed Scala back in 2007
> and decide
Jon Harrop wrote:
> Scala
> feels like a minor departure from Java to me, and I am not a Java fan. In
> fact, more like C# 3 than any real functional language
Don't say that too loud unless you're ready for a drawn-out flame war.
http://enfranchisedmind.com/blog/posts/scala-not-functional/
~~
On Thursday 02 July 2009 07:58:11 you wrote:
> I wonder if Jon Harrop is still planning to write Clojure for
> Scientists or Scala for Scientists or both?
I am certainly interested in writing both books. I reviewed Scala back in 2007
and decided that it was not ready to be advocated. Perhaps thi
I suspect you are not using double arrays with direct array manipulation in
CLojure.
I wonder whether it is linked to the fact your arrays are not in local (let)
variables.
I will try to randomly change a few things in your implementation tomorrow.
Best,
Nicolas.
On Fri, Jul 3, 2009 at 9:56 PM
On Jul 3, 4:30 pm, Shawn Hoover wrote:
> Interesting. Maybe I'm crazy, but when running java -server, replacing
> vectors/assoc with arrays/aset slowed my project down from 4000
> iterations/second to 100! Similarly, removing multimethods for each
> instruction and loop/recur to churn through the
On Fri, Jul 3, 2009 at 9:29 AM, igorrumiha wrote:
>
> On Jul 2, 7:13 pm, Nicolas Oury wrote:
>
> You can also try to replace the arithmetic by unchecked arithmetic. (Is it
> > correct from the point of view of the semantic of the VM you are
> > implementing?).
>
> I didn't get to that yet becaus
On Jul 2, 7:13 pm, Nicolas Oury wrote:
> Hello,
> I just have a look at your code. I was wondering why reflect.Array/getDouble
> was faster than aget?
(aget arrayname) actually makes a call to java.lang.reflect.Array/get
which looks at the type of data in the array and then does the right
thing.
On Jul 2, 1:01 am, Daniel Lyons wrote:
> On Jul 2, 2009, at 12:58 AM, fft1976 wrote:
>
> > On Jun 30, 3:02 pm, igorrumiha wrote:
>
> >> Some people claim
> >> that the JVM can give you C-like performance, but I would be more
> >> than
> >> happy if I got my VM to be 10x slower than the C one
Hello,
I just have a look at your code. I was wondering why reflect.Array/getDouble
was faster than aget?
And I realized than you create arrays of objects and not array of doubles.
Have you tried to replace make-array by double-array?
I am not a Java specialist but if I understand well the API ot
On Jul 2, 2009, at 10:36, Daniel Lyons wrote:
> This is one reason I am not a big fan of
> comparing the speed of languages; another is that it often changes out
> from under you. Java itself is a great example of this: by the time
> everyone had gotten the message that it was slow, it had alread
Mark,
On Jul 1, 2009, at 3:16 PM, Mark Engelberg wrote:
> But each language encourages a certain style of design and algorithm,
> so it IS fair to compare the way that the language encourages a
> certain approach. For example, Clojure encourages you to use a more
> functional approach and persis
On Jul 2, 2009, at 12:58 AM, fft1976 wrote:
> On Jun 30, 3:02 pm, igorrumiha wrote:
>
>> Some people claim
>> that the JVM can give you C-like performance, but I would be more
>> than
>> happy if I got my VM to be 10x slower than the C ones :)
>
> I like your honesty! You can come to my house
On Jun 30, 3:02 pm, igorrumiha wrote:
> Some people claim
> that the JVM can give you C-like performance, but I would be more than
> happy if I got my VM to be 10x slower than the C ones :)
I like your honesty! You can come to my house and * my sister!
I wonder if Jon Harrop is still plannin
On Jul 1, 10:24 pm, fft1976 wrote:
>
> > > Has either one of you tried adding type declarations?
>
> > Yes, I had them from the start.
>
> Isn't it strange that Clojure with type declarations (that some people
> say should be as fast as Java) was only as fast as Python (which does
> not allow typ
On Wed, Jul 1, 2009 at 2:08 PM, Daniel Lyons wrote:
>
>
> On Jul 1, 2009, at 2:24 PM, fft1976 wrote:
>
>> Isn't it strange that Clojure with type declarations (that some people
>> say should be as fast as Java) was only as fast as Python (which does
>> not allow type declarations and does not exac
On Jul 1, 2009, at 2:24 PM, fft1976 wrote:
> Isn't it strange that Clojure with type declarations (that some people
> say should be as fast as Java) was only as fast as Python (which does
> not allow type declarations and does not exactly have a reputation for
> speed)?
Unless the two implemen
On Jul 1, 1:10 pm, igorrumiha wrote:
> On Jul 1, 8:25 pm, fft1976 wrote:
>
> > On Jun 30, 3:02 pm, igorrumiha wrote:
>
> > > According to some of the people on the #icfp-contest channel my
> > > VM implementation is 500x to 1000x slower than a typical
> > > implementation written in C. It is,
On Jul 1, 8:55 am, Nicolas Oury wrote:
[SNIP]
> And instead of reading the instruction and storing them in a vector
> you create a term:
>
> program-term =
>
> `(fn [input-array output-array memory]
>
> (do ~...@list-of-instructions)
>
> Then you (eval program-term) (once only) at ru
On Jul 1, 8:25 pm, fft1976 wrote:
> On Jun 30, 3:02 pm, igorrumiha wrote:
>
> > According to some of the people on the #icfp-contest channel my
> > VM implementation is 500x to 1000x slower than a typical
> > implementation written in C. It is, on the other hand, in the same
> > performance rang
On Jun 30, 3:02 pm, igorrumiha wrote:
> According to some of the people on the #icfp-contest channel my
> VM implementation is 500x to 1000x slower than a typical
> implementation written in C. It is, on the other hand, in the same
> performance range as some VMs written in Python.
On Jun 30,
Another one: http://bitbucket.org/shoover/icfp. Like Jeff we had fun on the
VM but didn't get to post a solution :)
On Wed, Jul 1, 2009 at 1:34 AM, Jeff Foster wrote:
>
> I looked at the ICFP Contest too. I didn't even get as far as solving
> the first problem, but I did implement a virtual mach
I did icfp09 on my own using a mix of clojure+java. I'd sitll call myself a
clojure newbie, but have been writting java for a few years now. my code is
here:
http://github.com/mcodik/icfp2009-momo/tree/master
I wrote the vm in java since I figured that most of the code would be really
imperative
On Jul 1, 8:55 am, Nicolas Oury wrote:
> - Use java arrays for memory. You don't seem to use the vectors in a
> persistent way, and there does not seem to be easy parallelization of the
> vm. That's less elegant but probably quicker. I wouldn't say the same thing
> if there were possible ways of
Hello,
That is an interesting blog post. I am not a clojure specialist, but if I
was to try to change your program to get towards C-like speed (or better), I
would :
- Use java arrays for memory. You don't seem to use the vectors in a
persistent way, and there does not seem to be easy parallelizat
I looked at the ICFP Contest too. I didn't even get as far as solving
the first problem, but I did implement a virtual machine that appeared
to work. I really enjoyed the coding, though I didn't get very far
with the physics! I tried a couple of approaches but settling on the
functional side.
On Jun 30, 3:02 pm, igorrumiha wrote:
> Greetings everyone,
>
> I didn't actually plan it but I ended up participating in the ICFP
> programming contest (http://www.icfpcontest.org). This year the task
> was to move satellites from one orbit to another, to meet with other
> satellites etc. Quit
Greetings everyone,
I didn't actually plan it but I ended up participating in the ICFP
programming contest (http://www.icfpcontest.org). This year the task
was to move satellites from one orbit to another, to meet with other
satellites etc. Quite interesting, and to start it all you need to
imple
42 matches
Mail list logo
