r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Steeve
29-Apr-2009
[13689]
... it  anymore
Anton
29-Apr-2009
[13690]
Except if you don't want functions evaluated.
Steeve
29-Apr-2009
[13691]
uh !?
Anton
29-Apr-2009
[13692]
b: reduce [does [print "hi"]]
Ladislav
29-Apr-2009
[13693]
Here are my results:

>> include %timblk.r
== 1.55177304964539E-2
>> x: 1
== 1
>> t: [1]
== [1]
>> t/:x
== 1
>> t/(x)
== 1
>> pick t x
== 1
>> time-block [t/:x] 0,05
== 4.09841537475586E-7
>> time-block [t/(x)] 0,05
== 4.84228134155273E-7
>> time-block [pick t x] 0,05
== 2.98023223876953E-7

showing, that PICK is the fastest
DideC
29-Apr-2009
[13694x3]
Steeve: you are not executing the same thing : in the second case, 
x does not advance it's always x +1 with x static. In the first case 
x is incrementing so the pick is not the same at each loop, so it 
depends of t length.

>> x: 1
== 1


>> t: "sldfhg ksdjlfgh sjkdfhgsjkdfhgjksdhfgjkhsdfjkghsdjkfhgkjdhfgjkdghfdjkh"

== {sldfhg ksdjlfgh sjkdfhgsjkdfhgjksdhfgjkhsdfjkghsdjkfhgkjdhfgjkdghfdjkh}

>> dt [loop 1000000 [x: x + 1 pick t x]]
== 0:00:00.406

>> dt [loop 1000000 [pick t x: x + 1]]
== 0:00:00.359

>> dt [loop 1000000 [pick t ++ x]]
== 0:00:00.265
Here, only the length of the code block is explaining the time difference 
(7, 6 or only 4 instructions to interpret).
So, if the following is faster it's because the code block evaluation 
take less time IMO (3 instructions) :

>> x: 1 dt [loop 1000000 [t/(++ x)]]
== 0:00:00.172
PeterWood
29-Apr-2009
[13697x2]
Ladislav: I get different results from you. I'm running A49 on Mac 
OS X:

>> fastest [t/(x)] [pick t x]

The first code took 0:00:00.003794

The second code took 0:00:00.004753

>> fastest [t/:x] [pick t x]

The first code took 0:00:00.002759

The second code took 0:00:00.004285

What OS did you run your tests under?
By the way, it is probably far too early to come to any conclusions 
about the relative speeds of different functions in R3 as I believe 
the code has not been optimised yet.
Gabriele
29-Apr-2009
[13699]
Brian: then my memory is that R3's value slots are not fixed size 
any more, because they will be bigger on 64bit systems, but the current 
version is still 16 bytes per slot. so, you can't trust it being 
that way across versions, but i don't think there are versions that 
use more memory yet.
Ladislav
29-Apr-2009
[13700]
my OS: Windows XP Prof SP3
Steeve
29-Apr-2009
[13701x2]
Didec, i have the same results than Peter with the A49.
And what you're saying is not the problem i pointed.

See, there something strange with the number of evaluations done.

>> dp [loop 1000000 [pick t x + 1]]
== make object! [
    timer: 517292
    evals: 4000011
    eval-natives: 2000004

>> dp [loop 1000000 [t/(x + 1)]]
== make object! [
    timer: 350263
    evals: 3000011
    eval-natives: 1000004


So the conclusion is that evaluating a path don't  follow the same 
scheme than a block evaluation.
actually resolving a path is faster than calling a native function, 
it was not the case in the past
Ladislav
29-Apr-2009
[13703x3]
my Linux results (Mepis 6) show the same pattern as Windows XP
aha, you are using A49, sorry
A49 yields:

>> time-block [t/:x] 0,05
== 1.23858451843262e-007

>> time-block [t/(x)] 0,05
== 1.9371509552002e-007

>> time-block [pick t x] 0,05
== 4.35829162597656e-007
Pekr
29-Apr-2009
[13706]
So why is 'pick so much slower?
Ladislav
29-Apr-2009
[13707x2]
It may be caused by the change in function algorithm passing, which 
is more complicated, due to multithreading support
algorithm - sorry, I mean argument
Pekr
29-Apr-2009
[13709]
It would be good to probably ask Carl on Chat, no?
BrianH
29-Apr-2009
[13710x2]
Gabriele, thanks, I trust your memory better than mine about this. 
This is definitely a good reason why Carl is trying to do Rebin before 
he releases the host code - reducing direct access to internal data 
structures.
So why is 'pick so much slower?

 It might be because of the overhead of looking up the word 'pick 
 to get the function :pick every time, same as in R2. It's not that 
 PICK is slower, it's that path decoding is drastically faster in 
 R3 than it is in R2.
[unknown: 5]
29-Apr-2009
[13712x2]
Is REBOL3 going to integrate into the browser at some point?
It seems that was always promised but I don't see where that is becoming 
a reality.
BrianH
29-Apr-2009
[13714]
Remember that you asked that question before you ever complain about 
how we've been working on security lately instead of (pet bug). We've 
been catching a lot of flack lately for working on changes to the 
security model, changes that are necessary to make a browser plugin 
that won't get marked as malware. This was the original reason why 
R3 was started :)
Henrik
29-Apr-2009
[13715]
Ladislav, I'd like to make your article on Identity into a cookbook 
recipe, so it gets an official listing in the cookbooks list, so 
people can find it. Where do you think it would fit on this page:

http://www.rebol.net/cookbooks/
shadwolf
29-Apr-2009
[13716]
arg yeah rebol plugin is important and it's a bad thing if people 
considers it as a malware T__T
BrianH
29-Apr-2009
[13717]
Recent Flash releases are the thing to beat. If we aren't at least 
as secure as Flash, consider R3 to be malware.
shadwolf
29-Apr-2009
[13718]
impossible cause rebol is nice like a puppy :P
BrianH
29-Apr-2009
[13719]
Remember what puppies can be trained to do :(
shadwolf
29-Apr-2009
[13720x2]
well ... if you want to screw Pcs why using rebol anything else is 
 already enought to screw a poor PC
I mean Vb script for example lol ... well ...
BrianH
29-Apr-2009
[13722]
Not my PC :)
shadwolf
29-Apr-2009
[13723x2]
Mine neithere i removed VB from my windows :P
i have the same XP since 2002 ... T___T Microsoft is borring
BrianH
29-Apr-2009
[13725]
Running a vbscript is not the same thing as running a vbscript in 
a browser. Browsers are for running malware, hopefully without getting 
caught by it. Hence the sandboxing, security restrictions, etc.
shadwolf
29-Apr-2009
[13726]
brianH the solution is to create our own kick ass browser in rebol 
 :P
BrianH
29-Apr-2009
[13727]
It's on my todo list, no html though.
shadwolf
29-Apr-2009
[13728]
this way no need of having to maintain 3 x3 rebol plugins ... lot 
of saved  time for Carl i will say
Henrik
29-Apr-2009
[13729]
I think ReBrowse will become more important than a browser plugin.
BrianH
29-Apr-2009
[13730x2]
There's no point to creating a web browser, even a kick-ass one. 
Look at Chrome: It is better in almost every way, but it only has 
< 2% market share (when last I checked). If you create a new browser, 
people will still use their old, crappy IE or Firefox.
That's why ReBrowse won't be a web (html) browser.
Maxim
29-Apr-2009
[13732]
Henrik: rebrowse vs plugin.... entirely different targets.
shadwolf
29-Apr-2009
[13733x2]
BrianH ... when what screw the fucking browser statistics is the 
fact 95%  of computers are wndows based and 100% of them comes with 
IE ...
but that doesn't means I use it (I use chrome, opera and firefox)
Maxim
29-Apr-2009
[13735]
and unless the web gets replaced by rebol, the plugin will always 
be more important to "the industry" I mean, to get others to use 
rebol in THEIR environment.  which is the biggest weak spot of rebol. 
 it is Hermetic.
shadwolf
29-Apr-2009
[13736]
Maxim web replaced by rebol yeah that's the idea brillant  ^^
Maxim
29-Apr-2009
[13737x2]
you can't tell a company that invested several years to start over 
from scratch.  it has to be able to migrate without changing the 
habits... rebol has to sink into the other model first, then slowly, 
if it worth it, people will start putting rebol in the center and 
eventually, something like rebrowse can replace the current framework 
or maybe even live besides it while the migration takes place.
I've suffered of trying to get rebol INTO companies and it never 
works.  there is too much ground work to do, it costs a lot of money.