similar to: [LLVMdev] Forward: Discussion about custom memory allocators for STL

On 2008-05-18, at 04:36, Roman Levenstein wrote: > Chris Lattner wrote: > >> We have already imported pieces of boost. > > BTW, which ones? > >> The general rule is that it is ok to use specific pieces, > > Totally agree with you. > >> but they have to be converted to the LLVM style and way of doing >> things. Also, things with huge chains of

Hi, There is a discussion thread on llvm-commits list about a possibility of using custom memory allocators for STL to improve the performance and reduce the memory pressure of STL containers, e.g. std::set. I thought that this discussion may be interesting for a wider audience and therefore I re-post the messages on llvm-dev as well. It would be interesting to hear what others think about -

On Sunday 18 May 2008 09:02, Gordon Henriksen wrote: > As for the 340, for an highly replaceable library comprising 1% of our > LOC to bloat the source file count in our tree by 20%—after using a > script to extract a perfect transitive dependency closure—well, I was > on the verge of tossing it overboard. I can't blame Chris for his > reticence to add such nonsense to LLVM, as

Roman Levenstein wrote: > - possibility of using 3rd party libs like Boost (or their parts) in LLVM > There is a thread elsewhere on this mailing list illustrating how important it is for the maintainers of LLVM to keep LLVM usable in a commercial environment. As such, I would strongly recommend avoiding Boost as it has a bad name in some quarters, regardless of its license, for

On Sun, May 18, 2008 at 7:59 PM, Dominic Hamon <dom.hamon at gmail.com> wrote: > It has also been mentioned that it is also true for LLVM itself, and it > is. However, the amount of code in LLVM, and the specific nature of its > usage and what it is for lends itself to better contribution tracking > immediately. Boost is a nebulous piece of software with a wide range of >

me22 wrote: > On Sat, May 17, 2008 at 9:28 PM, Dominic Hamon <dom.hamon at gmail.com> wrote: > >> There is a thread elsewhere on this mailing list illustrating how >> important it is for the maintainers of LLVM to keep LLVM usable in a >> commercial environment. As such, I would strongly recommend avoiding >> Boost as it has a bad name in some quarters,

Dominic Hamon <dom.hamon at gmail.com> writes: [snip] > Boost as it has a bad name in some quarters, regardless of its license, > for including work that is not safe for commercial users to take on. Ie, > there are so many contributors, and their contribution tracking has been > poor in the past, that business affairs departments in commercial > companies, and their

On Sat, May 17, 2008 at 9:28 PM, Dominic Hamon <dom.hamon at gmail.com> wrote: > There is a thread elsewhere on this mailing list illustrating how > important it is for the maintainers of LLVM to keep LLVM usable in a > commercial environment. As such, I would strongly recommend avoiding > Boost as it has a bad name in some quarters, regardless of its license, > for including

Am Sonntag, den 18.05.2008, 20:39 -0400 schrieb me22: > On Sun, May 18, 2008 at 7:59 PM, Dominic Hamon <dom.hamon at gmail.com> wrote: > > It has also been mentioned that it is also true for LLVM itself, and it > > is. However, the amount of code in LLVM, and the specific nature of its > > usage and what it is for lends itself to better contribution tracking > >

Hi All, I am in the process of writing an R extension in c++ and am using several STL containers (e.g., vector<double>, map<int, double>, multimap<int, double>). I make sure to clear all these containers at the end of the .Call. Everything compiles and runs just fine, but I'm a bit worried since I haven't found any other packages that use STL. So, my question: is it

Hello, I was looking at how the memory for MachineBasicBlocks is managed and something seems strange. On one hand, a MachineFunction uses a recycling allocator to create and destroy MBBs without costly heap allocation (the same is done for MachineInstrs, MachineOperands, etc.). On the other hand, each MBB also has a number of STL vectors within it. For example, for Predecessors, Successors,

Hi, I try to figure out what the stl-function exactly do. I was reading the paper by Cleveland et al. (1990) and tested some features of stl (the ability to decompose time series with missing values and the robustness feature). I tried the following: > data(co2) > co2.na <- co2 > is.na(co2.na[c(50, 100)]) <- TRUE > plot(stl(co2.na, s.window = 12, na.action = na.exclude)) With

Hi there, My name is Renan X. Cortes, student of Statistics, from south of Brazil, and I'd like to ask you a few questions about decomposition of time series. In R, when I fit the decomposition using the "stl" function, an object is returned when ask the summary of the fit, called STL.seasonal (%), STL.trend (%) and STL.remainder (%). Once the decomposition is additive,

I am trying to understand the nuances of STL (seasonal trend decomposition with loess) based on William Cleveland's (and others?) original development. I do not understand the specification or use of "frequency components" or equivalent "low-pass filter" components in the stl() function. I have run the stl() function on a standard example data (co2) in both S-Plus and

2009/10/18 Oleg Knut <oleg77 at gmail.com>: > Maybe some of you can guide me on how to do following operations: >  1) prevent system calls >  2) memory allocation management (set some limits that can't be used > by JIT) >  3) CPU power limiting Hi Oleg, This is totally system dependent, it'd be *very* hard to do it multi-platform. On Unix, a good part of it is

I am running R 1.2.2 under Linux. When using the function stl in the ts library, how can I save the seasonal component? What I would like was something like: library(ts) data(nottem) data.stl <- stl(nottem, "per") x <- data.stl$sea This what I get: > x NULL I would, however, like to store in x the seasonal component. Thanks in advance. Francisco. -- Francisco

Dear helpeRs, Is it possible to change the shading colour of the range bars in the plot generated by plot.stl? By default they are grey, but I would prefer them white (I am preparing some graphics for a powerpoint presentation so I'm inverting all colours). As far as I can see plot.stl allows you to turn off the range bars, but nothing about the shading colour. I tried to look at the

Hi everyone. I'm having some troubles with STL function to decompose some data. My issue is that I have monthly data from September 2005 up to August 2010 i. e. 60 observations. I define it in the following way: *u<-read.csv("C:/CELEBREX.csv",header = TRUE) u.ts<-ts(u, start=c(2005,9), frequency=12) * The issue is that when I try to use stl(u.ts, 'per') Then the

Hi, This is actually a theory question. I'm a bit confused by the s.window parameter in the stl() function (which is in the ts package). For example, in the stl documentation it uses the nottem data, and then: plot(stl(nottem, s.win = 4, t.win = 50, t.jump = 1)) What does it mean by s.win = 4? Is it because a year has 4 seasons (namely Spring, Summer, Autumn and Winter)? If so will it

Currently I find that if I call stl() repeatedly I can use the weights array that is part of the stil output to detect outliers. I also find that if I repeatedly call stl() (replacing the outliers after each call) that the "remainder" portion of the stil output gets reduced. I am calling it like: for(.index in 1:4) { st <- stl(mt, s.window=frequency(mt), robust=TRUE)