[ros-dev] ROS Performance Numbers

[magnus at itkonsult-olsen.com]

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 at videotron.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
>
>
>
>