Dear Marc and Robert,
I have another observation, which looks strange to me. If in the example given below I uncomment the following line (* one := 1.0; *) , which just duplicates the previous command, the execution time of the whole program drops by a factor of ~3. Is this because the BB compiler is a non optimizing one? Or something is broken here? I'm using Windows XP on a Pentium M CPU.
Thank you and best regards,
Georgy
MODULE
TestFlops;
IMPORT Log := StdLog , Services;
VAR
sa
, sb, sc , one, two, scale: REAL;
T
: ARRAY 5 OF REAL ;
time1
, time2: LONGINT;
s
, u, v , x: REAL ;
i
, n: LONGINT;
D1
, D2, D3 , E2, E3: REAL;
PROCEDURE
Do*;
BEGIN
D1
:= 0.3999999946405E-1 ;
D2
:= 0.96E-3;
D3
:= 0.1233153E-5 ;
E2
:= 0.48E-3;
E3
:= 0.411051E-6 ;
one
:= 1.0;
(* one := 1.0; *)
two
:= 2.0;
Log
.String(' Module Error RunTime MFLOPS' ); Log.Ln ;
Log
.String(' (sec)' ); Log.Ln ;
(*******************************************************
Module 1. Calculate integral of df(x)/f(x) defined
below. Result is ln(f(1)). There are 14
double precision operations per loop
( 7 +, 0 -, 6 *, 1 / ) that are included in the timing.
50.0% +, 00.0% -, 42.9% *, and 7.1% /
*******************************************************)
n
:=5120000;
sa
:= 0.0;
x
:= one / n ;
s
:= 0.0;
v
:= 0.0;
time1
:= Services.Ticks ();
FOR i := 1 TO n- 1 DO
v
:= v + one ;
u
:= v * x ;
s
:= s + (D1 + u * (D2 + u * D3)) / (one + u * (D1 + u * (E2 + u * E3)));
END;
time2
:= Services.Ticks ();
sa
:= (time2 -time1)/Services. resolution;
scale
:= 1.0E+06 / n;
T
[1]:= scale ;
T
[2]:= T [1] * sa ;
sa
:= (D1 + D2 + D3) / (one + D1 + E2 + E3);
sb
:= D1;
T
[3]:= T [2] / 14.0;
sa:= x * (sa + sb + two * s) / two;
sb:= one / sa;
sc:= sb - 25.2;
T
[4]:= one / T[3 ];
Log
.String(' 1' );
Log
.RealForm( sc ,3,16, 3,' ');
Log
.RealForm( (time2-time1)/ Services.resolution,4 ,11,0 ,' '); Log. RealForm( T[ 4],7,14 ,0,' ' );
Log
.Ln;
END Do;
END
TestFlops.
On 9/25/07, Oberon microsystems AG, Tech-Support <support{([at]})nowhere.xy
Dear Georgy,
thank you very much for the hint. As Robert has pointed out, the problem is caused by how Windows XP handles "busy" applications; on Windows 2000, e.g., updating the log works as expected.
We will try and investigate possible solutions for this problem.
Thanks again and with best regards,
Marc
Oberon microsystems AG
www.oberon.ch <
http://www.oberon.ch/>
+41 (0)44 445 17 51
_____
From: blackbox{([at]})nowhere.xy
Sent: Montag, 24. September 2007 22:57
To: blackbox
Subject: [BlackBox] - 1.6-rc5: Background multitasking
Hi everybody,
I would really like to know, if there is any workaround in BB version 1.5 or RC 1.6 to circumvent the following problem: a program calculates something and writes intermediate results to the Log. If during the calculation a mouse was moved, focus changed etc. the BB Framework freezes out until the calculation is completely finished. A simple example is shown below. Can I call Services.actionHook.Step or whatever to reactivate the Log during the calculation?
Any help would be greatly appreciated...
Best regards,
Georgy
Example:
MODULE TestSum;
IMPORT StdLog, Math, Services;
VAR
i, j, n: INTEGER;
sum: REAL;
t0: LONGINT;
PROCEDURE Do*;
BEGIN
t0:= Services.Ticks();
n:=1000000;
FOR i := 0 TO 9 DO
sum := 0.0;
FOR j := n TO 1 BY -1 DO
sum := sum+1.0/j;
END;
StdLog.Int(i); StdLog.Real( sum-Math.Ln(n)); StdLog.Int(Services.Ticks() - t0); StdLog.Ln;
n := n*2;
END;
END Do;
END TestSum.
On 5/26/07, Oberon microsystems AG, Tech-Support < <mailto:support{([at]})nowhere.xy
Dear Alexander,
thanks for your observation. We intentionally decided not to apply
Marco's entire patch to HostPorts.Rider.Input: We included the statement
WinApi.Sleep(1) but we deliberately left out the proposed call to
Services.actionHook.Step.
The reason for this is that we did not want to break the contract for
objects of type Services.Action as specified in the documentation for
the module Services: "Actions are objects whose Do procedures are called
in a deferred way, when the system is idle again." Calling
Services.actionHook.Step from within HostPorts.Rider.Input would break
this since it leads to actions being executed while the system is not
idle. This could break all sorts of assumptions on which actions should
be able to rely on.
Yes, freezing background tasks while polling for input is an annoyance.
But for the above mentioned reason we would rather live with the problem
than complicating the programming model for Services.Actions. In my
opinion, the real solution would be to attack the problem's root cause
by eliminating the polling loops. This would lead to complete inversion
of control and thus to smoother cooperative multitasking.
with best regards,
Marc
> -----Original Message-----
> From: blackbox{([at]})nowhere.xy
> Behalf Of Alexander Iljin
> Sent: Samstag, 26. Mai 2007 09:12
> To: Blackbox
> Subject: [BlackBox] - 1.6-rc5: Background multitasking
>
> Hello, BlackBox developers!
>
> I see the following lines in the BlackBox 1.6-rc5 changelog:
>
> Host/Mod/Ports
> - 20060325, mc, Rider.Input changed for the benefit of
> background task response.
>
> But in fact Marco Ciot's contribution is not included. It
> would be if HostPorts.Rider.Input would contain a call to
> Services.actionHook.Step, but it does not. The background
> tasks freeze while user holds a mouse button or is otherwise
> stuck in an Input-related loop.
> I've created a simple module that allows to test that. Here it is:
>
> StdCoder.Decode ..,,
> ..UV....3Qw7uP5PRPPNR9Rbf9b8R79FTvMf1GomCrlAy2xhX,Cb2x
>
> hXhC6FU1xhiZiVBhihgmRiioedhgrZcZRiXFfaqmSrtuGfa4700zdGrr8rmCLL
> CJuyKtYcZRiX
>
> 7.2.s ,MtD.,6.5Qw7uP51QCPuP7PNN9F9vQAy1xB.gdj,UBxhYhAbf9P0G2sId
> vPZntgcghghZ
>
> cZRC8T0E.kNS.H.Lt <http://czrc8t0e.kns.h.lt/> ,2.,U08J99SdfJHPNjvQCJuGKfaqmY6MwdONl1QCh0708
> T,U..w.gu4.,
>
> sUGpmWbBxhYhAbndMHT9NY6Mw.sQq2Y6cwB.0.zC,w,wu2E.0.oZ,U00.bnUGL
> u8ro8quGrmCL
>
> WKqtE0E.kN0.,6.I16.M.6.JFyuv.U.2m,.T10.uFq8Ua5V0cUXDF9fR5uPPPP
> 1fP7PNZvQRtI
>
> dHf.2UlbcZpC.c9h0E.8z,U.EEE.E1U.M3MK1.,6.o1.8T5U.E8E.E1U.M3seM
> .3gwP.,6..EB
>
> U.U,2.I3.0ES9.I.cTM.9.e3Y.2U5Vz5ZegVI3hdRiUghjZgpZhZ3Ychgg3in3
> YohgnZiUIcgB
>
> gXRh0xhs3YWBgXRhbJijhiiZgUghpZhoBhoBgnRhdphbpZUYej3YnZiVJio3Yo
> hgnNORvNN769
>
> 9S9vMf9R996d9O996BvPN9PTvRHfPD965vPP1cCPc.3uNPPRN9RRtIdPMgVBAf
> jhiUwidZhg3Y
>
> nhgZ3YnhglhiZphoBhVZhUohphhWhgmRiUAgk3iZBgmBhixgUAhi3Yo3hZ7HTv
> N,tRHfP7vPj9
>
> 69fR9fQn96bPN5vPR9NR76RuPj96VfQ9vQb961fP796FvPN9N,NMRPS,NPTPRb
> PN,dMf9RdvPR
>
> 961fPnvRFPNZPN,tRH9RFPOR96Ahn7NTvMq40mvaKrUaxhm3YnhgqhgmBgg3Yn
> hgXVnpZUAda3
>
> Ytxhp3YnhgZ7RFPMd96d9O9HrKrq.LPN99Q ,NMV9Q..9Ha69,7RFHr0Gu663PM
> 51oBq4a4.jvP
>
> ZvOb961vQ,NOd96b9OTPRN9NRN1P6JT96bnr0LEGLoa4P1YZUggs,kmoA.QA.U
> b,RVjN1JN8PM
>
> HT8Ff8H9863uNPPRQbBgV7AdB3eDJeI3YHhgmpidRgZRig2YAxhbRbBgV7YeN3
> e3hV7AV,RgoB
>
> hjphUgbU2eDBdCZe3JeUYeD3YGhc1xdGZcU2ZHhgm,umUCKua4H769eH7uCPM1
> OpU8p4ak2CKr
>
> GLR0mYuIeKoXKIdin4ak24KR0mUCKua4rN1P6IZuH5OF7OJZOF,781fC,NEUd6
> FTP9,78HtCPc
>
> E9uFHeHPM0HeH5885fPdP8rN1H6HTvNRNGR9RFtMR9R2YAxhbpZAphcAZvg,bO
> NZfRU2xhABgo
>
> hgm3ZVZZUQeZ,6JHvMLvQFN8LtI9fQh1IiZRijZhpZidxhiN19eH7867uPrN1P
> 6I.sIdPMZHJ0
>
> GIamRI6UXpB,dCv76VtCPM0ROFj881P8rN1H..70..EryqvamRqkWuIWQeoBAi
> n4qEc..T9QJ7
>
> 6F,.Cpm.IeZhhjpiZBcXZC2ZVBZvkk0GRqHEuoYmo4KIbG2yavgVBgcCFVSqqE
> L8ssHpmsETfP
>
> dfQT9PNPNZvQRtIQcoJigZcZRiX3Ulb8..umVyKrG5EWKqtCK.Q6AAELUm,..U
> np3.6F6.ZD,6
>
> .636.M00.,..1cUXDJ9XGhighgmRiiQ88pum470,Mwd0UnpZGhighA70,cw5.,
> 6.QJw.0kFF.0
>
> U18J.QiiQ8CJuaLqKKWKqt2Ul1.RVtZBE.8z1U..2,I92U.E,,.RNEd1YCG259
> .G.0..676.16
>
> .6.665hK2., 6TxR.eKZM.M.6.,U0KyB.,..e,2.A.c8U.E.0t.U..61lbAUgQn
> Pt0lLU8ssHor
> kmsQCor..c2E..U6U..HE.6RvuQ0mHCe.az86Utj0GTkWaUKZM03b,...
> --- end of encoding ---
>
> ---=====---
> Alexander
>
> --- BlackBox
> --- send subject HELP or UNSUBSCRIBE to blackbox{([at]})nowhere.xy
>
>
--- BlackBox
--- send subject HELP or UNSUBSCRIBE to blackbox{([at]})nowhere.xy
Received on Wed Sep 26 2007 - 22:56:13 UTC