World: r3wp

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.

I would keep the DO dialect as is - it would be faster that way, 
because Java is only faster after you factor out JIT overhead. By 
having the compilation overhead at function creation time you could 
plan for it accordingly.

I don't agree for Java JIT overhead. Programs spend most of their 
time in loops where JIT overhead becomes rapidly unnoticeable (loops 
compiled code is cached).

Btw, I guess that Java JIT compiler can run in their own thread, 
so also being able to take real advantage from multi-core CPU.

There would be 2 things you would have to give up in a compilable 
dialect of REBOL, if you want it to be worth it:

- Code blocks that aren't statically determinable at function creation 
time (unlike your example above, which could be partially evaluated)

- Functions that could be edited in place, or hot-patched (already 
gone in R3)

If you don't give these up you would be adding compilation overhead. 
Admittedly, Java isn't the right language to emulate here - Forth 
or other stack languages would be better, as they are closer to the 
REBOL execution model and compiled Forth can be drastically faster 
than the best Java code.

There are several functions in REBOL that operate on their argument 
blocks following the DO model. If you make those functions require 
a literal block you could compile REBOL as-is.

Forth vs Java: well maybe it was very true 10 years ago, but since 
then, the gap is closing with some great  improvements in compilation 
like Java's Hotspot VM.

That's why I mentioned "other stack languages". There has been a 
lot of research in that camp too - they just name their languages 
other names than Forth. I think that some of the research in type-inferenced 
stack languages will eventually make Java and .NET faster too.

Remember, the JVM and CLR are both stack engnes.

Code blocks that aren't statically determinable at function creation 
time

. I agree, but if you look at most of the code written in REBOL (including 
mine or Carl's), it doesn't fall into that case. So, I guess that 
most of REBOL written code can be compiled. Maybe the compiler could 
be made smart enough to figure out what code can or cannot be compiled.

Yup (I've already given this some thought). Hand-optimized code may 
have to be reoptimized though, and this includes some of the optimizations 
that I made to some of the mezzanine functions. You would speed things 
up drastically by using explicit type checking or get-words to filter 
out theoretical function value evaluation.

The fewer possible interpretations of a particular piece of REBOL 
code, the faster the compiler could make it. Inflexibility is what 
makes Java fast, not compilation.

Inflexibility is what makes Java easier to compile. ;-)

I've also thought about all that quite often, it's a really fascinating 
topic.

Need to go to sleep, thanks for the nice chat Brian.

Java code that is as powerful as REBOL code is slower than REBOL. 
If you restrict what your REBOL code does to what Java can do it 
will be slower with the current interpreter. You only get speed out 
of REBOL by writing REBOL code.

Good night :)

the comicis great i was the first one to propose Carl to do something 
like that as presentation for R3 technos

what i like in the  comic is how they present the deferent technologies 
aspect how they are deal to day what is the problem and then what 
is the solution apported by the new point of view introdiced into 
chrome

for example java script -> slow because it's part of the asynchronous 
rendering system and because the javascript systeme reads over and 
over the same code to execute it

solution introduced in chrome javascript runs in a new VM  that read 
the code once transform it into hiden object and then into natural 
code wich is runed again and again  and the VM  is a speparated process 
to focus the resources where they are needed