World: r3wp

ssecond does has some problem

does=test

Is it neccessary to tune that, or would macro-expansion do? faster 
anyway. How big may rebcode-parts be?

hunderts lines of rebcode in my case :)

Not much memory then! But much work :)

1GB is not enough for ten milions multiplications? :)

It looks like APPLY inside a LOOP is causing those problems.

This need to be fixed.

(I meant inside Rebcode LOOP)

if I lower number of loops to 1 000 000, there's no crash and the 
difference between direct and apply version is not so big, some 5% 
(but still remember, that in the apply version, there's loop inside 
rebcode and it's way faster than rebol's loop, so apply is still 
slowing it down)

I think it eat too much memory.

It looks like some memory leak.

time: func [b /local start] [
	start: now/precise
	do b
	print ["Time:" difference now/precise start]
]

rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	or a r
	or a g
	or a b
	return a
]


draw-pix: rebcode [r g b a][
	apply a rgba-to-int [r g b a]
	return a
]

draw-pix2: rebcode [r g b a][
	loop 1000000 [
		apply a rgba-to-int [r g b a]
	]
	return a
]

probe stats
recycle
time [loop 1000000 [draw-pix 255 255 255 255]]
probe stats
recycle
time [loop 1000000 [rgba-to-int 255 255 255 255]]
probe stats
recycle
time [draw-pix2 255 255 255 255]
probe stats

you can see that stats in Rebol shows 'normal' values but in the 
last test case the memory allocation under Windows increase by 300MB!!

A note about speed:
I've made an exponont function like this:

exponent: rebcode [b [decimal!] x [decimal!]] [
	eqd x 0.0
	braf 2
	return 1.0
	log-e b
	muld b x
	exp b
	return b
]

It can then be used in a rebcode function, e.g.:
apply result exponent [2.0 4.0]

An alternative way is to make a normal REBOL function:
exponent: func [b x][b ** x]
which can be used the same way:
apply result exponent [2.0 4.0]


It turns out, that using a normal REBOL function is faster in this 
example. It then occured to me, that it could be even faster, if 
APPLY was changed to support operators. Like this:
apply result ** [2.0 4.0]

Is that a good request?

I will check it

Apply doesn't support operators?

no

How well does  apply res power [b x]  work? That's the regular native 
equivalent to **.

All operators have native equivalents.

it's faster than using a REBOL function. It works with POWER as it 
should with the operator **, so I'm happy. (I just noticed, POWER 
wasn't an operator. Didn't know that.)

Kru: this really seems to be APPLY related, because the following 
code crashes too:

mulr: rebcode [][return 4]
mull: rebcode [][loop 10000000 [apply a mulr []] return a]
mull

Geomol, POWER may seem faster that rebcode version, but this is again 
thanks to apply. From my tests it looks like apply/POWER version 
is cca 5% faster than apply/rebcode version but rebcode version only 
(loop is inside rebcode and no apply) is cca 3.8x faster than apply/rebcode 
version

APPLY may be good for thinks like reading from network or so, that 
cannot be done in rebcode, but it's not useable as subroutine call 
in rebcode, it's too slow.

Kru, ok I'll check with the bezier function, I'm doing here...

guys, how well does parse play with rebcode? It was said that parse 
is VM in itself, it is very right, but now we have some discussion 
about zlib support. Let's suppose we have rebol version on rebol.org 
and that we would like to speed it up. We can simple extend the idea 
to any other datatype (= in amiga terms, simply a file format, or 
protocol one). you will surely want to use parse. The question is, 
if you can speed up some things using rebcode?

Imagine e.g. doing image loader/saver ....

Kru, I calculate apply/power to be 5% faster than inline rebcode 
exponential function in my case. So I find:

apply/power is fastest, then
inline rebcode exponential, then
apply/REBOL function, then
apply/rebcode function

, when it comes to exponential function in my case.

Geomol can I see your test code?

Kru, I write it to you privately...

Using APPLY with POWER may be a special case, because the equivalent 
is 10-11 lines of rebcode. So in this case, calling POWER with APPLY 
is actually faster than programming the POWER function inline in 
rebcode. (I hope, I make sense.)

I also find
apply result power [b x]
to be faster than
do result [b ** x]

Correction:
power 0.0 0.0

gives result 0.0. I check for that in my code and give result 1.0. 
With that check before calling POWER, the inline rebcode version 
becomes the fastest, *not* apply/power

With rebcode, optimization suddently becomes science.

Wow! Making the factorial inline speeded it up 245%!
New bezier:

bezier: rebcode [
	t	[decimal!]
	P	[block!]
	/local result m n n! i a b c d idx
][
	do result [copy [0.0 0.0]]
	length? n P
	div n 2
	set m n
	sub n 1
	;apply n! factorial [n]
	set n! 1
	repeat x n [
		mul n! x
	]
	repeatz i m [
		to-dec a n!
		;apply b factorial [i]
		set b 1
		repeat x i [
			mul b x
		]
		to-dec b b
		divd a b
		set b n
		sub b i
		;apply c factorial [b]
		set c 1
		repeat x b [
			mul c x
		]
		to-dec c c
		divd a c

		eq i 0
		braf i-not-0
		set d 1.0
		bra muld-d-a
		label i-not-0
		to-dec c i
		set d t
		;apply d power [t c]
		log-e d
		muld d c
		exp d

		label muld-d-a
		muld d a
		set a 1.0
		subd a t

		eq b 0
		braf b-not-0
		set a 1.0
		bra muld-a-c
		label b-not-0
		to-dec b b
		;apply a power [a b]
		log-e a
		muld a b
		exp a

		label muld-a-c
		muld a d

		set idx i
		mul idx 2
		pickz b P idx
		muld b a
		pick c result 1
		addd b c
		poke result 1 b

		add idx 1
		pickz b P idx
		muld b a
		pick c result 2
		addd b c
		poke result 2 b
	]
	return result
]

how long would it take to calculate an image histogram?

ops, my last 2 messages should have been to Kru.

Pekr, with this histogram function:
histogram: rebcode [rgb result /local r n a b c] [
	length? n rgb
	div n 3
	repeatz i n [
		set a i
		mul a 3
		pickz b rgb a
		add a 1
		pickz c rgb a
		add b c
		add a 1
		pickz c rgb a
		add b c
		div b 3
		pickz c result b
		add c 1
		pokez result b c
	]
	return result
]

it takes 0.094 seconds on my machine to get histogram of 640x480 
pixel image.

0.406 seconds for 1280x1024 image.

You can try it like this:

img: make image! 1280x1024
result: copy []
loop img/size/x * img/size/y [insert tail result 0]
histogram img/rgb result

this code is not histogram:)

shouldn't histogram basically count pixels of 0- 255 channel values? 
:-)

yes

The histogram, I posted, count combined rgb values (or light value 
if you like). To count rgb values individually, a little change is 
needed.

(And you need more data structures to hold the results.)

I guess, Pekr's original question was about, if it's reasonable fast 
with rebcode, and I would say, that it is.

yes, thanks :-)

you know, when we originally developed high-end astronomy CCD camera, 
it returns you per-pixel value of 1 to 65535, according of how much 
current counts in the individual pixels ... you ten need to convert 
it to image, so you have to get minimu,maximum, and divide it into 
256 zones .... when I did it using plain rebol, it was painfully 
slow. Imagine having lucrative in-camera ethernet + ip, downloading 
image using rebol in 1 sec or so, and then waiting 19 secs tojust 
view the image :-) If we would do this device nowadays, with Rebcode, 
I believe I would not hesistate to use rebol for all operations ....

Was anybody testing if what is faster, if rebcode or c-code call 
using dll?