Displaying 9 results from an estimated 9 matches for "0.9608".
Did you mean:
0.608
2016 Dec 17
19
llvm (the middle-end) is getting slower, December edition
First of all, sorry for the long mail.
Inspired by the excellent analysis Rui did for lld, I decided to do
the same for llvm.
I'm personally very interested in build-time for LTO configuration,
with particular attention to the time spent in the optimizer.
Rafael did something similar back in March, so this can be considered
as an update. This tries to include a more accurate high-level
2016 Dec 18
1
llvm (the middle-end) is getting slower, December edition
On Sat, Dec 17, 2016 at 6:39 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
>> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> First of all, sorry for the long mail.
>> Inspired by the excellent analysis Rui did for lld, I decided to do
>> the same for llvm.
>> I'm personally very
2016 Dec 18
0
llvm (the middle-end) is getting slower, December edition
> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> First of all, sorry for the long mail.
> Inspired by the excellent analysis Rui did for lld, I decided to do
> the same for llvm.
> I'm personally very interested in build-time for LTO configuration,
> with particular attention to the time spent in the optimizer.
>
2016 Dec 18
0
llvm (the middle-end) is getting slower, December edition
> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> First of all, sorry for the long mail.
> Inspired by the excellent analysis Rui did for lld, I decided to do
> the same for llvm.
> I'm personally very interested in build-time for LTO configuration,
> with particular attention to the time spent in the optimizer.
>
2016 Dec 18
0
llvm (the middle-end) is getting slower, December edition
On 12/17/2016 01:35 PM, Davide Italiano via llvm-dev wrote:
> First of all, sorry for the long mail.
> Inspired by the excellent analysis Rui did for lld, I decided to do
> the same for llvm.
> I'm personally very interested in build-time for LTO configuration,
> with particular attention to the time spent in the optimizer.
> Rafael did something similar back in March, so
2016 Dec 18
0
llvm (the middle-end) is getting slower, December edition
On Sat, Dec 17, 2016 at 1:35 PM, Davide Italiano via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> First of all, sorry for the long mail.
> Inspired by the excellent analysis Rui did for lld, I decided to do
> the same for llvm.
> I'm personally very interested in build-time for LTO configuration,
> with particular attention to the time spent in the optimizer.
>
2004 Jul 26
5
covariate selection in cox model (counting process)
Hello everyone,
I am searching for a covariate selection procedure in a cox model formulated
as a counting process.
I use intervals, my formula looks like coxph(Surv(start,stop,status)~
x1+x2+...+cluster(id),robust=T) where id is a country code (I study
occurence of civil wars from 1962 to 1997).
I'd like something not based on p-values, since they have several flaws for
this purpose.
I turned
2016 Dec 20
0
llvm (the middle-end) is getting slower, December edition
Hi Davide,
Thanks for the analysis, it's really interesting! And I'm really glad that we now put more and more attention at the compile time!
Just recently I've been looking into historical compile time data as well, and have had similar conclusions. The regressions you've found are probably caused by:
1) r289813 and r289855 - new matchers in InstCombine
2) r286814 and r288024 -
2009 Dec 01
5
Normal tests disagree?
If I have data that I feed into shapio.test and jarque.bera.test yet they seem to disagree. What do I use for a decision?
For my data set I have p.value of 0.05496421 returned from the shapiro.test and 0.882027 returned from the jarque.bera.test. I have included the data set below.
Thank you.
Kevin
"Category","Period","Residual"
"CHILD HATS, WIGS &