World: r3wp
[!REBOL3-OLD1]
older newer | first last |
Steeve 28-Apr-2009 [13678x5] | what i don't understand, it that: >> dt [loop 1000000 [x: x + 1 pick t x]] == 0:00:00.706 >> dt [loop 1000000 [pick t x + 1]] == 0:00:00.521 |
when using DP, i can see that the second case do much more evaluations than the first one. How can this be possible ? | |
it's illogic Mister Spok, | |
so doing: >> ++ x t/:x is to 2 times faster than: >> pick t x + 1 Astounding... | |
in the past PICK was the fastest method to deal with calculated indexes | |
Steeve 29-Apr-2009 [13683] | Geez... i have to rewite a bunch of scripts beacause of that |
Maxim 29-Apr-2009 [13684x2] | but does t/:x still return none when the index doesn't exist? cause that is the main advantage of pick for me... |
by the term "still" above, I really mean when compared to the pick method. | |
Steeve 29-Apr-2009 [13686x4] | Perter showed you that is the case now in R3. t/:x == none if the index X doesn't exist in T |
*Peter | |
So i can make this announce. PICK is USELESS now in R3, don't ever use | |
... 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. |
older newer | first last |