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 public boolean for StatusReg. - The biggest speep-up was the chunking of the generated program. It seems that the fact that the program was so big prevented the JIT to compile it. So I changed the code to emit it by chunk of around 50 guest VM instructions. (after a few tries, it seemed this was a good figure. On my computer, the performance seems to be highly sensitive on the size of the chunk. I don't really understand why and it worries me a bit on the correctness of my program. ) To do so, I create intermediate local functions that I call.
- I generate the program at compile time, in order to only mesure execution time and not compilation time. 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 computer). When you look at the profile, 98.7% is spent in compiled code, 1.3% in interpreted and 0% in stub. This proves that input program actually get translated to Clojure, compiled to byte code, recompiled to native instructions and then executed natively. This is so fast, that I actually wonder whether too many things get optimized away and the program is not benchmarking anything anymore. Or maybe my code transformation is completly wrong and throws everything away. igorrumiha, I am going to send you the source in a private mail so you can check whether the program still works, and put it in your git hub if it does. (I don't know what is the policy of this list regarding attaching files.) If it does work, and I have not made some stupid mistakes, is is a nice example of program where Clojure's performance can compete with C and even outperform it, because you can write easily a better implementation. (The code I wrote is really ugly, because it was made as multiple hacks, but I think with more experience than me and more cleverness in the design, you can keep the code really expressive and clear, while achieving the same level of performance.). Best, Nicolas. --~--~---------~--~----~------------~-------~--~----~ 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. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
