World: r4wp

Pekr: you have a wrong view on what the Red ecosystem is and will 
be. It is probably caused by 15 years of limited options from RT 
and closed-source nature of REBOL products.


In Red ecosystem, like in any most other languages ecosystems, you'll 
be able to choose GUI between different options. Don't give a wrong 
picture of Red by assuming that you will be limited to only one choice.

As for /Core, /View, /Command etc, I just wonder - will there be 
any such product separation with Red? I mean - you can have big "ecosystem" 
linked via R/S, so I wonder, if there will be any packaging, or simply 
products, for certain areas, containing related libs, etc.? Or an 
environment builder, where you choose modules, or something like 
that?

Doc - OK, so that user, who wished all the years RT linked View to 
VLC, could find his remedy via Red, being bridged to VLC via R/S, 
right? :-)

Yep

Yep, and that user will live happy in the Red world. ;-)

btw - libVLC is LGPL 2.1, should be OK to link to, licence-wise?

Sure, almost any licence is

The "RT-like product" separation wouldn't have much meaning in Red 
where you can build your  executables with whatever modules you need. 


We'll define a common "extension" standard (probably based on module! 
datatype) that all third-party modules will implement, so that your 
app could easily use any modules at a cost of a simple "import" directive. 
Such extensions will be typically coded in Red, but with all the 
low-level options, like Red/System routines and bindings to external 
libs.


Moreover, you'll have also the alternative option to build everything 
in a single binary (including third-party libs if they can be statically 
linked). Such thing is impossible in R2 or closed-source R3. In  
 open-source'd R3, you'll be able to do that too, but you'll have 
to get your hands dirty by implementing the bindings in C and using 
a C compiler to produce the executable binary.

LGPL: no problem.

Well - can you statically link LGPL lib? I think not?

But - no problem loading libs dynamically ...

You can, if you provide your object code so it can be relinked to 
other versions of the LGPL part

I dug up John's result for World when he fixed it to run Fibonacci:

I fixed the compile bug in World, so Kaj's Fibonacci test now takes 
8.7s to run in World on my machine. R2 takes 17s and C less than 
1s.

Those results are quite similar to Red's current performance

Is World being compiled?

Yes

I understand that the 2 times faster than R3 includes the compile 
of the Fibonacci program? 

No the performance of the Red program is a bit dissappointing at 
a first glance for the programsource is not very different from that 
in Red/System?

Similarity between the two is not so easily related, as Red is more 
dynamic than Red/System.

the performance of the Red program is a bit dissappointing

 Maybe I should have kept Red project secret until v1.0 to avoid "deceiving" 
 people who thinks that any v0.x version should be equal to a v1.0...;-)

Well the compile is not a simple 1-to-1 translation. 

I am glad you did not keep it a secret, I enjoy seeing the developments. 
And it IS already faster then R3! :D

The speed difference with R3 is not a constant, the more code you 
put in the loop, the bigger the speed difference.

Doc, can you make both MOLD and LOAD support /BINARY refinement to 
input/output Redbin format?

Arnold, the time does not include the compilation. That's a one-time 
operation, so it would be unusual to include it

For World, it does include the compilation, because its operation 
mimics an interpreter

AFAIK, World compiles to bytecode, then runs the bytecode in an interpreter.

Yes, rather different model

Jerry: it's a bit premature, but yes, that should be the way to create 
and consume redbin data. You can also add SAVE to that list.

I gave the topic of the "speed" more thoughts, and though I am very 
uneducated in lower level internals and language designs, I think 
that I might have more understanding, why I can't think about Red 
being just a compiler to Red/System in a 1:1 manner. In such a case, 
Red would not be needed. What needs to be included in the final exe 
is kind of "engine", supporting stuff like GC, all the dynamic things, 
type checking engine, etc etc. 


When I ask myself, if I am willing to exchange dynamic stuff for 
speed, I say - no, at least not necessarily. It was just that I got 
trapped by first R/S performance tests, and thinking that if Red 
compile, it has to be almost that fast too.


As for waiting for 1.x and possible optimisations - I don't believe 
optimisations can change things drastically, at least non in order 
of a magnitude. But - we will see.

Personally, I feel that Google's V8 & Apple's Nitro give orders of 
magnitude speed improvements over early JavaScript Compilers.

Peter - in the case of JS engines - is that only about the compilers, 
or also about an overal architecture change?

Pekr: there are several layers at which optimizations can be applied. 
With an optimizing Red/System compiler, you'll already get an overall 
x2-4 boost. Then optimizations at Red level can bring us another 
boost (runtime code can be optimized, compilation output can be optimized 
to be closer to 1:1 with Red/System, when possible). The end result 
should give us, on average, a x10-20 boost over R3. I am pretty confident 
that this can be achieved, given the current results.

Will also "self-hosting" - rewrite of Red/System in Red, help too 
in that regard? Or is that unrelated?

Not really on the run-time performance, it will boost compilation 
time only. The main motivation for being self-host is the JIT-compiler 
(we need to embed the target compiler in Red runtime).

Today's new features:

- FIRST, SECOND, THIRD, FOURTH, FIRTH and LAST functions added.
- Paren! datatype added.
- Compilation of parens expressions now supported.

You should now feel a bit more "at home" with Red. ;-)

SIXTH, SEVENTH, EIGHTH and NINTH also exist in REBOL. :-)

yes, they do, but - have you ever used them? :-)

I have used FOURTH once or twice, a long time ago, never used others 
above that.

(should be FIFTH, sorry for the typo)

Pekr, no, but they should still be available, if any scripts use 
them. The cost of adding them should be very small.

Have you ever seen source code that use such accessor above FIFTH?

I won't add them if nobody uses them, no matter the light cost.

I would certainly wonder why you stop at FIFTH.

SIXTH is used in some of the REBOL/Services source, written by Carl.

And his way of using it might be a good argument for continuing up 
to NINTH.

Example:


; Packet header values (keep in-sync with load-header and mold-packet):
ph-version?: :second
ph-session?: :third
ph-encode?:  :fourth
ph-req-len?: :fifth
ph-pay-len?: :sixth

TENTH is there too.

Now that you mention it, I remember seeing that code. Such code won't 
compile until we get JIT-compilation.

I would certainly wonder why you stop at FIFTH.

Why stop at TENTH? :-)

Any occurrence of above FIFTH usage in other than Carl's code?