Here is simple benchmark program that show that scheduling on AROS work not very good currently.

http://www.zshare.net/download/858000634ba5d18d/

AROS 68k is currently slow on winuae in compare to windows native version, need 2 sec to show a dir on my system(after wanderer window is open), and windows AROS show a dir in less than 0.3 sec.I see AROS on qemu is too slow, maybe its a problen that happen on native AROS.

if you think its no time for speedup, then remember the sooner AROS get faster, the more time you can save.and when you need later must add that too.

On my system on AOS show 78.xxxx millions /sec with 1 program run.
On 68k aros only show .08010
so AROS is 1000* slower.

if 2 programs start show same speed.But sometimes show only half 0.040xx then its ok.every output take 1 sec.the value depend how much CPU time a program get.

But all in all scheduling is very worse on AROS now and when 2 programs run together, both should get 50% CPU time.on AOS this work ok.

test can start from wb, and open a
window.
when you click on close button, it quit.

here is source of this so can see how it work in general, source of eclock include i have too

WBStartup
optimize 7
#short=0

XINCLUDE "eclock.include.bb2"
FindScreen(0)

Window 0,0,0,400,400,$100f,"",0,1
DEFTYPE .f
bufstart.l=AllocMem (2000,$10000)
MOVE.l d0,bufstart
restart:eclock_Start{50}
i2.l=0
cnt.l=0
;Forbid_
loop5
fmove.l #0,fp0
fmove.l #0,fp1
fmove.l #0,fp3
fmove.l #0,fp2

;********************************** bench code start
eclock_Stop{}
;********************************** bench code End
cnt+1
If i2>1000 Then i2=0:If eclock_Stop{} >49 Then Goto out5
i2+1
Goto loop5
out5
erg.f=cnt/1000000

NPrint erg*40," eclock_read /sec"
;Permit_
restart2
If Event <> $200 Then Goto restart
End
bufstart:Dc.l 0


the OS stuff source of eclock_stop is this

Macro _eclock_ReadEClock ; {ll timeval, long efreq}
GetD0 `1
MOVE.l d0,a0
GetD0 \timer_base
MOVEM.l a0/a6,-(a7)
MOVE.l d0,a6
JSR LVO_ReadEClock(a6)
MOVEM.l (a7)+,a6/a0
`2 = PutD0
End Macro

!_eclock_ReadEClock{\r\ev,\efreq}

is the above macro call


Function.l eclock_Stop {@unit.l}
SHARED eclock
If unit<0 Then unit=0
timediff.l = 0
If \is_open
!_eclock_ReadEClock{\r\ev,\efreq}
CNIF #eclock_use_longlong
!ll_SetLongLong{ltime1.ll,\a[unit]\ev\ev_hi,\a[unit]\ev\ev_lo}
!ll_SetLongLong{ltime2.ll,\r\ev\ev_hi,\r\ev\ev_lo}
!ll_Sub{ltimediff.ll,ltime2,ltime1}
;!ll_Set{ltimediff.ll,ltime2}
!ll_SetLong{lscaler.ll,\scaler[unit]}
!ll_Mulu{ltimediff,ltimediff,lscaler}
!ll_Divu6432{ltimediff,ltimediff,\efreq}

timediff.l = ltimediff\lo
CELSE
time2.d=\r\ev\ev_hi * (65536.0*65536.0) + \r\ev\ev_lo
If \r\ev\ev_lo <0 Then time2=time2 + (65536.0*65536.0)

time1.d=\a[unit]\ev\ev_hi * (65536.0*65536.0) + \a[unit]\ev\ev_lo
If \a[unit]\ev\ev_lo <0 Then time1=time1 + (65536.0*65536.0)

defreq.d = \efreq
dscaler.d = \scaler[unit]
dtimediff.d = (time2-time1)*dscaler/defreq
timediff.l = Int(dtimediff)
CEND
End If
Function Return timediff
End Function

Does anyone have any interested in Alpha-testing AROS m68k?

Right now we (Toni and I) would need testers that are willing to:

* Attempt to run AROS on A1200 and other Amiga hardware
* Have at least 2M of chip ram and 4M of fast ram
* Be able to debug by themselves any issues they find
* Submit patches that fix those issues, or at least a small C or m68k assembly test case that demonstrates the defect.

We are not ready for general testing. If you don't know m68k assembly and your way around low level debuggers, please wait until the next phase in AROS m68k development.

These early releases of AROS are guaranteed only to crash, destroy your data, and/or release all the magic smoke in your Amiga. You have been warned.