AltME groups: search

Oldes, about ImageMagick interface, nice to know. I looked quickly 
at the code and I advise not to make structs inside the address? 
function etc. because it's quite slow compared to reusing an existing 
struct. (I tested this a few years ago when I was making fmod interface 
and needed speed.)

and to speed up the refresh... the real solution is to make the window 
smaller  :-(   which is great to show off liquid, but examplifies 
slow R2 gfx engine

I proposed to speed-up REBOL developments by bounty system, like 
Amiga or other communities had. I think this might be a great idea 
.... simply put - I would like to have LDAP protocol? OK, maybe community 
gathers enough money, so that e.g. Softinnov can pick-it up, and 
does not need to work for free necessarily ...

append got native too :-) well, imo if you use something often, in 
mezzanine level, then it could be brought to native level? Imo it 
could be even profilet, to know if the speed gain is there or not, 
no?

I have a slightly modified help, that does not evaluate functions 
in objects and ports and that also dumps ports like objects.
>> a: open http://www.rebol.com
connecting to: www.rebol.com
>> help a
A is a port of value:
   scheme          word!     HTTP
   host            string!   "www.rebol.com"
   port-id         integer!  80
   user            none!     none
   pass            none!     none
   target          none!     none
   path            none!     none
   proxy           object!   [host port-id user pass type bypass]
   access          none!     none
   allow           none!     none
   buffer-size     none!     none
   limit           none!     none

   handler         object!   [port-flags open-check close-check write-check 
   ini...
   status          word!     file
   size            integer!  0
   date            date!     6-Nov-2006/21:26:44
   url             string!   "http://www.rebol.com/"

   sub-port        port!     make port! [ scheme: 'tcp host: "www.rebol.com" 
   po...
   locals          object!   [list headers querying]

   state           object!   [flags misc tail num with custom index 
   func fpos i...
   timeout         integer!  30
   local-ip        none!     none
   local-service   none!     none
   remote-service  none!     none
   last-remote-service none! none
   direction       none!     none
   key             none!     none
   strength        none!     none
   algorithm       none!     none
   block-chaining  none!     none
   init-vector     none!     none
   padding         none!     none
   async-modes     none!     none
   remote-ip       none!     none
   local-port      none!     none
   remote-port     none!     none
   backlog         none!     none
   device          none!     none
   speed           none!     none
   data-bits       none!     none
   parity          none!     none
   stop-bits       none!     none
   rts-cts         logic!    true
   user-data       none!     none
   awake           none!     none

Is there interest in including in the new release?

i would prefer precision over speed.

ICarii > "i would prefer precision over speed." - - I would prefere 
speed over precision. But I'm not making any financial calcultions:-)

Graham: It's *Alpha* so no hard benchmark results yet, but moving 
from VID to View for mdViewer cut the WinXP process size from 15MB 
to 12MB and improved speed threefold ... I'd expect similiar things 
from a View-based GUI.


Anton: "No it doesn't Ashley, read again." - I thought the opening 
paragraph of the referenced document made it pretty clear; "Facets 
are attributes of a face. Facets include the face's location, size, 
color, image, font, style, paragraph format, rendering effects, behavior 
functions, and other details.", but I'll probably use the term attributes 
anyway as facets might be confused with faces.

Louis: Good documentation can make *anything* seem simple! ;)


Robert: Maybe. Main purpose of a View-GUI is for high-performance 
scripts where you really want to know what *every* face is doing.

event system is stopped when you resize the window: try to do something 
at each clock tick (at 'rate speed,) and you'll see that no event 
is processed while resizing

VID is great for prototyping, and for apps where saving a little 
memory and speed aren't critical. So, I think VID is still a valid 
prototyping tool because you don't know what you want to build the 
first time out (in many cases) and it allows you to play around more, 
with less effort. Now, there's no good reason you couldn't use the 
VID dialect, limit yourself to what REBGui can do, and use the VID 
spec to generate REBGui code. Best of both worlds.

I'm fortunate in that I can choose what I use and I wont be using 
anything else!  Just need to get up to speed ;-)

in sunanda's example, APPEND is actually a mezzanine. if you wanted 
a tiny speed up, INSERT/ONLY TAIL is a little faster than APPEND/ONLY

generally about speed: I rarely worry about REBOL/Core speed. I made 
a database once that was mainly about in memory block manipulation 
in REBOL. On an old 500 Mhz Celeron laptop, I couldn't saturate it, 
when throwing queries at it from 3 fast PCs over a 100 MBit LAN. 
I think it was about 100-1000 times faster than a MySQL database, 
but of course with the price that it's in-memory and that it had 
very few features.

View is a bit different, because it hogs memory quite badly. You 
can do a few limited things there to speed up display, but not much 
in terms of helping GC.

Thanks, I think with the speed that's been mentioned compared to 
my old recursions in c# I'm worrying about nothing.

Hi Henrik, I read your blog about Natives vs. Actions vs. Mezzanines, 
thanks it explains the speed differences.

VID is actually famous for its speed with which you can write usable 
GUIs. So it's not hard to learn.

Note that, although behavior in VMWare is improved with this release, 
speed is not optimal. There are a few tricks to improve it

* A cleaner, fresher looking Desktop
    * Initial support for printing with CUPS
    * Support for Broadcom Gigabit ethernet cards
    * Support for USB CD-ROM drives
    * Rendering and graphics speed improvements
    * The GRUB boot loader can now be installed automatically

    * New versions of many applications, including AEdit, AView and Whisper
    * Improved media support and playback
    * Many bug fixes and improved application compatibility
    * Many improved drivers

Software OpenGL should be possible on SDL, though, for testing or 
low speed requirements

There's also no point in it for trying Syllable, because all the 
speed will be sucked up by the VM

Speed isn't everything - you can test functionality in a VM.

I/O *speed* that is...

And I/O speed is not very good, but it works

Note that there's no speed option used in the LFS instructions

Kaj: there is a way to specify speed. When you pass a natural number 
as an option to pppd, it considers it as a speed (baud rate) setting.

Syllable pppd complained about _pty_ having a 0 baud rate setting, 
which is invalid condition and pppd exits. Therefore I added a speed 
option.

This speed is visible by mouse cursor responsivity.

btiffin, thanks. I like Linux. I did a lot of experimenting when 
I first made the switch, and that helped speed up the learning process. 
There is so much to learn that I doubt that any one person could 
ever know it all, but I've already learned enough to be able to do 
more than I was able to do with windows after many years of use. 
My rant: I hate the Windows registry file!

just recieved my new samsung SSD's today. Any experience here in 
what kind of filesystem (linux) is optimal, blocksize etc? found 
some technical info's in 

the web (some choose ext3 others reiser) but I would prefer some 
infos from real life users. The intention is to use the SSD for highspeed 
desktop 

virtualisation (very big single files). any tipp for speed and durability?

thx for the info kaj and gabriele. looks like a non journaling FS 
(ext2) and a noatime mounting will speed things up. will post some 
experiences after a while using this new stuff.

DroboShare speed was between 5-10 MB/s. Now I have 30MB/s for read 
& write over the network. So this thing flies!

your forum seems to be picking speed and users... am I wrong?

high speed camera??

Faster DEs: "Q: How much faster is fluxbox compared with XFCE? A: 
Fluxbox will certainly load much faster after the login screen, and 
will consume probably 1/2 to 1/3 of the RAM that xfce will, but if 
you have lots of RAM you probably won't notice much speed difference 
after the loading process. However, if you only have 256MB of RAM 
fluxbox is the way to go..." http://forums.linuxmint.com/viewtopic.php?f=142&t=30599
(Untested by me)

view plug-ins should change it a bit, as some things needing speed 
could help a bit, although I fear View would have to be recoded. 
I do remember Dave Haynie (dunno if you know Amiga :-), he once told 
me (in some interview), that they coded they own "small os" under 
Windows, when they wanted to get good base for Scala Multimedia ...

Agreed, that agg does good things to refrsh-speed :)

I would guess one thing would be direct rendering instead of using 
SHOW? it would speed up many operations dramatically...

it's probably depending on the graphics driver, but it doesn't really 
matter what I do, whether its rebcode, AGG or VID, things slow down 
to a crawl when going full screen. I did some time profiling which 
showed that SHOW takes up probably more than 75-90% of a drawing 
cycle, much depending on resolution. removing that obstacle or making 
SHOW more intelligent will speed animation up a lot.

2 weeks ago I have intorduced Rebcode(some alphaversion in those 
days) to Oldes who is doing the Rebol to SWF dialect and know very 
well internals of Flash 8. He converted in a few hours one simple 
Flash demo to Rebcode and was amazed about the speed.

In Flash8 he was able to control  hundreds pixels on the screen at 
decent speed while in Rebcode he could do the same operation with 
thousands pixels!

AGG wouldn't have this effect since it does not seem to use clear 
text.  in fact, in general I find AGG font AA pretty ugly... is there 
a way to improve this?  even if its slow?  there are some situations 
which do not mind speed (generating HQ output graphics, for example) 
 or small GUIs or when converting face looks to bitmaps before display.. 
(trades speed for ram)

This latest rendering was just a test to see what the triangle speed 
limits were using a height map and a colour map.

ah... just read... not 3d rotations... I guess that is part of the 
reason for speed.

geomol,

interesting concept. It will also be interesting to see the performance 
and behavior with
different filesystems like: ZFS,REISER, NFS XFS, CFS, GFS etc.

in mysql you can choose the database engine, with nicomDB you choose 
the filesystem 

for different features. (e.g. REISER for speed, NFS for distributed 
networking, CFS/EncFS 
for crypto, GFS for cluster etc. :-) 
any aprox. date when it will be available?

Well, I can give him some other options, like telling him, that he 
could use sqlite, mysql, postgress, as we have drivers for them. 
Not sure about the hash and its speed, etc.

just a thing Brian...

i don't like how map evolved. It lost his simplicity and inner speed.
Some gain like (either vs to-block) have been over rated.

some other bringing major speed regression  have been under rated.


i prefer the throw of an error during initialisation (ie. if find 
word  'output) instead of using the tricks of the embedded builded 
function.

What is the major speed regression?

When you mentioned it was faster, I got curious, as I need speed 
for some data mining algorithms I'm implementing in Rebol for a class

It states in the documentation, that using hash can increase the 
speed hundreds of times, if you have large tables.

Rebcode is the history, though, as R3 models does not provide significant 
speed-up, to be worth inclusion (said speed-up is only something 
like 3x normal REBOL code)

in my demo (galaga) , actually i was limited by by the framerate 
of show, not by the inner speed of rebcode

I have my coffe and code now runs twice smoothly than first version 
:)
www.visaprom.com/tunel.r

And I tried that size trick:   view layout [image img (img/size * 
8)]
and speed is the same.....

Uploaded a version with repeat.... speed is still similar to previous 
versions....

I draw 4x4 pixels in image for each pixel I calculate.... and thats 
not slow....

I just tried an improvement that halves the drawn pixels and speed 
is the same...

I won't bet on it, but looks to me like show is the limit... its 
not the first time....

But on the other hand, this slowness gives me right speed to see 
whats going on and to check if algorythm is correct...

I dont even have to make some kind of slowdown loop :) less code 
to write.... :)

yes... if Im going to make a game in rebol out of this, then the 
speed is a must :)

ufff.... demo from contest wont run..... Im on Ubuntu right now.... 
it cannot open sound.....

aha..... I put show on 'ekran and speed is the same.... 

If Henrik's observation about replacing Show with prin... and that 
speed is the same... there is no need to mess with layout :)


Is there some way of time profiling code ? how to find out wich part 
is slowest?

By the way this script I want to use to make lookup tables for maping 
tunnel 3d coordinates onto screen so when I make those tables I can 
see if math is causing the slowdown....


And question for Anton, what did you use in your "Tunnel" demo.? 
show, direct image manipulation? or just effects for image datatype 
?

I just tried to separate math functions like square root and arctan 
with simpler constant values and speed seams to go up a bit, but 
not to much....

Ill try to make lookup tables for all visible coordinates and see 
what will happen....

changing CHANGE/DUP to POKE gives a slight speed up, but then you 
need to scale in a different way.

There.... lookup table done...... speed difference obvious :)
pause after click on button is rendering first frame....

do http://www.visaprom.com/tunel.r

I did some compilers speed optimizations = http://box.lebeda.ws/~hmm/rswf/rswf_latest.r

That relay a pitty because the alpha currently is still very intresting 
for its speed...save or not ;-)

Yes.. i realy loved those mandelbrod scripts...fantastic speed..

.... remembering when rebcode was introduced, Carl seemed to implement 
improvements in light speed :-)

I feel, the main goal for rebcode implentation is speed, so it makes 
sense, that none is the same as zero. It would probably hit performance 
a lot, if you had the usual REBOL datatypes in rebcode.

And no, you can't play Elite with it! ;)

I made this to test the speed of rebcode. That's my primary goal 
with this. So there is no Operating System stuff of any kind, so 
no I/O for keyboard, joysticks or screen.

Yes, butthe jitwould be better, and ifiaim for speed..

main differences:

- /only refinement added (to only make a Rebol block containing the 
code)

- Parse usage to speed the implementation up and to shorten it a 
bit

Gabriele, (f a b) in the macros context is not always a function 
application. Regarding PARSE, Scheme also has many parsers and lexesr 
on in the  yacc/lex style and parser combinators.  So you can assing 
any semantics or any syntax just like rebol. The fact is that any 
Turing complete PL can reproduce any other. I can easily see how 
to write a C compile in Rebol, and obviouly Rebol is written in C. 
The same holds for Scheme. Or any other language. So that is not 
a valid point of discussion imo.  The thing with interpreters is 
that the tower of languages grows with each level and performace 
takes a hit with each layer of interpretation. The beauty of compilers 
is that once bootstrapped they can eliminate on layer, therefore 
gaining speed as they go directly to the hardware.

Interesting that they think a virtual colossus on Pentium II laptop 
( are there such things still? ) would run at the same speed as the 
original at Bletchley Park http://news.bbc.co.uk/2/hi/technology/7094881.stm

http://www.appleinsider.com/articles/08/02/07/apples_safari_3_1_to_support_downloadable_web_fonts_more.html
<--- Safari's Javascript engine will in the next version switch some 
commonly used DOM functions to native C-code for some big speed boosts. 
That's kind of interesting.

post that to r3-alpha All group, please .... it is not to make us 
more nervous, but to be realistic. If the speed of View development 
is as-is, we might as well close the door soon ...

About java being fast: It's speed is outweighed by its size. REBOL 
may not be extremely fast, but it's nimble enough to not let you 
notice most of the time.

My concerns about REBOL execution speed are related to my will to 
use REBOL for every programming tasks, so I don't have to rely on 
other languages.

Yup (I've already given this some thought). Hand-optimized code may 
have to be reoptimized though, and this includes some of the optimizations 
that I made to some of the mezzanine functions. You would speed things 
up drastically by using explicit type checking or get-words to filter 
out theoretical function value evaluation.

Java code that is as powerful as REBOL code is slower than REBOL. 
If you restrict what your REBOL code does to what Java can do it 
will be slower with the current interpreter. You only get speed out 
of REBOL by writing REBOL code.

related: will we get a native 'append ? If such speed-isues are now 
important, we should notstick with that important thing as meazzine?

Jamie, that was referring to using a hash as a table rather than 
as an index. If you use a hash rather than a block for your table, 
all of your searches would be faster without needing any seperate 
indexes. The only way to have the speed of searching a block be comparable 
would be to keep it sorted and use a binary search (what RebDB does 
I think), but that doesn't help much with multiple keys that require 
different sorting orders.


On the other hand, I've been sold on the idea that when you use a 
hash as an index (rather than the table), you are basically using 
it like an assoc, so using a structure optimized for that behavior 
would probably be best.

As for the hash (or assoc) index and list data combo, it has some 
advantages. When you are inserting and removing data a lot lists 
have a known speed benefit but the real advantage as far as indexes 
are concerned is in how lists handle series offsets (I'm using the 
word offset here because I'm using the word index to refer to the 
external hash/assoc index).


Blocks encode their offsets as a number offset from the beginning 
of the series:

>> a: [a b c]
== [a b c]
>> b: skip a 2
== [c]
>> index? b
== 3
>> insert next a 'd
== [b c]
>> b
== [b c]
>> index? b
== 3

List offsets are pointers to the associated list element.

>> a: make list! [a b c]
== make list! [a b c]
>> b: skip a 2
== make list! [c]
>> index? b
== 3
>> insert next a 'd
== make list! [b c]
>> b
== make list! [c]
>> index? b
== 4


If you are indexing your data and your data in in a block, you need 
to update your index with almost every insertion and removal because 
the references to latter positions of the block in the index will 
be invalid. With list insertion and removal, external references 
are likely to still be valid unless the referenced elements themselves 
are deleted. If you are sure to delete the reference from the index 
(or replace it with nones) the rest of the index should be OK. New 
index references can just be tacked on the end, or put into the first 
empty entry. This makes live indexes a lot more practical.


On the down side, if you are using lists and they are long enough 
to make linear searches impractical, you really do need an external 
index for them to be useful. Also you need to balance the overhead 
and complexity of keeping the indexes updated against their benefit. 
This technique is not for the faint of heart unless you can get some 
guru to do algorithms for you.

hehe, at digg.com I read reaction of one user, who read about REBOL 
and seemed to be excited - his equation is:


Rebol = ((Perl + AJAX + [SETI-:-Home]) - (Bloat + Crap)) * (Extacy + 
Speed ^3)

so no speed differences?

the only problem is the speed. I really wish I could speed it up.

payof is in:

 -robustness.  there are NO loose ends, no forgetting.  its impossible 
 by definition.

 -long-term dev speedup: adding features doesn't increase complexity, 
 since all features are developped completely independently.

 -speed: properly designed, lazyness can make an application quite 
 fast, even for very complex apps.  obviously, there are worst case 
 scenarios.. like anything.
 

add a dialect in the mix, and then the code size will shrink a lot, 
but since REBOL itself, isn't dataflow enabled, patching liquid within 
other REBOL components doesn't really benefit from a dialect.  cause 
creating, connecting and processing nodes is really simple.

we have tried to run liquid within R3 an it crashes rebol...  but 
I didn't have time to figure out why, its a pretty complex object. 
 but I will have to look at in sometime this summer... the simple 
10X speed gain of AGG is enough to make it worth, especially since 
gobs provide internally of what paint simulates in R2.

Nope, it's C (or maybe C++, I forget). He prototyped it in REBOL 
then went native for speed/scale.

Thanks! That's exactly why I've built Cheyenne ;-) I plan to improve 
it much more in features, speed, easy configuration,...

LNS or something similar, definitely. I would like something "lighter" 
if possible, than RT's LNS focused on speed and security.

I put in some minor fixes yesterday, but I haven't yet had the chance 
to really look it over properly. Any advice would be appreciated, 
especially related to speed, size and security.

Cheyenne, with its mono-thread full async engine, would scale very 
well on a similar benchmark, probably much better than Apache, but 
less than Yaws I guess. OTOH, a bench testing raw throughput, would 
show Apache performing quite better than Cheyenne (maybe 2 or 3 times 
better). It's hard for interpreted REBOL to compete with compiled 
C on raw power. I think that it would be possible to reduce this 
difference to 1.5 with deep optimization in Cheyenne (task scheduled 
for v1.1 according to my roadmap). R3 should open new perspectives 
for speed & memory optimizations (threading, clean async kernel, 
optimized ports, Rebcode, plugins...).

A good starting point for doc links is http://www.erlang.org/doc.html
.


The pros are that it's been around for a long time, it was built 
to solve a specific type of problem, and has been proven to work 
for large commercial systems. It also has a nice community it seems. 


Just as C# and VB.net are capable languages, you really need to know 
the .NET framework to make things sing. Erlang, by itself, is very 
capable, but the OTP (Open Telecom Platform) provides a huge amount 
of value on top of it, if you're building distributed systems. It 
also has Yaws, Ejabberd, and other things already built that you 
can leverage.


On the downside, it's a very different model that takes some getting 
used to, though Maarten got up to speed for experimentation very 
quickly. If you're used to Prolog, that will help. It's also really 
only good for back end stuff, so we would still be doing front ends 
in something else, which wasn't the dealbreaker in our case. What 
turned us away was the security model. It's designed for use in an 
intranet type (read safe) environment, where access to machines on 
the cluster is controlled by secret cookie. If your cookie is compromised, 
they have absolute power over the node, and any nodes it shares that 
cookie with.  http://www.erlang.org/doc/reference_manual/distributed.html#11.7


We decided that, since we would end up building security on top of 
everything, using something like dialects for control, we were better 
off sticking with REBOL. There are a number of things out there already 
to bulid on (LNS, Rugby, Uniserve, BEER), we can really do things 
the way we want, in a tool we know we like and are comfortable with. 
And we know its limitations, so there will be fewer surprises.

Maarten, I have between 100'000 and 200'000 rsp hits a day, many 
domains and subdomains, and other special configs, runs like a beautiful 
woman, no glitches, no problems, full speed, if it can help in your 
decision I can upload my httpd.cfg somewhere for you to have a look

Thanks for these interesting info. Cheyenne has been optimized for 
speed, caching in memory, at all levels is the key for performances. 
There's still some space for some speed improvements.

Oldes: Graham is using CALL from RSP scripts to do image processing 
IIRC. I never used CALL from RSP myself, so I can't tell. It seems 
to me that it would be faster/safer to wrap an image processing DLL 
than launching a new process for each new request. Using CALL from 
a RSP is like dropping to CGI, you're loosing most of RSP speed benefits.

aha, so rsps work on multiple worker processes, interesting.. well 
I think to me it's not a problem as each user has it's own data files 
so it's hard to imagine multiple writes could happen at the same 
time for the same file. And if I would need something reall y heavy 
duty I would make a server serving files and caching them in ram 
for speed etc, which would also take care for sync. or something 
off the shelf

git is faster and has more features (hg has been closing the gap 
on the features but not the speed), but windows people tend to hate 
it.

I'd like to not do everything by myself, but it's not that easy. 
I have some deep concerns for Cheyenne core part such as speed, memory 
usage, stability and security. Cheyenne has become a *critical* part 
of our business, I have to garantee that a new version won't break 
our webapps in production, nor make them instable, insecure or noticeably 
slower. My responsibility also extends to other companies that are 
selling products or services based on Cheyenne.


I've already accepted small patches on Cheyenne core in the past, 
but it takes me a lot of time to study and test each line of code 
an rewrite them if required. If your code has only a local impact, 
I might use it, if it needs to patch a lot of parts of Cheyenne/UniServe, 
I probably won't. Anyway, you can send it to me, it's always a good 
inspiration to see how other developers solved some specific problem.

bringing it up to the best servers speed wise will get people's attention.

just changing the size of buffers and tcp payloads added a big speed 
boost.  stupid detail, but now if we have such cases, we can actually 
really go as deep as that.

It's always possible to write session data to disk or to a DB and 
rely on the DB locking system to ensure that data is safe, but there's 
a performance overhead in that case that I'm afraid, may not result 
in any speed gain for the user. It also requires to have a DB engine 
installed on all servers running Cheyenne using RSP sessions, which 
might be overkill in some situations.

doc, I have noticed a usage in your mods which you might want to 
change for speed reasons.


you use the word return a lot... and in my tests, it causes a BIG 
performance hit on function calling... I really mean noticeable when 
you do loop profiling ... a minimum of 20% slow down IIRC.

so instead of:

    phase: func [svc req conf][
        if declined? [return none]
        ...
        if let-others [return false]
        ...
        true
    ]

you really should be doing 

phase: func [svc req conf][
        if accept? req [
              ...
             true =  let-others? req
       ]
] 

just my two cents.