Language Comparisons

Pretty thorough... http://shootout.alioth.debian.org/gp4/index.php

On Thursday, 16-October-2008 at 7:28:08 Tim Johnson wrote,

>Pretty thorough... >http://shootout.alioth.debian.org/gp4/index.php

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 <carl-cybercraft.co.nz> wrote:

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:

T> but the site is sitting out there supposedly being an example of rebol T> it may be worth it for the sake of advocacy to go through what is up T> there and at least make it as good an example as we could Agreed (also on the pointlessness part). If someone wanted to act as liaison, posting a challenge here, with rules and constraints, that would be a big help. These things can be fun distractions, but it's a pain to go through the site, find the rules, etc. -- Gregg

hi guys, actually, this site is extremely well designed! all tests are laid out in bare, and the rules are at the bottom of each test, in plain old english. the intents of each test is also obvious and some do's and don'ts are posted to keep any example within the goal of the test. in the test I tried, the goal is to test the Garbage Collector (GC) so a very well planned test is used... a binary tree which must reside all at once in ram, built one by one (not sure about allocation being forced to be one by one though). -MAx On Fri, Oct 17, 2008 at 1:47 AM, Gregg Irwin <gregg-pointillistic.com> wrote: