• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

Kaj
8-Mar-2013
[6034x2]
The Red interpreter can execute the Fibonacci example now
I did some first measurements. The interpreter takes 1.5 times as 
long as R3
DocKimbel
8-Mar-2013
[6036x2]
Good! :)
Given how much space for optimization we have, it's very good results.
Kaj
8-Mar-2013
[6038]
Yes, that's actually an excellent result. We established before that 
the Red/System compiler is twice as slow as optimised C from GCC, 
so the interpreter could have been expected to be twice as slow as 
R3
DocKimbel
8-Mar-2013
[6039]
So, is Red interpreter faster than R2 for fibonacci test?
Kaj
8-Mar-2013
[6040x2]
It may reach that factor two once it does argument type checking, 
but a rough conclusion would have to be that the Red interpreter 
is pretty much at least as efficient as R3
Good question, I'll add a test. I would expect them to be about equally 
fast, as R3 is usually a third faster than R2
DocKimbel
8-Mar-2013
[6042]
Just a third?? I thought it was twice as fast as R2 on average?
Kaj
8-Mar-2013
[6043x2]
Nope
Diminishing returns. Almost half of REBOL's lifetime was spent on 
a one third speed increase
DocKimbel
8-Mar-2013
[6045]
Good job, now BrianH will flood this group to prove you wrong! ;-)
Arnold
8-Mar-2013
[6046x2]
Is there a way to hide this group from him (temporarily?)
Great progress guys!!
GrahamC
8-Mar-2013
[6048]
any group can be made private
Kaj
8-Mar-2013
[6049x4]
I'm getting strange results now: R2 actually faster than R3
This is Carl's official R3 release that I compiled for i686, so it 
probably has a compilation advantage over R2
In my older benchmarks with Carl's R3 build, R3 was a quarter faster 
than R2 (3 : 4). But I was computing Fibonacci 35 then, and now Fibonacci 
40 to have a better comparison with fast languages on fast machines
The Red interpreter takes 1.7 times as long as 2.7.8 on Fibonacci 
40
DocKimbel
8-Mar-2013
[6053x2]
I just added char! to LOAD. It doesn't support the whole set of escaped 
sequences, only the most used once. Also, the molding of codepoints 
< 32 is not escaped yet, so you'll get strange results on screen.


I'm working on improving MOLD on string! and char!, to better support 
escaping of special characters and correct usage of {} braces when 
required.
I probably won't have time to finish file! before going to sleep, 
so you'll get it tomorrow.
Kaj
8-Mar-2013
[6055]
The Red compiler is 3.6 times as fast as the interpreter. Red/System 
is 265 times as fast as the interpreter
DocKimbel
8-Mar-2013
[6056]
(for Fibonacci test)
Kaj
8-Mar-2013
[6057]
Fibonacci 40
DocKimbel
8-Mar-2013
[6058]
Better specify it clearly each time you announce comparative performances, 
else people will generalize it and get a wrong picture of the real 
performance ratios. 


Fibonacci basically tests the efficiency of the function calls. A 
test with a bigger loop could be interesting. For example, you can 
take the %demo.red script and strip all screen outputs, add a LOOP 
around the main code and  you'll should see much bigger differences.
Kaj
8-Mar-2013
[6059x4]
You know how it is with benchmarks: you can never specify it deep 
enough to prevent all caveats
So either the only specification is some salt, or you actually benchmark 
the readers to see who gets it and who doesn't
I don't know what "real" performance ratios are, but I think that 
computing Fibonacci numbers is a more real task than running the 
text console demo in a loop
I'd measure Mandelbrot performance, but Red can't do it ;-)
Paul
8-Mar-2013
[6063]
Kaj, good thanks for the update on the SDL problem.
Kaj
8-Mar-2013
[6064x2]
I'll test later if that's it
In any case, we just bought an XP machine for testing
Paul
8-Mar-2013
[6066]
Great, let me know what's next that you guys need help debugging.
DocKimbel
8-Mar-2013
[6067x2]
Paul: how can we reach you when we need some help?
Will you check AltME regularly now?
Paul
8-Mar-2013
[6069]
you can email me if need be at [ptretter-:-hotmail-:-com]
DocKimbel
8-Mar-2013
[6070]
Great, thanks.
Paul
8-Mar-2013
[6071]
yeah I'll be checking much more often now.
DocKimbel
8-Mar-2013
[6072]
Kaj, what matters in such benchmark is not the usefulness of the 
resulting data, it is how the test stresses the language implementation. 
From that perspective, Fibonacci just tests the efficiency of nested 
calls, nothing else, no series manipulation, no memory allocation, 
very limited math, very limited control flow, ... The demo code will 
stress more parts of the implementation, hence giving you a more 
accurate picture (closer to what user will experience with their 
own scripts).


If you take the language Shootout tests, each test is meant to stress 
a specific part of each language, giving a good (and quite fair) 
comparison for each category.


I think we should implement them in order to get a good picture of 
Red performances and how they evolve. Anyone interested in implementing 
them? http://dada.perl.it/shootout/
Kaj
8-Mar-2013
[6073]
Yes, so Fibonacci is a good such test, isn't it?
GrahamC
8-Mar-2013
[6074]
Looks like there are rebol versions there
Kaj
8-Mar-2013
[6075x3]
The Red interpreter can now actually load and run REBOL scripts, 
as long as they're compatible and they don't have a Unix shebang 
line
I could check for the shebang line in the console
Now that REDUCE is implemented, I suppose it's time for PRINT to 
reduce its argument?
DocKimbel
8-Mar-2013
[6078x4]
Fibonacci is a good such test, isn't it?
 It is a very good test for nested calls. :-)
PRINT: yes we could enhance it, but it would need to be promoted 
as a "keyword" in the compiler (not a big deal though).
I still have work on MOLD tomorrow, I'll try to do PRINT too.
There are also some refinements for some natives that are implemented 
in the compiler and not in the interpreter (/any for SET and GET 
from top of my head, but there are probably more). I need to do a 
review to collect them and implement them before the release (probably 
on Sunday).
Kaj
8-Mar-2013
[6082]
Are you sure PRINT can't just be a function?
DocKimbel
8-Mar-2013
[6083]
Yes, it is a function, but the reduction (on literal blocks only) 
could be handled by the compiler if it's also declared as a keyword 
(in the compiler).