World: r4wp

Rebolek: I've pushed a fix for your issue (Intel CPU). I'm looking 
on the other issue you had with ARMv5TE.

Great! But I've got another one... putting it to bugtracker.

For the ARM isse, I'm testing with an emulated ARMv5TEJL, and both 
Fibonacci and Mandelbrot perform correctly. I've added some questions 
to the ticket on the bugtracker.

I will provide the info tomorrow when I have access to the machine.

I've answered to your ticket #220.

Thanks, it's getting late, I better should left testing for tommorrow 
:)

I've located the cause of bug #220, you should have a fix when you'll 
wake up. ;-)

Fix for issue #220 pushed.

Wow, that' was fast! :)

I've added information about my machine to #219 (no gcc info, as 
it doesn't have gcc installed).

Doc, another float! problem found (#221).

Can anybody check this code? https://gist.github.com/3135678

It's not a bug, but I wonder why the obviously more complex sine-osc 
is cca 50% faster than square-osc. These are the results I get on 
my machine:

sine-osc time:  1068
square-osc time:  1790

Are you running on OSX?

Windows

If I remember correctly, the Windows clock function is a bit different 
from the LibC one.

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