On 07/26/05 05:52 PM, Robert Dewar sat at the `puter and typed:
> Louis LeBlanc wrote:
>
> > 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.
>
> why surprise?
I wasn't aware it was poss
Louis LeBlanc wrote:
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.
why surprise?
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:
>
O Jul 25, 2005, at 3:50 PM, Robert Dewar wrote:
The unoptimized version completed a 401,900 transaction test with no
problem. All day, I've been playing with different things,
there are many bugs, most notably uninitialed vars, that show
up only when you turn on optimization.
Also violations
Louis LeBlanc wrote:
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?
you generally expect -O3 files to be larger. inlining does not save
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
On 07/25/05 05:15 PM, Giovanni Bajo sat at the `puter and typed:
> Louis LeBlanc <[EMAIL PROTECTED]> wrote:
>
> > The problem is I'm getting core dumps (SEGV) that appears to come from
> > this code when I know it shouldn't be in the execution path. The code
> > in question is switched on by a co
On 07/25/05 05:15 PM, Giovanni Bajo sat at the `puter and typed:
> Louis LeBlanc <[EMAIL PROTECTED]> wrote:
>
> > The problem is I'm getting core dumps (SEGV) that appears to come from
> > this code when I know it shouldn't be in the execution path. The code
> > in question is switched on by a co
Louis LeBlanc <[EMAIL PROTECTED]> wrote:
> The problem is I'm getting core dumps (SEGV) that appears to come from
> this code when I know it shouldn't be in the execution path. The code
> in question is switched on by a command line argument only, and the
> process is managed by a parent process
Hey folks. I'm having some trouble with a process compiled with gcc
3.3.6. This code is pretty complex and has several features that are not
typically in use because they involve non-production test cases.
The problem is I'm getting core dumps (SEGV) that appears to come from
this code when I kn
10 matches
Mail list logo
