hi all, well for me, in the btree test (a GC oriented test)... just removing the 2 return statements, shrank times by more than 30% in runs I did. since this is a b-tree nothing can be pre-allocated, unless we rebuild the algorythm itself with some 'trick', so all the burden is on the GC itself.
removing parens further improved speed by 3% on average now, we all know rebol's GC is pretty basic and has trouble dealing with very large datasets (exponentially slow, maybe even cubed) so this test was hard to further improve, because the main work is internal to the interpreter. If I compare this new benchmark, we are still 17 times slower than python... which is, well... a bit sad. its possible that using structs and preallocating a big chunk of them at a time might have improved the speed, but I don't have time right now to test this. this leads me to... people often forget that rebol is not about implementing the same logic again in a nifty little syntax. its a different computing model, and to be effective, applications must be tuned to its way of thinking. in most cases, many of the usual computer science philosophy is useless in rebol. Many algorythms, just arent needed in the first place. BUT! obviously, the fact that nothing in rebol can be compiled (although parts of it could be jit compiled) is a big drawback in speed. MOST modern languages do SOME jit compilation, some even automatically store it and reuse it, further improving later application runs. IMHO rebcode, should be part of A final R2 version, even if its buggy. we`ve got enface/enpro/enview etc... we should also have one with rebcode enabled (encode) and let users decide if they can cope with the bugs/caveats. in most benchmarks I've seen rebcode was at least 3 times faster and often up to 10 times quicker for simple algorythms. I'm sure some people would implement rebcoded functions we could share on rebol.org and include as libs in many apps. some smart rebolers might even implement rebcode compilers to convert parts of normal rebol code or single funcs, into rebcode. any how, I was just passing... took a little (and much needed) break to play around with this benchmark. have fun -MAx On Thu, Oct 16, 2008 at 3:03 PM, Carl Read <[EMAIL PROTECTED]> wrote: > > On Thursday, 16-October-2008 at 7:28:08 Tim Johnson wrote, > > > > >Pretty thorough... > >http://shootout.alioth.debian.org/gp4/index.php > > And REBOL shows up as one of the slowest - probably because FOR is used in > quite a lot of the scripts, (is it native in R3? It is the best loop to use > sometimes), as are many parens, and no doubt in a lot of cases where it's > not necessary. > > -- Carl Read. > > -- > To unsubscribe from the list, just send an email to > lists at rebol.com with unsubscribe as the subject. > > -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
