This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Performance problems between gcc 12.2 and 13
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Judd Montgomery <judd at engineer dot com>
- Cc: libc-help at sourceware dot org
- Date: Tue, 17 Jul 2012 20:01:19 -0400
- Subject: Re: Performance problems between gcc 12.2 and 13
- References: <5005C98E.1080602@engineer.com><5005CF69.6050804@mentor.com><5005D6B5.2060802@engineer.com>
On Tue, Jul 17, 2012 at 5:18 PM, Judd Montgomery <judd@engineer.com> wrote:
>> If you step into the function which is the final routine selected to
>> perform the string operation?
>>
> Is this what you are asking?
Yes.
> $ gdb ./loop.12
> GNU gdb (GDB) 7.0-ubuntu
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/jmontgomery/loop.12...done.
> (gdb) break strptime
> Breakpoint 1 at 0x400548
> (gdb) run
> Starting program: /home/jmontgomery/loop.12
>
> Breakpoint 1, 0x00007ffff7af85c0 in strptime () from
> /opt/glibc-2.12.2/lib/libc.so.6
> (gdb) step
> Single stepping until exit from function strptime,
> which has no line number information.
> 0x00007ffff7af86c0 in __strptime_internal () from
> /opt/glibc-2.12.2/lib/libc.so.6
> (gdb) step
> Single stepping until exit from function __strptime_internal,
> which has no line number information.
> 0x00000000004006d5 in main ()
> (gdb)
Is this function actually consuming most of your time?
You need to profile your program, either with a proper profiling tool
or simply using RDTSCP (see
http://download.intel.com/embedded/software/IA/324264.pdf).
The function __strptime_internal hasn't changed in any significant way
since 2007, so if __strptime_internal is taking up time in your
profile it might be that the compiler is doing something different.
Next steps:
- Profile your run.
- Find out which functions are taking up time.
- Look into those.
Cheers,
Carlos.