World: r4wp

On my Linux VM, it now performs as fast as C, but I'm not sure how 
accurate is the emulated clock.

Optimised or unoptimised C?

unoptimised

The times are small, so they become less accurate, and the printing 
comes into play

Here's my new table:

Mandelbrot
Syllable Server, AMD Athlon XP 1800+ (256 KB L2 cache)
						CPU Time	Relative
C (GCC -O2)				.025		1
C (GCC 4.4.3 i686)		.05			2
Red/System				.11 (0.3)	4
World (complex math)	4 (7)		150
World					6 (9)		250
Boron (i486)			7.5 (10)	300
ORCA (i486)				9 (12)		350
REBOL 3 2.100.111.4.4	9 (12)		350
REBOL 2 2.7.7			11 (13)		450
Ruby 1.8.7.248 (i486)	12 (15)		500

Ah, still no cigare :-)

I'm still impressed :-)

It's a bit strange, because the inner FP code should be identical 
between C and Red/System now. But anyway, it's more than enough for 
now.

Yes, I'm satisfied for now :-)

I hope that will be fast enough to make the USS Enterprise travel 
at warp speed? ;-)

It will have to travel back in time, because that will still take 
a while

I just saw the first black GL window flashing open and close in a 
splitsecond, that's all

i have a green gl window driven by red/s :) nothing more, yet, though 
:)

I have a case where the library wants to use a function that should 
be defined in the program. This doesn't work, apparently because 
Red/System doesn't export the function. The library can't resolve 
the symbol

We could try and export symbols for all [callback]/[cdecl]/[stdcall] 
functions.

What library?

OpenGL

What function?

The main UI loop I can work around it

but I can

What are you using, GLUT?

No, but it's a GLUT like emulation on top of SDL

Kaj: It's comment {} not comment []. ... I tested your example using 
{} and it compiled okay.

I suppose both are allowed, as in REBOL?

{} can go wrong if there's a curly bracket in the code

Comment [] is the word comment followed by a block in REBOL. It works 
because the block doesn't get evalutated.

I thought COMMENT takes one parameter, as it were?

In any case, a block works in Red/System, so it doesn't get compiled

I don't believe Comment is a function in Red/System as it is in REBOL. 
I think it is more like a compiler directive.

A block will work with the compiler but not the pre-processor because 
the complier is working with loaded REBOL values whereas the pre-processor 
is probably working with string data.

Kaj: could you replace `print` by `putchar` in the Mandelbrot bench, 
so it is equivalent to the C version? (Not sure it would change much 
the timings, but at least, the sources will be equivalent).

`print newline` would then become `putchar lf`

In earlier tests it made no difference, but it may now because the 
times are small. Better test that without printing at all

A better way would be to increase the number of iterations

The preprocessor is block oriented now, isn't it?

Yes it is.

To be more precise, there's a string stage and a block stage in the 
preprocessor. All the compiler directive are processed at the block 
stage. The string stage is just a front-end to handle R2-incompatible 
syntax, like the Red/System hex notation, and count source lines.

Kaj: do you know why __libc_csu_init and __libc_csu_fini are not 
defined in libc in Linux? How am I supposed to pass them to __libc_start_main 
if I can't access them?

Don't pass them.

Isn't the libc doing important initialization and clean-up in these 
two functions?

Nope, they can safely be NULL.

__libc_start_main by itself is not doing much work, just a few calls 
and some global var init (like __environ). When I disassemble a C 
binary, these two calls are doing a lot of work.

well, __libc_csu_init and __libc_csu_fini are functions that are 
linked by gcc into the generated executable.

__libc_csu_init calls _init which in turn calls two more functions: 
call_gmon_start and __do_global_ctors_aux

call_gmon_start is support for the gnu profiler

__do_global_ctors_aux is for traversing ELF "constructors" (stored 
in a .CTORS section) which are then rnu

run*

as red/s neither supports elf ctors/dtors nor gprof, none if this 
should be needed

(again, all of the above are functions linked into the program binary 
by gcc)

okay, thanks for checking that.