11:26 a.m.
do we need to support legacy cpu's by i386 compilation?
i586 would make fedora faster even 3 times.
difference is noticeable.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
11:51 a.m.
2008/1/12 Jakub 'Livio' Rusinek <jakub.rusinek(a)gmail.com>:
do we need to support legacy cpu's by i386 compilation?
i586 would make fedora faster even 3 times.
difference is noticeable.
.....
where are your benchmarks for the "3 times faster" claim?
the i386 packages are already optimized for newer cpus (mtune vs. march)
where it makes sense to have i686 versions there are some (kernel, glibc)
12:06 p.m.
I've used openSUSE (i586) with the same configuration and packages installed
and eg. Firefox 3 was started in < 1 sec. I have no benchmarks but
everything runs faster and is more responsible.
Our optimalization does nothing compared to > i386 compilation.
2008/1/12, drago01 <drago01(a)gmail.com>:
2008/1/12 Jakub 'Livio' Rusinek <jakub.rusinek(a)gmail.com>:
> do we need to support legacy cpu's by i386 compilation?
> i586 would make fedora faster even 3 times.
> difference is noticeable.
.....
where are your benchmarks for the "3 times faster" claim?
the i386 packages are already optimized for newer cpus (mtune vs. march)
where it makes sense to have i686 versions there are some (kernel, glibc)
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
12:12 p.m.
On Sat, Jan 12, 2008 at 07:06:50PM +0100, Jakub 'Livio' Rusinek wrote:
I've used openSUSE (i586) with the same configuration and
packages installed
and eg. Firefox 3 was started in < 1 sec. I have no benchmarks but
everything runs faster and is more responsible.
Our optimalization does nothing compared to > i386 compilation.
I can only guess that there are many differences besides the arch
between suse and fedora. Did you try a more meaningfull test, for
instance rebuilding the firefox rpm as i586 and seeing what the gain is?
--
Pat
12:13 p.m.
Jakub 'Livio' Rusinek wrote:
I've used openSUSE (i586) with the same configuration and
packages
installed and eg. Firefox 3 was started in < 1 sec. I have no benchmarks
but everything runs faster and is more responsible.
I'm afraid you're going to have to come up with hard scientific evidence
to convince anyone. Firefox 3 startup is probably dominated by disk I/O
anyways (all those dynamic libraries it has to load). Still, It would be
a fun experiment to run. Compute the cold (i.e. just after boot) startup
time of firefox, then recompiles all of its dependencies (all the way
down to glibc) with i586, reboot, and recomputes. To be honest, I'd be
surprised if you had even one tenth of a second of difference.
-denis
12:27 p.m.
Don't be silly. Try some > i386 distro, and look at the difference.
About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot from
Mozilla's FTP.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
12:50 p.m.
Don't be silly. Try some > i386 distro, and look at the
difference.
The rule is: Anyone who proposes a change because of performance,
must supply *measurements* which support the change.
The measurements must be reproducible on other machines
by other members of the community, so the environment and
test procedure must be well-specified, too.
--
12:54 p.m.
On Sat, 2008-01-12 at 19:27 +0100, Jakub 'Livio' Rusinek wrote:
Don't be silly. Try some > i386 distro, and look at the
difference.
About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot
from Mozilla's FTP.
You're suggesting trying a completely different architecture... with
completely different features... and completely different build options?
http://en.wikipedia.org/wiki/Scientific_method
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
1:18 p.m.
2008/1/12, Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>:
On Sat, 2008-01-12 at 19:27 +0100, Jakub 'Livio' Rusinek wrote:
> Don't be silly. Try some > i386 distro, and look at the difference.
> About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot
> from Mozilla's FTP.
You're suggesting trying a completely different architecture... with
completely different features... and completely different build options?
http://en.wikipedia.org/wiki/Scientific_method
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
So I can say only one thing: "fedora does something in wrong,
performance-loss way".
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
1:33 p.m.
On Sat, 12 Jan 2008 20:18:34 +0100
"Jakub 'Livio' Rusinek" <jakub.rusinek(a)gmail.com> wrote:
So I can say only one thing: "fedora does something in wrong,
performance-loss way".
You could say that, but you'd be wrong.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
2:09 p.m.
2008/1/12, Jesse Keating <jkeating(a)redhat.com>:
On Sat, 12 Jan 2008 20:18:34 +0100
"Jakub 'Livio' Rusinek" <jakub.rusinek(a)gmail.com> wrote:
> So I can say only one thing: "fedora does something in wrong,
> performance-loss way".
You could say that, but you'd be wrong.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Try openSUSE 10.3. You'll see the difference between it and F8.
It's noticeable FASTER!
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
3:34 p.m.
2008/1/12, Patrice Dumas <pertusus(a)free.fr>:
On Sat, Jan 12, 2008 at 09:09:22PM +0100, Jakub 'Livio' Rusinek wrote:
> Try openSUSE 10.3. You'll see the difference between it and F8.
> It's noticeable FASTER!
Knowing why indeed would be interesting. But I guess it doesn't come
from the i386 versus i586 arch for rpm.
--
Pat
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
So where Fedora just... sucks? Don't tell me "everything in Fedora is
perfect". Fedora is slow. It's a fact.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
3:39 p.m.
2008/1/12, Patrice Dumas <pertusus(a)free.fr>:
On Sat, Jan 12, 2008 at 10:34:38PM +0100, Jakub 'Livio' Rusinek wrote:
> >
>
> So where Fedora just... sucks? Don't tell me "everything in Fedora is
> perfect". Fedora is slow. It's a fact.
If you want to know, search. And avoid coming with ideas, but with
facts.
--
Pat
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
You're funny...
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
4:01 p.m.
lør, 12 01 2008 kl. 22:39 +0100, skrev Jakub 'Livio' Rusinek:
2008/1/12, Patrice Dumas <pertusus(a)free.fr>:
On Sat, Jan 12, 2008 at 10:34:38PM +0100, Jakub 'Livio'
Rusinek wrote:
> >
>
> So where Fedora just... sucks? Don't tell me "everything in
Fedora is
> perfect". Fedora is slow. It's a fact.
If you want to know, search. And avoid coming with ideas, but
with
facts.
You're funny...
If it's a fact, it should be a piece of cake for you to provide evidence
in the form of hard numbers. As easy indeed as it was for drago01
provide numbers to show that you are wrong in your basic assessment (at
least in a some what simplistic test case).
There's the chain of analysis that is useful:
Is Fedora indeed performing slowly compared to distributions released in
the same time frame (Fedora 8 vs. OpenSuSE 10.3 or Ubuntu Gutsy)?
If yes, what is the specific problem area in terms of performance. How
do we test for this to avoid regressions, how do we fix it (if it's
fixable at all). Then we need to retest the system performance after the
change to see that it does not introduce a regression in another area.
You do not jump directly to a conclusion without evidence and then
insult contributors.
With all possible lack of respect,
David Nielsen
4:21 p.m.
With all possible lack of respect,
David Nielsen
I'm not talking with such people.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
9:39 p.m.
Jakub 'Livio' Rusinek wrote:
2008/1/12, Patrice Dumas <pertusus(a)free.fr
<mailto:pertusus@free.fr>>:
On Sat, Jan 12, 2008 at 10:34:38PM +0100, Jakub 'Livio' Rusinek wrote:
> >
>
> So where Fedora just... sucks? Don't tell me "everything in Fedora is
> perfect". Fedora is slow. It's a fact.
If you want to know, search. And avoid coming with ideas, but with
facts.
You're funny...
No, serious. And I think Patrice is willing to believe you when you say
Fedora feels slower than OpenSuSE. But, if it's real, and you're
motivated to see it change, stick with it, and *really* find out why it
is so. First prove it: find a representative test, measure it
objectively, and if Fedora is slower, find out why by further
measurement and testing. You can be part of the solution.
For example - the Linux Battery Life Toolkit (BLTK) has 6 representative
workloads - Idle, Reader, Office, DVD Player, SW Developer, and
3D-Gamer. Maybe that could be a place to start: tweak it to measure the
time for one run of an interesting workload on a fresh boot & login on
both platforms. (This may not be the right test; "feels faster" is
probably more of a latency/responsiveness thing than a total runtime
thing, but perhaps this gets you thinking in the right direction).
Show the numbers that prove your impression, and people will probably
get much more interested.
One thing I think SuSE does is more aggressive preloading of shared
libraries:
http://sourceware.org/ml/libc-alpha/2004-07/msg00135.html
Like anything, this has tradeoffs of course. But it's an example of one
difference worth investigating. (Incidentally, in that thread, Ulrich
asks for hard numbers to show the performance gain, if any. Detect a
theme here?) :)
-Eric
1:45 p.m.
2008/1/12 Jakub 'Livio' Rusinek <jakub.rusinek(a)gmail.com>:
So I can say only one thing: "fedora does something in wrong,
performance-loss way".
OK here is one synthetic benchmark (non real world) but it should show
you that compiling for a different arch does not automatically makes
things go faster:
benchmark used was "flops.c"
first run:
gcc flops.c -o flops -m32 -O2 -march=i386 -mtune=i686 -DUNIX
FLOPS C Program (Double Precision), V2.0 18 Dec 1992
Module Error RunTime MFLOPS
(usec)
1 -8.1208e-11 0.0171 816.4320
2 1.4704e-15 0.0195 358.7055
3 -3.8213e-15 0.0101 1676.3571
4 6.1151e-14 0.0102 1471.7699
5 -4.4419e-14 0.0184 1574.1210
6 7.7002e-15 0.0172 1683.3209
7 -6.6161e-13 0.0517 232.0156
8 2.2789e-14 0.0187 1606.4346
Iterations = 512000000
NullTime (usec) = 0.0000
MFLOPS(1) = 482.7594
MFLOPS(2) = 542.8299
MFLOPS(3) = 1017.2301
MFLOPS(4) = 1618.1922
----------------------------------------------------------
second run:
gcc flops.c -o flops -m32 -O2 -march=i686 -mtune=i686 -DUNIX
FLOPS C Program (Double Precision), V2.0 18 Dec 1992
Module Error RunTime MFLOPS
(usec)
1 -8.1208e-11 0.0172 812.6376
2 1.4704e-15 0.0196 357.9533
3 -3.8213e-15 0.0101 1677.3263
4 6.1151e-14 0.0102 1471.7699
5 -4.4419e-14 0.0184 1575.9585
6 7.7002e-15 0.0172 1682.3675
7 -6.6161e-13 0.0517 232.1120
8 2.2789e-14 0.0187 1603.4166
Iterations = 512000000
NullTime (usec) = 0.0000
MFLOPS(1) = 481.8683
MFLOPS(2) = 542.8753
MFLOPS(3) = 1016.6906
MFLOPS(4) = 1617.0692
------------------------------------------------------------
even thought not the topic here I have done a x86_64 run too:
gcc flops.c -DUNIX -o flops -O2
./flops
FLOPS C Program (Double Precision), V2.0 18 Dec 1992
Module Error RunTime MFLOPS
(usec)
1 4.0146e-13 0.0144 969.8444
2 -1.4166e-13 0.0163 430.2659
3 4.7184e-14 0.0091 1871.3076
4 -1.2557e-13 0.0083 1808.1842
5 -1.3800e-13 0.0302 960.4358
6 3.2380e-13 0.0158 1834.0442
7 -8.4583e-11 0.0433 276.9485
8 3.4867e-13 0.0303 991.5022
Iterations = 512000000
NullTime (usec) = 0.0000
MFLOPS(1) = 575.0329
MFLOPS(2) = 605.2412
MFLOPS(3) = 964.2780
MFLOPS(4) = 1434.2150
-----------------------------------------------------
Test machine was a Core 2 Duo T7400 running F8.
So as you can see here there is no virtually difference between i386 and i686.
x86_64 is faster in most cases but not always. (and its no way near "3
times faster")
So numbers prove what I (and others) said before ... "it feels faster"
isn't going to convince anyone or change anything.
4:31 p.m.
Jakub 'Livio' Rusinek wrote:
So I can say only one thing: "fedora does something in wrong,
performance-loss way".
I'm not sure if this is still the case, but I know SuSE used to not enable
synchronization in syslogd. Yes, synchronization slows down your logging, but
it also greatly improves the chances of having a record of why a system crashed,
which is important.
I don't mean this as a knock on SuSE, and I don't think that's why you're
seeing
this difference on your desktop, but it's a great example of how people with
different design priorities can make different, reasonable decisions that may
seem wrong to someone with the other priorities.
Performance is all about tradeoffs. If you actually analyze the problem, you
can usually design an intermediate solution that's good enough for people across
most of the spectrum. There will always be outliers with special needs, but you
can usually make Fedora (or openSuSE for that matter) satisfy them will a little
careful tweaking.
-- Chris
4:50 p.m.
2008/1/12, Chris Snook <csnook(a)redhat.com>:
Jakub 'Livio' Rusinek wrote:
> So I can say only one thing: "fedora does something in wrong,
> performance-loss way".
I'm not sure if this is still the case, but I know SuSE used to not enable
synchronization in syslogd. Yes, synchronization slows down your logging,
but
it also greatly improves the chances of having a record of why a system
crashed,
which is important.
I don't mean this as a knock on SuSE, and I don't think that's why
you're
seeing
this difference on your desktop, but it's a great example of how people
with
different design priorities can make different, reasonable decisions that
may
seem wrong to someone with the other priorities.
Performance is all about tradeoffs. If you actually analyze the problem,
you
can usually design an intermediate solution that's good enough for people
across
most of the spectrum. There will always be outliers with special needs,
but you
can usually make Fedora (or openSuSE for that matter) satisfy them will a
little
careful tweaking.
-- Chris
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora and openSUSE (there are openSUSE and SuSE - actuall spelling) are
both using rsyslog, the newer, modern system logger.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
9:09 a.m.
On Sat, 12 Jan 2008 23:50:59 +0100
"Jakub 'Livio' Rusinek" <jakub.rusinek(a)gmail.com> wrote:
Fedora and openSUSE (there are openSUSE and SuSE - actuall spelling)
are both using rsyslog, the newer, modern system logger.
Which still has the option to sync the writes to the logger so that you
have a record of what happened that doesn't get lost at a power
outage. Fedora uses rsyslog too, which if you looked you would have
noticed.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
2:17 p.m.
On 1/12/08, Jakub 'Livio' Rusinek <jakub.rusinek(a)gmail.com> wrote:
Don't be silly. Try some > i386 distro, and look at the difference.
About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot from
Mozilla's FTP.
I'm fairly pissed off that a 15 year old school boy bullies fedora-devel
list subscribers in the most annoying way not even mentioning the flow of
unqualified postings clogging my inbox. After taking a 'yellow card' on the
fedora-art list, Jakub seems to be eager to take another one here ..
https://www.redhat.com/archives/fedora-art-list/2007-November/msg00225.html
3:11 p.m.
2008/1/12, Joachim Frieben <joachim.frieben(a)googlemail.com>:
On 1/12/08, Jakub 'Livio' Rusinek <jakub.rusinek(a)gmail.com> wrote:
>
> Don't be silly. Try some > i386 distro, and look at the difference.
> About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot
> from Mozilla's FTP.
I'm fairly pissed off that a 15 year old school boy bullies fedora-devel
list subscribers in the most annoying way not even mentioning the flow of
unqualified postings clogging my inbox. After taking a 'yellow card' on the
fedora-art list, Jakub seems to be eager to take another one here ..
https://www.redhat.com/archives/fedora-art-list/2007-November/msg00225.html
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
So, unsubscribe yourself if you don't like something!
I just want Fedora to be fast, beautiful and yet powerful, but I see you
want to come back to C64 epoch...
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
5:51 p.m.
Jakub 'Livio' Rusinek wrote:
Don't be silly. Try some > i386 distro, and look at the
difference.
About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot from
Mozilla's FTP.
I've spent *considerable time* keeping fully optimized i686 mtune p4 -O3
compiled gentoo installed on a machine I also had Fedora rawhide with *my own
compiled and optimized i686 kernel and glibc*... the differences are minor at
best. I guarantee a i586 compiled SUSE install is not faster than that gentoo
build.
If you're really seeing that large a performance difference you need to be
considering legitimate sources of 'startup' time, such as already mentioned in
the thread... disk IO. How SUSE is choosing to link the libraries might be the
place to start. Are they prelinking? How. Did they maybe statically link
certain apps (like firefox that is used more than anything else)?
--
Andrew Farris <lordmorgul(a)gmail.com> <ajfarris(a)gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
4:21 p.m.
Jakub 'Livio' Rusinek wrote:
I've used openSUSE (i586) with the same configuration and
packages
installed and eg. Firefox 3 was started in < 1 sec. I have no benchmarks
but everything runs faster and is more responsible.
Our optimalization does nothing compared to > i386 compilation.
False. On modern processors, with most userspace code, building for i586
generates code with instruction scheduling that is *slower* than i386
instructions tuned for i686. This is why Fedora builds most packages as i386,
tuned for i686.
i586 really only makes sense for things like the kernel, glibc, JVMs, and
multimedia/hpc libraries that use MMX/SSE instructions. In these cases, i686
will usually be even better, though it occasionally makes sense to build with
i586 instructions and tune for i686 if you want to have one package that'll work
acceptably on i586 and work very well on i686.
On a typical desktop system, you'll never notice the difference between i386,
i586, and i686 packages except with high-performance graphics. Your experience
with openSUSE is interesting, but it is not related to compiler optimizations.
-- Chris
2008/1/12, drago01 <drago01(a)gmail.com
<mailto:drago01@gmail.com>>:
2008/1/12 Jakub 'Livio' Rusinek <jakub.rusinek(a)gmail.com
<mailto:jakub.rusinek@gmail.com>>:
> do we need to support legacy cpu's by i386 compilation?
> i586 would make fedora faster even 3 times.
> difference is noticeable.
.....
where are your benchmarks for the "3 times faster" claim?
the i386 packages are already optimized for newer cpus (mtune vs. march)
where it makes sense to have i686 versions there are some (kernel,
glibc)
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com <mailto:fedora-devel-list@redhat.com>
https://www.redhat.com/mailman/listinfo/fedora-devel-list
<https://www.redhat.com/mailman/listinfo/fedora-devel-list>
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
4:32 p.m.
I wonder if Fedora will be so fast some day. openSUSE really was faster on
my computer. But I don't know why.
I thinked it's compilation question.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
4:34 p.m.
Jakub 'Livio' Rusinek wrote:
I wonder if Fedora will be so fast some day. openSUSE really was
faster
on my computer. But I don't know why.
I thinked it's compilation question.
I'm skeptical, but I'll believe you if you have some data. I suggest starting
here:
http://people.redhat.com/wcohen/FedoraCore6OProfileTutorial.txt
-- Chris
6:05 p.m.
New subject: SuSE Project SUPER [Was Re: compilation architecture]
On Sat, 12 Jan 2008, Jakub 'Livio' Rusinek wrote:
I thinked it's compilation question.
There are much more probable things I think, SuSE had project SUPER
http://en.opensuse.org/SUPER
This project was closed in November last year because everything desirable
had been integrated into OpenSuSE.
It doesn't quite say which things they have integrated in the end sadly,
but if we ask them they can probably tell us. AFAICS they atleast have
these (correct me if wrong):
* They use a LOT of preloading, personalized per user with PePr so it
preloads the stuff you are most likely to use before you use it. Not
strange if you feel it is noticably faster, especially if you have lots
of RAM to preload things into.
* They are possibly using and maintaining some of the non-mainlined CK
patches. (i.e. a kernel responsiveness issue) but looks like they
actually don't because of lack of support. Swap prefetch is the usual
suspect key patch here.
* They default to using reiserfs of their disks which may result in
quicker loads. The mount it noatime,notail. This is QUICK.
* They prelink heavily. (And so do we I think.)
* They have all the same problems with sysvinit as we do.
* Yes and they do use -O3 -march i686 -mtune i686
.. probably more.
We could do all of these in Fedora of course. If they are using that PePr
thing, it would be interesting to test on Fedora, it looks like a cool
idea. A rootfs with reiserfs is customizable during install I think, but
I don't think it'll mount noatime,notail default, but that is easy to test
too.
Linus
7:03 p.m.
New subject: SuSE Project SUPER
On 2008/01/13 01:05 (GMT+0100) Linus Walleij apparently typed:
* They default to using reiserfs of their disks which may result in
quicker loads. The mount it noatime,notail. This is QUICK.
OpenSUSE switched from reiserfs to ext3 a release or two back.
OpenSUSE also supports upgrades that don't require repartitioning. Those with
traditional partitions >15, and backup and support strategies that depend on
them, have the option to continue using them, including for /.
--
"In the beginning was the Word, and the Word was
with God, and the Word was God." John 1:1 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://mrmazda.no-ip.com/
5:25 a.m.
New subject: SuSE Project SUPER [Was Re: compilation architecture]
* They default to using reiserfs of their disks which may result in
quicker loads. The mount it noatime,notail. This is QUICK.
Not in openSUSE. SuSE maybe uses Reiser, but default for openSUSE is
extended 2 or 3.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
6:14 p.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
On Sun, 13 Jan 2008, Linus Walleij wrote:
* They use a LOT of preloading,
I have now looked a bit closer at this, and it is *indeed* looking like a
major user-perceiveable thing, they preload pretty much everything and
also add other hints to the kernel of what may be expected to be used
soonish during boot, early-{x|g|k}dm and so forth.
It is rather crude: the actual mechanisms used are:
preload, source can be found here:
http://download.opensuse.org/distribution/10.3/repo/src-oss/suse/src/prel...
anyone knows wher SuSE keep their CVS/SVN/git of this?
Preload then uses readahead(2) or fadvice(2) to do the actual preloading.
Then preload is triggered from /etc/init.d scripts prepended with
ionice(1) like this:
/usr/bin/ionice -n2 /sbin/preload /etc/preload.d/gdm
Then as can be seen there are some app profiles in /etc/preload.d that
configure depending on used desktop what to preload, e.g. gdm/kdm,
Khelpcenter, OpenOffice, Firefox, Gimp (why?), etc.
All code and scripts are heavily SuSEified.
But has this really been under our radar for all this time? The entire
concept is like 2-3 years old, surely it must have been discussed before?
(Not that I heard it though...)
I don't have much time in my life but unless someone else starts looking
at this I will se if it can be Fedorified, target for F10 or so.
And thanks to Jakub for the hints given that allowed me to find this cool
thing...
Linus
6:34 p.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
I think Fedora did use some sort of preloading (well, atleast
Readahead), but it was decided that there was no tangible benefit from
it in the way it was being done.
8:47 p.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
Naheem Zaffar wrote:
I think Fedora did use some sort of preloading (well, atleast
Readahead), but it was decided that there was no tangible benefit from
it in the way it was being done.
Well, I looked into the readahead util for boot time, and it seemed to
hurt more than help. But ongoing preload that learns & adjusts to usage
patterns could help I'm sure, if done right
-Eric (while waiting for the one long boot of OS X 10.5 after a system
update, as it updates its caches for the *next* fast boot...)
12:44 a.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
On Jan 13, 2008 5:47 PM, Eric Sandeen <sandeen(a)redhat.com> wrote:
Well, I looked into the readahead util for boot time, and it seemed
to
hurt more than help. But ongoing preload that learns & adjusts to usage
patterns could help I'm sure, if done right
That wont help the critical first impression phase.. before
application usage patterns are established and people are feeling out
the release. And to be more blunt about it.. it won't help first
impression from the reviewers who run a distro just long enough to
figure what they like and don't like about it and want to get their
review in within the first week of a release.
How many people end up relying on the first impression of others to
form their own impressions? Adaptive methods that only help boot
speeds after multiple reboots with extended usage pattern trending
isn't really going to impact the impression people have one damn bit.
And it wont help livecds where state information is lost between reboots.
-jef
1:05 a.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
Jeff Spaleta wrote:
On Jan 13, 2008 5:47 PM, Eric Sandeen <sandeen(a)redhat.com>
wrote:
> Well, I looked into the readahead util for boot time, and it seemed to
> hurt more than help. But ongoing preload that learns & adjusts to usage
> patterns could help I'm sure, if done right
That wont help the critical first impression phase.. before
application usage patterns are established and people are feeling out
the release. And to be more blunt about it.. it won't help first
impression from the reviewers who run a distro just long enough to
figure what they like and don't like about it and want to get their
review in within the first week of a release.
How many people end up relying on the first impression of others to
form their own impressions? Adaptive methods that only help boot
speeds after multiple reboots with extended usage pattern trending
isn't really going to impact the impression people have one damn bit.
Uhm, yeah you're right. But it will help those who actually use the
distribution rather than toss it aside based off bad information they got from
someone else. There is certainly time and place to consider user first
impressions, but I hardly think its a good idea to filter an idea like the above
by ONLY that consideration.
And it wont help livecds where state information is lost between
reboots.
-jef
--
Andrew Farris <lordmorgul(a)gmail.com> <ajfarris(a)gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
12:57 p.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
On Sun, Jan 13, 2008 at 11:05:32PM -0800, Andrew Farris wrote:
Uhm, yeah you're right. But it will help those who actually use
the
distribution rather than toss it aside based off bad information they got
from someone else. There is certainly time and place to consider user
first impressions, but I hardly think its a good idea to filter an idea
like the above by ONLY that consideration.
I dunno. It seems like optimizing for startup time seems a misguided if
that's your goal. Starting stuff is a very low percentage of actual use,
especially with suspend/hibernate.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
2:17 p.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
Matthew Miller wrote:
On Sun, Jan 13, 2008 at 11:05:32PM -0800, Andrew Farris wrote:
> Uhm, yeah you're right. But it will help those who actually use the
> distribution rather than toss it aside based off bad information they got
> from someone else. There is certainly time and place to consider user
> first impressions, but I hardly think its a good idea to filter an idea
> like the above by ONLY that consideration.
I dunno. It seems like optimizing for startup time seems a misguided if
that's your goal. Starting stuff is a very low percentage of actual use,
especially with suspend/hibernate.
I'm aware its fairly low usage time, and not suggesting that any startup
optimization options be made at the cost of others (quite the opposite...).
What I was suggesting was that cached or otherwise optimized startup times are
nicer than slow ones, and it would not be wasted effort if some improvements
were made there. I like OSX's performance in that way alot.
So I wouldn't call it misguided, just lower priority. It sounds like you would
agree with me that no start time optimizations should have detrimental impact on
performance the rest of the time though. I would not want startup performance
caching to be going on while I'm trying to play a game for instance.
--
Andrew Farris <lordmorgul(a)gmail.com> <ajfarris(a)gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
2:38 p.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
2008/1/14, Andrew Farris <lordmorgul(a)gmail.com>:
Matthew Miller wrote:
> On Sun, Jan 13, 2008 at 11:05:32PM -0800, Andrew Farris wrote:
>> Uhm, yeah you're right. But it will help those who actually use the
>> distribution rather than toss it aside based off bad information they
got
>> from someone else. There is certainly time and place to consider user
>> first impressions, but I hardly think its a good idea to filter an idea
>> like the above by ONLY that consideration.
>
> I dunno. It seems like optimizing for startup time seems a misguided if
> that's your goal. Starting stuff is a very low percentage of actual use,
> especially with suspend/hibernate.
I'm aware its fairly low usage time, and not suggesting that any startup
optimization options be made at the cost of others (quite the
opposite...).
What I was suggesting was that cached or otherwise optimized startup times
are
nicer than slow ones, and it would not be wasted effort if some
improvements
were made there. I like OSX's performance in that way alot.
So I wouldn't call it misguided, just lower priority. It sounds like you
would
agree with me that no start time optimizations should have detrimental
impact on
performance the rest of the time though. I would not want startup
performance
caching to be going on while I'm trying to play a game for instance.
--
Andrew Farris <lordmorgul(a)gmail.com> <ajfarris(a)gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B
1DF3
No one now has, and no one will ever again get, the big picture. - Daniel
Geer
----
----
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Disabling unused services is the first step :> .
But hey, there's no second step :> .
We should just make something with Fedora to make it load and work faster...
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
1:39 a.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
The whole idea of preloading is crackrock. Its just hiding the problem,
at best.
The problem is the relentless march of bloat.
8:18 a.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
Callum Lerwick wrote:
The whole idea of preloading is crackrock. Its just hiding the
problem,
at best.
The problem is the relentless march of bloat.
One person's bloat is someone else's most needed feature - and there's
not a big problem these days with disk space to store unused options.
The problem is that the programs, their shared libraries, and config
files are splattered all over the disk and seeking to access them is
much slower than any other computer operation. There has to be some
trick that could be used either to pre-arrange all the files used in the
boot process together or load something early to pull in all of the
shared libs in a certain order, or have them preloaded in a swapfile or
something. If you change the goal to reducing disk seeks instead of
specifically preloading files it might be easier to accomplish a speedup.
--
Les Mikesell
lesmikesell(a)gmail.com
9:36 a.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
Les Mikesell wrote:
If you change the goal to reducing disk seeks instead of
specifically preloading files it might be easier to accomplish a speedup.
Just a note, seekwatcher is in F8 now ;)
Doesn't solve the problem but helps visualize it (and potential
solutions) at least.
-Eric
4:26 p.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
On Mon, Jan 14, 2008 at 08:18:55AM -0600, Les Mikesell wrote:
Callum Lerwick wrote:
> The whole idea of preloading is crackrock. Its just hiding the problem,
> at best.
>
> The problem is the relentless march of bloat.
>
One person's bloat is someone else's most needed feature - and there's not
a big problem these days with disk space to store unused options. The
problem is that the programs, their shared libraries, and config files are
splattered all over the disk and seeking to access them is much slower than
any other computer operation. There has to be some trick that could be
used either to pre-arrange all the files used in the boot process together
or load something early to pull in all of the shared libs in a certain
order, or have them preloaded in a swapfile or something. If you change
the goal to reducing disk seeks instead of specifically preloading files it
might be easier to accomplish a speedup.
From my point of view Callum has dead right. If I remember to Fedora
Core 4 or 5 it was significantly faster that F8. I remember day when I
turned off Compiz (maybe in F6) and said "Yeah, this is pretty fast".
Now I'm back in Compiz days but without Compiz. I don't think disk
usage is main problem (but in some cases yes - command yum update
always bother me in this case) generally. It looks like code become
slower and slower. And last team of really good programmers stucks
with improvements like preloading or compiler optimization. I'm not
against features. But We really should not add features and improve
stability without care about code speed and quality. Looks like I have
to switch from gnome to blackbox or fluxbox. This will solve my
problem. For now. And after two years I will start using runlevel 3 by
default...
Adam
--
Adam Tkac, Red Hat, Inc.
9:27 a.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
On Mon, Jan 14, 2008 at 11:26:58PM +0100, Adam Tkac wrote:
stability without care about code speed and quality. Looks like I
have
to switch from gnome to blackbox or fluxbox. This will solve my
problem. For now. And after two years I will start using runlevel 3 by
Adam: XFCE.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
3:03 a.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
On Sun, 13 Jan 2008, Jeff Spaleta wrote:
That wont help the critical first impression phase..
Agreed, what "other" OS:es (Vista, MacOS X) do is to come pre-installed,
i.e. it was booted once by a technician out of sight of the user. Then
they leverage on that.
They are of course doing much more agressive things than simple
preloading, more like suspend-to-disk, so the user actually more or less
resumes a pre-booted image customized for that machine at "boot" time.
I wonder if we could do that.
Linus
12:04 p.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
Linus Walleij wrote:
On Sun, 13 Jan 2008, Jeff Spaleta wrote:
> That wont help the critical first impression phase..
They are of course doing much more agressive things than simple
preloading, more like suspend-to-disk, so the user actually more or less
resumes a pre-booted image customized for that machine at "boot" time.
I wonder if we could do that.
I've considered this in the past, specifically for my mythtv home
theatre box.
The theory is that the 120G disk is a big data disk and has nothing to
do with the OS. The OS can live on a little usbflash.
Then, once thinking about it that way, and remembering the "repeatable
resume" feature from vmware, the following idea occurred to me-
Do just as you say- Do a livecd/liveusb style copy-on-write boot, where
the rootfs is read-only and changes go to a devicemapper snapshot. Then
do a hibernate during install, but save a copy of this golden hibernate
(swap) image along with a golden copy of the dm-snapshot. Also, make
the hibernate do an unmount of all data disks, and a resume do a
remounting of them.
Then, every power up of the system, would be a resume from the golden
hibernation image. With a post-resume script that mounts data disks,
resets the clock, and does whatever else is needed.
Really it is similar behavior as a vmware 'repeatable resume', but
non-virtual.
-dmc
9:05 a.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
søn, 13 01 2008 kl. 21:44 -0900, skrev Jeff Spaleta:
On Jan 13, 2008 5:47 PM, Eric Sandeen <sandeen(a)redhat.com>
wrote:
> Well, I looked into the readahead util for boot time, and it seemed to
> hurt more than help. But ongoing preload that learns & adjusts to usage
> patterns could help I'm sure, if done right
That wont help the critical first impression phase.. before
application usage patterns are established and people are feeling out
the release. And to be more blunt about it.. it won't help first
impression from the reviewers who run a distro just long enough to
figure what they like and don't like about it and want to get their
review in within the first week of a release.
How many people end up relying on the first impression of others to
form their own impressions? Adaptive methods that only help boot
speeds after multiple reboots with extended usage pattern trending
isn't really going to impact the impression people have one damn bit.
And it wont help livecds where state information is lost between reboots.
Would it be possible to pre-seed such an adaptive scheme.. we know what
we call on boot on a out of the box F9 final. Then as usage changes,
updates are issued and such the adaptive stuff would be able to keep the
preload system in as close to an optimal state?
That would seem to be the best of both worlds to me, but then again I'm
a self-admitted bumbling fool so what do I know.
- David
11:54 a.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
David Nielsen wrote:
søn, 13 01 2008 kl. 21:44 -0900, skrev Jeff Spaleta:
> On Jan 13, 2008 5:47 PM, Eric Sandeen <sandeen(a)redhat.com> wrote:
>> Well, I looked into the readahead util for boot time, and it seemed to
>> hurt more than help. But ongoing preload that learns & adjusts to usage
>> patterns could help I'm sure, if done right
> That wont help the critical first impression phase.. before
> application usage patterns are established and people are feeling out
> the release. And to be more blunt about it.. it won't help first
> impression from the reviewers who run a distro just long enough to
> figure what they like and don't like about it and want to get their
> review in within the first week of a release.
> How many people end up relying on the first impression of others to
> form their own impressions? Adaptive methods that only help boot
> speeds after multiple reboots with extended usage pattern trending
> isn't really going to impact the impression people have one damn bit.
>
> And it wont help livecds where state information is lost between reboots.
Would it be possible to pre-seed such an adaptive scheme.. we know what
we call on boot on a out of the box F9 final.
Personally of course, I think the long term ideal solution might end up
looking like my method with the livecd, percolating to normal usage.
I.e. my method does a precooking boot under qemu during livecd compose
to get file access order. Then creates the ext3 fsimage on the livecd
with that sorting order, by just copying the files in order. Then when
booting, preloads a chunk from the beginning of the fs into ram(tmpfs),
in one big long read. Then after boot is done, discards the chunk in
ram. (And the size of the chunk is determined by how much ram the
system has.)
This already has a benefit of minimizing seeks for disk based
installation once this ext3 image is copied to the hard drive, during a
normal livecd installation now.
The key to making this an ideal disk-boot solution, is that you need a
daemon which watches each boot, and resorts the blocks on the ext3fs
such that the earlier they are accessed relative to boot, the closer
they are to the outter rim of the filesystem. And then using the same
devicemapper ram caching trick during disk-boot as during livecd-boot.
Note, the above method doesn't minimize seeks like sorting does, it
removes them, as a huge chunk is read into ram with just a singe seek.
I suspect something similar had been discussed for disk-boot before, but
probably has been shelved because of the trouble of keeping the fs
sorted. I'm amazed no one else however noticed how easy it is to apply
to the livecd case, where seeks are drastically worse, and it is
drastically easier to get the filesystem sorted.
-dmc
Then as usage changes,
updates are issued and such the adaptive stuff would be able to keep
the
preload system in as close to an optimal state?
That would seem to be the best of both worlds to me, but then again I'm
a self-admitted bumbling fool so what do I know.
- David
7:25 p.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
Linus Walleij wrote:
Preload then uses readahead(2) or fadvice(2) to do the actual
preloading.
Then preload is triggered from /etc/init.d scripts prepended with
ionice(1) like this:
/usr/bin/ionice -n2 /sbin/preload /etc/preload.d/gdm
Then as can be seen there are some app profiles in /etc/preload.d that
configure depending on used desktop what to preload, e.g. gdm/kdm,
Khelpcenter, OpenOffice, Firefox, Gimp (why?), etc.
Incidentally, I think one of the main reasons the idea hasn't had much
discussion is that question of what applications are so crucial to preload like
this (gimp? laughable). Also, once an application is open its shared libraries
are cached for later, so for machines that stay on all day this has almost no
real benefit.
All code and scripts are heavily SuSEified.
But has this really been under our radar for all this time? The entire
concept is like 2-3 years old, surely it must have been discussed
before? (Not that I heard it though...)
I've seen discussion of this concept at least, maybe not that particular
implementation strategy. The idea should provide some better performance from
the user perspective... but the fact is the real wall time of getting your
machine cold booted, logged in, and an application fired up and usable should
not be much different overall. The real differences would be seen if you are
not sitting at the machine logging in asap for instance (the machine has nothing
to do until you log in, whereas with that preloading it might start loading up
firefox for you).
If you put this in the distro, you need good high-level configuration tools so
the user can choose what to preload or not, so you're not slowing the machine
unnecessarily, or packing all the free memory with libraries the user doesn't
intend to use that day/boot/login just to later unload it.
I wouldn't even want something learning my most used applications, just
something to configure what will get loaded and what won't.
--
Andrew Farris <lordmorgul(a)gmail.com> <ajfarris(a)gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
8:06 p.m.
New subject: Preloading [WAS: Re: SuSE Project SUPER]
Linus Walleij wrote:
On Sun, 13 Jan 2008, Linus Walleij wrote:
> * They use a LOT of preloading,
I have now looked a bit closer at this, and it is *indeed* looking like
a major user-perceiveable thing, they preload pretty much everything and
also add other hints to the kernel of what may be expected to be used
soonish during boot, early-{x|g|k}dm and so forth.
It is rather crude: the actual mechanisms used are:
...
FYI, I recently outlined a (livecd) preloading implementation completely
unrelated to all of this, which I'd bet money will speed up livecd boot
by at least 10% (perhaps much more).
My method involves a devicemapper trick, the primary benefit of which is
removing seeks. Theoretically this could help disk (non-cdrom) based
boots, but would require ext3 features for sorting that I don't think
currently exist, and the benefit would probably be <<5% anyway.
Still, something to look forward to. Now that my no-root-privs livecd
generator tool is looking pretty swank along with liveusb persistence, I
think I'm nearly ready to write the relatively few lines of bash code
required to implement "super device-mapper caching" (just plain d.m.c.
was already taken for something different that might help the disk boot
case as well)
http://www.redhat.com/archives/fedora-livecd-list/2008-January/msg00036.html
-dmc
2:14 p.m.
On Sat, 2008-01-12 at 18:51 +0100, drago01 wrote:
2008/1/12 Jakub 'Livio' Rusinek
<jakub.rusinek(a)gmail.com>:
> do we need to support legacy cpu's by i386 compilation?
> i586 would make fedora faster even 3 times.
> difference is noticeable.
.....
where are your benchmarks for the "3 times faster" claim?
the i386 packages are already optimized for newer cpus (mtune vs. march)
where it makes sense to have i686 versions there are some (kernel, glibc)
Lets get some real numbers in here. For a quick and dirty benchmark I'm
using OpenJPEG's MJ2 tools, I encode the speedway example using
"frames_to_mj2 -i Speedway.yuv -o Speedway.mj2 -I 1", then decode it.
I'm measuring the decode time. Tests were performed on a Mobile Celeron
1.3, which is P3 architecture.
Here it is with -march=i386 -mcpu=generic. That is, standard Fedora
flags:
Total decoding time: 21.14 seconds (9.5 fps)
With -march=i586 -mcpu=generic:
Total decoding time: 21.26 seconds (9.4 fps)
And -march=i686 -mcpu=generic:
Total decoding time: 20.45 seconds (9.8 fps)
So it is 0.54% *slower* when compiled for i586, which is unexpected and
strange, but such is gcc. I wouldn't expect much of a speed difference
compiling for i586, there was no major additions to the instruction set,
and we're already scheduling for modern processors.
Not quite "three times" faster, but 3.26% faster with i686. A major
addition to the i686 architecture was cmov, and gcc is actually very
aggressive about eliminating branching using cmovs, increasing
performance on modern deeply pipelined processors by eliminating
pipeline stalls.
And yes, cmov is technically optional, earlier VIA C3 processors, still
being sold, lack it. Completely dropping support for pre-i686 just isn't
an option yet.
If Smolt is to be believed, i686 machines are 99.43% (!) of all x86
machines. (Though I don't know if those pesky C3's are being counted as
i686 or i586 or what...) I think its safe to say the vast majority of
x86 systems out there have cmov, and are suffering with reduced
performance in order to cater to a minority of systems.
I suggest all key performance critical packages be made available in
both i386 and i686 versions. glibc and openssl already do this. Off the
top of my head, this would include Mesa, I know for a fact the majority
of Second Life runtime is actually consumed by T&L inside Mesa/DRI. From
what I understand, even Intel's latest chipsets lack hardware T&L. Makes
sense, it helps sell more multi-core Intel processors, and probably
helps consolidate power management.
Also, all multimedia codecs. Old sub-Ghz machines have a lot of trouble
playing the MPEG4 video that is common these days, and MythTV could use
all the help it can get. Not that the MPEG4 codecs are in Fedora
itself...
Not that any of this has anything to do with the "firefox startup is
slow" complaint that this thread has devolved into.
2:28 p.m.
2008/1/14, Callum Lerwick <seg(a)haxxed.com>:
On Sat, 2008-01-12 at 18:51 +0100, drago01 wrote:
> 2008/1/12 Jakub 'Livio' Rusinek <jakub.rusinek(a)gmail.com>:
> > do we need to support legacy cpu's by i386 compilation?
> > i586 would make fedora faster even 3 times.
> > difference is noticeable.
>
> .....
> where are your benchmarks for the "3 times faster" claim?
> the i386 packages are already optimized for newer cpus (mtune vs. march)
> where it makes sense to have i686 versions there are some (kernel,
glibc)
Lets get some real numbers in here. For a quick and dirty benchmark I'm
using OpenJPEG's MJ2 tools, I encode the speedway example using
"frames_to_mj2 -i Speedway.yuv -o Speedway.mj2 -I 1", then decode it.
I'm measuring the decode time. Tests were performed on a Mobile Celeron
1.3, which is P3 architecture.
Here it is with -march=i386 -mcpu=generic. That is, standard Fedora
flags:
Total decoding time: 21.14 seconds (9.5 fps)
With -march=i586 -mcpu=generic:
Total decoding time: 21.26 seconds (9.4 fps)
And -march=i686 -mcpu=generic:
Total decoding time: 20.45 seconds (9.8 fps)
So it is 0.54% *slower* when compiled for i586, which is unexpected and
strange, but such is gcc. I wouldn't expect much of a speed difference
compiling for i586, there was no major additions to the instruction set,
and we're already scheduling for modern processors.
Not quite "three times" faster, but 3.26% faster with i686. A major
addition to the i686 architecture was cmov, and gcc is actually very
aggressive about eliminating branching using cmovs, increasing
performance on modern deeply pipelined processors by eliminating
pipeline stalls.
And yes, cmov is technically optional, earlier VIA C3 processors, still
being sold, lack it. Completely dropping support for pre-i686 just isn't
an option yet.
If Smolt is to be believed, i686 machines are 99.43% (!) of all x86
machines. (Though I don't know if those pesky C3's are being counted as
i686 or i586 or what...) I think its safe to say the vast majority of
x86 systems out there have cmov, and are suffering with reduced
performance in order to cater to a minority of systems.
I suggest all key performance critical packages be made available in
both i386 and i686 versions. glibc and openssl already do this. Off the
top of my head, this would include Mesa, I know for a fact the majority
of Second Life runtime is actually consumed by T&L inside Mesa/DRI. From
what I understand, even Intel's latest chipsets lack hardware T&L. Makes
sense, it helps sell more multi-core Intel processors, and probably
helps consolidate power management.
Also, all multimedia codecs. Old sub-Ghz machines have a lot of trouble
playing the MPEG4 video that is common these days, and MythTV could use
all the help it can get. Not that the MPEG4 codecs are in Fedora
itself...
Not that any of this has anything to do with the "firefox startup is
slow" complaint that this thread has devolved into.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I have no idea, why Firefox 3 starts in Fedora so long and scrolls in smooth
mode so long (with hanging for a while). Maybe it's Mesa compilation issue.
Xorg? I don't know.
I can only say that I want Fedora to be stable as rock, powerful and
beautiful.
No matter how we can do it.
I sad my words few times and did nothing, it's true, but it's because I
didn't know what I could really do.
About compilation: preloading is probably making everything in openSUSE load
faster, but how to implement this in Fedora? I'll invesigate where's their
SVN/CVS/GIT/MNT/etc.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
2:38 p.m.
On Mon, Jan 14, 2008 at 02:14:02PM -0600, Callum Lerwick wrote:
using OpenJPEG's MJ2 tools, I encode the speedway example using
"frames_to_mj2 -i Speedway.yuv -o Speedway.mj2 -I 1", then decode it.
Which is about the most extreme case you will find.
So it is 0.54% *slower* when compiled for i586, which is unexpected
and
strange, but such is gcc. I wouldn't expect much of a speed difference
compiling for i586, there was no major additions to the instruction set,
and we're already scheduling for modern processors.
586 has completely different scheduling pipelines wiht complex rules
Not quite "three times" faster, but 3.26% faster with i686.
A major
addition to the i686 architecture was cmov, and gcc is actually very
Current CPUs cmov is generally a lose.
both i386 and i686 versions. glibc and openssl already do this. Off
the
top of my head, this would include Mesa, I know for a fact the majority
Mesa already internally uses things like 3DNow. The Mesa folks would
I'm sure welcome more optimised paths and cpu tuned variants.
all the help it can get. Not that the MPEG4 codecs are in Fedora
itself...
MPEG4 is dominated by memory bandwidth so cache size is critical and
FSB, not compiler options.
Memory actually dominates most things today - and -Os is often the macro
scale win
3:05 p.m.
On Mon, 2008-01-14 at 14:14 -0600, Callum Lerwick wrote:
I suggest all key performance critical packages be made available in
both i386 and i686 versions. glibc and openssl already do this. Off the
top of my head, this would include Mesa, I know for a fact the majority
of Second Life runtime is actually consumed by T&L inside Mesa/DRI. From
what I understand, even Intel's latest chipsets lack hardware T&L. Makes
sense, it helps sell more multi-core Intel processors, and probably
helps consolidate power management.
915 does not have hardware vertex programs. 965 does though. 915 only
has fragment programs, which makes sense since that's the most bang for
the buck. 965 has both simply because it's a unified shader
architecture. It's not really a power management or a sales decision
either way, it's just what was easiest to build at the time.
Our Mesa builds already include 586+ assembly for many routines,
selected at runtime by processor inspection. I don't think they're
using anything newer than SSE2 yet, there might be something to be
gained from the newer ISA extensions. Patches gratefully accepted.
If you want to see if there's any benefit from an i686 Mesa build just
check it out from CVS and make local. Last time I looked the difference
was down in the noise region.
- ajax
4:21 p.m.
2008/1/14 Callum Lerwick <seg(a)haxxed.com>:
> Also, all multimedia codecs. Old sub-Ghz machines have a lot of trouble
> playing the MPEG4 video that is common these days, and MythTV could use
> all the help it can get. Not that the MPEG4 codecs are in Fedora
> itself...
Most (all) mpeg4 en-/decoders use hand written asm with runtime cpu
detection so adding compiler flags won't gain anything there.
6:57 a.m.
Callum Lerwick <seg(a)haxxed.com> wrote:
[...]
Not quite "three times" faster, but 3.26% faster with i686.
A major
addition to the i686 architecture was cmov, and gcc is actually very
aggressive about eliminating branching using cmovs, increasing
performance on modern deeply pipelined processors by eliminating
pipeline stalls.
[...]
I suggest all key performance critical packages be made available in
both i386 and i686 versions. glibc and openssl already do this. Off the
top of my head, this would include Mesa, I know for a fact the majority
of Second Life runtime is actually consumed by T&L inside Mesa/DRI. From
what I understand, even Intel's latest chipsets lack hardware T&L. Makes
sense, it helps sell more multi-core Intel processors, and probably
helps consolidate power management.
Twice the size for 3% improvement in extremely CPU-intensive tasks, and no
gain whatsoever in load time, etc? That will translate to < 1% improvement
overall. Lost in the noise, anyway. Not worth it in my book.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
7:07 a.m.
2008/1/15, Horst H. von Brand <vonbrand(a)inf.utfsm.cl>:
Callum Lerwick <seg(a)haxxed.com> wrote:
[...]
> Not quite "three times" faster, but 3.26% faster with i686. A major
> addition to the i686 architecture was cmov, and gcc is actually very
> aggressive about eliminating branching using cmovs, increasing
> performance on modern deeply pipelined processors by eliminating
> pipeline stalls.
[...]
> I suggest all key performance critical packages be made available in
> both i386 and i686 versions. glibc and openssl already do this. Off the
> top of my head, this would include Mesa, I know for a fact the majority
> of Second Life runtime is actually consumed by T&L inside Mesa/DRI. From
> what I understand, even Intel's latest chipsets lack hardware T&L. Makes
> sense, it helps sell more multi-core Intel processors, and probably
> helps consolidate power management.
Twice the size for 3% improvement in extremely CPU-intensive tasks, and no
gain whatsoever in load time, etc? That will translate to < 1% improvement
overall. Lost in the noise, anyway. Not worth it in my book.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
So what in your opinion should be made to make Fedora faster?
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
8:19 a.m.
On Tue, 15 Jan 2008 14:07:30 +0100, Jakub 'Livio' Rusinek wrote:
So what in your opinion should be made to make Fedora faster?
Have you performed any tests other than perception-based comparison of
Firefox start-times under two different [unspecified] configurations? Any
benchmark results? Is it just Firefox that starts more quickly? Or do you
see faster builds when compiling software, compressing archives, encoding
Ogg files, or FPS values in graphical rendering applications? Can you post
even simple "time command" based results which compare execution times of
several programs? First you say the compiler optimisation flags are
insufficient. Then, with the assistance from list subscribers, it is found
out that more likely the faster start-times are due to a different
preloading strategy.
It's not the first time somebody bumps into this list and claims that the
compiler flags are either "wrong", "should be for i686 not i386" or
"don't
optimise enough". It happens once a year or so and is covered by the list
archives. Usually, there is interest in discussing it. Even experts
comment on such topics and give serious answers instead of treating the
original poster like a troll. Nobody would mind if they ignored topics
like this one. But what is missing in all these cases is a scientific
approach to analysing what you believe is a problem. Even the step where
you would collect data, from which to proceed, is missing.
9:11 a.m.
2008/1/15, Michael Schwendt <mschwendt.tmp0701.nospam(a)arcor.de>:
On Tue, 15 Jan 2008 14:07:30 +0100, Jakub 'Livio' Rusinek wrote:
> So what in your opinion should be made to make Fedora faster?
Have you performed any tests other than perception-based comparison of
Firefox start-times under two different [unspecified] configurations? Any
benchmark results? Is it just Firefox that starts more quickly? Or do you
see faster builds when compiling software, compressing archives, encoding
Ogg files, or FPS values in graphical rendering applications? Can you post
even simple "time command" based results which compare execution times of
several programs? First you say the compiler optimisation flags are
insufficient. Then, with the assistance from list subscribers, it is found
out that more likely the faster start-times are due to a different
preloading strategy.
It's not the first time somebody bumps into this list and claims that the
compiler flags are either "wrong", "should be for i686 not i386" or
"don't
optimise enough". It happens once a year or so and is covered by the list
archives. Usually, there is interest in discussing it. Even experts
comment on such topics and give serious answers instead of treating the
original poster like a troll. Nobody would mind if they ignored topics
like this one. But what is missing in all these cases is a scientific
approach to analysing what you believe is a problem. Even the step where
you would collect data, from which to proceed, is missing.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I'm not using openSUSE anymore, but I can say:
* udev was running faster
* networkmanager too
* firefox started faster
* firefox scrolled webpages faster (even in smooth mode, which doesn't work
well for me in Fedora)
* opengl rendering were waster (eg elisa started drawing earlier, compiz
burn effect was smooth)
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
9:35 a.m.
On Tue, 2008-01-15 at 16:11 +0100, Jakub 'Livio' Rusinek wrote:
I'm not using openSUSE anymore, but I can say:
* udev was running faster
* networkmanager too
* firefox started faster
* firefox scrolled webpages faster (even in smooth mode, which doesn't
work well for me in Fedora)
* opengl rendering were waster (eg elisa started drawing earlier,
compiz burn effect was smooth)
Measure or GTFO.
- ajax
9:26 a.m.
2008/1/15, Adam Jackson <ajackson(a)redhat.com>:
On Tue, 2008-01-15 at 16:11 +0100, Jakub 'Livio' Rusinek wrote:
> I'm not using openSUSE anymore, but I can say:
>
> * udev was running faster
> * networkmanager too
> * firefox started faster
> * firefox scrolled webpages faster (even in smooth mode, which doesn't
> work well for me in Fedora)
> * opengl rendering were waster (eg elisa started drawing earlier,
> compiz burn effect was smooth)
Measure or GTFO.
- ajax
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
So now I must to install openSUSE only because you want to see data? It's
kinda stupid.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
9:37 a.m.
On Tue, 2008-01-15 at 16:26 +0100, Jakub 'Livio' Rusinek wrote:
So now I must to install openSUSE only because you want to see data?
It's kinda stupid.
Do you really not understand this? Let me try to make this simple.
<JohnDoe> My car is faster than your car.
<JaneDoe> Really? How fast does it go?
<JohnDoe> I don't know, fast.
<JaneDoe> OK, how did you measure the speed?
<JohnDoe> I didn't. It just felt faster.
<JaneDoe> Hmm. OK, maybe we could setup a race between our cars?
<JohnDoe> I don't have that car anymore.
<JaneDoe> So, let me get this straight. A car that you don't have
anymore is somehow faster than mine, but you don't know how fast it
goes, nor do you have any measurements of its speed?
<JohnDoe> Yes! You need to make your car fast like that.
<JaneDoe> I'll get right on that. Really.
~spot
9:56 a.m.
On Tue, 15 Jan 2008 16:26:56 +0100, Jakub 'Livio' Rusinek wrote:
So now I must to install openSUSE only because you want to see data?
It's
kinda stupid.
No, it isn't. So far, you have not provided any data. You have not even
posted data about your hardware, active drivers, your configuration of
both test environments.
* udev was running faster
* networkmanager too
Hmm, but especially when writing things like that it is really necessary
to provide actual numbers to back up your claims and to take a close look
at these two programs are configured. For example, a simple change in
number of udev rules to process can have an impact. You skip that work and
expect other people to do it instead?
10:31 a.m.
Installing openSUSE again would complicate my life. Again.
But if it's so necessary, I can install it one more time.
My hardware and configuration?
http://www.smolts.org/show_all?UUID=c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
7:09 a.m.
Ok, I've installed openSUSE and configured it like my Fedora.
time commands (fedora vs opensuse)
firefox 3, snapshot from trunk
real 12.125s 6.598s
user 6.564s 4.584s
sys 0.766s 0.544s
gnome-terminal
real 2.359s 0.312s
user 0.451s 0.076s
sys 0.099s 0.028s
nautilus (when running on desktop, below new instance ran from
gnome-terminal)
real 0.523s 0.257s
user 0.151s 0.148s
sys 0.045s 0.024s
totem
real 3.742s 2.758s
user 1.440s 1.816s
sys 0.415s 0.352s
Tell me if you want more data (I'll provide bootchart too).
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
7:14 a.m.
Jakub 'Livio' Rusinek wrote:
Ok, I've installed openSUSE and configured it like my Fedora.
time commands (fedora vs opensuse)
where are the fedora and where are the opensuse
numbers?
Plain numbers without something to compare too are useless (you need to
post both fedora _AND_ opensuse numbers).
7:18 a.m.
2008/1/16, drago01 <drago01(a)gmail.com>:
Jakub 'Livio' Rusinek wrote:
> Ok, I've installed openSUSE and configured it like my Fedora.
>
> time commands (fedora vs opensuse)
where are the fedora and where are the opensuse numbers?
Plain numbers without something to compare too are useless (you need to
post both fedora _AND_ opensuse numbers).
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I've posted Fedora and openSUSE numbers, silly.
| example program:
|
| real (fedora) (opensuse)
| user (fedora) (opensuse)
| sys (fedora) (opensuse)
They're even easy to compare. Higher time - Fedora, lower - openSUSE.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
7:25 a.m.
Jakub 'Livio' Rusinek wrote:
2008/1/16, drago01 <drago01(a)gmail.com
<mailto:drago01@gmail.com>>:
Jakub 'Livio' Rusinek wrote:
> Ok, I've installed openSUSE and configured it like my Fedora.
>
> time commands (fedora vs opensuse)
where are the fedora and where are the opensuse numbers?
Plain numbers without something to compare too are useless (you
need to
post both fedora _AND_ opensuse numbers).
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com <mailto:fedora-devel-list@redhat.com>
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I've posted Fedora and openSUSE numbers, silly.
Sorry I missed it because there where only one "real, user and sys" line
for each app
7:20 a.m.
Jakub 'Livio' Rusinek writes:
Ok, I've installed openSUSE and configured it like my Fedora.
time commands (fedora vs opensuse)
firefox 3, snapshot from trunk
real 12.125s 6.598s
user 6.564s 4.584s
sys 0.766s 0.544s
What command did you use to time Firefox startup? At what point did
you stop the clock?
gnome-terminal
real 2.359s 0.312s
user 0.451s 0.076s
sys 0.099s 0.028s
What exactly are you testing here? I get
$ time gnome-terminal
real 0m0.035s
user 0m0.012s
sys 0m0.012s
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
9:44 a.m.
On Wed, 16 Jan 2008 14:09:13 +0100, Jakub 'Livio' Rusinek wrote:
Ok, I've installed openSUSE and configured it like my Fedora.
time commands (fedora vs opensuse)
firefox 3, snapshot from trunk
real 12.125s 6.598s
user 6.564s 4.584s
sys 0.766s 0.544s
What command did you use to do this?
Do consecutive runs of the same test change the values? How?
Earlier you wrote:
and eg. Firefox 3 was started in < 1 sec.
That doesn't match your new values at all.
9:56 a.m.
2008/1/16, Michael Schwendt <mschwendt.tmp0701.nospam(a)arcor.de>:
On Wed, 16 Jan 2008 14:09:13 +0100, Jakub 'Livio' Rusinek wrote:
> Ok, I've installed openSUSE and configured it like my Fedora.
>
> time commands (fedora vs opensuse)
>
> firefox 3, snapshot from trunk
>
> real 12.125s 6.598s
> user 6.564s 4.584s
> sys 0.766s 0.544s
What command did you use to do this?
Do consecutive runs of the same test change the values? How?
Earlier you wrote:
> and eg. Firefox 3 was started in < 1 sec.
That doesn't match your new values at all.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
What command did you use to do this? time, /usr/bin/time, I guess
time (some command here)
and then quick exit of program, quickest you can.
It was second start of Firefox.
2nd time it's starting faster and faster.
12s for Fedora and 6s for openSUSE is time from starting command to Firefox
being shown.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
6:03 p.m.
On Wed, 16 Jan 2008 16:56:58 +0100, Jakub 'Livio' Rusinek wrote:
> On Wed, 16 Jan 2008 14:09:13 +0100, Jakub 'Livio'
Rusinek wrote:
>
> > Ok, I've installed openSUSE and configured it like my Fedora.
I went through the pains of installing openSUSE 10.3 for GNOME. Except for
the installation settings, which I adjusted only minimally, I used the
defaults and I did not reconfigure anything after booting the first time.
I explicitly did not enable the non-free repository.
First thing I noticed: harddisk access in openSUSE happens at half the
speed of Fedora. hdparm -t confirms it whereas hdparm -T results for
cache reads are about the same for both systems.
This difference in disk access had a bad effect on some data processing
speed tests. For huge files, openSUSE was about 33% slower in overall
execution time, and I almost stopped at that point.
For tests with smaller files, openSUSE computed approx. 3% faster than
Fedora 8 (this is on AMD Athlon). Sometimes 2%, sometimes a bit more than
3%, but I didn't spend the time to take more than 1 or 2 samples each. And
it was unconvincing enough to even consider comparing special computations
of e.g. ASM-optimised A/V codecs.
The openSUSE GNOME Desktop does not feel any snappier to me. Not when
starting applications and not when opening xterm either. Though, I've
noticed that when dragging xterm from the menu onto the desktop, an
invalid launcher file is created and gives an error. ;)
Firefox (it's 2.0.0.6 in openSUSE and 2.0.0.10 in F8) in Fedora 8 starts
and exits from within a terminal in roughly 4.3 seconds (reproducibly)
when quickly pressing Ctrl+W as soon as the window appears. That should
mimic your own test procedure. In openSUSE it did that in approx. 6
seconds, and possibly due to the disk access issues I had difficulties in
trying to start and close it faster than in 5-6 seconds.
8:27 a.m.
2008/1/18, Michael Schwendt <mschwendt.tmp0701.nospam(a)arcor.de>:
On Wed, 16 Jan 2008 16:56:58 +0100, Jakub 'Livio' Rusinek wrote:
> > On Wed, 16 Jan 2008 14:09:13 +0100, Jakub 'Livio' Rusinek wrote:
> >
> > > Ok, I've installed openSUSE and configured it like my Fedora.
I went through the pains of installing openSUSE 10.3 for GNOME. Except for
the installation settings, which I adjusted only minimally, I used the
defaults and I did not reconfigure anything after booting the first time.
I explicitly did not enable the non-free repository.
First thing I noticed: harddisk access in openSUSE happens at half the
speed of Fedora. hdparm -t confirms it whereas hdparm -T results for
cache reads are about the same for both systems.
This difference in disk access had a bad effect on some data processing
speed tests. For huge files, openSUSE was about 33% slower in overall
execution time, and I almost stopped at that point.
For tests with smaller files, openSUSE computed approx. 3% faster than
Fedora 8 (this is on AMD Athlon). Sometimes 2%, sometimes a bit more than
3%, but I didn't spend the time to take more than 1 or 2 samples each. And
it was unconvincing enough to even consider comparing special computations
of e.g. ASM-optimised A/V codecs.
The openSUSE GNOME Desktop does not feel any snappier to me. Not when
starting applications and not when opening xterm either. Though, I've
noticed that when dragging xterm from the menu onto the desktop, an
invalid launcher file is created and gives an error. ;)
Firefox (it's 2.0.0.6 in openSUSE and 2.0.0.10 in F8) in Fedora 8 starts
and exits from within a terminal in roughly 4.3 seconds (reproducibly)
when quickly pressing Ctrl+W as soon as the window appears. That should
mimic your own test procedure. In openSUSE it did that in approx. 6
seconds, and possibly due to the disk access issues I had difficulties in
trying to start and close it faster than in 5-6 seconds.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
But notice that I've used Firefox 3. It's MUCH faster than Firefox 2.
They removed many memory leaks and improved many things (eg they're using
Cairo for drawing interface and websites).
Only thing that I do not like now is starting apps. It takes sometimes very
long for eg Nautilus to open some window (in browser mode, ofc).
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
10:09 a.m.
2008/1/12, Jakub 'Livio' Rusinek <jakub.rusinek(a)gmail.com>:
do we need to support legacy cpu's by i386 compilation?
i586 would make fedora faster even 3 times.
difference is noticeable.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
You really are making a fool of yourself around here.
i can't imagine that the architecture has anything to do with performance.
but this [1] will most likely explain why openSuSE is so "much" faster
than fedora.
Fedora used to use caching (preload) as well but it wasn't offering
speed improvements on default installs. more the opposite and that why
it's not in fedora anymore. Apparently opensuse has a
better/custom/other preloading system than fedora had (which was
readahead) and that's causing the speed improvements that you noticed.
If you want to do a "fair" comparison of the speed than you must run
Firefox on fedora once first (than it gets cached) and than start
measuring the speed when you open it again. i bet it will be about
equal to opensuse. I did this test a while ago with readahead and if
the readahead files have the right paths than you will notice speed
improvements in all apps that are in the readahead list.
Fedora currently has no (correct me if i'm wrong) preloading/readahead
thing started with a default install so (nearly) nothing gets pumped
into the memory to get speed improvements. They will get there once
they are started.
So fedora isn't fast or slow. it's just working without caching
programs that improve your performance.
Perhaps it's time for fedora to look how opensuse is doing this
preloading and investigate if that can be used in Fedora 9 (or Fedora
10 if 9 is feature frozen).
[1] http://en.opensuse.org/SUPER_standard_benchmark
10:47 a.m.
I would expect different services to also cause some performance
penalties. I doubt OpenSUSE uses SElinux for one. This is a selling
point for Fedora.
11:13 a.m.
On 13/01/2008, Naheem Zaffar <naheemzaffar(a)gmail.com> wrote:
I would expect different services to also cause some performance
penalties. I doubt OpenSUSE uses SElinux for one. This is a selling
point for Fedora.
This thread makes for interesting reading on the overhead of SElinux:
http://lkml.org/lkml/2007/9/6/14
Even with that patch, SElinux seems to incur a 25% overhead on simple
file open/close. Not sure if that's since been adressed, or if I am
misinterpretting the data given.
11:31 a.m.
On Jan 13, 2008 6:13 PM, Jonathan Underwood
<jonathan.underwood(a)gmail.com> wrote:
On 13/01/2008, Naheem Zaffar <naheemzaffar(a)gmail.com> wrote:
> I would expect different services to also cause some performance
> penalties. I doubt OpenSUSE uses SElinux for one. This is a selling
> point for Fedora.
>
This thread makes for interesting reading on the overhead of SElinux:
http://lkml.org/lkml/2007/9/6/14
Even with that patch, SElinux seems to incur a 25% overhead on simple
file open/close. Not sure if that's since been adressed, or if I am
misinterpretting the data given.
This is about a patch that fixes this issue and the patch is already merged.
11:34 a.m.
On 13/01/2008, drago01 <drago01(a)gmail.com> wrote:
This is about a patch that fixes this issue and the patch is already
merged.
I think you missread. The patch fixes the overhead of file read and
write. It does not address the 25 % overhead associated with file
open/close - look further down the thread.
11:41 a.m.
On Jan 13, 2008 6:34 PM, Jonathan Underwood
<jonathan.underwood(a)gmail.com> wrote:
On 13/01/2008, drago01 <drago01(a)gmail.com> wrote:
> This is about a patch that fixes this issue and the patch is already merged.
I think you missread. The patch fixes the overhead of file read and
write. It does not address the 25 % overhead associated with file
open/close - look further down the thread.
true this seems to only deal with the read/write issues.
1:13 p.m.
2008/1/13, Jonathan Underwood <jonathan.underwood(a)gmail.com>:
On 13/01/2008, Naheem Zaffar <naheemzaffar(a)gmail.com> wrote:
> I would expect different services to also cause some performance
> penalties. I doubt OpenSUSE uses SElinux for one. This is a selling
> point for Fedora.
>
This thread makes for interesting reading on the overhead of SElinux:
http://lkml.org/lkml/2007/9/6/14
Even with that patch, SElinux seems to incur a 25% overhead on simple
file open/close. Not sure if that's since been adressed, or if I am
misinterpretting the data given.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I have SELinux disabled because of many problems.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
1:12 p.m.
2008/1/13, Mark <markg85(a)gmail.com>:
2008/1/12, Jakub 'Livio' Rusinek <jakub.rusinek(a)gmail.com>:
> do we need to support legacy cpu's by i386 compilation?
> i586 would make fedora faster even 3 times.
> difference is noticeable.
>
> --
> Jakub 'Livio' Rusinek
> http://liviopl.jogger.pl/
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
You really are making a fool of yourself around here.
i can't imagine that the architecture has anything to do with performance.
but this [1] will most likely explain why openSuSE is so "much" faster
than fedora.
Fedora used to use caching (preload) as well but it wasn't offering
speed improvements on default installs. more the opposite and that why
it's not in fedora anymore. Apparently opensuse has a
better/custom/other preloading system than fedora had (which was
readahead) and that's causing the speed improvements that you noticed.
If you want to do a "fair" comparison of the speed than you must run
Firefox on fedora once first (than it gets cached) and than start
measuring the speed when you open it again. i bet it will be about
equal to opensuse. I did this test a while ago with readahead and if
the readahead files have the right paths than you will notice speed
improvements in all apps that are in the readahead list.
Fedora currently has no (correct me if i'm wrong) preloading/readahead
thing started with a default install so (nearly) nothing gets pumped
into the memory to get speed improvements. They will get there once
they are started.
So fedora isn't fast or slow. it's just working without caching
programs that improve your performance.
Perhaps it's time for fedora to look how opensuse is doing this
preloading and investigate if that can be used in Fedora 9 (or Fedora
10 if 9 is feature frozen).
[1] http://en.opensuse.org/SUPER_standard_benchmark
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Listen. Firefox 3 is very fast. First run always is long (every distro), but
second, third, fourth run are faster than the first - that's normal with
Firefox, but in openSUSE Firefox 3 started in less than one second on my
current hardware. On Fedora it was more than 1 second in > 1st run.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
1:24 p.m.
On 01/13/2008 08:12 PM, Jakub 'Livio' Rusinek wrote:
Listen. Firefox 3 is very fast. First run always is long (every
distro), but
second, third, fourth run are faster than the first - that's normal with
Firefox, but in openSUSE Firefox 3 started in less than one second on my
current hardware. On Fedora it was more than 1 second in > 1st run.
... but you aren't even using Fedora's firefox RPMs! [1] If you're
going to complain, complain about things we're building and have control
over!
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01202.html
1:35 p.m.
2008/1/13, Christopher Aillon <caillon(a)redhat.com>:
On 01/13/2008 08:12 PM, Jakub 'Livio' Rusinek wrote:
> Listen. Firefox 3 is very fast. First run always is long (every distro),
but
> second, third, fourth run are faster than the first - that's normal with
> Firefox, but in openSUSE Firefox 3 started in less than one second on my
> current hardware. On Fedora it was more than 1 second in > 1st run.
... but you aren't even using Fedora's firefox RPMs! [1] If you're
going to complain, complain about things we're building and have control
over!
[1]
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01202.html
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I'll now use you RPMs, because I want to use trunk code, which you'll don't
package every day.
In rawhide/remi's repo is oldest version.
Firefox 3 without your flags is fast. Not in Fedora of course.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
1:37 p.m.
On 01/13/2008 08:35 PM, Jakub 'Livio' Rusinek wrote:
I'll now use you RPMs, because I want to use trunk code, which
you'll don't
package every day.
In rawhide/remi's repo is oldest version.
Firefox 3 without your flags is fast. Not in Fedora of course.
Um, I didn't understand that...
2:30 p.m.
2008/1/13, Christopher Aillon <caillon(a)redhat.com>:
On 01/13/2008 08:35 PM, Jakub 'Livio' Rusinek wrote:
> I'll now use you RPMs, because I want to use trunk code, which you'll
don't
> package every day.
> In rawhide/remi's repo is oldest version.
>
> Firefox 3 without your flags is fast. Not in Fedora of course.
Um, I didn't understand that...
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Trunk snapshot in Mozilla's FTP is updated every day. Using it instead of
older RPMs is better if I want to see current bugs and file them (I'm
involved in Firefox 3).
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
3:32 p.m.
On 01/13/2008 09:30 PM, Jakub 'Livio' Rusinek wrote:
Trunk snapshot in Mozilla's FTP is updated every day. Using it
instead of
older RPMs is better if I want to see current bugs and file them (I'm
involved in Firefox 3).
We're tracking Mozilla upstream pretty closely in Rawhide. While not
daily, we aren't that far off...
3:34 p.m.
2008/1/13, Jakub 'Livio' Rusinek <jakub.rusinek(a)gmail.com>:
2008/1/13, Christopher Aillon <caillon(a)redhat.com>:
> On 01/13/2008 08:35 PM, Jakub 'Livio' Rusinek wrote:
> > I'll now use you RPMs, because I want to use trunk code, which you'll
don't
> > package every day.
> > In rawhide/remi's repo is oldest version.
> >
> > Firefox 3 without your flags is fast. Not in Fedora of course.
>
>
> Um, I didn't understand that...
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
Trunk snapshot in Mozilla's FTP is updated every day. Using it instead of
older RPMs is better if I want to see current bugs and file them (I'm
involved in Firefox 3).
i can hardly believe that you are part of the FF3 development.
O well... want to talk about speed?
look at this:
[mark@localhost ~]$ time firefox
real 0m0.151s
user 0m0.021s
sys 0m0.029s
[mark@localhost ~]$
Yes! that's well below one second (firefox 2.0.0.10)! and nothing is
specially tuned! i even have one additional plugin installed (tamper
data)! and my hardware isn't that fancy. it's just a $600 notebook.
Perhaps you need to reinstall your Fedora?
But you made me curious about how well FF3 will run on Fedora 8 so i
will try to install that one and see shat the timings are than.
2:08 p.m.
sön 2008-01-13 klockan 20:35 +0100 skrev Jakub 'Livio' Rusinek:
Firefox 3 without your flags is fast. Not in Fedora of course.
Perhaps the issue here is all the language pack extensions that you
might get in the Fedora Firefox. They might slow down startup compared
to the relatively clean upstream binaries. (This is a known problem,
btw, the question is if it's a big problem and what to do about it.)
/abo
2:29 p.m.
2008/1/13, Alexander Boström <abo(a)kth.se>:
sön 2008-01-13 klockan 20:35 +0100 skrev Jakub 'Livio' Rusinek:
> Firefox 3 without your flags is fast. Not in Fedora of course.
Perhaps the issue here is all the language pack extensions that you
might get in the Fedora Firefox. They might slow down startup compared
to the relatively clean upstream binaries. (This is a known problem,
btw, the question is if it's a big problem and what to do about it.)
/abo
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I didn't mean the localization slows down Firefox, but when using Firefox 3
from repo I feel little slowing down compared to Firefox 3 snapshot from
trunk.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
5:01 p.m.
sön 2008-01-13 klockan 21:29 +0100 skrev Jakub 'Livio' Rusinek:
I didn't mean the localization slows down Firefox, but when
using
Firefox 3 from repo I feel little slowing down compared to Firefox 3
snapshot from trunk.
Yes, and if you list the number of extensions in one versus the
other...?
/abo
11:18 a.m.
2008/1/14, Alexander Boström <abo(a)kth.se>:
sön 2008-01-13 klockan 21:29 +0100 skrev Jakub 'Livio' Rusinek:
> I didn't mean the localization slows down Firefox, but when using
> Firefox 3 from repo I feel little slowing down compared to Firefox 3
> snapshot from trunk.
Yes, and if you list the number of extensions in one versus the
other...?
/abo
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I have no extensions, silly, but I noticed that starting Firefox 2 on Fedora
always taked for me a long time.
--
Jakub 'Livio' Rusinek
http://liviopl.jogger.pl/
2:11 p.m.
Firefox 2 in Fedora uses Pango for text layout. Upstream does not. No
idea about other distributions, nor about whether this is more of a
rendering performance penalty or a startup one.
5943
days inactive
5949
days old
92 comments
32 participants
participants (32)
-
Adam Jackson -
Adam Tkac -
Alan Cox -
Alexander Boström -
Andrew Farris -
Andrew Haley -
Callum Lerwick -
Chris Snook -
Christopher Aillon -
David Nielsen -
Denis Leroy -
Douglas McClendon -
drago01 -
Eric Sandeen -
Felix Miata -
Horst H. von Brand -
Ignacio Vazquez-Abrams -
Jakub 'Livio' Rusinek -
Jef Spaleta -
Jesse Keating -
Joachim Frieben -
John Reiser -
Jonathan Underwood -
Les Mikesell -
Linus Walleij -
Mark -
Matthew Miller -
Michael Schwendt -
Naheem Zaffar -
Patrice Dumas -
Rahul Sundaram -
Tom Callaway