On Fri, Jul 17, 2009 at 04:41:55PM -0700, Eli Friedman wrote:> On Fri, Jul 17, 2009 at 4:14 PM, Jonathan Gray<jsg at goblin.cx> wrote: > > This seems to go against notes such as > > http://clang.llvm.org/features.html#performance > > which claim clang is signifcantly faster than gcc. > > I think the URL you want is actually > http://clang.llvm.org/performance.html. The difference isn't as > dramatic when you consider code generation, at least for the moment.Are these scripts to break down the time spent in different stages available somewhere?> > > Below are some times and the larger object files when > > compiling an i386 OpenBSD kernel at -O2 on an Intel Atom > > based laptop. ?The significantly larger code size > > is rather disturbing as it means binaries can't fit on > > space constrained installation media for example. > > Are you building with -g? The debug info implementation is known to > be relatively inefficient.No -g/debug info, as below with additional -D defines. -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-uninitialized -Wno-format -fno-builtin -fno-zero-initialized-in-bss -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -O2 -pipe -nostdinc
On Fri, Jul 17, 2009 at 5:12 PM, Jonathan Gray<jsg at goblin.cx> wrote:> On Fri, Jul 17, 2009 at 04:41:55PM -0700, Eli Friedman wrote: >> On Fri, Jul 17, 2009 at 4:14 PM, Jonathan Gray<jsg at goblin.cx> wrote: >> > This seems to go against notes such as >> > http://clang.llvm.org/features.html#performance >> > which claim clang is signifcantly faster than gcc. >> >> I think the URL you want is actually >> http://clang.llvm.org/performance.html. The difference isn't as >> dramatic when you consider code generation, at least for the moment. > > Are these scripts to break down the time spent > in different stages available somewhere?Not currently, I've never bothered to make them public because they aren't very generic. They more or less amount to running the compiler with extra options like -fsyntax-only, or -E, and timing those. Its worth trying to reproduce the performance issue on a single file before going down this road. However, if you really want them I can ship you what I have, I just don't promise it will be very useful. - Daniel
I'd look at if_spppsubr.o, which is big in the llvm directories and doesn't appear in the gcc directory listings at all (I assume the listings were fed through tail or something, but there's clearly a sizeable difference there) On Jul 17, 2009, at 5:41 PMPDT, Daniel Dunbar wrote:> On Fri, Jul 17, 2009 at 5:12 PM, Jonathan Gray<jsg at goblin.cx> wrote: >> On Fri, Jul 17, 2009 at 04:41:55PM -0700, Eli Friedman wrote: >>> On Fri, Jul 17, 2009 at 4:14 PM, Jonathan Gray<jsg at goblin.cx> wrote: >>>> This seems to go against notes such as >>>> http://clang.llvm.org/features.html#performance >>>> which claim clang is signifcantly faster than gcc. >>> >>> I think the URL you want is actually >>> http://clang.llvm.org/performance.html. The difference isn't as >>> dramatic when you consider code generation, at least for the moment. >> >> Are these scripts to break down the time spent >> in different stages available somewhere? > > Not currently, I've never bothered to make them public because they > aren't very generic. They more or less amount to running the compiler > with extra options like -fsyntax-only, or -E, and timing those. Its > worth trying to reproduce the performance issue on a single file > before going down this road. However, if you really want them I can > ship you what I have, I just don't promise it will be very useful. > > - Daniel > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> No -g/debug info, as below with additional -D defines. > > -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-uninitialized -Wno-format > -fno-builtin -fno-zero-initialized-in-bss -mno-mmx -mno-sse -mno-sse2 -mno-sse3 > -O2 -pipe -nostdinc >I suppose that a kernel don't use much floating point instructions, but I was under the impression that the x87 backend (ie x86 without sse/sse2) of llvm was not very good, at least, not up to par with the rest. regards, Cédric