Hi Phil, Looks like my latest coalescing changes broke a few things in the build reports, but I'm working through those... however I noticed that performance on benchmark.dawes improved even more. It went from 229 ms in the May 31st build, to 160 ms two weeks ago, and now its running at 105ms. This is on my Core 2 Duo Mac Book Pro.
Another few rounds of this and we might be competitive with C :-) Actually the benchmark has some overflow checks in it, which could be avoided if you change 1 + to 1 + >fixnum (the number of ones probably won't exceed fixnum bounds anyway). But optimizing higher-level code is more interesting, IMO. If I recall correctly, I based this benchmark on the inner loop of some bloom filter code you posted at one point. It would be interesting to see if the original code got faster too. Slava ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
