World: r3wp

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]
	poke img 1 a
]

update-pixel: does [
	do draw-pix col/1 col/2 col/3 col/4
	probe img
	show i
]

col: 0.0.0.0
img: make image! 1x1

view layout [
	backcolor black
	i: image img 100x100
	scroller 200x16 [
		col/1: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/2: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/3: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/4: to-integer face/data * 255
		update-pixel
	]
]

not if you do PICK on image!

I mean in regular REBOL code.

I guess Cyphre has a good qualification for such statements ;)

I REBOL the pixelformat is RGBA due to tuple! behaviour (you can 
left the last value of tupple == opaque pixel)

So another coversion needed :)

In REBCODE you are accessing image! internally so the pixelformat 
is ARGB.

Kru: yes, in Rebol there is conversion done. In Rebcode you are at 
full speed ;)

Cypher, have you looked at the apply problem?

not yet

There's an apply problem?

trying to reproduce the problem I've just crashed REBOL with CRASH 
Should not happen

Maybe not a problem, but overhead?

And REBOL ate all memory

can you post the code?

yes, show us!

two testing functions:

>> mulr: rebcode [a][mul a 2 return a]
>> mull: rebcode [a][loop 10000000 [apply a mulr [a]] return a]

From my tests calling a REBCODE function (or subroutine) using APPLY 
is by 100% slower than reusing the same code.

first test: xt: now/time/precise loop 10000000 [mulr 2] now/time/precise 
- xt

Is that neccessary?

second test: xt: now/time/precise mull 2 now/time/precise - xt

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.