search for: bloating

Greetings all The help file for GAMM in mgcv indicates that the log likelihood for a GAMM reported using summary(my.gamm$lme) (as an example) is not correct. However, in a past 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

We would also like to clarify on the misconceptions around CFI Instructions: There are two things that need to be clarified here: 1) Extra CFI FDE entries for basic blocks does not mean more dynamic instructions are executed. In fact, they do not increase at all. Krys talked about this earlier. 2) We do deduplication of common static CFI instructions in the FDE and move it to the CIE . Hence,

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? On Wed,

Some more information about the relaxation pass whose effectiveness and convergence guarantees were listed as a concern: TLDR; Our relaxation pass is similar to what LLVM’s MCAssembler does but with a caveat for efficiency. Our experimental results show it is efficient and convergence is guaranteed. Our relaxation pass is very similar to what MCAssembler does as it needs to solve the same

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) I''d like to get

lld definitely shouldn't be that big. I would expect 10MB at most. Can you check whether something weird is happening, like lld 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

Hi all, As a Ph.D. student majored in Software Reliability, I have used LLVM in many of my projects, such as the Anticipating Invariant ( http://james0zan.github.io/AI.html) and some other undergoing ones. Thus, it would be a great pleasure for me if I could take this opportunity to contribute to this awesome project. After reading the idea list (http://llvm.org/OpenProjects.html), I was most

Hello John, Thank you for your advices and congratulations~ I'll read the code of cfl-aa and Giri first and make the decision of which project to pursue. The choice will be reported to this thread once I made the determination (hopefully within this week). Thanks! On 3 March 2015 at 23:12, John Criswell <jtcriswel at gmail.com> wrote: > Dear Mingxing, > > I think both

I''m an RJS newbie. I just did the tutorial at http://www.codyfauser.com/articles/2005/11/20/rails-rjs-templates, and then used wget to look at the output the RJS template generates. This is what I got: try { new Insertion.Bottom("list", "<li>Fox</li>"); new Effect.Highlight("list",{duration:1}); Element.update("header", "RJS

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 them can be accepted. > Thus I will prepare a proposal for each of the two projects. Correct. Only one proposal will be accepted. > And, after reading the code of cfl-aa and several related papers, I've > listed four milestones for the

Wow, that is cool! I'll check about it. Thank you! On 4 March 2015 at 21:57, John Criswell <jtcriswel at gmail.com> wrote: > On 3/4/15 2:18 AM, Mingxing Zhang wrote: > > Hello John, > > Thank you for your advices and congratulations~ > > I'll read the code of cfl-aa and Giri first and make the decision of which > project to pursue. > The choice will be

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

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

...nt 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''m currently running 1.0.1) Are there any other recommendations for handling this situation? thanks

Hello John, I've finished the first version of my proposal on enhancing alias analysis. The proposal can be downloaded at http://james0zan.github.io/resource/GSoC15-Proposal-AA.pdf. I hope I've successfully justified the necessity and benefits of this project. If possible, please find some time to review it and give me some more feedbacks. Thank you very much! P.S. I'm working on

Is there large value from deferring the block ordering to link time? That is, does the block layout algorithm need to consider global layout issues when deciding which blocks to put together and which to relegate to the far-away part of the code? Or, could the propellor-optimized compile step instead split each function into only 2 pieces -- one containing an "optimally-ordered" set of

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

Hi Jack, Are you packaging all the static libraries that lld produces as part of the package ? 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

On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: > Is there any reason -ffunction-sections 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

Hello Daniel, Thank you for your comments and sorry for my mistakes, I'll revise them. And I'll for sure read the paper you mentioned and survey the recent researches before deciding the implementation technique. To George: May I know the exact plan of your attempt for making cfl-aa interprocedural? I do think that this is the most valuable part of my proposal, but that makes no sense to