llvm dev - Feb 2015 - [LLVMdev] [cfe-dev] [3.6 Release] RC3 has been tagged

On Wed, Feb 18, 2015 at 3:01 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 18 February 2015 at 19:52, Jack Howarth
> <howarth.mailing.lists at gmail.com> wrote:
>> Assuming that the clang-omp
>> developers can find time to rebase their upstream tree on the new 3.6
>> release, I intend to do the same for the fink llvm36 packaging. So
>> yes, a stable compiler does matter to some folks.
>
> So it seems that you're one of the very few people that doesn't use
> ToT. Almost everyone else uses it and the progress of LLVM kind of
> assume you do.
>
I believe MacPorts uses the major llvm releases for their toolchain
these days as the older supported systems don't have access to the
latest Xcode (due to SDK deprecation).
> The past releases didn't mean much until we started doing the
> dot-releases, and even those didn't mean much in the first iterations.
> You can't blame people for not caring that much for something that so
> few people actually use it.
Well, I assumed that llvm releases were supposed to be more than just
glorified semi-annual snapshots.
>
> I think that buildbots make us rely a lot more on inter-release master
> branches than we should. Maybe once more OS distributions start
> relying on LLVM we'll have to match a more professional release cycle,
> but for now, we have very little reason to.
>
> I'm perfectly happy to open a bug for each one of that Phoronix
run's
> regressions and fix throughout the next six months...
>
> cheers,
> --renato

On Wed, Feb 18, 2015 at 3:10 PM, Jack Howarth
<howarth.mailing.lists at gmail.com> wrote:
> On Wed, Feb 18, 2015 at 3:01 PM, Renato Golin <renato.golin at
linaro.org> wrote:
>> On 18 February 2015 at 19:52, Jack Howarth
>> <howarth.mailing.lists at gmail.com> wrote:
>>> Assuming that the clang-omp
>>> developers can find time to rebase their upstream tree on the new
3.6
>>> release, I intend to do the same for the fink llvm36 packaging. So
>>> yes, a stable compiler does matter to some folks.
>>
>> So it seems that you're one of the very few people that doesn't
use
>> ToT. Almost everyone else uses it and the progress of LLVM kind of
>> assume you do.
>>
>
> I believe MacPorts uses the major llvm releases for their toolchain
> these days as the older supported systems don't have access to the
> latest Xcode (due to SDK deprecation).
>
>> The past releases didn't mean much until we started doing the
>> dot-releases, and even those didn't mean much in the first
iterations.
>> You can't blame people for not caring that much for something that
so
>> few people actually use it.
>
> Well, I assumed that llvm releases were supposed to be more than just
> glorified semi-annual snapshots.
>
Also doesn't FreeBSD use the standard major llvm releases for their
system compilers? Somehow, I doubt that they would be thrilled to have
to resort to svn trunk.
>>
>> I think that buildbots make us rely a lot more on inter-release master
>> branches than we should. Maybe once more OS distributions start
>> relying on LLVM we'll have to match a more professional release
cycle,
>> but for now, we have very little reason to.
>>
>> I'm perfectly happy to open a bug for each one of that Phoronix
run's
>> regressions and fix throughout the next six months...
>>
>> cheers,
>> --renato

On 18 February 2015 at 20:10, Jack Howarth
<howarth.mailing.lists at gmail.com> wrote:
> Well, I assumed that llvm releases were supposed to be more than just
> glorified semi-annual snapshots.
It's that time of the year that we get all together and run some tests
and benchmarks we normally don't run the rest of the year, but we stop
the analogy short of giving each other presents. :)

So far we've being pretty good at spotting regressions like that and
fixing them later, and people like Michael will keep us on our toes if
we deliver it again with the regression, or if we deviate too much
from GCC.

cheers,
--renato

On 18 February 2015 at 20:18, Jack Howarth
<howarth.mailing.lists at gmail.com> wrote:
> Also doesn't FreeBSD use the standard major llvm releases for their
> system compilers? Somehow, I doubt that they would be thrilled to have
> to resort to svn trunk.
AFAIK, they use some commit between releases that they know it's
stable for them, like everyone else.

It's not because people call it "3.6" that it was actually
extracted
from "release_36" branch at the "final" tag.

cheers,
--renato

On 18 Feb 2015, at 20:18, Jack Howarth <howarth.mailing.lists at
gmail.com> wrote:
> 
> Also doesn't FreeBSD use the standard major llvm releases for their
> system compilers? 
We do pull in releases, but Dimitry also cherry-picks bug fixes throughout the
life of each release.

David

On Wed, Feb 18, 2015 at 12:19 PM, Renato Golin <renato.golin at
linaro.org>
wrote:
> On 18 February 2015 at 20:10, Jack Howarth
> <howarth.mailing.lists at gmail.com> wrote:
> > Well, I assumed that llvm releases were supposed to be more than just
> > glorified semi-annual snapshots.
>
> It's that time of the year that we get all together and run some tests
> and benchmarks we normally don't run the rest of the year, but we stop
> the analogy short of giving each other presents. :)
>
> So far we've being pretty good at spotting regressions like that and
> fixing them later, and people like Michael will keep us on our toes if
> we deliver it again with the regression, or if we deviate too much
> from GCC.
>
> cheers,
> --renato
> _______________________________________________
>


By looking at some numbers only and say that "Performance increased" 
or
"Performance decreased" is not a correct way of decision making .

It is necessary to specify a set of programs which will be a representative
sample of real life usage population ( it is necessary to exceed at least
60 programs to be able to assume "Central Limit Theorem" is valid ,
i.e. ,
sample is from a "Normal Distribution" ) .


Then by using the SAME execution environment ( means the SAME programs
running in the computers , best is not to run any programs other than
compilation and running the program , the computers may be in any model ,
from 500 MHz to 5 GHz , with different operating systems )  .


After obtaining compilation times , they should be analysed by using a
convenient statistical package
to test equality of variances and equality of means by using   "Pair-wise
correlated values" .


Assume tests revealed that "Differences are not significant" , then to
say
that "There is a performance loss" is not correct .


If variances are different ( populations are not from the SAME distribution
) , either variability of computations are increased or decreased :
Decrease is good , increase requires inspection .



If means are different ( populations are not from the SAME distribution ) ,
either average time of computations are increased or decreased : Decrease
is good , increase requires inspection .


Repeat the above computations for -
- No optimization
- Optimizations applied


Then reasons should be checked one by one , for example :

(1) Assume a bug is corrected by introducing a check : Is it possible to
remove the corrections and keep the bug to increase the speed ? Obviously
NO .

(2) In one point , optimization is ignoring a feature , but it is not a bug
( assume optimization is not applied ) .

(3) During code generation , there are redundant parts which may be
eliminated .
This is not a bug , but slowing down computation , because the computed
values will not be affected .


(4) Instead letting the programs crash blindly some new checks are
introduced to prevent blind crashing : Is it necessary to eliminate such
checks .

Then , it will be decided which points need improvement , and which points
will be kept as it is .


Without doing such analyses , and pursuing a discussion on some pure
different numbers and making decisions will not contribute anything to
development of Clang/LLVM .


Thank you very much .

Mehmet Erol Sanliturk
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150218/79805e12/attachment.html>