search for: bloat

...st R-help post (included below), there is some indication that the likelihood ratio test in anova.lme(mygamm$lme, mygamm1$lme) is valid. How can I tell if anova.lme results are meaningful (are AIC, BIC, and logLik estimates accurate)? The data include hydroacoustic estimates of fish biomass (lbloat) in 1,000 meter long intervals (elementary sampling units) from multiple transects (each 20-30 km long, tranf) in two different lakes and three different years. bloat.gamm1 <- gamm(lbloat ~ s(depth), correlation=corSpher(c(30000, 0.01),form = ~ x+y|tranf, nugget=TRUE), data=fish3) bloat....

...iraman Tallam <tmsriram at google.com> wrote: > > Maks and team, thanks for the detailed feedback and we will address all of your > concerns. Let’s begin with CFI and DebugInfo first since this is already > being discussed. > > TLDR; clang is pathological and the actual CFI bloat will go down from 7x to > 2x. > > Let us present the CFI Bloats for each benchmark with the default option, which > is creating basic block sections only for functions with samples. For clang, > it is 7x and *not 17x* (the 17 x number is for all sections), and for the > large be...

I'm a bit confused by this subthread -- doesn't BOLT have the exact same CFI bloat issue? From my cursory reading of the propellor doc, the CFI duplication is _necessary_ to represent discontiguous functions, not anything particular to the way Propellor happens to generate those discontiguous functions. And emitting discontiguous functions is a fundamental goal of this, right?...

...; > > > > Maks and team, thanks for the detailed feedback and we will address all of your > > > concerns. Let’s begin with CFI and DebugInfo first since this is already > > > being discussed. > > > > > > TLDR; clang is pathological and the actual CFI bloat will go down from 7x to > > > 2x. > > > > > > Let us present the CFI Bloats for each benchmark with the default option, which > > > is creating basic block sections only for functions with samples. For clang, > > > it is 7x and *not 17x* (the 17 x numb...

Two ideas, one more controversial than the other. First: auto-killing bloated workers.?My current app has some memory leakage that wasn''t really visible on our older passenger setup, since the auto-scaling meant that bloated workers got killed periodically. In a perfect world, we''d find and patch all of the leaks, but in the meantime (and as a safety net)...

...being built with debug info? -- Sean Silva On Wed, Nov 20, 2013 at 10:15 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > When lld-3.4 is added to the tools directory of the llvm source tree > as lld, the resulting cmake build produces a huge number of static libs and > bloats the overall package from... > > -rw-r--r-- 1 root wheel 86361440 Nov 19 21:09 > llvm34_3.4-0_darwin-x86_64.deb > > to > > -rw-r--r-- 1 root wheel 495257452 Nov 19 20:49 > llvm34_3.4-0_darwin-x86_64.deb > > Is this a known issue with the initial release of lld? &...

.../OpenProjects.html), I was most interested in the idea of improving the "Pointer and Alias Analysis" passes. Could you please give me some more tips or advices on how to get started on working on the application? Simultaneously, I also have another idea about using LLVM to detect runtime bloat, just like the ThreadSanitizer tool for data races. If there is anyone here who would like to mentor this project, could you please find some time to review the more detailed proposal on gist <https://gist.github.com/james0zan/d03737c60b10d0d11d34> and give me some feedbacks? P.S. I do pre...

...eful to both > research and industry users of LLVM. A points-to analysis proposal must > indicate how it will help both of these subsets of the LLVM community, and > it must argue why current efforts do not meet the requirements of both > subsets of the community. > > The runtime bloat tool also looks interesting, and your approach (at least > to me) is interesting. One question in my mind, though, is whether dynamic > slicing is going to work well. Swarup Sahoo and I built a dynamic slicer > for LLVM named Giri, and we found the tracing required for dynamic slicing &g...

...st\", \"<li>Fox</li>\");\nnew Effect.Highlight(\"list\",{duration:1}) ;\nElement.update(\"header\", \"RJS Template Test Complete\");''); throw e } It looks to me like the exception handling logic sent in the response causes too much bloat. I think it''s better to send only the "meat": new Insertion.Bottom("list", "<li>Fox</li>"); new Effect.Highlight("list",{duration:1}); Element.update("header", "RJS Template Test Complete"); Thoughts? -- Posted via...

...variables, such as errno. > > 4) It seems that the current version of cfl-aa is an intraprocedural > analysis. > If the time is enough, I think we may extend it to an interprocedural > analysis. > The algorithm described in [3] can be applied to scaling it. > > As for the bloat-detection project, the final result should be a tool > that is verified by known bugs and a set of newly detected bugs. For the bloat detection tool, I would like to be convinced that dynamic tracing will be, or can be, sufficiently efficient to be practical. I hate to ask, but I think you...

...search and industry users of LLVM. A points-to analysis proposal must >> indicate how it will help both of these subsets of the LLVM community, and >> it must argue why current efforts do not meet the requirements of both >> subsets of the community. >> >> The runtime bloat tool also looks interesting, and your approach (at >> least to me) is interesting. One question in my mind, though, is whether >> dynamic slicing is going to work well. Swarup Sahoo and I built a dynamic >> slicer for LLVM named Giri, and we found the tracing required for dynami...

When lld-3.4 is added to the tools directory of the llvm source tree as lld, the resulting cmake build produces a huge number of static libs and bloats the overall package from... -rw-r--r-- 1 root wheel 86361440 Nov 19 21:09 llvm34_3.4-0_darwin-x86_64.deb to -rw-r--r-- 1 root wheel 495257452 Nov 19 20:49 llvm34_3.4-0_darwin-x86_64.deb Is this a known issue with the initial release of lld? Jack

On Fri, Nov 20, 2015 at 5:06 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > We'd need to look precisely at what's causing the code size bloat. The > midend commit pointed out by Steve shouldn't cause bloat in and of itself - > it should reduce code size. It removes a load of stores and branches. > Hi James, Sounds like your patch should have been the best of both worlds, so can you investigate the -Os code size mystery? Do...

...using sendfile to return large files to customers. We can''t use regular Apache to handle this static content since the files are what the customers are paying for - so it wouldn''t be cool for anyone else to get access to them. The issue is that the mongrel mem footprint gets bloated when the files are transferred and this mem does not get returned to the system. I''ve looked into x-sendfile, but it doesn''t appear to be compatible with Apache 2.2. Now the question, does the current mongrel 1.1.1 have this same issue with sendfile and memory bloating? (I&...

...ed. On 8 March 2015 at 21:42, Mingxing Zhang <james0zan at gmail.com> wrote: > Got it. > I'll try to find the applications for field-sensitivity (and > interprocedural, etc) AA analysis. > And I'll do some preliminary evaluation on the tracing/slicing part for > the bloat detection. > > Thanks! > > On 8 March 2015 at 21:34, John Criswell <jtcriswel at gmail.com> wrote: > >> On 3/8/15 8:56 AM, Mingxing Zhang wrote: >> >> Hello John, >> >> According to the FAQ, I can submit two proposals although at most one of >...

...Wed, Oct 2, 2019 at 6:18 PM Rafael Auler <rafaelauler at fb.com> wrote: > You’re correct, except that, in Propeller, CFI duplication happens for > every basic block as it operates with the conservative assumption that a > block can be put anywhere by the linker. That’s a significant bloat that is > not cleaned up later. So, during link time, if N blocks from the same > function are contiguous in the final layout, as it should happen most of > the time for any sane BB order, we would have several FDEs for a region > that only needs one. The bloat goes to the final binary...

Here's an example where llvm should probably be producing smaller code, its output is 700% larger than gcc. regehr at john-home:~/volatile/tmp11$ llvm-gcc -Os -w small.c -o small ; size small text data bss dec hex filename 6324 252 8 6584 19b8 small regehr at john-home:~/volatile/tmp11$ current-gcc -Os -w small.c -o small ; size small text data

...ge ? PS : When I build on x86_64, I only get a 9M image for lld. Thanks Shankar Easwaran On 11/20/2013 9:15 AM, Jack Howarth wrote: > When lld-3.4 is added to the tools directory of the llvm source tree > as lld, the resulting cmake build produces a huge number of static libs and > bloats the overall package from... > > -rw-r--r-- 1 root wheel 86361440 Nov 19 21:09 llvm34_3.4-0_darwin-x86_64.deb > > to > > -rw-r--r-- 1 root wheel 495257452 Nov 19 20:49 llvm34_3.4-0_darwin-x86_64.deb > > Is this a known issue with the initial release of lld? >...

...s and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining new ELF section. >From my understanding, -ffunction-sections is a good semantic match. But it introduces a lot of bloat in the .o file which the linker must process. For reference, with mach-o we just added a flag to the overall .o file that says all sections are "safe". The compiler always generates safe object files (unless there is inline code with non-local labels) and always sets the flag. Hand...

...<james0zan at gmail.com> wrote: >> >>> Got it. >>> I'll try to find the applications for field-sensitivity (and >>> interprocedural, etc) AA analysis. >>> And I'll do some preliminary evaluation on the tracing/slicing part for >>> the bloat detection. >>> >>> Thanks! >>> >>> On 8 March 2015 at 21:34, John Criswell <jtcriswel at gmail.com> wrote: >>> >>>> On 3/8/15 8:56 AM, Mingxing Zhang wrote: >>>> >>>> Hello John, >>>> >>>&g...