Comments on: R3 Math Speed

Ticket #0001338 suggests that math speed is reduced in R3 as compared to R2. Let me comment on that.

First, all R3 releases are alpha test builds which means they're not optimized builds. However, if I enable compiler optimizations, I see that R3 is slightly faster than R2.

Using the example code that was posted (fair code because it is 64 bits in both R2 and R3):

a: 1.0
b: 2.0
dt [loop 20'000'000 [a + b * a / b]]

The timings on x86 in XP are:

R2.276:   0:00:14.062
R3.A94:   0:00:14.218 (no opts)
R3.A95o1: 0:00:13.920443 (some opts)
R3.A95o2: 0:00:13.858737 (more opts)

So, for now, while in alpha, let's focus on the last few language-related elements of R3, so we can move to the next release stage.

Also, for higher performance math, rebcode functions should be available in R3.1. And, if the R3 developer community feels inclined to support compiled functions (yes, such support would be in the host), greater levels of performance could be achieved.

13 Comments

Comments:

-pekr- 24-Nov-2009 1:35:30	Interesting info about the Rebcode. IIRC, Rebcode, due to R3 internal changes, was much slower than its R2 equivalent? So you still plan to add it? I think that with Extensions, some ppl will try to add some compillable dialects, JIT ....
Brian Hawley 24-Nov-2009 13:21:38	The old Rebcode was too slow to add to R3 due to the change in function work lookup. However, there is nothing blocking us from adding a brand new Rebcode that makes up for the speed loss with semantic changes to get the speed back. That new Rebcode would likely be incompatible with the old though. And yes, we can start work on the new dialect right now using extensions and commands. That wouldn't require a rebcode! type though, just command!.
Carl Sassenrath 24-Nov-2009 14:04:23	Yes, a good idea. Also, a method that would provide good performance (on par with R2 rebcode) would be to restrict rebcode functions to only access local variables. Access to vars outside the scope would require an explicit fetch or set of their values to and from locals. In this way, the rebcode evaluator can remove some of the checks needed for high frequency instructions like ADD. Of course, the trick to any such code is good security... preventing modifications that allow access to other parts of the stack frame or main memory.
M 24-Nov-2009 18:11:01	6.26 sec for me. Similar program in lua took 0.5 sec.
zen 25-Nov-2009 22:33:14	(at)M holy crap, this is a huge difference man! Are you sure about your stats ? you've caught my attention now. I will start playing with Lua.
Maxim Olivier-Adlhoch 26-Nov-2009 15:44:18	some JIT compilation of REBOL has been successfully achieved by a REBOL user and resulted in a 25x speed improvement in a Mandelbrot test. At such a speed, it would make it comparable to lua, for maths, or maybe even faster. we will see how this evolves in the next few weeks, and how its author will want to license it.
-pekr- 30-Nov-2009 3:51:35	Hmm, you've got challenge to beat :-) Cyphre's experimental JIT engine for REBOL (5.5 KB DLL + 10KB REBOL code so far :-), is approximately 4 times faster than Rebcode, and 27x faster than R2 :-) http://cyphre.mysteria.cz/tests/rebol-jit-test.html
batman 1-Dec-2009 11:06:40	I always had that nagging feeling that Rebol was not going to scale in a large production environment where you have very intensive computation or processing of millions of records e.g tables of 500 Gb. Looks like this is what is being confirmed by the first posts. However the last 2 posts from Maxim and Pekr do send out some hope that maybe they have found a solution. This is going to help Rebol for sure. the most important thing that people would like to know is :-what is the licence going to be? Is it going to be available freely by default to the rebol community at large? this is the kind of thing that will kindle interest in Rebol and will allow it to compete with other faster languages out there. cheers batman
Carl Sassenrath 4-Dec-2009 14:34:11	Batman: as you can see various developers are working on JIT solutions for such functions. At some point, we'll make one of those method standard for R3. The R3 license is free, and for a generally useful extension such as JIT that would be included in R3, we will require that it also to be free. However, I should also note that developers are also allowed to build and sell commercial extensions that are not free. That is, each extension created by someone is not necessarily free.
Maxim Olivier-Adlhoch 6-Dec-2009 13:25:55	I also plan on participating in an LLVM extension at some point. one thing that is in the works behind the scenes (by a few of us users) is to formalize a "compilable" REBOL dialect. basically a subset of REBOL which is simple, has only a few words, a few datatypes, and control structures. this will allow us to build various compilation-able tools, such as rebol syntax for C code, JITs, and better interoperability with other languages.
Brian Hawley 7-Dec-2009 19:47:25	Carl: "for a generally useful extension such as JIT that would be included in R3, we will require that it also to be free." A clarification: We will require it to be free (and likely with a permissive license) to be included in R3, not because it is generally useful :) We in the REBOL community tend to like permissive licenses, and if you want to participate in the community development of REBOL itself, it would be a lot easier if you didn't (L)GPL your code. However, it looks like code that isn't included in REBOL itself - like external modules or extensions - can be GPL3, LGPL or Classpath. Consult your lawyer. Maxim, it's not just simplicity that would be needed to make a compilable dialect. It might be enough to require that all code blocks of the control functions like if, while, etc. be literal, static blocks rather than expressions. That and having function words be resolved at compile time rather than runtime. Reducing the dynamism a little goes a long way.
shadwolf 19-Dec-2009 8:35:07	benchmark are typically the point where the hardware is as important as the implementation. for example on core R3 a96 on my computer i get a timing of 0:00:06.642301 which just represents half the time it takes on your computer... But yes improving math if it's possible is always a good thing... by the way i like the new 20'000'000 annotation ... I hate the console of R3 ... really it's like returning 10 years ago. Will it be possible for example to make our own console using draw and our own way to set text in colors in our own consoles ?
Shadwolf 19-Dec-2009 8:42:39	talking about console i saw something really cool in the ruby area it's like a console and an help documentation merged in 1 application. The name of this application is "FXRI - Interactive Help & console"... I'm not saying we don't have cool stuffs on our own I just say those cool stuff are splited in different projects what would be cool is an applicaton made in rebol ca could merge the help interactive documentation, an anamonitor, a test console, a advanced edition tool. A debug tracker? somthing that could iteract with the track system and make it integrated... This tool of more a swiss knife would come by default in rebol package.

Post a Comment:

You can post a comment here. Keep it on-topic.