AltME groups: search

@DocLimbel Is there a way to speed updates? Could you ask for some 
specific functions or some other piece of code to be developed ?

@Marco: I don't see any simple way to speed up updates for now, but 
if you have propositions, I'll be glad to review them.

So you think that the 50% speed difference between these two functions 
is due to Windows clock?

There is a bit that is worth learning from R3's Unicode transition 
that would help Red.


First, make sure that strings are logically series of codepoints. 
Don't expose the internal structure of strings to code that uses 
them. Different underlying platforms do their Unicode APIs using 
different formats, so on different platforms you might need to implement 
strings differently. You don't want these differences affecting the 
Red code that uses these strings.


Don't have direct equivalence between binary! and string! - require 
conversion between them. No AS-STRING and AS-BINARY functions. Don't 
export the underlying binary data. If you do, the code that uses 
strings would come to depend on a particular underlying format, and 
would then break on platforms where the underlying format is different. 
Also, if you provide access to the underlying binary data to Red 
code, you have to assume that the format of that data can be corrupted 
at any moment, so you'll have to add a lot of verification code, 
and your compiler won't be able to get rid of it.


Work in codepoints, not characters. Unicode characters are complicated 
and can involve multiple codepoints, or not, but until you display 
it none of that matters.


R3 uses fixed-length encodings of strings internally in order to 
speed things up, but that can cause problems when running on underlying 
platforms that use variable-length encodings in their APIs, like 
Linux (UTF-8) and Windows/Java/.NET/OSX? (UTF-16). This makes sense 
for R3 because the underlying code is compiled, but the outer code 
is not, and there's no way to break that barrier. With Red the string 
API could be logical, with the optimizer making the distinction go 
away, so you might be able to get away with using variable-length 
encodings internally if that makes sense to you. Length and index 
would be slower, but there'd be less overhead when calling external 
API functions, so make the tradeoff that works best for you.

I am for sure no expert regarding unicode, but as red is a compiler 
and open source, why not not add flags that the user has to choose 
which unicode/string support he wants; either flexibility, but of 
cost of speed or no unicode support, then he  has to do the hard 
work by himself

Is there any "tedious" task (not involving manuals, docs or graphics) 
that could be done by some volunteer to speed up Red development 
?

Marco: besides coding in Red/System, I don't see what you could do 
currently to speed it up. Here are some ideas for the additional 
coding that will need to be done:


You can write in Red/System some of the non-trivial natives, like 
e.g. set natives: sort, union, intersect, unique, difference. Other 
natives or support code we will need are codecs for:

- compression supporting these algorithms: deflate, lzo

- cryptography: MD5, SHA-1, AES, ...(all the required ones for SSH 
and SSL support)


You can port C code to Red/System, there are tons of available C 
source code, you just have to make it right (crypto requires accurate 
coding, implementations need to be deeply tested for flaws).

I don't see currently any trivial task that could speed up the progress 
of Red, unfortunately, all the tasks in the Roadmap are non-trivial. 
If I stumble upon some non-coding task that can be outsourced, I 
will contact you.

Elapsed time for fib on Reds is 0, process time is 0.103 - so fib 
is hundreds of times faster on Reds compared to R2 - so I guess it 
depends on the program as to the speed difference

What is really exciting is the concept of creating an OS which is 
completely red/red/system - the control, power and speed of that 
woulod be phenomenal

Red/System v2 will be faster, it will benefit from a lot of optimization 
stages that do not exist in the current version. I expect a raw speed 
improvement of between x2 and x4. Maybe more if we can use some SIMD 
to speed up some processing (but that will probably require new datatypes, 
and/or new looping functions).

I hope that a lot more Rebol coders get on-board with Red to help 
Doc and speed development - Red is the future I think, not interpreted 
Rebol, as brilliant as that has been in the past.

Also, the implementation speed factor also weighed a lot in architectural 
choices for the bootstrap code.

bOK Doc I agree for the speed factor But then you would do the multi-targets 
road again this time for multiple GPUs , isn't it ?

OpenCL is certainly a quicker way to access it. My plan for direct 
GPU access is not only motivated by speed gains, but also by reducing 
complexity, having a simple, lightweight access to GPGPU capabilities.

Kaj: you can switch the Windows console to an UTF-8 compatible mode 
using _setmode():
http://msdn.microsoft.com/en-us/library/tw4k6df8.aspx


I haven't test it but it should work. Windows uses natively UTF-16LE, 
so you would probably have a speed penalty using that mode.

Jerry: that sounds like a realistic deadline to reach 1.0 release, 
as long as I can keep working full time on Red in 2013. Though, Red 
should be fully usable in a couple of months, all features would 
not be there, it won't run at full speed, but it will be enough to 
be able to build almost any app.

So, we get both worlds. If we manage to call R3 code from the Red 
section and vice versa, that would be great. We could use the compiled 
speed for inner loops and let the interpreter do all the non-speed 
relevant things.

I want to compliment you on the speed of development of Red! It is 
truly amazing. Keep up the good work.
Is this news also worth mentioning on the red-lang.org website?

Uh, what optimisations, Kaj? We are talking Red bing compiled to 
Red/System, so how comes, that the result is only 2 times faster 
than R3? I expected speed of nearly a R/S version. Something must 
be wrong, or Red would not make sense with such poor performance 
at all imo ...

You can get Red/System speed if you write in Red/System, not if you 
write Red

Red is a high-level language with high-level abstract types. Once 
we get optimizations, Kaj's example should run 5-10 faster than R3. 
For some high-level expressions that have low-level counterparts, 
it is possible to achieve very high gains (in the 10-100 range), 
for those that do not have low-level counterparts, you can only expect 
typical gains from moving from an interpreter to a compiler (on average 
5-10 faster).


Also, there is also a source of additional speed gains: the possible 
runtime optimizations enabled by the JIT-compiler.

Steeve, performances gains will depends on the kind of code you run. 
For micro-benchmarks (like loop 10'000'000 [tail? ""]), the target 
compiler should perform 5-10 faster than R3. For "normal apps", you 
should expect a 10-20 gain (very rough early estimates). For math 
intensive apps, you'll be able to go up to x100 speed gains.

The speed difference with R3 is not a constant, the more code you 
put in the loop, the bigger the speed difference.

I gave the topic of the "speed" more thoughts, and though I am very 
uneducated in lower level internals and language designs, I think 
that I might have more understanding, why I can't think about Red 
being just a compiler to Red/System in a 1:1 manner. In such a case, 
Red would not be needed. What needs to be included in the final exe 
is kind of "engine", supporting stuff like GC, all the dynamic things, 
type checking engine, etc etc. 


When I ask myself, if I am willing to exchange dynamic stuff for 
speed, I say - no, at least not necessarily. It was just that I got 
trapped by first R/S performance tests, and thinking that if Red 
compile, it has to be almost that fast too.


As for waiting for 1.x and possible optimisations - I don't believe 
optimisations can change things drastically, at least non in order 
of a magnitude. But - we will see.

Personally, I feel that Google's V8 & Apple's Nitro give orders of 
magnitude speed improvements over early JavaScript Compilers.

The "step in the middle" is the compilation of:

- the Red/System code generated from Red code (user + boot script)
- the whole Red runtime code (in Red/System)
- the whole Red/System runtime code (in Red/System)

The current "slowness" is caused mainly by:
1) all the runtime parts being recompiled for each user script
2) REBOL relative slowness

The cures are:

- for 1), precompile runtime parts, and recompile them only on changes

- for 2), Red self-hosted compiler will give a good boost (x10 is 
my target)


Also, the self-hosted Red and Red/System compilation speed will be 
improved compared to the current versions. In the end, we should 
have very fast static and dynamic compilation, the target to reach 
for the JIT compilation mode is less than 100ms for short scripts, 
typically, most functions should compile under 10ms.

Ah, I thought so, could count minutes before someone comes with "hardware 
acceleration claim". We havent ever utilised full speed of new View 
engine in R3, yet we want it even faster :-) But understood, some 
mobile devices might not have FPU or so ...

We havent ever utilised full speed of new View engine in R3, yet 
we want it even faster :-)


What I just say is that you have it for free when using native widgets.

I have added a new function type today: routine!. It allows to write 
a Red/System function in a Red program. The compiler will marshal 
(or type-cast) the arguments back and forth automatically.

Here is the Fibonacci example rewritten as a routine:

Red [ ]

fibonacci: routine [
    n          [integer!]
    return: [integer!]
][
    either n < 2 [
        n
    ][
        (fibonacci n - 1) + (fibonacci n - 2)
    ]
]


The function body is Red/System code, so it will run at full Red/System 
speed.


Integer! and logic! values are converted automatically, other Red 
datatypes are passed boxed but type-casted as Red/System counterparts 
(as defined in the Red runtime). Hint: floats will be converted automatically 
too.

So, passing and processing a block! series would look like this:

Red [ ]

add-one: routine [
    blk       [block!]
    return: [block!]
    /local value tail int
][
    value: HEAD(blk)
    tail: TAIL(blk)
	
    while [value < tail][
        if TYPE(value) = TYPE_INTEGER [
                int: as red-integer! value
                int/value: int/value + 1
        ]
        value: value + 1
    ]
    RETURN(blk)
]


I haven't yet released the code, it needs a bit more work, it should 
be ready by tomorrow.


The purpose of routine! datatype is to provide access to ultra-fast 
and low-level code for Red program in a simple way. The design is 
not yet fully set in stone, so suggestions and comments are welcome.

Right, if you bench from the console, currently, you're just measuring 
the speed of the interpreter. When the JIT will be there, loops from 
the console might get JIT-compiled, so it will be even less relevant 
to bench from the console. My plan since the beginning is to add 
a profiler to Red, so you'll be able to make precise comparisons 
whatever way the code is run.

in otjer words - how much is red compiled different to red interprete, 
speed wise?

I'll try to speed things up.

Since Red compiles to Red/system, how can I get the red/system source 
result?

Red is simpler to use but sometimes we want speed so why not let 
red compile to r/s

and then use that source to make a routine! or as a stand-alone program?

If used as keywords/hashtags in messages (blocks), would they be 
better as word! or string! values? Limits versus speed I suppose.

Doc, what I meant was, if you use blocks as a message structure, 
you include issue! values as hashtags, you gain speed and storage 
efficiency. But you may also hit limits. Suppose you have a blog/chat/tweet 
system, how many unique issues can you have without blowing a symbol 
table if they are words?


Not saying they shouldn't be words, to be clear, just making sure 
I know how to use them correctly. :-)

My brain came up with a solution for issue! while I was sleeping. 
It's a notational problem, so how about having both issue! and keyword! 
start with a # but when the next character is alphabetic, it's a 
keyword, and otherwise, it's an issue!.


This is consistent with both issue notation in American English and 
preprocessor keywords in C-like languages.


It's an easy rule for the lexer, and a relatively easy rule for humans, 
that is intuitively clear.


It optimises keyword use for speed, while preventing memory leaking 
into the symbol table for almost all issue notations.


It's unlikely that someone has issues starting with an alphabet character, 
but when they do, most cases will be transparent. In other cases, 
only little code needs to be added to handle them as keyword!.

Just want to briefly describe that in my expectation a C-level language 
means you can do things like you would when using C. So it is not 
that you would have to call functions/programs/libraries with C programs 
to do those things. So for speed issues or fast prototyping purposes 
or to do things not yet possible in another way you use the bindings. 
In my case I wanted to try to program a relative simple algorithm 
of which I have an example in C and I want to do that using Red or 
Red/System. I can accept it is too early at this stage.. at least 
for me but this kind of thing is what others will be doing in the 
near future and they discover you can do literally anything using 
Red and Red/System, as long as you make a C program to do it and 
call that. That is a bit of a black and white view, but that is how 
I see it.

pity he did not start porting Red/System into Red, that would speed-up 
removal of dependency on Rebol :-)

Bo, it depends on the code in question and the processor it's running 
on. It could be the same speed, it could be many times faster, and 
for some code it could be resolved completely at compile time and 
replaced with a constant.

Diminishing returns. Almost half of REBOL's lifetime was spent on 
a one third speed increase

Doc, on stress testing, I was just trying to do eyeball speed testing 
of some mezz code.

Yes, you said you might speed it up if I have a big need for it, 
so I'm expressing my need

I could, but I know very little of Unicode, so there would be a lot 
of overhead in getting up to speed

@Arnold and Pekr : What is the current behaviour of the Hello.apk 
? I thought it was displaying some welcome msg and then askin for 
some input before disappearing gracefully. Now on my machine a while 
screen is displayed with a "Hello" as its window name and nothing 
else is going on.... For the previous Red/System Hello, something 
almost similar was going on too. So it's not for the Red part fault 
but it is due to the lower layer ... I knew this but I can't diagnose 
what ios coming myself as I'm missing some vital knowlwdge here to 
be really helpful to debug anything ... on my own - sorry for having 
acquired some product in the first pioneers just to test how this 
kind of product was running on Android. I required some Flash and 
my Apple products just could'nt do it - but my tablet Android tablet 
was much slower on display than my iDevices. Hope that under Red 
and Red/System there will be some products running at full speed 
- if not I plan to let it go at a real bargain price very soon ... 
to get some more powerful device ASAP.

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

That change alone should make a significant difference in speed (I 
expected it close to twice faster) and code size compared to the 
current approach.

That speed result is consistent with earlier benchmarks

Yes the speed indicates there could be a possible bug, but the MS 
code is pretty straightforward and more one-to-one transcodable, 
so it might as well be right.

Quick testing of the MT Red/S and C versions on my machine give a 
~4x difference in speed.

I know that Doc says Red isn't ready for general use yet, but I was 
wondering if maybe there were some resources so I could get started 
getting up to speed on it.  When I started learning Rebol, it was 
probably even less complete.

You're correct. I checked and the optimisation benefit through "loop 
inversion" apparently comes from reducing the number of jumps in 
the underlying code not difference in speed in atrithmetic.

The development cycle?  Or the speed of the software?

Yes, the ARM instruction set is optimised for speed at the expense 
of size

My motion detection executable on the Pi is 30KB.  The same executable 
compiled for Windows is 15KB (50% the size).


Red currently emits only the standard ARM opcodes, so 32-bit per 
instruction. We'll add support in the future for Thumb mode (more 
compact instruction set). In the meantime, you can try to activate 
the literal pools by adding the following option to the Linux-ARM 
config block (in %config.r):

literal-pool?:	 yes


That should both reduce final binary size and give you a little speed 
improvement. But be sure to test is well as this mode has not been 
much used yet. Also, it might fail to compile if you use very big 
functions, or a lot of code in global context.

i can still imagine an example, when one would like to have more 
expressive R/S. Red does not compile only down to R/S, it also adds 
some Red related framework, which might mean larger executable, loss 
of speed, etc. Not sure what Doc thinks, as he always tells me - 
hey, use Red for such purposes, but maybe, who knows, there is a 
place for more advanced barebones R/S 2.0 after all :-)

I just noticed a few minutes ago when my trusty "do http://rebol.com/speed.r"
failed.

oh don't worry about speed, its a really small app with verry little 
to update... 


I've got 250000 line draw blocks which refresh 10 frames a second 
interactively  :-)

My full Atari emulator ran full speed on a Pentium 75 or a 100 MHz 
486. I roughly expect this one to run half as fast, so as a full 
emulator I'd expect it to need a Pentium 150. As another guesstimate, 
it should need half a Raspberry Pi

Let me announce first achievement of bringing R3 to Android OS based 
devices. I know many of you were waiting for this so long so here 
is the first test version to download:

http://development.saphirion.com/experimental/R3droid.apk


Note this is just first raw port showing the interpreter is working. 
The console input is missing at the moment, but will be probably 
among first things to add so you can have your beloved /Core on your 
mobile/tablet.


If you would like to speed up this developement, donate, sponsor 
or make a bounty for features please crosscheck with Robert/Saphition(he'll 
write more info here as well)

Kaj: how do Fibonaci.ruby and Fibonaci.r compare in speed on your 
demo machine?

Hasn't someone written 6502 emulator for REBOL too? Was it Geomol? 
It would be nice to compare speed-wise :-)

Yes, my em6502.r was a test of the speed of rebcode. It was meant 
as a proof-of-concept. I never used it much. It's for the rebcode 
found in REBOL/View 1.3.50, which was the first rebcode version afaik. 
So not compatible with later rebcode.


There also is an assembler: http://www.fys.ku.dk/~niclasen/rebol/language/asm6502.r

and a MOS 6502 workbench: http://www.fys.ku.dk/~niclasen/rebol/language/m6502wb.r

, if anyone can find some use of it.

Speed function crashed on my Huawei M865C:

Access error: cannot open %tmp-junk.txt   reason: -3
Where:  write unless do foreach speed? 

Near:  write file: %tmp-junk.txt  "" tmp: make string! 32000 * 5 
ins...

But indeed I do think for such relative simple algorithms you would 
not use calling of C functions unless you want speed etc.

@Kaj, I heard you ;) That would be on http://static.red-lang.org/red-system-specs.html
about section 14.1 examl=ple using malloc I guess. I have very limited 
time off atm :(

Rebol 3 Bazaar is Saphirion Rebol 3, at the moment. Saphirion wanted 
to go on GitHub, but htey ahve not time to do it. Now everybody can 
contribute and speed up Rebol 3 devolpment.

Yes.  I ran the test and posted it.  (I'm assuming you mean the speed 
test.)

Note that the project is done in Red so far. Only a small piece of 
Red/System was added to the pre-existing 0MQ binding to optimise 
it. I'm compiling the three programs of the project, but because 
they're in Red, they could also run in the interpreter. On the other 
hand, I would expect that to use more memory, so the compiler is 
probably essential to this project, not for speed but for memory 
performance. Also, a custom Red needs to be compiled to scale the 
memory system, so I could compile a special interpreter, but I might 
as well compile the entire program

Interesting, my tally function and Joel's, work almost in same speed, 
53 sec. for 1 million execution for both.

Interesting, my tally function and Joel's, work almost in same speed, 
53 sec. for 1 million execution for both.
 - I guess that the version using SORT should be much faster.

...and its speed cannot exceed the speed of more universal tallies 
in a significant way

I wanted to tell that they are too specialized while bringing no 
speed advantage compared to Joel's code.

Steeve, I like it. Most of the time I prefer readability over speed. 
This time a little speeding things up comes in handy.

Foreach doesn't go in reverse, so you're back to modifying your data. 
If you want to speed up stuff that FORALL does, just look at the 
source. You can inline the FORALL source, drop the error screening 
stuff and simplify the code in the WHILE. You will end up with something 
that can be as fast as the FOREACH, and in some cases faster.

Time-out! :D

I have enough information to make my script working with reasonable 
speed. After I publish it on rebol.org we can write out a competition 
to have it gain speed ;)

Don't know how the speed compares to Endo's original though.

Also runtime performance is a big concern for such functions, so 
every little speed gain is good to take.

As I mentioned, I already gave Carl an advice how to speed up binding 
in R3 substantially when compared to R2

OTOH, there is still one trick that can be used to speed up rebinding 
in closure case.

testing of binding itself on class vs prototype based oop for Rebol 
was several orders of magnitude when dealing with large objects. 
 both in speed and RAM.  I admit my tests are more on the extreme 
side of things, with the object in question taking up 80kb of RAM 
for every new instance.


but when grouping up the functions of the object into a "sub" object, 
like face/feel, instead of letting them live within the face itself, 
speedup was exponential.

at 1000 objects it was probably about 10 times faster, at 10000 objects 
it was about 25 times faster and I couldn't even allocate 100000 
prototype objects and it crashed after a full 76 minutes of crunching 
at 100% CPU.  a 1'000'000 object test with "classes" took 4 minutes 
and 400MB... so you can see that binding is a very significant part 
of the processing of Rebol, when it is required often.


obviously, some peeking into the C sources will allow us to optimize 
all of this, (especially if it can be memcopied directly)  but by 
default, as in R2, closures would theoretically be quite a hit in 
performance.

See also

http://issue.cc/r3/1946



to note that there is almost no limit how much more inefficient can 
R3 functions be compared to closures. This is unacceptable taking 
into account that R3 functions purportedly are a "compromise solution" 
sacrificing correctness, reliability, comfort for speed.

you have more than one solution, the first is a simple serial SELECT 
on each table -> compare the output for equal.

of course this produce unnecessary DB overhead but I guess you won't 
feel any speed difference except you are

serving a whole city concurrently. another, better one is a JOIN 
or UNION.

SELECT table_name1.column_name(s), ...
FROM table_name1
LEFT JOIN table_name2
ON table_name1.column_name=table_name2.column_name


the JOIN direction (LEFT,RIGHT,INNER) for your reference table is 
important here. 

the resultset is a table containing BOTH columns. if both having 
a value -> match, if one is empty then you don't.


index both fields to accelerate the query and use something like 
the free SQLyog 
to test different queries to make debugging easier for you.


while you situation reminds me to myself, sitting infront of a monochrom 
asthon tate dot some decades ago

and asking what next?, you should 'bite' yourself now thru the rest. 
It won't help you on longterm if you don't.

I'm starting to get the GUI build to work, and it takes a few hours 
here, but Syllable Desktop can't use the second core on this machine, 
and compiling is roughly half the speed as on Linux, anyway, so that's 
roughly consistent with your timing

We see people taking two days to download at snail speed via BitTorrent. 
I imagine they're in Siberia or something. That's why the downloads 
need to be as small as possible

with an additional lightweight scheme for user/authentication on 
the rebol site and the zmq workhorse lives on the C side, with all 
it's advantages (speed/thread).

If you are writing tests, there are a few things you should know 
about the behavior-as-designed of REWORD:

- values is a collection of key/value pairs, like a map. If a block, 
no reduce is done, it's just data.

- Keys are converted to strings if they aren't strings already, and 
are considered equivalent if their strings are equivalent.

- Empty strings don't count, but the check for empty keys is done 
after the string conversion so none is not empty, it's "none".
- If a value is unset or none, the key/value pair is ignored.

- If the same key is specified more than once, the last value of 
that key takes precedence.

- After all of the key/value conflicts are resolved, if there are 
ambiguities between keys (like "ab" vs. "a") then the first key gets 
priority. That means that you probably want to put the longer key 
first, same as with PARSE alternates.


If we're writing tests, we need to write tests for all of those. 
And we probably need tests because it was intended that REWORD be 
converted to a native for speed after we settled on its behavior. 
The current REWORD works as designed, but we might want to tweak 
the design after further discussion.

I think a little funding would go a long, long way towards bringing 
REBOL back up to speed, and back into a relevant and competitive 
position.

The speed difference must be at least (actually, it should be even 
greater a bit due to the deimal nature) equal to the difference between 
floating point arithmetic done by the coprocessor, versus it being 
done by an emulator.

if speed is required (which it is rarely, for most cases in which 
rebol is optimal), then IMHO we won't mind dealing with any additional 
details like a type denominator (which other languages also use) 
to separate similar types like the use of   0.01f  in C/C++ to cast 
to float (instead of a double, used by default).

The beauty of freedom from C on all platforms cross-platform, relative 
speed => Red

The flexibility of REBOL to the maximum, remember Red will be a Reduced 
REBOL dialect => R3

You are almost one step ahead of me there, Yeksoon.

The code is in place to make each of the banner statements clickable. 
That will take you to a page with an extended explanation.

Example: one of the soundbites might be "includes cross-platform 
assembler for 20x code speed-up". If clicked will take you to a paragraph 
on rebcode with links to more documentation.

But first, we need the 20 best soundbites :-)
Any offers?

The new clickable banner text concept is a great idea. I much prefer 
it to the original.


One comment on the rebcode description - "decimal order of magnitude" 
is probably accurate but seems to read like a "point something" (10%?) 
speed increase. It maybe better to just to say "order of magnitude".

As always, good work for implementing it Sunanda.

Did you do any speed comparisons to classical templating engines? 
:-) I read about smarty, its compilation etc., but found it unpractical. 
Maybe Temple with FastCGI could be even faster, as it could have 
some templates preloaded :-)

on speed with respect to php (and probably other languages).


smarty itself can be further 'accelerated' with accelerators like 
ionCube 
http://www.php-accelerator.co.uk/


So, if one was to ever go down this lane of comparing speed, then 
there is a need to compare
1. tempate system alone
2. with accelerators on.

Yes, you're right. Up this point I was really looking at the wrong 
documentation so the Actionscript clue was helpful.


Here's an example. I haven't tried to translate it yet. It looks 
pretty straight forward. 

Movieclip.prototype.fade = function(speed) {
this.speed = speed;
this.f_index = this._alpha;
if(this.f_index >= 100) this.fade_by = -this.speed;
if(this.f_index <= 0) this.fade_by = this.speed;

this._alpha += this.fade_by;
}

Or you can use these to fadeIn() or fadeOut()


Movieclip.prototype.fadeOut = function($decrement, $fadeLimit){



	var $mcObject = this;

	//If $decrement is not defined, then define it

	if($decrement == undefined){

		var $decrement = 11;

	}//End if



	if($fadeLimit == undefined){

		var $fadeLimit = 0;

	}//End if



	if(eval($mcObject)._alpha < $fadeLimit){

		return(true);

	} else {

		eval($mcObject)._alpha -= $decrement;

	}//End if



}//End function

Movieclip.prototype.fade: func[speed][
	this.speed: speed
	this.f_index: this._alpha
	if this.f_index >= 100 [ this.fade_by: 0 - this.speed]
	if this.f_index <= 0   [ this.fade_by: this.speed]
	this._alpha: this._alpha + this.fade_by;
]

Movieclip.prototype.fade: func[speed][
	this.speed: speed
	tellTarget this [
		f_index: _alpha
		if f_index >= 100 [ fade_by: 0 - speed]
		if f_index <= 0   [ fade_by: speed]
		_alpha: _alpha + fade_by
	]
]

So Reichart when are you moving to OSX. Speed is no longer an excuse 
;-)

graham, it's most likely OSX and not just raw benchmarks that they 
use to measure speed

Btw, there's still some space for speed improvements.