World: r3wp

I have a huge graphical application written in R2 (Canvas RPaint, 
close to 13'000 lines of code), that I can't get released because 
of host problems and differences in REBOL between OSs. I do much 
of my development under OS X, and I have lots of utilities and applications 
written in R2, that suffer from problems in REBOL/View, that I might 
be able to solve, if the host code was released. I have tried to 
look into the graphical part of R3, but I can't see, how I'm able 
to convert my code to R3.


(I'm sorry to say so, but R3 to me looks like a hobby project, not 
a serious business projekt.)

Geomol, I wouldn't expect any further development on lowlevel R2 
View.

R3 is Alpha! A little unfair to call it a hobby project..

Geomol, last year I have written the same thing but this year a lot 
has happened.

Once alpha i finalized and VID is complete expect a boost into the 
development.

Also I suppose REBOL is short of money and programmers so they cannot 
speed up the project.

Geomol - you are completly off. I would not expect reaction like 
yours from person like you. Calling R3 dev. effort a hobby project? 
Where do you live, man? On a different planet? Sorry for being picky, 
but R2 dev. effort, compared to what we achieved with R3, is a complete 
joke, yet you call R3 being a hobby project?

Geomol - wait half a year, and you might get even View/VID in R3. 
Core 3.0 is close.

It would be good, if you are right.


As an example of my use of R2, and where I can't use R3, look at 
this image:
http://www.fys.ku.dk/~niclasen/bachelor/dist.png


I'm working on my bachelor project in astronomy at the university. 
I'm going to make a simulation of comets at the Late Heavy Bombartment 
some 3.9 bio. years ago to test a theory, that the water on Earth 
came from those comets. A part of my work is to study earlier simulaitons 
of 10'038 comets made by others. I would like to see, how the distribution 
of their initial situation looked, so I made a little REBOL script, 
that plotted the 10'038 comets and the orbits of the planets, Jupiter, 
Saturn, Uranus and Neptun. The image is showing this. It took me 
very little time to write the script in R2, and I can use the result.

Can you see, I can't use R3 for such things?

Geomol, it sounds like you expect that R3 will never be able to do 
that. Why this attitude?

No, you misunderstand. I hope and expect R3 to be able to do that 
some day. I just look at the facts:
The project has been gong on for 4 years since 2005.
Where it is now.

When I can expect it to be in a condition, where I would begin to 
use it for real. (I've learnt to have very small expectations.)

I'm trying to answer the question from Pekr: "why is R2 more interesting 
to you? I can't somehow understand it"

I think that trying to get R2 View working properly under OSX will 
take longer than reaching the same goal for R3. I don't think there 
is much we can do in terms of speeding either R2 or R3 development 
up, so it's simply a matter of waiting until it's ready with the 
number of developers available to us. I don't want to disturb R3 
development with too much interference from R2.

Fair enough.

I said a looong time ago that we would, when R3 reaches beta, require 
a much larger number of developers to move forward. When extensions 
and host are properly released, this will still be the case.

Henrik, you've used R3 more than I have, I think. Do you remember 
my work on FITS files in the spring from my visit to the telescopes 
at Tenerife? I made images from the 16MB FITS files using R2. It 
took 1-2 minutes to compute one file, where it takes less than a 
second if using C. How do you think, R3 perform compared to R2, when 
it comes to brute force calculations?

If it's math heavy it will probably be around the same. If you use 
graphics, the better scalability of having many GOBs will help speed 
up certain operations. DRAW is currently around the same speed. If 
you use it as a C extension, then you will of course get C speeds. 
There are a few tricks in R3 to reduce the need for copying as well 
as some functions that have gone from mezzanine to native.

I made a quick test to compare calc performance between R2 and R3. 
A 10'000'000 loop of some simple + * and /. It took around 17 seconds 
using R2, and 27 seconds using R3. If this is not changing, then 
I will probably continue to use R2 more than R3.

The key is that if we want real speed, we can do it in C now.

Please post an example.

a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]

I tested on an iBook. It might be different results under Windows!?

I didn't know there was a PPC version of R3.

You maybe forgot? :-)
http://www.rebol.com/r3/downloads.html

Seems like there's a newer version, than what I have installed. I'll 
try the newer one...

It takes 55 seconds in R2 and 64 seconds in R3 here.

There might be some math changes that BrianH knows way more about 
than me.

But don't forget that extensions are precisely for such cases and 
R3 is way ahead of R2 here.

I got same result with latest PPC version of R3, 27 seconds.

So we can expect R3 to be slower than R2, when it comes to calculations? 
hm

Yes, the say to go with heavy calculations is probably to get some 
C code written somehow, and then just use REBOL as the control program.

we can expect

 - no, I think we can expect a reasonable explanation to the slowdown 
 and possibly a fix, when we get to that point.

the *way* to go

yes

I don't think Carl wants to complicate R3 with fast maths that could 
be done smaller and faster as a C extension anyway.

My results
R3
>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]

== 0:00:05.575825

R2
>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]
== 0:00:03.590101

What computer?

Geomol: "So we can expect R3 to be slower than R2, when it comes 
to calculations?"


No, I wouldn't expect R3 to have slower calculations. From what Carl 
has said, the R3 Alphas are not optimised for speed when compiled.

That might be the reason.

An older MacBook Pro - 2.4Ghz Intel Core 2 Duo

It's interesting, that the difference is large when running under 
OS X, and just a few percent when running Windows.

I tested mine under VMWare, so that's a third environment.

The money! datatype calculations are much slower, I guess that is 
the price of accuracy:


>> a: $1.00  b: $2.00 dt [loop 10000000 [a + b * a / b]]
== 0:00:15.957041

I not surprised that the Windows R3 Alphas run better than the Mac 
ones. Carl seems to develop for Windows and then ports to Mac and 
Linux in between "development phases". I think the more we report 
Mac bugs and issues in CureCode the more likely we are not to end 
up with a crippled R3 on Mac.

The documentation state, money! datatype uses standard IEEE floating 
point numbers. That can't be right.
http://rebol.com/r3/docs/datatypes/money.html

The docs appear to be missing the warning that they still  show the 
R2 docs.

Geomol, sometime I felt frustrated by the long time REBOL3 took to 
be developed but now I see the light out from the tunnel and it is 
not the train running against us !

REBOL3 has been rewritten from ground upp with high skills and few 
resources. This mean it needs time to be completed but it will be 
like a good wine.

I ran the calculation test under Windows/XP using VirtualBox. It 
took 5.009 seconds compared to 5.575825 seconds run natively under 
Mac OS X.

Actually we are in the state where all developers should wait for 
the core to be completed. In beta stage they will be able to operate 
and cooperate to extend it.

Keep the faith !

I also ran the calculation test with R2 under Windows/XP using Virtual 
Box it took 4.368 seconds.


As native R2 on Mac OS X is faster than Windows R2 running under 
emulation, it looks as though the issue is the that the code is yet 
to be optimised.

Giuseppe: I think it would be better if more developers could test 
the R3 alphas and report bugs and issues rather than just wait.