search for: superlinearly

On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > I don't think that arbitrary limiting the complexity of the search is the > right approach. There are numerous ways the LVI infrastructure could be > made more memory efficient. Fixing the existing code to be memory efficient > is the right approach. Only once there's no more low hanging fruit should > we

On Fri, Apr 18, 2014 at 11:13 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > Hi, > > This is long thread, so I will combine several comments into single email. > > > >> - 8-bit per-thread counters, dumping into central counters on overflow. > >The overflow will happen very quickly with 8bit counter. > > Yes, but it reduces contention by 256x (a thread

Adding LLVMdev, since this is intimately related to the optimization passes. > I think this is roughly because some function level optimisations are > worse than O(N) in the number of instructions. Please profile this and mail llvmdev regarding passes with significantly superlinear behavior (e.g. O(n^2)). My understanding is that these kinds of algorithmic problems are generally considered

On 01/13/2016 04:28 PM, Daniel Berlin via llvm-dev wrote: > > > On Wed, Jan 13, 2016 at 4:23 PM, Joerg Sonnenberger via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > > I don't think that arbitrary limiting the complexity of the > search

On Wed, Jan 13, 2016 at 04:28:03PM -0800, Daniel Berlin wrote: > On Wed, Jan 13, 2016 at 4:23 PM, Joerg Sonnenberger via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > > > I don't think that arbitrary limiting the complexity of the search is the > > > right approach. There are

Hi, Here's a personal perspective on the issue: Firstly I don't think TeX does pre-estimation of work, it's just the standard stepwise "refinement stuff". However, the idea itself isn't necessarily a bad one. In the academic community there's a set of people (John Cavazos, Lous-Noel Pouchet, others I've forgotten) doing work on estimating which sets of

On Apr 17, 2014, at 2:04 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Apr 17, 2014 at 1:27 PM, Justin Bogner <mail at justinbogner.com> wrote: > Chandler Carruth <chandlerc at google.com> writes: > > if (thread-ID != main's thread-ID && shard_count < std::min(MAX, NUMBER_OF_CORES)) { > > shard_count = std::min(MAX,

On Fri, Apr 18, 2014 at 11:44 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > On Fri, Apr 18, 2014 at 11:32 AM, Dmitry Vyukov <dvyukov at google.com>wrote: > >> On Fri, Apr 18, 2014 at 11:13 AM, Dmitry Vyukov <dvyukov at google.com>wrote: >> >>> Hi, >>> >>> This is long thread, so I will combine several comments into single

----- Original Message ----- > From: "Daniel Berlin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Joerg Sonnenberger" <joerg at britannica.bec.de>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Thursday, January 14, 2016 10:38:10 AM > Subject: Re: [llvm-dev] High memory use and LVI/Correlated Value > Propagation > On

Sorry, by debug build I actually meant asserts enabled.  Thus, this issue can show up in either a debug or release build, if asserts are enabled. On 10/26/2017 4:05 PM, Chad Rosier via llvm-dev wrote: > > Chandler/All, > > We've just started testing the new pass manager this week and we ran > into a 548x slowdown (i.e., 6.28s to 3443.83s) for one of the files > from

What are the limitations on size of matrix for MDS functions? steve -- Steve Antos Priva-Technologies 847-640-9020 x3114 cell (540)409-1231 [[alternative HTML version deleted]]

From: jypuppy36@hotmail.com To: r-help-bounces@r-project.org Subject: R programing help-newton iterations for the square root Date: Tue, 7 Dec 2010 12:00:01 -0800 NEWTON ITERATIONS FOR THE SQUARE ROOT Newton iterations to find the root of a real valued function f , i.e. a number x for which f (x) = 0, are of the form Example. To find the square root of a positive number y we can use

On 23/11/2012, at 5:46 PM, Sean Silva wrote: > Adding LLVMdev, since this is intimately related to the optimization passes. > >> I think this is roughly because some function level optimisations are >> worse than O(N) in the number of instructions. > > Please profile this and mail llvmdev regarding passes with > significantly superlinear behavior (e.g. O(n^2)). My

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Krzysztof Parzyszek via llvm-dev > Sent: Monday, June 12, 2017 1:24 PM > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Open bug count passes 10,000 mark > > On 6/12/2017 3:18 PM, Robinson, Paul via llvm-dev wrote: > > > > I have been tracking this

Hi, I am new to R, and as a first exercise, I decided to try to implement an XIRR function using the secant method. I did a quick search and saw another posting that used the Bisection method but wanted to see if it was possible using the secant method. I would input a Cash Flow and Date vector as well as an initial guess. I hardcoded today's initial date so I could do checks in Excel.

On 23/11/2012, at 8:28 PM, David Tweed wrote: > Firstly I don't think TeX does pre-estimation of work, it's just the > standard stepwise "refinement stuff". I didn't mean that example to be taken so literally. When TeX formats a paragraph, it has to decide where to put line breaks. Breaking a line on a space has less badness that hyphenating a word. If I recall

I'm reading a file and using the file to populate a data frame. The way the file is laid out, I need to fill in the data frame one row at a time. When I start reading my file, I don't know how many rows I will need. It's on the order of a million. Being mindful of the time expense of reallocation, I decided on a strategy of doubling the data frame size every time I needed to expand

Hi all, with the current trunk I have two major cases where clang needs more than 2GB memory for compiling programs with -O2. One is related to GVN and MemoryDependenceAnalysis and has a pending patch. The other is related to the Correlated Value Propagation and Lazy Value Information cache. Attached is a heap profile for one of the relevant test cases. Looking at the sources, I don't see any

I have noticed that LLVM doesn't seem to "like" large functions, as a general rule. Admittedly, my experience is similar with gcc, so I'm not sure it's something that can be easily fixed. And I'm probably sounding like a broken record, because I have said this before. My experience is that the time it takes to compile something is growing above linear with size of

On 23.11.2012, at 15:12, john skaller <skaller at users.sourceforge.net> wrote: > > On 23/11/2012, at 5:46 PM, Sean Silva wrote: > >> Adding LLVMdev, since this is intimately related to the optimization passes. >> >>> I think this is roughly because some function level optimisations are >>> worse than O(N) in the number of instructions. >>