|
Home > Archive > Debian Developers > February 2004 > P4 optimized Debian GNU/Linux?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
P4 optimized Debian GNU/Linux?
|
|
| Turbo Fredriksson 2004-02-25, 9:37 am |
| It's been discussed before, but I never bothered to look into that,
since I didn't think I cared 
Now, a friend of mine took the time to (more or less) manually recompile/
repackage/reinstall his Debian GNU/Linux woody box.
His word was "it WAY faster!". No numbers, just those three words. Got'a
mean something...
If I remember correctly from the last time I saw this subject come up,
the resolution was "no, we don't want that". I can't remember why, but
I don't care (unless it's changed .
I've tried to install pbuilder, wanna-build and sbuild, but I can't figure
out how to use them to recompile the whole dist. Wanna-build looks 'dangerous'
(it seems to do DB lookups @ Debian GNU/Linux etc), and PBuilder can't even
generate the CHROOTs (neither for sid nor woody!).
So... Any ideas on how to do this in a more 'automatic' fashion for my own
use?
--
Nazi FBI fissionable congress Marxist ammonium $400 million in gold
bullion bomb Uzi subway genetic cracking attack Kennedy NORAD
[See http://www.aclu.org/echelonwatch/index.html for more about this]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-02-25, 9:37 am |
| On Wed, 25 Feb 2004 19:05, Turbo Fredriksson <turbo@debian.org> wrote:
> His word was "it WAY faster!". No numbers, just those three words. Got'a
> mean something...
When I was younger and felt like playing a prank I would adjust some
meaningless parameters on someone's computer and tell them "this will make it
run about 5% faster, but you probably won't notice it". With such a
challenge they usually responded by becoming totally convinced that I had
improved their machines considerably and that they could feel the 5%
difference!
It's great if someone is happy with their machine. But if we are going to
make changes that affect millions of people then we need some numbers.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Chris Cheney 2004-02-25, 9:37 am |
| On Wed, Feb 25, 2004 at 09:05:16AM +0100, Turbo Fredriksson wrote:
> So... Any ideas on how to do this in a more 'automatic' fashion for my own
> use?
I'm not sure how to set it up, but once you do, please post results on
how much faster various things are. If you can prove optimizing for P4
is faster and back it up with numbers then you will finally dispel the
old assumption that it does not speed things up much.
I have personally seen cases where compiling for amd64 speeds things up
to 50% faster on the same box, but it has more general purpose registers
as well.
Chris
| |
| Bas Zoetekouw 2004-02-25, 9:37 am |
| Hi Turbo!
You wrote:
> If I remember correctly from the last time I saw this subject come up,
> the resolution was "no, we don't want that". I can't remember why, but
> I don't care (unless it's changed .
IIRC, the conclusion was "show us the numbers".
--
Kind regards,
+--------------------------------------------------------------------+
| Bas Zoetekouw | GPG key: 0644fab7 |
|----------------------------| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| bas@o2w.nl, bas@debian.org | a2b1 2bae e41f 0644 fab7 |
+--------------------------------------------------------------------+
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Cameron Patrick 2004-02-25, 9:37 am |
| Bas Zoetekouw wrote:
| IIRC, the conclusion was "show us the numbers".
Bah, numbers are easy to come by. /Meaningful/ numbers are what might
be interesting.
Some people from my LUG compared the speed of Mandrake to Debian to a
P4-optimised Gentoo for various tasks a while ago. I seem to remember
that for most of their tests there was bugger-all difference: < 10%;
and where there /was/ a difference, it was mostly due to different
versions of software being used. I've no idea how meaningful or
statistically significant their testing was either, either.
Cameron.
| |
| David Pashley 2004-02-25, 9:37 am |
| On Feb 25, 2004 at 08:05, Turbo Fredriksson praised the llamas by saying:
>
>
> So... Any ideas on how to do this in a more 'automatic' fashion for my own
> use?
> --
You could look at apt-src or apt-build and pentium-builder. I haven't
used them, but aiui, they work like apt-get but download the source and
recompile it instead of downloading the binaries. pentium-builder sets
the optimisations on gcc automatically for you so you don;t need to
alter the packages.
--
David Pashley
david@davidpashley.com
Nihil curo de ista tua stulta superstitione.
| |
| Russell Coker 2004-02-25, 9:37 am |
| On Wed, 25 Feb 2004 19:34, Chris Cheney <ccheney@cheney.cx> wrote:
> I have personally seen cases where compiling for amd64 speeds things up
> to 50% faster on the same box, but it has more general purpose registers
> as well.
AMD64 is totally different.
64bit registers can make a factor of 10 difference for some algorithms.
More registers can also make a huge difference.
Then you have a different version of EVERY shared object.
Think of AMD64 as a different CPU not as an optimisation.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-02-25, 10:33 am |
| Turbo Fredriksson <turbo@debian.org> writes:
> It's been discussed before, but I never bothered to look into that,
> since I didn't think I cared
>
> Now, a friend of mine took the time to (more or less) manually recompile/
> repackage/reinstall his Debian GNU/Linux woody box.
>
> His word was "it WAY faster!". No numbers, just those three words. Got'a
> mean something...
Of cause its faster when you optimize for _your_ system.
> If I remember correctly from the last time I saw this subject come up,
> the resolution was "no, we don't want that". I can't remember why, but
> I don't care (unless it's changed .
The problem is the number of different systems out there. For people
to benefit you need a i486, i585, P1, P1-mmx, P2, P3, P4, Cyrix, Crusoe,
Via, K5, K6, K7, .... optimized flavour. The benefit is small and even
nonexisting if you don't have the exact right flavour. The time and
space wasteage is huge. Its just not feasable for Debian to invest that
much time, bandwith and mirror space into so little benefit.
> I've tried to install pbuilder, wanna-build and sbuild, but I can't figure
> out how to use them to recompile the whole dist. Wanna-build looks 'dangerous'
> (it seems to do DB lookups @ Debian GNU/Linux etc), and PBuilder can't even
> generate the CHROOTs (neither for sid nor woody!).
You have to feed wanna-build with quinn-diff output. Its a bit messy
and needs work to get to know it.
You don't need pbuilder at all but you need sbuild.
You most certainly want a chroot to build in, use cdebootstrap to make
one and then add the missing things like etc/apt/sources.list,
etc/passwd, etc/group, buildds home, apt-get install build-essential,
....
You also need buildd to actually build packages wanna-build has in
needs-build.
And then you need some upload queue and apt archive software
(e.g. mini-dinstall) so you can use apt on the new debs.
After all this, once you get it working, you only have the same debs
Debian builds. No optimization yet. For that you would have to hack
around. Most likely to succeed is to replace gcc/g++ with a wrapper
that selectively adds the right flags.
> So... Any ideas on how to do this in a more 'automatic' fashion for my own
> use?
If you are intrested in using a locally compiled Debian maybe you are
willing to sponsor sourcerer.
Sourcerer will setup a chroot for building packages, create an
apt-repository for locally build packages (with higher pin than the
official one) and keps track of packages getting installed by apt and
new sources being uploaded to debian.
When you run "apt-get install foobar" sourcerer will add foobar to its
list of packages that should be build. A cron job later fetches the
source, rebuilds the package locally and adds it to the local archive.
The next time you run "apt-get update; apt-get upgrade" the localy
compiled version will be installed. When a new debian version of
foobar is released Sourcerer will fetch the new source and also build
it locally. The pining of the local repository prevents the old
locally build version to be replaced by the new debian one until its
locally build, i.e. prevents downloading debs that will be rebuild
anyway.
I have the setup running on my system successfully but the packaging
still needs work. Mainly automating the setup of the initial chroot
and providing a nice frontend to manage failed builds. And a nice,
configurable gcc/g++ wraper has to be written so people can specify
what kind of optimizations they would like.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Kemp 2004-02-25, 11:33 am |
| On Wed, Feb 25, 2004 at 03:30:14PM +0100, Goswin von Brederlow wrote:
>
> If you are intrested in using a locally compiled Debian maybe you are
> willing to sponsor sourcerer.
If not then I would be interested in testing and potentially
sponsoring it.
(This seems like an ideal way of producing a base system which
had been compiled by the SSP compiler I've been toying with).
> I have the setup running on my system successfully but the packaging
> still needs work. Mainly automating the setup of the initial chroot
> and providing a nice frontend to manage failed builds. And a nice,
> configurable gcc/g++ wraper has to be written so people can specify
> what kind of optimizations they would like.
If it were me I'd just write a tiny g++/gcc shell script that
does something like:
#!/bin/sh
/usr/bin/gcc.real `cat /etc/gcc/global.options` $*
Then use diversions to install it over the relevent file - I've done
this with success before.
Steve
--
# Debian Security Audit Project
http://www.shellcode.org/Audit/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Josip Rodin 2004-02-25, 12:33 pm |
| On Wed, Feb 25, 2004 at 09:05:16AM +0100, Turbo Fredriksson wrote:
> His word was "it WAY faster!". No numbers, just those three words. Got'a
> mean something...
Can you please tell him that his ideas are intriguing to me and I wish to
subscribe to his newsletter.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2004-02-25, 1:33 pm |
| >It's been discussed before, but I never bothered to look into that,
>since I didn't think I cared
>
>Now, a friend of mine took the time to (more or less) manually recompile/
>repackage/reinstall his Debian GNU/Linux woody box.
>
>His word was "it WAY faster!". No numbers, just those three words. Got'a
>mean something...
>
>If I remember correctly from the last time I saw this subject come up,
>the resolution was "no, we don't want that". I can't remember why, but
>I don't care (unless it's changed .
We concluded that it makes little difference -- for *most* packages.
And that the correct thing to do was to figure out which packages cared, and
make custom optimized versions of *them*.
Start with an optimized kernel, which you can do pretty easily. Then switch
to libc6-i686.
Looking at 'top', it seems to me that XFree86 and artsd are the two biggest
CPU hogs on my machine....mebbe I'll look into optimized compiles of those.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2004-02-25, 1:33 pm |
| Steve Kemp <skx@debian.org> writes:
> On Wed, Feb 25, 2004 at 03:30:14PM +0100, Goswin von Brederlow wrote:
>
> If not then I would be interested in testing and potentially
> sponsoring it.
>
> (This seems like an ideal way of producing a base system which
> had been compiled by the SSP compiler I've been toying with).
>
>
> If it were me I'd just write a tiny g++/gcc shell script that
> does something like:
>
> #!/bin/sh
> /usr/bin/gcc.real `cat /etc/gcc/global.options` $*
>
> Then use diversions to install it over the relevent file - I've done
> this with success before.
>
> Steve
The thing is that some packages already set options. Esspecially "-O2"
should be pretty much in everywhere.
I want to compile with "-Os" by default for my router, memory
constrains are far more important that speed there. I can easily add
"-Os" with your approach but the later "-O2" would override the
setting.
This is just one example. Other would be packages that use different
code at runtime and thus compile for non-mmx, mxx, sse, .... Removing
or overriding -mcpu or -march options blindly would most likely break
the compile. And last there are some sources that intentionally use
"-O3" for the time consuming part of the code. I would prefer if thats
kept.
For me I would like a config file that says 'If no -O option is given
or -O2 then add/replace with -Os'. Other will want to add -mcpu or
-march options. I haven't yet found a good syntax and algorithm to
make that kind of option changing/replaing for the general case.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Brian May 2004-02-25, 5:34 pm |
| >>>>> "Turbo" == Turbo Fredriksson <turbo@debian.org> writes:
Turbo> lookups @ Debian GNU/Linux etc), and PBuilder can't even
Turbo> generate the CHROOTs (neither for sid nor woody!).
I am not sure what you mean here (pbuilder depends on debootstrap for
creating new chroot systems) - perhaps you have found a bug?
(you do need to have the latest version of debootstrap installed to
install sid).
--
Brian May <bam@debian.org>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Turbo Fredriksson 2004-02-26, 6:33 am |
| that they'd jusT SUED you! These people are EVIL!!! They kidnapped my dog
and G$%<S-F4>@^<S-F6>RB. f NO CARRIER
Date: 26 Feb 2004 11:48:04 +0100
In-Reply-To: <84u11ealrh.fsf@snoopy.apana.org.au>
Message-ID: <8765du2k2j.fsf@papadoc.bayour.com>
Lines: 17
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
[color=darkred]
[color=darkred]
Turbo> lookups @ Debian GNU/Linux etc), and PBuilder can't even
Turbo> generate the CHROOTs (neither for sid nor woody!).
Brian> I am not sure what you mean here (pbuilder depends on
Brian> debootstrap for creating new chroot systems) - perhaps you
Brian> have found a bug?
I have. At least for 'woody'. I'm still investigating why 'sid' fails
(it have something to do with exim4 and GNUTLS - might be a exim4
bug). It's in the BTS...
--
attack arrangements CIA radar Serbian FSF spy FBI BATF NSA South
Africa AK-47 supercomputer Uzi Panama
[See http://www.aclu.org/echelonwatch/index.html for more about this]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tollef Fog Heen 2004-02-26, 6:33 am |
| * Steve Kemp
| #!/bin/sh
| /usr/bin/gcc.real `cat /etc/gcc/global.options` $*
You want "$@" instead of $* to not split the command line once more,
else it will break on files with spaces in them and such. </nitpick>
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Turbo Fredriksson 2004-02-26, 6:33 am |
| >>>>> "Goswin" == Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
Goswin> When you run "apt-get install foobar" sourcerer will add
Goswin> foobar to its list of packages that should be build. A
Goswin> cron job later fetches the source, rebuilds the package
Goswin> locally and adds it to the local archive. The next time
Goswin> you run "apt-get update; apt-get upgrade" the localy
Goswin> compiled version will be installed. When a new debian
Goswin> version of foobar is released Sourcerer will fetch the new
Goswin> source and also build it locally. The pining of the local
Goswin> repository prevents the old locally build version to be
Goswin> replaced by the new debian one until its locally build,
Goswin> i.e. prevents downloading debs that will be rebuild
Goswin> anyway.
VERY nice!
Goswin> If you are intrested in using a locally compiled Debian
Goswin> maybe you are willing to sponsor sourcerer.
Sure! 'Show me the code'
--
quiche killed ammonium 767 Ft. Bragg Cuba cryptographic Rule Psix
Ortega supercomputer munitions Treasury NSA Semtex Cocaine
[See http://www.aclu.org/echelonwatch/index.html for more about this]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Metzler 2004-02-26, 6:33 am |
| Turbo Fredriksson <turbo@debian.org> wrote:
> "Brian" == Brian May <bam@debian.org> writes:
[color=darkred]
[color=darkred]
> I have. At least for 'woody'. I'm still investigating why 'sid' fails
> (it have something to do with exim4 and GNUTLS - might be a exim4
> bug). It's in the BTS...
I cannot see it, have got a bug-number?
cu andreas
--
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~amet...n/tin-snapshot/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adam Majer 2004-02-27, 4:33 am |
| Turbo Fredriksson wrote:
>It's been discussed before, but I never bothered to look into that,
>since I didn't think I cared
>
>Now, a friend of mine took the time to (more or less) manually recompile/
>repackage/reinstall his Debian GNU/Linux woody box.
>
>His word was "it WAY faster!". No numbers, just those three words. Got'a
>mean something...
>
>If I remember correctly from the last time I saw this subject come up,
>the resolution was "no, we don't want that". I can't remember why, but
>I don't care (unless it's changed .
>
>
Ok, I have actually done a little test program. The problem is that
optimizing an application with gcc 3.3 might actually make things
*slower*. I have a P4 (2.6GHz) and an K7 2000+ workstation. When I run a
simple program that only does,
start_time = time();
for( int i=0; i<10000000; i++ ) // I forget how many 0 I had exactly
sin ( i / 324.34444 );
end_time = time();
printf( "Diff: %d\n", end_time - start_time );
When I run the program with no optimization -O0, I got some numbers that
looked about the same for both machines. Then I compiled with
-march=pentium-4 and -march=athlon-xp and -O6, and surprise, surprise,
the P4 had a speed *decrease*!! It slowed down from something like 23
seconds to 25 seconds. I don't know the exact numbers right now since
this was about a month ago, but optimizing things for P4 using gcc is
not the best thing. It is much better to just least things with i386 or
i486, and just use -O6 or whatever. There is a reason why linux uses
assembly for speed critical parts of the kernel!
If someone wants, I can post some numbers from a simple test like above
tomorrow.
- Adam
PS. I know for a fact that optimizing things with SSE or SSE2 *slows
down* the program if compiled with gcc. This happed for both Athlon and
P4 when I tried to optimize a loop-heavy magic square program.
Optimizing things with the Intel's C++ compiler might produce
drastically different results, but that is not the point here
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nano Nano 2004-02-27, 5:33 am |
| On Fri, Feb 27, 2004 at 08:40:28AM +0000, Adam Majer wrote:
> start_time = time();
> for( int i=0; i<10000000; i++ ) // I forget how many 0 I had exactly
> sin ( i / 324.34444 );
> end_time = time();
> printf( "Diff: %d\n", end_time - start_time );
>
> When I run the program with no optimization -O0, I got some numbers that
> looked about the same for both machines. Then I compiled with
> -march=pentium-4 and -march=athlon-xp and -O6, and surprise, surprise,
> the P4 had a speed *decrease*!! It slowed down from something like 23
I did enough performance work at Microsoft to know that your test is
meaningless. Just because you know X at level Y doesn't imply a thing
about your knowledge at level 10Y, good or bad. The program might get
slower, or faster, or crash.
Some people call this "nonlinear." A perf expert described it to me as
more accurately: stochastic.
So you can draw no conclusions whatsoever from your test.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Miah Gregory 2004-02-27, 5:33 am |
| On Fri, 2004-02-27 at 08:40, Adam Majer wrote:
> Turbo Fredriksson wrote:
[color=darkred]
> Ok, I have actually done a little test program. The problem is that
> optimizing an application with gcc 3.3 might actually make things
> *slower*. I have a P4 (2.6GHz) and an K7 2000+ workstation. When I run a
> simple program that only does,
-snip-
> PS. I know for a fact that optimizing things with SSE or SSE2 *slows
> down* the program if compiled with gcc. This happed for both Athlon and
> P4 when I tried to optimize a loop-heavy magic square program.
FWIW, the P4 is extremely bad with unrolled loops in my experience, to
the point where a CPU intensive application we run here goes faster on a
P3 1GHz than it does on a P4 1.7GHz, when running i386 optimised code.
In summary, we run this application tens of thousands of times every
night, and get consistent results.
--
Miah Gregory
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thiemo Seufer 2004-02-27, 6:33 am |
| Nano Nano wrote:
[snip]
>
> I did enough performance work at Microsoft to know that your test is
> meaningless. Just because you know X at level Y doesn't imply a thing
> about your knowledge at level 10Y, good or bad. The program might get
> slower, or faster, or crash.
>
> Some people call this "nonlinear." A perf expert described it to me as
> more accurately: stochastic.
>
> So you can draw no conclusions whatsoever from your test.
The conclusion is: Switching on all the optimizations is no silver bullet.
Thiemo
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Turbo Fredriksson 2004-02-28, 5:33 am |
| Quoting Andreas Metzler <ametzler@downhill.at.eu.org>:
> Turbo Fredriksson <turbo@debian.org> wrote:
>
> I cannot see it, have got a bug-number?
I haven't submitted the exim4 problems yet (I still don't know exactly
WHERE the problem is - it works if I do 'the pbuilder stuff' manually
using chroot et all), but the bug for pbuilder (the woody problem) are
#234859.
--
Legion of Doom cracking Marxist strategic Noriega Ft. Meade Serbian
supercomputer terrorist Soviet NSA AK-47 congress explosion Clinton
[See http://www.aclu.org/echelonwatch/index.html for more about this]
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2004-02-28, 5:33 pm |
| On Fri, Feb 27, 2004 at 08:40:28AM +0000, Adam Majer wrote:
> Turbo Fredriksson wrote:
>
> Ok, I have actually done a little test program. The problem is that
> optimizing an application with gcc 3.3 might actually make things
> *slower*. I have a P4 (2.6GHz) and an K7 2000+ workstation. When I run a
> simple program that only does,
>
> start_time = time();
> for( int i=0; i<10000000; i++ ) // I forget how many 0 I had exactly
> sin ( i / 324.34444 );
> end_time = time();
> printf( "Diff: %d\n", end_time - start_time );
>
> When I run the program with no optimization -O0, I got some numbers that
> looked about the same for both machines. Then I compiled with
> -march=pentium-4 and -march=athlon-xp and -O6, and surprise, surprise,
> the P4 had a speed *decrease*!! It slowed down from something like 23
> seconds to 25 seconds. I don't know the exact numbers right now since
> this was about a month ago, but optimizing things for P4 using gcc is
> not the best thing. It is much better to just least things with i386 or
First of all -O6 is the same as -O3.
It's well-known that in most cases -Os or -O2 produces the fastest code -
-O3 usually produces slower code.
Could you double-check whether -Os or -O2 produce slower code than -O0?
> i486, and just use -O6 or whatever. There is a reason why linux uses
> assembly for speed critical parts of the kernel!
>...
These are only very few parts of the kernel.
_Many_ speed-critical paths of the kernel are written in C (often with
people checking the output of gcc).
The days when hand-written assembler was better than compiled C code are
nearly gone - writing faster assembler code for a modern cpu than the
output of a good C compiler is a very hard task.
> - Adam
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|