stack size
May be this question is not strictly suited to this list, but I see lots of people contributing from lots of different platforms. The question regards to stack space management under different platforms, or execution models. Under my preferred platform ( QNX 4.25 ) stack space is allocated at process creation, and remains fixed until process death. Thas is so because the data segment layout leaves the heap on top, so it can grow easily. So, one must guess how much stack would be needed, and give the figure to the linker. The question is: are there some other ( not exotic, of course ) platforms that allows stack growing on demand ? i.e the stack as one segment by its own, which can be dynamically re-allocated during process lifetime ? Thank you ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: stack size
mnicolet wrote (in a message from Tuesday 8) May be this question is not strictly suited to this list, but I see lots of people contributing from lots of different platforms. The question regards to stack space management under different platforms, or execution models. Under my preferred platform ( QNX 4.25 ) stack space is allocated at process creation, and remains fixed until process death. Thas is so because the data segment layout leaves the heap on top, so it can grow easily. So, one must guess how much stack would be needed, and give the figure to the linker. The question is: are there some other ( not exotic, of course ) platforms that allows stack growing on demand ? i.e the stack as one segment by its own, which can be dynamically re-allocated during process lifetime ? On Unix-like systems (and I guess in modern MS Window too) the virtual memory system allows to allocate a large stack for each process. Real memory is used only as stack grows and as virtual addresses need to have real memory pages vired to them. There still is a physical fixed stack size limit, but it's generally set quite high. I don't know any system without shared memory that would behave this way. In VxWorks you specify the stack size at task creation and it's allocating memory from the global pool. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Performance regression between 4.3.0 and snapshot version.
Bugzilla #434 shows a x11perf regression test between 4.3.0 and a rather current CVS versions. The performance of some tests has gone down by 20% for a specific test, some other tests have suffered a performance penalty of 3%. There may be a simple explanation for this however I can't find it right now. Any idea? Egbert. === Cut from Bugzilla #434 === Yes! Just done all tests with : 4.3.0 vanilla and CVS (as a few days ago, with the O_SYNC flags removed) both compiled on the box. See attachment for the full output of x11percomp. Here are the bad results (ie when CVS performs really worse than 4.3.0, at least more than ~3%, and I've tried to put them in badness order) : 217.0 153.0 ( 0.71) Circulate Unmapped window (50 kids) 1530.0 ( 0.82) 100-pixel wide double-dashed circle 1860.0 108000.093600.0 ( 0.87) Char in 80-char a core line (Courier 12) 133.0 116.0 ( 0.87) Circulate Unmapped window (100 kids) 154.0 142.0 ( 0.92) Char in 80-char a line (Courier 12) 24500.023200.0 ( 0.95) QueryPointer 23000.022000.0 ( 0.96) GetProperty 414000.0 402000.0 ( 0.97) Unmap window via parent (4 kids) 779000.0 753000.0 ( 0.97) Unmap window via parent (25 kids) 818000.0 802000.0 ( 0.98) Unmap window via parent (50 kids) 24.0 234000.0 ( 0.97) Destroy window via parent (4 kids) 37.0 362000.0 ( 0.98) Destroy window via parent (16 kids) 403000.0 391000.0 ( 0.97) Destroy window via parent (25 kids) 428000.0 39.0 ( 0.91) Destroy window via parent (200 kids) 152000.0 149000.0 ( 0.98) Create and map subwindows (4 kids) 288000.0 283000.0 ( 0.98) Map window via parent (25 kids) 108000.0 106000.0 ( 0.98) Hide/expose window via popup (4 kids) 199000.0 193000.0 ( 0.97) Hide/expose window via popup (16 kids) 22.0 216000.0 ( 0.98) Hide/expose window via popup (25 kids) 224000.0 219000.0 ( 0.98) Hide/expose window via popup (50 kids) 225000.0 223000.0 ( 0.99) Hide/expose window via popup (75 kids) 231000.0 224000.0 ( 0.97) Hide/expose window via popup (100 kids) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Why lib/font/builtin is not useful -- yet
Juliusz Chroboczek writes: I'm currently in the process of changing somewhat the core bitmaps fonts system in order to simplify it and extend its functionality. Because the planned changes will break some users' configurations[1], David suggested that the core server should include Keith's ``builtin'' fonts, and that builtin should be implicitly added to the font path. Because builtin fonts include the fonts that the server absolutely needs to function (fixed and cursor), this would make sure that the server can start whatever the fonts (mis-)configuration. In the longer term, as client-side fonts become the norm, we could kill the core fonts system altogether and only keep the built-in fonts for compatibility with the protocol. We cannot do this for people who rely on running legacy apps. Especially commercial binary only apps that have been used for years and which cannot be changed because the vendor went out of business. This will make these legacy apps look horrible, some will not even start as they insist on a specific font. This will at best be configurable in some app default, but still it will be a huge pain in the neck. Unfortunately, the built-in fonts code, in its current state, is not useful for that. Indeed, the current built-in code pulls in much of the PCF code (which is exactly what I'm in the process of eliminating), much of the local FPE code (which I hope to eliminate later), and much of the fontfile code (which must go at some point). In object-oriented terms, it inherits from the current (``legacy'') PCF code rather than being a completely independent implementation of the FPE interface. Rewriting built-in fonts from scratch in a manner such that they can be included in the core server would not be a big job, and I will be glad to help anyone who volunteers to do that. If nobody does, I'll probably do it at some point. For now, I'm going to break users' configurations without the ``builtin'' safety net. Watch this space for further updates[1]. Juliusz [1] I haven't quite made up my mind about how to handle it, but I expect that the ``bitmap'' module will no longer be loaded automatically. Thus, one day you'll cvs update, make World, and if you don't load either bitmap or freetype, stuff will break. If you explicitly load either bitmap or freetype, you should be fine. We should then add one of these modules to the config files generated by our configuration tools. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Bugzilla #460] BIGREQUEST size change.
This is a matter that maybe should also be discussed on 'forum'. I don't know how to initiate a joint discussion on both lists. There is a comment on Roland Mainz's changes to make BIGREQUEST size tunable. Further comments are welcome. Egbert. === comment by Juliusz Chroboczek Roland, The below is not an objection to your change, just an explanation. XFree86 does not reschedule clients within requests; all rescheduling happens at a request boundary. Thus, with very large requests it is possible for a client to lock-out other clients for noticeable amounts of time. The situation is even worse on the SI, where scheduling is done by counting requests (rather than measuring time, as is done on XFree86). There, using big requests can impact the server's fairness in a big way. If Mozilla needs big requests to function with half-decent performance, then Mozilla is broken and should be fixed. Including work-arounds in XFree86 is counter-productive in the long term. I would like to suggest that you should file a bug with Mozilla. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance regression between 4.3.0 and snapshot version.
On Tue, Jul 08, 2003 at 10:25:40AM +0200, Egbert Eich wrote: Bugzilla #434 shows a x11perf regression test between 4.3.0 and a rather current CVS versions. The performance of some tests has gone down by 20% for a specific test, some other tests have suffered a performance penalty of 3%. There may be a simple explanation for this however I can't find it right now. Any idea? Egbert, I believe this guy had 4.3.0 running with a savage with UseBIOS off because the BIOS failed for some reason so the UseBIOS option was turned off. In the later 4.3.99.x series the BIOS now works for him, but unfortunately the BIOS makes some more conservative settings for the accelerator engine in the savage. If he add Option UseBIOS off back in, I believe that will solve his problem. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Re: stack size
- Original Message - From: Matthieu Herrb [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 3:52 AM Subject: Re: stack size mnicolet wrote (in a message from Tuesday 8) May be this question is not strictly suited to this list, but I see lots of people contributing from lots of different platforms. The question regards to stack space management under different platforms, or execution models. On Unix-like systems (and I guess in modern MS Window too) the virtual memory system allows to allocate a large stack for each process. Real memory is used only as stack grows and as virtual addresses need to have real memory pages vired to them. There still is a physical fixed stack size limit, but it's generally set quite high. I don't know any system without shared memory that would behave this way. In VxWorks you specify the stack size at task creation and it's allocating memory from the global pool. I forget to mention: QNX does use virtual memory, ( reliyng on the processor for actual memory management ) but no disk paging. So it behaves like VxWorks, i.e, early and _true_ stack allocation. Matthieu Thank you. You answered me what I was expecting: no system allows for a true or full dynamic stack size. Another wording: on every system one could reach some stack limit, and therefore one migth care about this figure. So, my true question comes into scene. The people who ported XFree86 to QNX 4.x setted the stack size hint to the Watcom linker to 4 Mb ( yes, 4 Mb ) for the server. I am wondering why a so high figure. I tried to grep the sources searching for some form of alloca usage ( the native one or a home brew, Postgresql style ) without success. In fact, all what is malloc and free related is coded using macros, which even appear redefined for some modules. But what I cannot figure simply is the possible recursions, and/or giant local objects. Is there a true need for such stack size ? marcelo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Re: stack size
On Tue, 08 Jul 2003 10:13:06 -0300, mnicolet wrote: Thank you. You answered me what I was expecting: no system allows for a true or full dynamic stack size. If that's your interpretation, then I'm not sure what you mean by a full dynamic stack size. All the operating systems he mentioned reserve address space for a gigantic stack, but they only allocate physical memory as it is needed. Special tricks with guard pages are used to determine when a new page of physical memory needs to be added to the stack. Another wording: on every system one could reach some stack limit, and therefore one migth care about this figure. Yes, of course. Memory is not infinite, even on a 4GB system. So, my true question comes into scene. The people who ported XFree86 to QNX 4.x setted the stack size hint to the Watcom linker to 4 Mb ( yes, 4 Mb ) for the server. I am wondering why a so high figure. I am wondering (1) why this figure seems high to you, and (2) why you are worried about it? The stack doesn't actually use 4MB of physical memory. It only uses the memory that is required. X11 is a thoroughly modular and layered server. It nests extremely deeply -- much more deeply than a typical application. I'm not saying 4MB is absolutely necessary, but if cutting it to 1MB causes even a single crash, what's the point? Is there a true need for such stack size ? Who cares? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance regression between 4.3.0 and snapshot version.
On Tue, 8 Jul 2003 11:46:30 +0100, Alan Hourihane wrote: On Tue, Jul 08, 2003 at 10:25:40AM +0200, Egbert Eich wrote: Bugzilla #434 shows a x11perf regression test between 4.3.0 and a rather current CVS versions. The performance of some tests has gone down by 20% for a specific test, some other tests have suffered a performance penalty of 3%. There may be a simple explanation for this however I can't find it right now. Any idea? Egbert, I believe this guy had 4.3.0 running with a savage with UseBIOS off because the BIOS failed for some reason so the UseBIOS option was turned off. In the later 4.3.99.x series the BIOS now works for him, but unfortunately the BIOS makes some more conservative settings for the accelerator engine in the savage. The Savage BIOS doesn't touch the graphics accelerator at all -- only the video timings. The accelerator is managed entirely in the driver. Can you tell me what settings you are referring to? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xaw expert?
I'd ask this on devel, but I'm certain I won't get an answer (at least not by anyone but you guys): Who would be an Xaw expert? Bugzilla #482 describes a situation (rather unlikely one) where Xaw causes a segfault. I've tracked it down however I'm not sure what would be the best solution. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
TFT Pivot function
Hello! I just bought a ViewSonic TFT-monitor (VP171b) with the pivot function the ability to flip the display 90 degrees) and I wonder if there is or are going to be support for this in X? best regards Jesper ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: TFT Pivot function
some drivers offer a rotate option, however there is no HW acceleration when this is used. Alex --- Jesper Tiberg [EMAIL PROTECTED] wrote: Hello! I just bought a ViewSonic TFT-monitor (VP171b) with the pivot function the ability to flip the display 90 degrees) and I wonder if there is or are going to be support for this in X? best regards Jesper __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re:: Re: stack size
Thank you. You pointed me back to documentation. QNX 4.x does not page to disk. A philosophical question for a RTOS. The only available memory is RAM. That´s why I care about everything. But it offers two main process image layouts. One that ´sandwiches´ the stack between the BSS and the heap, so the stack memory must be allocated at process startup. And another that leaves the stack at the low end of the data segment, so even if hinted, the stack only grows as required. What you pointed me to. By the way, the idea behind is that managing the stack in its own segment could be prohibitive for a system without disk paging. The question was I took the QNX options verbatim from the people who made the porting, and ended with a X server which at it´s very start was ´using´ more than 4 Mb of data !!! The right answer is to change compile and linking options, so even with a generous limit, the stack would be dynamically allocated as required. Than you again - Original Message - From: Tim Roberts [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 1:34 PM Subject: Re: Re: stack size On Tue, 08 Jul 2003 10:13:06 -0300, mnicolet wrote: Thank you. You answered me what I was expecting: no system allows for a true or full dynamic stack size. If that's your interpretation, then I'm not sure what you mean by a full dynamic stack size. All the operating systems he mentioned reserve address space for a gigantic stack, but they only allocate physical memory as it is needed. Special tricks with guard pages are used to determine when a new page of physical memory needs to be added to the stack. Another wording: on every system one could reach some stack limit, and therefore one migth care about this figure. Yes, of course. Memory is not infinite, even on a 4GB system. So, my true question comes into scene. The people who ported XFree86 to QNX 4.x setted the stack size hint to the Watcom linker to 4 Mb ( yes, 4 Mb ) for the server. I am wondering why a so high figure. I am wondering (1) why this figure seems high to you, and (2) why you are worried about it? The stack doesn't actually use 4MB of physical memory. It only uses the memory that is required. X11 is a thoroughly modular and layered server. It nests extremely deeply -- much more deeply than a typical application. I'm not saying 4MB is absolutely necessary, but if cutting it to 1MB causes even a single crash, what's the point? Is there a true need for such stack size ? Who cares? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re : Performance regression between 4.3.0 and snapshot version.
On 2003.07.08 06:46, Alan Hourihane wrote: On Tue, Jul 08, 2003 at 10:25:40AM +0200, Egbert Eich wrote: Bugzilla #434 shows a x11perf regression test between 4.3.0 and a rather current CVS versions. The performance of some tests has gone down by 20% for a specific test, some other tests have suffered a performance penalty of 3%. There may be a simple explanation for this however I can't find it right now. Any idea? Egbert, I believe this guy had 4.3.0 running with a savage with UseBIOS off because the BIOS failed for some reason so the UseBIOS option was turned off. In the later 4.3.99.x series the BIOS now works for him, but unfortunately the BIOS makes some more conservative settings for the accelerator engine in the savage. If he add Option UseBIOS off back in, I believe that will solve his problem. OK I'll redo the tests for CVS. But I don't really understand why I saw only few performance problems and almost all other tests are good (and several are even very very good wrt to 4.3.0. Anyway I'll post the result here and on bugzilla. Bye Manu pgp0.pgp Description: PGP signature
Re : Performance regression between 4.3.0 and snapshot version.
On 2003.07.08 04:25, Egbert Eich wrote: Bugzilla #434 shows a x11perf regression test between 4.3.0 and a rather current CVS versions. The performance of some tests has gone down by 20% for a specific test, some other tests have suffered a performance penalty of 3%. There may be a simple explanation for this however I can't find it right now. Any idea? Here are the new numbers (with the CVS config file using usebios off option). I put only the one that are bad (put the whole output on bugzilla) : 109000.086300.0 ( 0.79) Fill 1x1 aa trapezoid 45300.040400.0 ( 0.89) Fill 10x10 aa trapezoid 30300.025100.0 ( 0.83) 10-pixel wide partial circle 472000.0 403000.0 ( 0.85) Destroy window via parent (200 kids) 33400.031300.0 ( 0.94) 10-pixel wide partial ellipse 79300.078000.0 ( 0.98) 500-pixel horizontal line segment 2070.0 1910.0 ( 0.92) 100-pixel wide dashed circle 462000.0 447000.0 ( 0.97) Fill 1x1 opaque stippled trapezoid (17x15 stipple) 1460.0 1410.0 ( 0.97) Fill 100x100 aa trapezoid 182.0 176.0 ( 0.97) Fill 300x300 aa trapezoid 25200.0 23700.0 ( 0.94) QueryPointer 23100.022500.0 ( 0.97) GetProperty 415000.0 404000.0 ( 0.97) Unmap window via parent (4 kids) 70.0 684000.0 ( 0.98) Unmap window via parent (16 kids) 764000.0 745000.0 ( 0.98) Unmap window via parent (25 kids) 256000.0 244000.0 ( 0.95) Destroy window via parent (4 kids) 394000.0 377000.0 ( 0.96) Destroy window via parent (16 kids) 448000.0 41.0 ( 0.92) Destroy window via parent (25 kids) 473000.0 455000.0 ( 0.96) Destroy window via parent (50 kids) 478000.0 454000.0 ( 0.95) Destroy window via parent (75 kids) 483000.0 45.0 ( 0.93) Destroy window via parent (100 kids) 472000.0 403000.0 ( 0.85) Destroy window via parent (200 kids) 109000.0 107000.0 ( 0.98) Hide/expose window via popup (4 kids) 196000.0 194000.0 ( 0.99) Hide/expose window via popup (16 kids) 22.0 216000.0 ( 0.98) Hide/expose window via popup (25 kids) 222000.0 216000.0 ( 0.97) Hide/expose window via popup (50 kids) 227000.0 223000.0 ( 0.98) Hide/expose window via popup (75 kids) 231000.0 228000.0 ( 0.99) Hide/expose window via popup (100 kids) 233000.0 232000.0 ( 1.00) Hide/expose window via popup (200 kids) 77700.073400.0 ( 0.94) Move window (4 kids) 59600.0 56400.0 ( 0.95) Move window (16 kids) 52400.049700.0 ( 0.95) Move window (25 kids) 4.038100.0 ( 0.95) Move window (50 kids) 32600.031400.0 ( 0.96) Move window (75 kids) 27700.0 26400.0 ( 0.95) Move window (100 kids) 16400.016200.0 ( 0.99) Move window (200 kids) 96.0 935000.0 ( 0.97) Moved unmapped window (100 kids) 297000.0 277000.0 ( 0.93) Move window via parent (4 kids) 686000.0 662000.0 ( 0.97) Move window via parent (16 kids) 821000.0 791000.0 ( 0.96) Move window via parent (25 kids) 36500.035800.0 ( 0.98) Circulate window (4 kids) 24300.0 23600.0 ( 0.97) Circulate window (16 kids) 23300.023000.0 ( 0.99) Circulate window (25 kids) 22200.021600.0 ( 0.97) Circulate window (50 kids) 21500.020700.0 ( 0.96) Circulate window (75 kids) 20700.020100.0 ( 0.97) Circulate window (100 kids) 17900.017600.0 ( 0.98) Circulate window (200 kids) 376.0 378.0 ( 1.01) Circulate Unmapped window (4 kids) 307.0 308.0 ( 1.00) Circulate Unmapped window (16 kids) 276.0 270.0 ( 0.98) Circulate Unmapped window (25 kids) 214.0 217.0 ( 1.01) Circulate Unmapped window (50 kids) 179.0 177.0 ( 0.99) Circulate Unmapped window (75 kids) 150.0 147.0 ( 0.98) Circulate Unmapped window (100 kids) 904000.0 87.0 ( 0.96) Circulate Unmapped window (200 kids) pgp0.pgp Description: PGP signature
Re : Performance regression between 4.3.0 and snapshot version.
Oh sorry for the bad format of the post, bad numbers are in attachment. Bye Manu109000.086300.0 ( 0.79) Fill 1x1 aa trapezoid 45300.040400.0 ( 0.89) Fill 10x10 aa trapezoid 30300.025100.0 ( 0.83) 10-pixel wide partial circle 472000.0 403000.0 ( 0.85) Destroy window via parent (200 kids) 33400.031300.0 ( 0.94) 10-pixel wide partial ellipse 79300.078000.0 ( 0.98) 500-pixel horizontal line segment 2070.0 1910.0 ( 0.92) 100-pixel wide dashed circle 462000.0 447000.0 ( 0.97) Fill 1x1 opaque stippled trapezoid (17x15 stipple) 1460.0 1410.0 ( 0.97) Fill 100x100 aa trapezoid 182.0 176.0 ( 0.97) Fill 300x300 aa trapezoid 25200.023700.0 ( 0.94) QueryPointer 23100.022500.0 ( 0.97) GetProperty 415000.0 404000.0 ( 0.97) Unmap window via parent (4 kids) 70.0 684000.0 ( 0.98) Unmap window via parent (16 kids) 764000.0 745000.0 ( 0.98) Unmap window via parent (25 kids) 256000.0 244000.0 ( 0.95) Destroy window via parent (4 kids) 394000.0 377000.0 ( 0.96) Destroy window via parent (16 kids) 448000.0 41.0 ( 0.92) Destroy window via parent (25 kids) 473000.0 455000.0 ( 0.96) Destroy window via parent (50 kids) 478000.0 454000.0 ( 0.95) Destroy window via parent (75 kids) 483000.0 45.0 ( 0.93) Destroy window via parent (100 kids) 472000.0 403000.0 ( 0.85) Destroy window via parent (200 kids) 109000.0 107000.0 ( 0.98) Hide/expose window via popup (4 kids) 196000.0 194000.0 ( 0.99) Hide/expose window via popup (16 kids) 22.0 216000.0 ( 0.98) Hide/expose window via popup (25 kids) 222000.0 216000.0 ( 0.97) Hide/expose window via popup (50 kids) 227000.0 223000.0 ( 0.98) Hide/expose window via popup (75 kids) 231000.0 228000.0 ( 0.99) Hide/expose window via popup (100 kids) 233000.0 232000.0 ( 1.00) Hide/expose window via popup (200 kids) 77700.073400.0 ( 0.94) Move window (4 kids) 59600.056400.0 ( 0.95) Move window (16 kids) 52400.049700.0 ( 0.95) Move window (25 kids) 4.038100.0 ( 0.95) Move window (50 kids) 32600.031400.0 ( 0.96) Move window (75 kids) 27700.026400.0 ( 0.95) Move window (100 kids) 16400.016200.0 ( 0.99) Move window (200 kids) 96.0 935000.0 ( 0.97) Moved unmapped window (100 kids) 297000.0 277000.0 ( 0.93) Move window via parent (4 kids) 686000.0 662000.0 ( 0.97) Move window via parent (16 kids) 821000.0 791000.0 ( 0.96) Move window via parent (25 kids) 36500.035800.0 ( 0.98) Circulate window (4 kids) 24300.023600.0 ( 0.97) Circulate window (16 kids) 23300.023000.0 ( 0.99) Circulate window (25 kids) 22200.021600.0 ( 0.97) Circulate window (50 kids) 21500.020700.0 ( 0.96) Circulate window (75 kids) 20700.020100.0 ( 0.97) Circulate window (100 kids) 17900.017600.0 ( 0.98) Circulate window (200 kids) 376.0 378.0 ( 1.01) Circulate Unmapped window (4 kids) 307.0 308.0 ( 1.00) Circulate Unmapped window (16 kids) 276.0 270.0 ( 0.98) Circulate Unmapped window (25 kids) 214.0 217.0 ( 1.01) Circulate Unmapped window (50 kids) 179.0 177.0 ( 0.99) Circulate Unmapped window (75 kids) 150.0 147.0 ( 0.98) Circulate Unmapped window (100 kids) 904000.0 87.0 ( 0.96) Circulate Unmapped window (200 kids) pgp0.pgp Description: PGP signature
Re: Performance regression between 4.3.0 and snapshot version.
Looks like a code generation issue. P4's will do that sometimes when you change the alignment of particular functions/structures. The graphics driver probably has nothing to do with it since the worst regressions don't involve graphics. Mark. On Tue, 8 Jul 2003, Egbert Eich wrote: Bugzilla #434 shows a x11perf regression test between 4.3.0 and a rather current CVS versions. The performance of some tests has gone down by 20% for a specific test, some other tests have suffered a performance penalty of 3%. There may be a simple explanation for this however I can't find it right now. Any idea? Egbert. === Cut from Bugzilla #434 === Yes! Just done all tests with : 4.3.0 vanilla and CVS (as a few days ago, with the O_SYNC flags removed) both compiled on the box. See attachment for the full output of x11percomp. Here are the bad results (ie when CVS performs really worse than 4.3.0, at least more than ~3%, and I've tried to put them in badness order) : 217.0 153.0 ( 0.71) Circulate Unmapped window (50 kids) 1530.0 ( 0.82) 100-pixel wide double-dashed circle 1860.0 108000.093600.0 ( 0.87) Char in 80-char a core line (Courier 12) 133.0 116.0 ( 0.87) Circulate Unmapped window (100 kids) 154.0 142.0 ( 0.92) Char in 80-char a line (Courier 12) 24500.023200.0 ( 0.95) QueryPointer 23000.022000.0 ( 0.96) GetProperty 414000.0 402000.0 ( 0.97) Unmap window via parent (4 kids) 779000.0 753000.0 ( 0.97) Unmap window via parent (25 kids) 818000.0 802000.0 ( 0.98) Unmap window via parent (50 kids) 24.0 234000.0 ( 0.97) Destroy window via parent (4 kids) 37.0 362000.0 ( 0.98) Destroy window via parent (16 kids) 403000.0 391000.0 ( 0.97) Destroy window via parent (25 kids) 428000.0 39.0 ( 0.91) Destroy window via parent (200 kids) 152000.0 149000.0 ( 0.98) Create and map subwindows (4 kids) 288000.0 283000.0 ( 0.98) Map window via parent (25 kids) 108000.0 106000.0 ( 0.98) Hide/expose window via popup (4 kids) 199000.0 193000.0 ( 0.97) Hide/expose window via popup (16 kids) 22.0 216000.0 ( 0.98) Hide/expose window via popup (25 kids) 224000.0 219000.0 ( 0.98) Hide/expose window via popup (50 kids) 225000.0 223000.0 ( 0.99) Hide/expose window via popup (75 kids) 231000.0 224000.0 ( 0.97) Hide/expose window via popup (100 kids) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: stack size
Tim Roberts wrote: On Tue, 08 Jul 2003 10:13:06 -0300, mnicolet wrote: So, my true question comes into scene. The people who ported XFree86 to QNX 4.x setted the stack size hint to the Watcom linker to 4 Mb ( yes, 4 Mb ) for the server. I am wondering why a so high figure. I am wondering (1) why this figure seems high to you, and (2) why you are worried about it? The stack doesn't actually use 4MB of physical memory. It only uses the memory that is required. X11 is a thoroughly modular and layered server. It nests extremely deeply -- much more deeply than a typical application. I'm not saying 4MB is absolutely necessary, but if cutting it to 1MB causes even a single crash, what's the point? Is there a true need for such stack size ? Who cares? Is QNX a threaded OS (like Netware)? Threaded applications on x86 usually have much smaller default stack limits, averaging 64-128k, because all threads must share the same address space, and a 4MB stack gives you a theoretical limit of only 1024 threads (assuming your kernel uses no memory and your process allocates no data, just stack :) mnicolet: the best way to answer your question Is there a true need for such stack size is probably for you to set the stack size lower and see if it breaks. -- Dan Nelson [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: stack size
On Tue, 08 Jul 2003 16:40:39 -0500, Dan Nelson wrote: Threaded applications on x86 usually have much smaller default stack limits, averaging 64-128k, because all threads must share the same address space, and a 4MB stack gives you a theoretical limit of only 1024 threads (assuming your kernel uses no memory and your process allocates no data, just stack :) Delving deeply into pedantics, the default stack size for a Win32 CreateThread call is 1MB, but you bump into other limits long before you get to 2048 threads (given the 2GB user-mode address space). -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
