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
41 matches
Mail list logo