for me the point of pointlessness for this particular programing party, (in which I have participated) ...is, it's goal is to compare how different languages to the same thing, as in done the same exact way.
Rebol's strengths may not lie in doing things the same exact way you would do them in a majority of other languages. I don't know the programmed who submitted most of those solutions (including clobbering more rebolish examples from me) but the site is sitting out there supposedly being an example of rebol it may be worth it for the sake of advocacy to go through what is up there and at least make it as good an example as we could Maxim Olivier-Adlhoch wrote: > 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.
