I agree with JohnFound, but there are other important things a hobby OS needs, like not crashing.
From my tests
MemuetOS
sol os
MyOs
All run at the same speed when running only one program.
KolibriOS ran mark amount faster on bochs and virtualbox, but it also crashed twice, once so bad i needed to reboot linux.
I may of just been unlucky.

So where do you draw the line ?.

Update, it seems i was using a 3 year old ver of KolibriOS, the latest ver runs fine without crashing.
But still just as fast, maybe they have a very fast 24bpp buffer to screen, as thats the mode most enulators use, but real hardware uses 32bpp vesa.

@Dex4u: I've discovered that in QEMU you cannot find a 32bpp mode. Actually MenuetOS could have only optimized code for 32bpp. Its a single DWORD write/read per pixel and it can be vectorized Q, DQ, QQ etc.
In the real world we need to support 24bpp modes which conserve space, but coding gets trickier. Should I do a WORD+BYTE transfer or a BYTE+BYTE+BYTE. Maybe if I transfered 4 pixels, I could write 12 bytes in 3 DWORDs. 16 bytes wide XMM fits 5 pixels and 1/3 of the 6th.

Getting this wrong is really easy and like you suggested - "very fast 24bpp buffer to screen" - probably is due to some research and optimizations.

Everything can be optimized (maybe not some NOPs ), lets hope we'll see faster graphics performance from MenuetOS in the near future.

I am using QEMU through "QEMU manager" front end. So, there is a hardware manager and I am able to choose between "Cirrus Logic GD5446", "Standard VGA" and "VMWare SVGA-II" video cards. Only GD5456 doesn't support 32bpp modes. All others does.
I tested KolibriOS with different modes and graphic addapters (including 320x200x8bpp and 640x480x4bpp) and I can't see any difference in the speed between them. (although it has sluggish response sometimes.)