On Nov 19, 2009, at 10:25 AM, Jon Harrop wrote:> > >> In this case, the assertion that LLVM is slow is correct: it's >> definitely slower than a non-optimizing compiler. > > I'm *very* surprised by this and will test it myself...Compared to a compiler in the same category as PCC, whose pinnacle of optimization is doing register allocation? I'm not surprised at all. --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091119/e9914c0b/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091119/e9914c0b/attachment.bin>
On Nov 19, 2009, at 11:48 AM, Owen Anderson <resistor at mac.com> wrote:> > On Nov 19, 2009, at 10:25 AM, Jon Harrop wrote: >> >> >>> In this case, the assertion that LLVM is slow is correct: it's >>> definitely slower than a non-optimizing compiler. >> >> I'm *very* surprised by this and will test it myself... > > Compared to a compiler in the same category as PCC, whose pinnacle > of optimization is doing register allocation? I'm not surprised at > all.Though, at -O0 llvm's goal is not to optimize but to be fast, no? I was certainly wondering what would prevent LLVM from being as fast as the go compiler. Do they need to be able to stream code from the front to middle to back ends or something? (Can llvm do that?)> --Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091119/1f9bf3b4/attachment.html>
2009/11/19 Ken Ferry <kenferry at gmail.com>:> Though, at -O0 llvm's goal is not to optimize but to be fast, no?I thought -O0's only use was to be ipsis literis with the code so you can debug the application... I can't see any other use for that... cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
On Nov 19, 2009, at 2:10 PM, Jon Harrop wrote:> On Thursday 19 November 2009 19:48:18 Owen Anderson wrote: >> On Nov 19, 2009, at 10:25 AM, Jon Harrop wrote: >>>> In this case, the assertion that LLVM is slow is correct: it's >>>> definitely slower than a non-optimizing compiler. >>> >>> I'm *very* surprised by this and will test it myself... > > I've tested it and LLVM is indeed 2x slower to compile, although it > generates > code that is 2x faster to run... > >> Compared to a compiler in the same category as PCC, whose pinnacle of >> optimization is doing register allocation? I'm not surprised at all. > > What else does LLVM do with optimizations turned off that makes it > slower?I haven't looked at Go at all, but in general, there is a significant overhead to creating a compiler intermediate representation. If you produce assembly code straight out of the parser, you can compile faster. Even though LLVM does little optimization at -O0, there is still a fair amount of work involved in translating to LLVM IR.
Jon Harrop wrote:> On Thursday 19 November 2009 19:48:18 Owen Anderson wrote: > >> On Nov 19, 2009, at 10:25 AM, Jon Harrop wrote: >> >>>> In this case, the assertion that LLVM is slow is correct: it's >>>> definitely slower than a non-optimizing compiler. >>>> >>> I'm *very* surprised by this and will test it myself... >>> > > I've tested it and LLVM is indeed 2x slower to compile, although it generates > code that is 2x faster to run... > > >> Compared to a compiler in the same category as PCC, whose pinnacle of >> optimization is doing register allocation? I'm not surprised at all. >> > > What else does LLVM do with optimizations turned off that makes it slower? >My guess would be primarily (1) respectable instruction selection, followed by (2) good register allocation. But at some point, the overhead of going through an abstract IR will slow you down. You're never going to beat a splat compiler except with another splat compiler. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091119/3a8c6de1/attachment.html>
Jon Harrop <jon at ffconsultancy.com> writes:> On Thursday 19 November 2009 19:48:18 Owen Anderson wrote:[snip]>> Compared to a compiler in the same category as PCC, whose pinnacle of >> optimization is doing register allocation? I'm not surprised at all. > > What else does LLVM do with optimizations turned off that makes it slower?On my experience, optimization is not the slowest part, native codegen is. (But it could be argued that native codegen is slow because it tries to produce the most efficient native code out of the llvm bitecode.) -- Óscar
2009/11/19 Jon Harrop <jon at ffconsultancy.com>:> I've tested it and LLVM is indeed 2x slower to compile, although it generates > code that is 2x faster to run...This is ok if the code is too small to be worth optimizations or complex codegen and need to be generated in huge volumes (something that Google has, for sure). For all other cases, I can't see the point. In that sense, they've created a domain-specific compiler for a domain-specific language, which will obviously perform better than anything else in their case and worse than anything else for all other cases. I don't see any novelty in that... cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
On Thursday 19 November 2009 19:48:18 Owen Anderson wrote:> On Nov 19, 2009, at 10:25 AM, Jon Harrop wrote: > >> In this case, the assertion that LLVM is slow is correct: it's > >> definitely slower than a non-optimizing compiler. > > > > I'm *very* surprised by this and will test it myself...I've tested it and LLVM is indeed 2x slower to compile, although it generates code that is 2x faster to run...> Compared to a compiler in the same category as PCC, whose pinnacle of > optimization is doing register allocation? I'm not surprised at all.What else does LLVM do with optimizations turned off that makes it slower? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e