On Tue, Jul 13, 2010 at 12:03 PM, Przemek Klosowski
wrote:
> On 07/13/2010 11:55 AM, Brandon Lozza wrote:
>
>> I'm going to keep a personal note of the apps which do perform faster
>> and grab the src rpm's so that I can compile them myself with LTO.
>
> Jakub Jelinek said that "LTO isn't really u
On Thu, Jul 08, 2010 at 06:17:49PM -0700, Roland McGrath wrote:
> It's pretty hard to imagine what you could preserve across builds of
> nontrivially nonidentical source trees that would continue to line up at
> the basic block level where it's meaningful to the compiler. Perhaps you
> could do so
On Fri, Jul 09, 2010 at 12:28:46PM -0400, Al Dunsmuir wrote:
> I would suggest doing PGO for the following:
The kernel?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packag
On 07/13/2010 11:55 AM, Brandon Lozza wrote:
> I'm going to keep a personal note of the apps which do perform faster
> and grab the src rpm's so that I can compile them myself with LTO.
Jakub Jelinek said that "LTO isn't really usable in 4.5."
--
devel mailing list
devel@lists.fedoraproject.org
On Tue, Jul 13, 2010 at 11:55:15AM -0400, Brandon Lozza wrote:
> I'm going to keep a personal note of the apps which do perform faster
> and grab the src rpm's so that I can compile them myself with LTO.
Remember that currently LTO doesn't play well with debug info,
for C sometimes somewhat usable
On Tue, Jul 13, 2010 at 10:15 AM, Pekka Pietikainen wrote:
> On Thu, Jul 08, 2010 at 11:31:09AM -0400, Brandon Lozza wrote:
>> A mass rebuild would be recommended as the new compiler will produce faster
>> code. I believe everything will benefit and it's worth looking into. For
>> example I notice
On Thu, Jul 08, 2010 at 11:31:09AM -0400, Brandon Lozza wrote:
> A mass rebuild would be recommended as the new compiler will produce faster
> code. I believe everything will benefit and it's worth looking into. For
> example I noticed a significant difference on the OpenSUSE distro when GCC was
Th
On Sat, Jul 10, 2010 at 7:06 AM, drago01 wrote:
>>> - Helper routines used by yum to extract dependencies
>>>
>>> - X-Windows server and libraries used for 2D and 3D display such as
>>> opengl, compiz, etc.
>> and ghostscript, poppler, ...
>> Everyone will easily suggest Firefox and OpenOffice.
2010/7/11 drago01 :
> On Sun, Jul 11, 2010 at 6:39 PM, Rudolf Kastl wrote:
>> 2010/7/10 drago01 :
>>> On Sat, Jul 10, 2010 at 12:35 PM, Roberto Ragusa
>>> wrote:
Al Dunsmuir wrote:
> I would suggest doing PGO for the following:
>
> - Compression-type utilities (gz, zip,
On Sun, Jul 11, 2010 at 6:39 PM, Rudolf Kastl wrote:
> 2010/7/10 drago01 :
>> On Sat, Jul 10, 2010 at 12:35 PM, Roberto Ragusa
>> wrote:
>>> Al Dunsmuir wrote:
>>>
I would suggest doing PGO for the following:
- Compression-type utilities (gz, zip, unzip, 7zip, etc),
2010/7/10 drago01 :
> On Sat, Jul 10, 2010 at 12:35 PM, Roberto Ragusa
> wrote:
>> Al Dunsmuir wrote:
>>
>>> I would suggest doing PGO for the following:
>>>
>>> - Compression-type utilities (gz, zip, unzip, 7zip, etc),
>>> especially those libraries used by RPM to generate/process delta
On Sat, Jul 10, 2010 at 12:35 PM, Roberto Ragusa wrote:
> Al Dunsmuir wrote:
>
>> I would suggest doing PGO for the following:
>>
>> - Compression-type utilities (gz, zip, unzip, 7zip, etc),
>> especially those libraries used by RPM to generate/process deltas.
>
> and encryption stuff: op
On Thu, Jul 8, 2010 at 3:43 AM, Jakub Jelinek wrote:
> On Thu, Jul 08, 2010 at 12:54:35PM +0530, Rahul Sundaram wrote:
>> Do you plan on doing a mass rebuild?
>
> I don't think it is necessary, at least not for the reason of a compiler
> upgrade. The mass rebuilds are usually done when we have so
Al Dunsmuir wrote:
> I would suggest doing PGO for the following:
>
> - Compression-type utilities (gz, zip, unzip, 7zip, etc),
> especially those libraries used by RPM to generate/process deltas.
and encryption stuff: openssl, openssh, md5sum, sha1sum, ...
and data intensive stuff: rs
> > Unresolved regressions
> > --
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16353
> > Subject : 2.6.35 regression
> > Submitter : Zeev Tarantov
> > Date: 2010-07-05 13:04 (4 days old)
> > Message-ID :
> > References
On Thu, 2010-07-08 at 17:51 -0700, Ulrich Drepper wrote:
> Perhaps the best that can done is providing an example but I guess every
> package needs to have its own way implemented.
FWIW, fired up with enthusiasm I splatted a double-build
profile-generate and profile-use into hunspell as an example
On Fri, 9 Jul 2010 12:28:46 -0400
Al Dunsmuir wrote:
...snip...
> - All programs measured under the Phoronix benchmarks. If we don't,
> all we do is guarantee easy ways for other distributions to beat us.
Sadly, I don't think there are many phoronix benchmarks where they use
our compiled s
Hello Chen,
Thursday, July 8, 2010, 12:05:43 PM, Jakub Jelinek wrote:
> 2010/7/8 Jakub Jelinek :
>> Generally, much better speedup can be achieved by using PGO
>> (-fprofile-generate, run on some testsuite, -fprofile-use).
>> GCC itself is built that way for several years, but it would be useful
Hello Chen,
Thursday, July 8, 2010, 12:05:43 PM, Chen Lei wrote:
> 2010/7/8 Jakub Jelinek :
>> Generally, much better speedup can be achieved by using PGO
>> (-fprofile-generate, run on some testsuite, -fprofile-use).
>> GCC itself is built that way for several years, but it would be useful if
>>
On Fri, Jul 09, 2010 at 05:50:24PM +0200, Jakub Jelinek wrote:
> On Fri, Jul 09, 2010 at 11:36:04AM -0400, David Malcolm wrote:
> > Python has a benchmarking suite that tries to reflect real-world
> > workloads, and I've filed
> > https://bugzilla.redhat.com/show_bug.cgi?id=613045
> > "RFE: Add pro
On Fri, Jul 09, 2010 at 11:36:04AM -0400, David Malcolm wrote:
> Python has a benchmarking suite that tries to reflect real-world
> workloads, and I've filed
> https://bugzilla.redhat.com/show_bug.cgi?id=613045
> "RFE: Add profile guided optimization to our builds of Python 2"
> and https://bugzill
On Fri, 2010-07-09 at 00:00 -0700, Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/08/2010 06:44 PM, Dave Airlie wrote:
> > So I'd package up stuff, do a koji build, download it, run my
> > representative test suite, upload the result and do another build.
>
> As
On Thu, 2010-07-08 at 17:51 -0700, Ulrich Drepper wrote:
> That's not so easy to generalize. As Jakub wrote, you need some form of
> workload. After the binaries are built this workload has to be
> executed. How to do that cannot really be summarized. Some packages
> might need to be installed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/08/2010 06:44 PM, Dave Airlie wrote:
> So I'd package up stuff, do a koji build, download it, run my
> representative test suite, upload the result and do another build.
As Roland wrote, if you cannot provide a self-contained RPM build
process i
On Thu, Jul 08, 2010 at 08:48:29PM -0700, Roland McGrath wrote:
> > This is accurate.
> >
> > the files must be identical if they are not elf binaries.
>
> I think the .py[co] files embed timestamps or something like that.
> So they are nonidentical but not actually different at all.
The embedde
> This is accurate.
>
> the files must be identical if they are not elf binaries.
I think the .py[co] files embed timestamps or something like that.
So they are nonidentical but not actually different at all.
You want all python to be in things that you don't want two of, AFAICT.
In general one
On Thu, 2010-07-08 at 22:36 -0400, Toshio Kuratomi wrote:
> On Thu, Jul 08, 2010 at 06:32:37PM -0700, Adam Williamson wrote:
> >
> > I think it probably doesn't 'work', in the sense that you can't install
> > the f13 -devel i686 and x86-64 packages together, but in another sense
> > that's fine, a
On Thu, 2010-07-08 at 22:36 -0400, Toshio Kuratomi wrote:
> On Thu, Jul 08, 2010 at 06:32:37PM -0700, Adam Williamson wrote:
> >
> > I think it probably doesn't 'work', in the sense that you can't install
> > the f13 -devel i686 and x86-64 packages together, but in another sense
> > that's fine, a
On Thu, Jul 08, 2010 at 06:32:37PM -0700, Adam Williamson wrote:
>
> I think it probably doesn't 'work', in the sense that you can't install
> the f13 -devel i686 and x86-64 packages together, but in another sense
> that's fine, as I don't think our multilib policy says you _will_ be
> able to ins
> So I'd package up stuff, do a koji build, download it, run my
> representative test suite, upload the result and do another build.
Oh. Well, sure then. What was the question? You don't want much of it
automated at all then, but you're asking about the little?
The profiled build will litter
On Thu, 2010-07-08 at 18:17 -0700, Roland McGrath wrote:
> > Is there a way to include pre-packaged workloads analysis? I realise
> > we'd have to regenerate these somehow possible for each compiler update
> > (not sure how the files look).
>
> What a "workload" means to the compiler is all the re
On Thu, 2010-07-08 at 09:18 +0200, Jakub Jelinek wrote:
> Hi!
>
> F14 now has gcc-4.5-RH compiler instead of 4.4-RH.
> For the changes (especially user visible ones), see
> http://gcc.gnu.org/gcc-4.5/changes.html
> (though the list contains even many features that have been
> backported to 4.4-RH.
> I dunno, I'm not a multilib expert, just an asshole telling you to make
> it work =)
I'm no expert on the rpm part of the world either, but I have seen many
things and I'll yell some out from the corner now and then.
> I think it probably doesn't 'work', in the sense that you can't install
> th
On Thu, 2010-07-08 at 18:21 -0700, Roland McGrath wrote:
> > This has a multilib problem. libstdc++ has a few of the same files in
> > both the x86-64 and i686 packages, making it impossible to have both
> > installed (which should be possible, and is in F13).
> >
> > The files are a few Python bi
> This has a multilib problem. libstdc++ has a few of the same files in
> both the x86-64 and i686 packages, making it impossible to have both
> installed (which should be possible, and is in F13).
>
> The files are a few Python bits
> in /usr/share/gcc-4.5.0/python/libstdcxx/v6/ .
Would it work
> Is there a way to include pre-packaged workloads analysis? I realise
> we'd have to regenerate these somehow possible for each compiler update
> (not sure how the files look).
What a "workload" means to the compiler is all the results of all the
conditional branches in the compiled code. What s
On Thu, 2010-07-08 at 09:18 +0200, Jakub Jelinek wrote:
> Hi!
>
> F14 now has gcc-4.5-RH compiler instead of 4.4-RH.
> For the changes (especially user visible ones), see
> http://gcc.gnu.org/gcc-4.5/changes.html
> (though the list contains even many features that have been
> backported to 4.4-RH.
On Thu, 2010-07-08 at 17:51 -0700, Ulrich Drepper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/08/2010 09:05 AM, Chen Lei wrote:
>
> > It seems MeeGo builds core packages by using PGO already. Is there
> > anyone who would like to volunteer to write a packaging guideline
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/08/2010 09:05 AM, Chen Lei wrote:
> It seems MeeGo builds core packages by using PGO already. Is there
> anyone who would like to volunteer to write a packaging guideline
> about using PGO?
That's not so easy to generalize. As Jakub wrote, you
On 7/8/10, Adam Williamson wrote:
> On Thu, 2010-07-08 at 11:31 -0400, Brandon Lozza wrote:
>
> > A mass rebuild would be recommended as the new compiler will produce
> > faster code. I believe everything will benefit and it's worth looking
> > into. For example I noticed a significant differenc
On Thu, 2010-07-08 at 11:31 -0400, Brandon Lozza wrote:
> A mass rebuild would be recommended as the new compiler will produce
> faster code. I believe everything will benefit and it's worth looking
> into. For example I noticed a significant difference on the OpenSUSE
> distro when GCC was upgrade
2010/7/8 Jakub Jelinek :
> Generally, much better speedup can be achieved by using PGO
> (-fprofile-generate, run on some testsuite, -fprofile-use).
> GCC itself is built that way for several years, but it would be useful if
> other performance sensitive packages were built that way too, assuming t
On Thu, 2010-07-08 at 11:31 -0400, Brandon Lozza wrote:
> A mass rebuild would be recommended as the new compiler will produce
> faster code. I believe everything will benefit and it's worth looking
> into. For example I noticed a significant difference on the OpenSUSE
> distro when GCC was upgrade
On Thu, Jul 08, 2010 at 11:31:09AM -0400, Brandon Lozza wrote:
> A mass rebuild would be recommended as the new compiler will produce faster
> code. I believe everything will benefit and it's worth looking into. For
> example I noticed a significant difference on the OpenSUSE distro when GCC
> was
A mass rebuild would be recommended as the new compiler will produce faster
code. I believe everything will benefit and it's worth looking into. For
example I noticed a significant difference on the OpenSUSE distro when GCC
was upgraded and they repackaged their software with it in their developmen
On Thu, 2010-07-08 at 09:18 +0200, Jakub Jelinek wrote:
> Hi!
>
> F14 now has gcc-4.5-RH compiler instead of 4.4-RH.
icu test-suite fails in koji with 4.5.0, but passes locally with 4.4.4.
If I get a chance after fiddling with all the licence foo I'll see if
its truly gcc related or some specific
On Thu, Jul 08, 2010 at 12:54:35PM +0530, Rahul Sundaram wrote:
> On 07/08/2010 12:48 PM, Jakub Jelinek wrote:
> > F14 now has gcc-4.5-RH compiler instead of 4.4-RH.
> > For the changes (especially user visible ones), see
> > http://gcc.gnu.org/gcc-4.5/changes.html
>
> Do you plan on doing a mass
On 07/08/2010 12:48 PM, Jakub Jelinek wrote:
> Hi!
>
> F14 now has gcc-4.5-RH compiler instead of 4.4-RH.
> For the changes (especially user visible ones), see
> http://gcc.gnu.org/gcc-4.5/changes.html
Do you plan on doing a mass rebuild?
Rahul
--
devel mailing list
devel@lists.fedoraproject.or
On 07/08/2010 12:48 PM, Jakub Jelinek wrote:
> Hi!
>
> F14 now has gcc-4.5-RH compiler instead of 4.4-RH.
> For the changes (especially user visible ones), see
> http://gcc.gnu.org/gcc-4.5/changes.html
Do you plan on doing a mass rebuild?
Rahul
--
devel mailing list
devel@lists.fedoraproject.or
Hi!
F14 now has gcc-4.5-RH compiler instead of 4.4-RH.
For the changes (especially user visible ones), see
http://gcc.gnu.org/gcc-4.5/changes.html
(though the list contains even many features that have been
backported to 4.4-RH. I had to backport even over 100 of changes
that were backported to 4
50 matches
Mail list logo
