Why ReactOS runs so slowly?

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

gabrielilardi
Moderator Team
Posts: 873
Joined: Sat Sep 02, 2006 1:30 am
Location: Italy

Post by gabrielilardi »

Ged wrote:I'd like to further investigate this issye, the following line sounds worrying
Although I'd installed it on real hardware I can watch the buildup of the window elements for a lot of seconds!
I have noticed important delays in 1024x768 in real HW (some time ago), I'll re-test to confirm.

z180
Posts: 197
Joined: Sat Mar 10, 2007 7:58 pm

Post by z180 »

I think that I would be able to make an optimized build without the recouces of languages I cant speak and less coloured icons and BMPs
and compiler arguments.I dont recommend doing it here,only as a
private initiative.SVN builds are for testing and have debug enabled.
Also an improvement over windows are the KDBG builds which
have a kernel debugger like BSDs DDB or KGDB.I also think that
reactos could be improved on older hardware like notebooks by testing
and reporting what make problems.File operations like playing
Duke Nukem Forever could be done faster when the cache manager
code arrives that was said to come in 0.3.0 but is not yet ready to use.
Also ReactOS could use something like the UIP stack to boot fast from
network with freeldr.

Ged
Developer
Posts: 925
Joined: Thu Sep 29, 2005 3:00 pm
Location: UK

Post by Ged »

The svn debug builds shouldn't cause any noticable speed difference. Debug output is limited in standard builds, esspecially in the window drawing code which is where Yellow said the problems were

gabrielilardi
Moderator Team
Posts: 873
Joined: Sat Sep 02, 2006 1:30 am
Location: Italy

Post by gabrielilardi »

Sorry, I can't confirm anything, reactos regressed in my computer, it crashes at the end of 2nd stage:

Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault)
Memory at 0x00000084 could not be read: Page not present.
kdb:> cont

*** Fatal System Error: 0x0000001e
(0xC0000005,0xAD87E379,0xAF49E510,0x00000000)

Entered debugger on embedded INT3 at 0x0008:0x808abf88.
kdb:> cont

!!! Unhandled or Unexpected Code at line: 80af74e7!!!

GreatLord
Developer
Posts: 926
Joined: Tue Nov 30, 2004 10:26 am
Location: Sweden

Post by GreatLord »

use command bt so we can get a backtrace

gabrielilardi
Moderator Team
Posts: 873
Joined: Sat Sep 02, 2006 1:30 am
Location: Italy

Post by gabrielilardi »

GreatLord wrote:use command bt so we can get a backtrace
Sorry, done:

Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault)
Memory at 0x00000084 could not be read: Page not present.
kdb:> bt
[7hEip:
<win32k.sys:90379 (subsystems/win32/win32k/objects/gdiobj.c:1311 (GDIOBJ_SetOwnership@8))>
Frames:
<win32k.sys:8898d (subsystems/win32/win32k/objects/dc.c:2629 (@DC_SetOwnership@8))>
<win32k.sys:78489 (subsystems/win32/win32k/ntuser/windc.c:598 (@DceFreeDCE@8))>
<win32k.sys:784b1 (subsystems/win32/win32k/ntuser/windc.c:688 (@DceEmptyCache@0))>
<win32k.sys:8a3bb (subsystems/win32/win32k/objects/dc.c:724 (@IntDestroyPrimarySurface@0))>
<win32k.sys:7fac4 (subsystems/win32/win32k/ntuser/winsta.c:327 (@IntEndDesktopGraphics@0))>
<win32k.sys:64ee3 (subsystems/win32/win32k/ntuser/guicheck.c:73 (@RemoveGuiApp@4))>
<win32k.sys:64f57 (subsystems/win32/win32k/ntuser/guicheck.c:94 (@co_IntGraphicsCheck@4))>
<win32k.sys:4c485 (subsystems/win32/win32k/main/dllmain.c:148 (Win32kProcessCallback@8))>
<NTOSKRNL.EXE:7e597 (ntoskrnl/ps/kill.c:697 (PspExitThread@4))>
<NTOSKRNL.EXE:7f115 (ntoskrnl/ps/kill.c:889 (PsExitSpecialApc@20))>
<NTOSKRNL.EXE:132b (ntoskrnl/ke/apc.c:443 (KiDeliverApc@12))>
<NTOSKRNL.EXE:96928 (ntoskrnl/ke/i386/trap.s:285 (KiServiceExit))>
<ntdll.dll:5d03>
<user32.dll:27e2b>
<user32.dll:27f54>
<msgina.dll:161f>
<kernel32.dll:2247e>
<00000000>
kdb:>

forart
Posts: 1050
Joined: Mon Nov 29, 2004 1:36 pm
Location: Italy
Contact:

Post by forart »

oiaohm wrote:forart more correct reactos developers don't need to do 3DNow!/MMX/SSE-2-3 optimizations. They are is gcc complier switchs that do them. x64 is waiting on a stable open source complier for windows.
AFAIK manual optimizations are better than compiler ones (that have mutch problems too)...
gabrielilardi wrote:
Ged wrote:I'd like to further investigate this issye, the following line sounds worrying
Although I'd installed it on real hardware I can watch the buildup of the window elements for a lot of seconds!
I have noticed important delays in 1024x768 in real HW (some time ago), I'll re-test to confirm.
I noticed too that VBE is mutch compatible (standard-compliant) but not so fast on real HW (i believe that asm optimizations would be useful here).

Last but not least I -still- feel the need of an HW configs database for testers (at least, better for all forum users), that IS useful for better compatibility feedback, IMHO. :!:
»Forward Agency NPO
In progress we (always) trust.

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Post by Z98 »

There's a reason we don't use assembly, and it's because we want to keep the amount of code we would need to rewrite for ports to a minimum. Assembly by definition isn't portable, and like oiaohm said, compilers these days are extremely good at optimizations. We are not in a situation where hand optimization would serve any purpose.

PsyDonia
Posts: 49
Joined: Sun Nov 12, 2006 10:45 am

Post by PsyDonia »

The version I can install is amaizingly fast.
I boots up in a few seconds.
Wile XP on the same computer boots up in about 2minutes.
Then apps and stuff start way faster than in XP.
For me I have not found anything that is slower in ROS

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

Forart stop following ASM is great logic.

Manual optimization have there own set of flaws. Now lets look at a few simple problems.

i486 pent 1 pent 2 pent 3 and pent 4. Each one of these requires different alignments to get best performance. I am restricting my self to intel chips.

So this now means any manual asm optimization has be coded for every chip to extract the best performance. Note that is not even a instruction list different.

Forart please read you locations you use to back up your point.

From Your wikipedia point
As compiler technologies have improved, good compilers can often generate better code than human programmers
First three points there why complier fail are complier dependent. Yes there are better compliers out there that do a better job.

The forth point of course running optmization passes cost times.

The last one is partly a joke. Early on in complier development getting the order right of opt functions was critical. These days the order is quite well worked out.

Most Asm coders are comparing themselfs to msvc and gcc. Sorry to say these are not the best in existence. Gcc openly admints that it does not have a overall exe optmiser and that one is required. Best compliers out there are really hard to beat on performance. They really only have one flaw they take a fair while to process to produce a exe.

inefficient algorithm inside gcc if its contained to 1 c file and the complier understands what the function is doing will be rewriten.

So trying
int c,b;
void func (){ c=1; b=c *2; }
Now b=c*2 is predictable to be 2 so void func(){c=1;b=2}
I could be doing way way more complex algorithm. The compliers these days are truly looking at it.

So why can ASM coders get smaller and faster than gcc. Its dead simple.
gcc produces .o files then LD goes and tacks them into a exe using only basic optmiztations. Final fault is not the complier is the dam linker. If a asm coder uses LD the same way they are just as stuffed.

Carlo Bramix
Posts: 282
Joined: Thu Jan 04, 2007 12:43 am
Location: Italy

Post by Carlo Bramix »

Yellow wrote:Although I'd installed it on real hardware I can watch the buildup of the window elements for a lot of seconds!
I use ReactOS with QEMU on a Pentium 4 at 3 GHz for testing.
And I must say, yes, actually I found several slowdowns, like one you said, but I always believed that this was caused by the virtual machine and by the fact that ReactOS does not provide an accelerated video driver, just a generic one, which is probably the same thing that happens on your real hardware.
The experience is really different if you work under VMware, here the accelerated graphic driver do its job and the response seems realtime.

Sincerely,

Carlo Bramini.

florian
Posts: 462
Joined: Tue Nov 01, 2005 2:19 am
Location: Germany

Post by florian »

PsyDonia wrote:The version I can install is amaizingly fast.
I boots up in a few seconds.
Wile XP on the same computer boots up in about 2minutes.
As long as you are aware that a "stripped" XP can boot faster, too, and that
within our ReactOS a lot of things are not yet implemented.
PsyDonia wrote:Then apps and stuff start way faster than in XP.
For me I have not found anything that is slower in ROS
Just look here as one example (although the posted information might be obsolete.)

z180
Posts: 197
Joined: Sat Mar 10, 2007 7:58 pm

Post by z180 »

It has a reason that ReactOS is written mostly in C because there is an
incomplete port to PowerPC CPU (PowerMac?) computers.I do not
know of system requirements but it crashs on booting.Also there
was some work going on to port ReactOS to ARM.

Haos
Test Team
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am
Contact:

Post by Haos »

PPC port crashes at boot because its incomplete. Or rather, it doesn`t boot completely because of its incompleteness.

elhoir
Test Team
Posts: 397
Joined: Thu Sep 13, 2007 7:01 pm
Location: Madrid, Spain
Contact:

Post by elhoir »

am i wrong if i say that the only piece of software that is different from an architerture to another is the HAL layer?

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest