Have you tried manual copying of the perm array (as in the scala version)? It is probably not much better or worse, but it would be nice to have the same algorithm than scala, for comparaison purpose.
On Fri, Jun 25, 2010 at 10:10 AM, Heinz N. Gies <he...@licenser.net> wrote: > > On Jun 24, 2010, at 23:17 , David Nolen wrote: > > > Don't have time to dive into this right now, but all I can say is now you > are starting to have an idea what the "other side" looks like. The kind of > hoop jumping you have to do get within 3x of Scala is absurd. > Yes to see what the "other side" looks like was one of the goals, and it is > abselutly insane I agree, so to be mean, adding a few (long) or +' in there > won't make it much worst :P but that isn't the point I wanted to see how far > one can go. > > > This style of coding is largely unnecessary with the latest equals > branch. However in order to be competitive you're going to have to be a bit > more clever with your combination of deftype/record, protocols, statics: > > > > * Data locality, solved by fields with deftype/record (also allows to > define a bunch of method/fns that have access to the field type to avoid > cast) > > * primitive return solved by static > > * macro inlining is unnecessary with static > > I took the aproach that was most likely to succeed to be fast and I figured > the lower you go the faster you get, I am not entirely sure but I think that > some using records and types instead of arrays would be slower then this > implementation but I'll gladly be proven wrong :P. > > > On Jun 25, 2010, at 4:50 , Mark Engelberg wrote: > > > When exactly did people start expecting Clojure to be as fast as Java > > and/or Scala? > Don't get me wrong I neither expect nor demand clojure to be as Fast as > Java/Scala, this was or is a scientific experiment to see how fast it can > be, scala is just a nice measuring pole especially since Rich mentioed that > this changes in the equal branch bring us a bit closer to the point where > people don't claim clojure to be that much slower. > > > I'm glad someone is starting to tackle these benchmarks. I think it's > > especially interesting to see how fast the code can be when written > > idiomatically, so I hope we'll see more of these results as well. > > Once you start using mutable arrays and type hinting every single > > variable, why aren't you just using Java? > Because Java us ugly as hell, it's worst then the most horrible clojure > code you could possibly write :P. (my 2 cents) also it would defeat the idea > behind this test. The ideomatic (at least in my eyes) clojure code is also > included in the tests but it is slower in a magnitude that it makes it > un-benchmarkable for longer runs. On the other hand the ideomatic code > nearly reads as the problem description, which is wonderful and I think in > most cases I'd say 'screw speed and make it nice' ... actualy I saied that > before :P ... but you get the point I think. > > Regards, > heinz > > -- > 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<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- 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
