AltME: Rebol School

Messages

Steeve
the overhed seems huge. An explication ?
*overhead
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?

Last message posted 157 weeks ago.