On 07/26/05 12:28 AM, Giovanni Bajo sat at the `puter and typed: > Louis LeBlanc <[EMAIL PROTECTED]> wrote: > > > I added the -fstack-check switch to my makefile and recompiled with > > various optimizations. I was pretty surprised at the file sizes that > > showed up: > > > > No Optimization: > > -rwxr-xr-x 1 leblanc daemon 1128660 Jul 25 16:25 myprocess* > > > > Optimized with -O2 > > -rwxr-xr-x 1 leblanc daemon 1058228 Jul 25 17:36 myprocess* > > > > Optimized with -O3 > > -rwxr-xr-x 1 leblanc daemon 1129792 Jul 25 17:32 myprocess* > > > > I would have expected much different results. Shouldn't the file > > sizes be smaller (at least a little) with the -O3 switch? Maybe > > there's a loop unrolled to make it faster, resulting in a larger > > codebase? > > > Or inlining, or many other things. If you care about size, use -Os.
Well, I don't care about size that much. This isn't an embedded app, and performance and stability usually contend with each other for the primary concern. I did finally get a build with 4.0.1. I certainly was surprised at some of the things I found, but it did help a lot. Funny thing is that the same compiler flags provide a much bigger executable with 4.0.1 than with 3.3.6, but it doesn't core trying to release a thread lock. I've also confirmed that this happens without contention because one of the apps that uses this code actually only runs a single thread. I used the following flags: -ggdb -g3 -Wall -fstack-check -fno-strict-aliasing -O2 -mcpu=ultrasparc The -fmudflaps flag requires some odd linking I haven't figured out yet, so I'm skipping it for now. I also found, to my delight and surprise, that the same code appears to perform between 10% and 20% better - in a rough, fairly imprecise environment. I still cannot find the cause of the core I get with the 3.3.6 version though. What I do get with 4.0.1 is some warnings I'd never seen before: disk.c: In function 'disk_find': disk.c:281: warning: frame size too large for reliable stack checking disk.c:281: warning: try reducing the number of local variables I was initially getting this for about 20 of my functions. I know very well that I'm using some large stacks, so I wasn't surprised about that, I was just surprised that the threshold here appears to be quite low (is it around 8K? - please clarify for me if you know). This process does some pretty heavy text management for URL transforms and transaction logging, so several routines statically allocate some fairly large character buffers for this. When I first saw these warnings, I went through and moved a few buffers to different scopes and changed a couple to dynamic allocations, since they weren't needed in all cases. This helped eliminate most of these (down to 6 functions), but some still require these buffers for all transactions, so it doesn't make much sense (to me, anyway) to allocate them dynamically. The source file that is still generating a core with 3.3.6 did have a couple of these warnings (in different functions, not the one that was coring), but they were easily accomodated, and even though the warnings are gone in the 4.0.1 build, it still cores with the 3.3.6 build unless I turn off optimization for that file. I know it's confusing, but I'm trying to use the behavior from the two compiler versions to make the code itself better, rather than just picking the compiler that "seems to work". I was actually hoping to get more discernable info in the 3.3.6 build core after these changes, but the core hasn't actually changed. Looking at the gcc docs, I noticed the -fstack-limit flags, but I'm not real clear if or how they can help, or exactly how they're used. I am using the gcc linker, so the method described in the docs should be fine if it applies, but it looks like an absolute address is needed for the lower bound. Any pointers on where I can get clarification on these flags and the default stack size limits? If I should be taking this to a usenet group or some other forum instead of here, please let me know. Once again, many thanks to all those that have provided input so far. It's been very helpful. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :þ http://www.keyslapper.net Ô¿Ô¬ Key fingerprint = C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2 QOTD: "If you keep an open mind people will throw a lot of garbage in it."
