ROS Performance Numbers

[Alex Ionescu]

Alex Ionescu wrote:
>   Hi all,
>  Here are the latest performance numbers of ReactOS.
>  
Here are the normalized results to 16bpp.
Same conclusions, just smaller differences (which were expected).
Actually I retract what I said about V Line...it seems OK, just that it
probably could be better. Smallfills/Lines are a problem..
Thanks for Waxdragon for the testing.
Best regards,
Alex Ionescu

[Alex Ionescu]

Alex Ionescu wrote:
>   Alex Ionescu wrote:
> >   Hi all,
> >  Here are the latest performance numbers of ReactOS.
> >  
>  Here are the normalized results to 16bpp.
>  Same conclusions, just smaller differences (which were expected).
>  Actually I retract what I said about V Line...it seems OK, just that
>  it probably could be better. Smallfills/Lines are a problem..
>  Thanks for Waxdragon for the testing.
>  Best regards,
>  Alex Ionescu
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[Jason Filby]

Looks great!
On 6/11/05, Alex Ionescu <ionucu(a)videotron.ca> wrote:
>    Hi all,
>   Here are the latest performance numbers of ReactOS.
>

Hi Alex
The small fill are calling same fill code as fill does
I have just improve the fill rate for 16bpp
here is my test reslut
vmware 1024x768x16bpp
Before
betwin 10200 - 10300 fill/sec
betwin 298000 - 299000 small fill/sec
after my lates commit
betwin 11200 - 11300 fill/sec
betwin 343000 - 344000 small fill/sec
vline and hline are already max optimize in 16bpp
But line are not yet optimize.
But I will working on that later today
But rember I have build this with oarch=pentium2 DBG=0
Quoting Alex Ionescu <ionucu(a)videotron.ca>ca>:
>  Hi all,
>  Here are the latest performance numbers of ReactOS.
>  All tests done on 800x600x24, except the last one (QEMU + Cirrus
>  Driver) which was done on 16bpp. It does not skew the numbers too much,
>  but it's possible the weird result in the "Lines" test is because our
>  24bpp path is optimized but not the 16bpp one. I will have 16bpp
>  numbers tomorrow. QEMU B refers to Before optimizations, A refers to
>  after optimizations. All these tests are done with DBG = 1, so
>  comparing with XP is slightly unfair right now because our code is even
>  faster. However, some things are clear:
>  1) We have greatly improved our fill speed on VBE, as well as
>  H.Lines...but the V.Lines and Line code has not been changed.
>  2) We beat XP on all the tests except the Lines and V.Lines/Small Fill
>  tests (depending if VBE or Hardware Accel (HW) is used)
>  Therfore, I think that we should stop over-optimizing the Fill Code now
>  and focus on Small Fill, V.Line and Lines. I think the issue with Small
>  Fill is that it's handled in C, while Big Fill has the ASM code. As for
>  Lines, I don't know what it could be... I don't think that code was
>  touched much.
>  Best regards,
>  Alex Ionescu
>