AltME: Rebol School

Messages

Steeve
perhaps you should raise the number of iterations. If it's too low for your cpu power. There is more variance in  the measures
Gregg
Yeah, could be something funny:
>> comp 1000000 [1 + 1][f]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[1 + 1]
0:00:00.043496
[f]
0:00:00.06899
== 58%
>> comp 1000000 [1 + 1][f]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[1 + 1]
0:00:00.038712
[f]
0:00:00.07201
== 86%
>> comp 1000000 [1 + 1][f]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[1 + 1]
0:00:00.005999
[f]
0:00:00.120692
== 1911%
Gregg
>> comp 10000000 [1 + 1][f]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[1 + 1]
0:00:00.545457
[f]
0:00:01.114441
== 104%
>> comp 10000000 [1 + 1][f]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[1 + 1]
0:00:00.825999
[f]
0:00:01.327313
== 60%
Steeve
It comes to my mind that if recycle is not turned off during the tests, it could explain the variance.
So I did the test, ans yes, it's a lot better.
Here the new version:
comp: func [n [int!] a [block!] b [block!] /local ref][
    print reform bind [product version platform build] rebol
    recycle/off
    ref: perf n []
    a: to-decimal probe abs (perf n probe a) - ref
    b: to-decimal probe abs (perf n probe b) - ref
    recycle/on
    to-percent (to-integer b - a / a * 100) / 100
]

Steeve
Again I fucked up ref calculation. Lot more stable now
perf: func [i [integer!] b [block!] /local t n] [
    n: 0 t: stats/timer
    bind b 'n ; to use vars i,n in b  
    loop i [do b ++ n]
    stats/timer - t
]
comp: func [n [int!] a [block!] b [block!] /local adjust][
    print reform bind [product version platform build] rebol
    recycle/off
    adjust: n / to-decimal perf n []
    a: adjust * to-decimal probe perf n probe a  
    b: adjust * to-decimal probe perf n probe b
    recycle/on
    to-percent (to-integer b - a / a * 100) / 100
]
And my result  for calling a function:
>> comp 100000 [to integer! 8.0][to-integer 8.0]
core 2.100.111.3.1 Windows win32-x86 20-Feb-2011/16:24:43
[to integer! 8.0]
0:00:00.025229
[to-integer 8.0]
0:00:00.038491
== 52% (overhead)
Gregg
COMP n arg needs to be integer!, not int!.
>> comp 100000 [to integer! 8.0][to-integer 8.0]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[to integer! 8.0]
0:00:00.046459
[to-integer 8.0]
0:00:00.028882
== -37%
>> comp 100000 [to integer! 8.0][to-integer 8.0]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[to integer! 8.0]
0:00:00.021502
[to-integer 8.0]
0:00:00.029488
== 37%
>> comp 100000 [to integer! 8.0][to-integer 8.0]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[to integer! 8.0]
0:00:00.024317
[to-integer 8.0]
0:00:00.028619
== 17%
>> comp 100000 [to integer! 8.0][to-integer 8.0]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[to integer! 8.0]
0:00:00.04053
[to-integer 8.0]
0:00:00.038208
== -5%

Gabriele
make it run for at least a couple seconds each if you want a stable result.
DideC
Gregg: it seems your machine has several process that take CPU in the background. Hence the funny results.
Has Gab say: make a longer loop (1M) to reduce this effect... or kill process ;-)
Could be funny to 'comp the exact same code and has so different results.
Pekr
Maybe Gregg's machine is reporting to NSA, FBI, CIA and other agencies in the background? :-)

Gabriele
the code i used on R2 was:
time*: func [n block /local start] [
        start: now/precise
        loop n block
        difference now/precise start
]
time: func [block /local count time result] [
        time: 0:00
        count: 1
        while [time < 0:00:01] [
                time: time* count block
                result: divide to decimal! time count
                ; multiply by two for faster convergence
                ; (ie. aim for 2 seconds)
                count: 0:00:01 * count * 2 / time
        ]
        result
]
>> time [1 + 1]
== 7.25799625998013E-8
>> f: does [1 + 1]
>> time [f]
== 1.39604952270899E-7

Drake
How do I save the contents of  dir-list to a file from the console ?
Drake
Solved.   Checked out  http://business-programming.com/business_programming.html#section-12.8 and saw the code snippet that uses echo which I didn't know existed.
amacleod
Drake, No need to post in multiple groups...we will see it.

Endo
Does DIFFERENCE works faster on hash! than block! ?
Endo
How can I upload files to a already open FTP port?
p: open ftp://localhost/
INSERT or APPEND don't work. WRITE doesn't accept port!.
If I use WRITE ftp://test:test@localhost/ READ %file.txt then it opens a new connection each time, which I don't want.
sqlab
ftp (re)uses up to the value of cache-size different ports. If you set p/cache-size to 1, it should always use the already opened port.
sqlab
or maybe it is system/schemes/ftp/cache-size. At the moment I can not test it.
Endo
Thank you sqlab. Still is there a way to use OPEN port and upload files via already open port?
Do I remember correctly? CALL hangs on Windows only on R2/view (if no CALL/SHOW " " trick), no such bug in R2/Command right?
Gregg
I don't know if the problem affects command as well, but I would guess it does. My workaround is to make at least one CALL on startup with /SHOW, then the rest work fine without it.

Last message posted 190 weeks ago.