World: r3wp

You could make a dialect that could compile to native code that would 
superficially resemble REBOL, and most non-guru REBOL code would 
likely work in that dialect. It might not be as much faster as you 
think though - a lot of REBOL is native code already (natives).

but you could tell that about any launguage, no? Every other language 
has natives too, so why do we have compliers at all?

isn't REBOL order of magnitude slower than e.g. JAVA? Not to mention 
JAVA can't match native code ...

If you read the whole comic you would realize that what they are 
proposing are relatively small but significant tweaks to what is 
out there already. Most of their code is derived from Firefox and 
Webkit - only the JavaScript VM is new, though its language is not. 
The process model has already been developed independantly by Microsoft 
for IE8. The real value this all provides is the source - the other 
OS browsers will be able to catch up with IE8 quite quickly with 
this source.

I can write REBOL code that is faster than the equivalent code in 
Java, and vice-versa. Every language has its strengths.

There was an article today on IE8's performance, which was cited 
as horrible, twice as slow as IE7, but I'm not trusting this source 
yet, as they could have been testing a debug build

All of the beta builds are debug builds, AFAIK.

About java being fast: It's speed is outweighed by its size. REBOL 
may not be extremely fast, but it's nimble enough to not let you 
notice most of the time.

I can write REBOL code that is faster than the equivalent code in 
Java
. Can you give us a short example ?

If your REBOL code is not very fast, it may be algorithmic. My REBOL 
code is rather fast, though that is because I hand-optimize and don't 
use REBOL where it isn't appropriate. I don't generally use Java 
because it is never appropriate for my work, but if it were I might 
use it. I don't use REBOL to write C code.

Anything that is native-heavy, uses parse a lot, or does structure 
manipulation can be made to be really fast in REBOL. Anything interpreter-heavy 
is likely not. If what you are doing is basic math, consider a calculator 
(or C).

Anything interpreter-heavy is likely not

 So, basically, you're saying that REBOL interpreter *is* slow. Parse 
  dialect is cool, but it's not REBOL dialect. If you make a fair 
 comparison, REBOL is orders (2-3) of magnitude slower than Java. 
 I guess that even Rebcode is slower than Java.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=rebol&lang2=java

Doc, I have a lot of trouble coming up with a short example in Java 
- Java isn't really useful for that kind of thing. Almost any one-line 
REBOL program would be faster than the equivalent Java program. The 
REBOL interpreter is slower than JIT'ed Java code, after you factor 
out the JIT overhead. REBOL is more than DO though - it has a lot 
of high-level operations that are quite useful and fast. If I try 
to write code in REBOL using Java-style algorithms it will be slow. 
If I try to write Java code using REBOL-style techniques, I would 
have to reimplement most of REBOL first, and it would be slower.

Remember, the DO dialect is just one of many. This will be even more 
the case in R3 (in theory) as it is proposed that user-defined datatypes 
include function types. This would allow you to retrofit REBOL with 
different execution engines - including JIT'ed dialects if you like.

There is no such thing as a fair comparison between Java and REBOL 
- the closest would be to show how a program written to take advantage 
of one language's strengths would be wors when translated to the 
language of the other, and then vice-versa.

wors -> worse

My concerns about REBOL execution speed are related to my will to 
use REBOL for every programming tasks, so I don't have to rely on 
other languages.

That would be nice (especially for us if you were to do so, given 
what you have written so far). Still, you should write to the strengths 
of the tool. I actually come pretty close right now - Much of the 
code I write in other languages is actually generated by REBOL scripts, 
something I would never dream of doing in Java.

If it makes you feel better, know this: You can bet that I will be 
making user-defined function types :)

I wasn't talking about relative strengths of languages but pure execution 
performances. I know how to implement fast algorithms in C, Java 
and REBOL. In REBOL, you can only find some "tricks" that will make 
 your code faster, but there's no intrinsic feature of REBOL language 
that could change the complexity of an optimized algorithm (that 
kind of case would fall in my "fair comparison" view).

The intrinsic feature of REBOL that changes the complexity of an 
optimized algorithm, for me, is runtime code generation. You can't 
make a fair comparison to C or Java about that though - you have 
to compare to Lisp or such. Tool for the job though.

My code wouldn't compile though. It is fast as-is, and I would rewrite 
it if REBOL were compiled to be fast then.

REBOL has nice and clean abstractions that make writing code much 
easier and much more pleasant, IMHO, it fails to become a general 
programming language mainly because of lack of performances. As long 
as you deal with a lot of I/O (like in a Cheyenne) or waiting for 
user event (like in VID/View), that's not a big showstopper, but 
when you need to process big amounts of data in memory, you have 
to rely on another language to do the job in acceptable times.

It depends on your needs, which is why it's important for Carl to 
know what has the most value for us, so he doesn't spend time on 
things that don't have as much value.

When VB1 came out, people would talk about how much faster C was 
for Windows apps. I would counter that VB was much faster than C...usually 
6 to 12 months faster. :-) I can argue the same for REBOL in many--though 
not all-cases.

Runtime code generation can reduce size of source code and make it 
more elegant, but I didn't saw yet, in my own code, any benefit on 
algorithm complexity (the big O notation).

I agree, Doc. I tend to do complex processing on smaller amounts 
of very complex data, so REBOL is very fast for me.

Very little math, much parsing and structure manipulation.

I've only hit a couple things where REBOL isn't fast enough. Animation 
(obviously), and longest-common-subsequence algorithm (Rebcode version 
was much faster, but still not fast). And if I could save JPGs natively 
from REBOL, I could eliminate one of my largest external dependencies 
(ImageMagick).

Gregg: as an old VB coder (still using it these days), I agree. But 
there's lot of applications you just can write in a slow executing 
language, and I *really* would like to only code in REBOL.

For most of my code, it isn't interpreter execution time that makes 
REBOL more efficient. A typical REBOL program for me saves me days 
or weeks of work, sometimes more.

I agree Doc. But even when I wrote VB, I often supplemented it with 
DLLs written in something else, so I'm OK with having to do that 
with REBOL, but I need to be able to do that easily--more easily 
than I do today.

Rebcode could have been a solution, but it seems quite low priority 
for Carl.

I tend to think that JIT compiling block! values to native code before 
executing would be the best way (rather that rely on a very different 
dialect, like Rebcode).

Rebcode will come as a side-effect of user-defined function types, 
which require user-defined datatypes, which requires the plugin model, 
which requires modules, which may require changes to object!, which 
are partly based on changes to the core that result from his current 
VID work.

But I guess that even a JIT approach would require to give up on 
a few features of the DO dialect.

:-D

Brian, you're a good advocate for Carl's strategy, but Rebcode already 
exists without all that dependency chain and it's even usable, it's 
just a pity it didn't make it in 2.7.6 and Encap.

Yes, the compilable dialect would have different semantics than the 
DO dialect but could look superficially the same, and execute a lot 
of the same code (not mine, of course). We have done this before 
in the R1 to R2 transition when we switched from a Scheme-like engine 
to a Forth-like engine without changing the syntax (except for getting 
rid of ELSE). I already have some ideas about how to do this - it's 
on my to-do list.

What would be the compilation unit in your view of "compilable dialect", 
function! or block! values ?

I am well aware of how the old rebcode worked - I was the main beta 
tester. It had the same dependencies then as well, though the execution 
engine being internal made the chain a little different. It was also 
unstable, buggy and insecure.

The natural compilation unit in REBOL is the function. That is how 
the different function types have different execution models already.

It is only the function type that makes the data in a block considered 
code.

Function values

(sorry)

Right. Functions are values in REBOL, and how they are interpreted 
(or compiled) depends on their datatype.

By the way, DELECT uses some of the same techniques that rebcode 
did to be fast.

The new function binding model in R3 makes Rebcode not as fast in 
R3 as it was in R2, if it uses the same semantic model. In order 
to be worth including we would have to change the semantic model 
accordingly.

I would choose block-level for a JIT compilation in REBOL, that would 
allow to compile more semantics than at function level. For example 
[do append [print] "hello"] could be compiled using block-level JIT.