World: r4wp

I use Query PerformnceCounter in Windows in my Date-Time lib.

So you think that the 50% speed difference between these two functions 
is due to Windows clock?

Windows clock is bitch :-)

http://www.codeproject.com/Articles/1236/Timers-Tutorial

There's even some mention of the Amiga in the above article comments, 
and even Carl liked it, IIRC :-)

Well the timing is consistently more or less same and square-osc 
is always about 50% slover than sine-osc. I think that it's not caused 
by Windows timing.

Beats me. It looks OK

It's true, though, that process-time is currently a primitive function

Have you tried moving the one execution before the other, to make 
sure it's not some process anomaly?

Yes.

Seems like a fairly sound timing, then

You could try increasing the loops another tenfold

Yes, I also tried putting more loops there (for example sine sine 
square square sine square), but the timing is always consistent.

Loop increased tenfold:

sine-osc time:  10576
square-osc time:  22034

Switched order:

square-osc time:  17441
sine-osc time:  15318

There's a lot of variation in the results for such a long loop, so 
it does point to timer instability

I remember that most platforms account real scheduler timeslices 
in this function, while some basically take wall clock time

I think the latter was Windows, so that would make ik very susceptible 
to anything else going on in the machine

Still, the difference between the Red functions is mysterious. I 
think Nenad would have to analyse that

It isn't causing any problems, I'm just curious why it happens.

Yes, it's a good point

Syllable Server (Linux):

bash-4.0# ./test                                                 
                                                                 
           
sine-osc time: 5330000
square-osc time: 2760000
bash-4.0# ./test 
sine-osc time: 5450000
square-osc time: 2830000

That's stable scheduler timing. Problem solved, I guess, but not 
a good verdict for Windows

There could still be a performance issue on Windows

These numbers look like something I expected :)

These are the timings on my Win7/Corei7 box:

sine-osc time:   1003
square-osc time: 939

sine-osc time:   997
square-osc time: 938

sine-osc time:   997
square-osc time: 952

-- reversed order --

square-osc time: 938
sine-osc time:   995

square-osc time: 939
sine-osc time:   996

square-osc time: 939
sine-osc time:   996

(ran the tests 3 times for each order)

Do you run Windows virtualized?

No

I had a quick look at the code paths of both generated `square-osc` 
and `sin-osc` functions, all seems fine. But I do concurr that the 
results are not intuitive. I guess that the relative performances 
in such case are just too hardware-dependent.

Probably yes.

Rebolek: issue #221 has been fixed.

Doc, I can still reproduce it with this code:

x: 0.0
x: either x > 0.0 [x][0.0 - x]
print [x lf]

If I assign the result to 'y instead of 'x, it works.

Ah, that's not the reason. It happens when the condition is FALSE 
and FALSE block ends with expession.So the above code works for x 
= 1.0

When I change order, the code works:

x: 0.0
x: either x <= 0.0 [0.0 - x][x]
print [x lf]

But this also throws 11: float stack check error when used in function:

fabs: func [x [float!] return: [float!] ][
	either x < 0.0 [0.0 - x][x]
]
print [fabs -3.14 lf]

Final workaround :)

fabs: func [
	x			[float!]
	return:	[float!]
][
	x: either x < 0.0 [0.0 - x][x]
	x
]
print [fabs -3.14 lf]

Thanks, I will debug that tonight.

Issue fixed.

It's fixed but this fix brings another 9: float invalid operation 
problem that wasn't present in last version. I'll post an example 
once I separate the problem.

I guess I should have added a few more unit tests from those tickets.

For people wondering what I was working on these last couple of month, 
here's a screenshot of the customer app I'm finishing now: http://sidl.fr/tmp/generator01.png


It's a visual editor for trading strategies that emits MQL4 code 
for Metatrader-based solutions (FOREX trading). The tree is editable 
and redraws itself automatically (no need to drag all the nodes around 
manually). This app also relies on an intermediary DSL for serializing 
the strategy on disk or before compiling it to MQL4. Here's an extract 
from the corresponding dialect representation of the tree from screenshot: 

start on 1 
if 1 buy 5 take 10 stop 10 on-profit [
    buy 6 take 10 stop 10 on-profit [
        buy 10 take 10 stop 10 loop
    ]
] on-loss [
    sell 7 take 10 stop 10 on-profit [
        buy 4 take 10 stop 10 loop
    ]
] 


All is done in REBOL/View 2.7.6 (to avoid CALL bug in 2.7.8) and 
all the source code is 47KB (25KB for the custom styles and VID events 
callbacks).


I'm at 99% completion of that app, so I've resume the work on Red 
since a couple of days.

(CALL is required for this app to invoke the MQL4 to EX4 native compiler)

Really nice :-)

Hopefully you got also refreshed, and got some new ideas for RED 
:-)

e.g. that native RED GUI would be handy, one day :-)

Certainly! But I must admit that I have hesitated in the beginning 
between HTML5 and VID for the GUI.

I chosed VID only because I knew I could do it faster than messing 
around with HTML/JS libs and intricacies. I was just a bit concerned 
about hitting some performance walls or native bugs I couldn't workaround. 
Fortunately, all went well.

*chose