World: r4wp

The user value is what matters most

It includes a bunch of display's but both the same.

Feared so much, It is still impressive.

How do you mean?

Red/System seems to be only a third slower. Did you compile the C 
version with optimisation?

I will clear both scripts from the extra display's I built in during 
debugging.

Optimisation? Just hit build in XCode, happy it does something. You 
want the sources when I am ready cleaning them up? 

I thought about looping it a 1000 times each and see how it performs, 
but that is maybe only for more digits beyond the decimal point..

I mean optimisation by the compiler. You should make sure an -O2 
option is passed to the compiler

Looping is a good idea to get better timing accuracy

Having debugging code in there distorts the result, and a lot compared 
to the real code, since it takes so little time

But even loading the executable takes more time than the calculation, 
so the above timing is meaningless

I can specify Release or Debug. I used the Debug up till now.
loop 1000 times Red/System script 
real	0m18.446s
user	0m18.385s
sys	0m0.023s
Then I have 
real	0m2.424s
user	0m2.405s
sys	0m0.006s

My C is not what is used to be. No doubechecked should do same loop. 
Well if this is the case there is some improvement ahead.

One difference I found during debugging is that Red seems to initialize 
its array before using it. In the C version there was data in an 
previously unused part of one of the arrays.

If you like  I can share the sources I used.

I don't think Red/System does. ALLOCATE should just use malloc()

To get zeroed memory, you can use MAKE in my C library binding

Is the second time for 1000 x C? Then Red/System comes out almost 
8 times as slow as C. I wouldn't expect that, either

(I am trying to avoid as much C as possible) I am happy with the 
result being the same now, could not judge where the memory was allocated 
but it was consistent during all my testruns, as was the C array 
with it's unexplainable filled fields.

Yes that is a lot, completely agreed. I'll have a third look. Seems 
the same stuff in the loops.

I usually get zero-filled memory in Red/System, too, but it's not 
guaranteed

C is supposed to work like that, for performance

Good to know it is not guaranteed. Trouble uploading .reds file stays 
Empty.

8 times slower - do you consider it bad, or good? I mean - in regards 
to how is Red/System designed ...

If it's correct, it's bad. So I think it's not correct :-)

Still prompt to jump to conclusions without even looking at what 
the code does? :-)

I'm torn between defending Red/System and defending my fellow countryman

My comment was directed to Pekr. ;-)

No need to defend me now. I hope I am wrong, it happens ;) Should 
have made the folder public do that anyway.

randompublic folder added.

Still prompt to jump to conclusions without even looking at what 
the code does
 - can you really read my message as jumping to any conclusion?

Yes, you were comparing the speed of two programs without being sure 
they were implementing exactly the same algorithm.

Knuth's code could compete at C obfuscated contests. Arnold seems 
to have done a literal translation to Red/System but keeping the 
same obfuscated symbols, so not easy to read. However, it seems at 
first look that the algorithm has been well preserved.

Congrats to Arnold for doing this conversion and getting the right 
results! :)

Here's a bug:

ran_arr_ptr/value: ran_arr_dummy   ;; the next random number, or 
-1

should be

ran_arr_ptr/value: :ran_arr_dummy

Yes, you were comparing

 - wrong - I was not comparing anything, nor complaining to anything 
 ;-) My question was more general, headed towards if in regards to 
 red/system architecture, the measure of being 8x slower than C (in 
 a concrete example guys were talking about), is good, or bad. I simply 
 don't remember outcome of prior discussions, that's all.

In limited tests so far, the indication was that Red/System was roughly 
as fast as unoptimised C, half as fast as optimised C compiled with 
GCC

This is a more elaborate test, though

Here's a real algorithmic bug:

if  (is_odd(ss) = 1) [

It's deceiving to write this in a form that looks like C. The Red 
evaluation rules compute this as

if is_odd (ss = 1) [

You would have to write

if 1 = is_odd ss [

But it's better to write

#define is_odd(x) [(x) and (1)] ; test on the unit bit of x

as

#define odd? (x) [(as-logic x and 1)]

if odd? ss [