What are AL's optimization codes and other feartures to speed up the system and applications beside i686? I have seen other distros using following codes and tools:
1) "-march=i686 -O3 -pipe -fomit-frame-pointer" to optimize all KDE and GUI applications.
2) binutils to take advantage of combreloc.
4) glibc with binutils installed.
5) hdparm speeds up the hard disk.
6) fam allows KDE to track files quicker.
i believe fam is in the trees somewhere and hdparm is definitely in the arch tree cuz i use it to get my dvd working properly.
i can't tell you for sure what the reasoning is for just using the i686 -02 -pipe instead of 03 -fomit-frame-pionter except to conjecture that perhaps those optimizations only benefit a select few while -02 -pipe may serve that whole of the arch community.
i can't speak to #2
4 (3) do you mean glibc with binutils ./configure flag or binutils and glibc both installed. because unless my eyes were decieving me moment ago they are bothinstalled as base pacakges.
I am not your friend
About glibc settings I don't know..... I copied the idea from Gentoo website.
One of the reasons why I brought up this optimization question, KDE is slow though binutils and hdparm were installed.
I found fam among unofficial packages and portmap (current). After intalling both packages, now my KDE works much better. Thanks.
If anyone wants to use fam..... add "fam" (no quotes) in /etc/rc.local file to run it when booting the system.
well i am glad i helped you with fam i am hoping apeiro will let you know why arch uses the -02 -pipe instead of -03 -pipe -fomit-frame-pointer. i am not well versed on what these optimizations do exactly.
I am not your friend
problem with -O3 is that if you package things up useing that level its very unlikely going to work well if at all on another i686.. because at this level the code is closely tied with the cpu.. where at level 2 its more generic.
thanks ody i just was reading about that in the linux from scratch manual.
I am not your friend
ody nailed it... -O3 is well-suited if you're building your own apps from source for your box and your box alone. But -O3 optimizations are more tightly tied to a specific architecture (p3/athlon/celeron coppermine/etc) and may fail on other i686 implementations.
But -O3 optimizations are more tightly tied to a specific architecture (p3/athlon/celeron coppermine/etc) and may fail on other i686 implementations.
Depending on how complex the software, -O3 et.al can even cause problems on the box it's compiling on. Some mysterious bugs have been tracked to just such optimizations including odd segmentation errors.
either way its not worth the time for the developers to sit down and figure out which packages can use -03 -pipe -fomit-frame-pointer, i'd rahter they work on more important things then makikng kde load .3432 seconds faster. but i do think this would be a cool idea. if somehow the abs used a global file for optimizations, like gentoo, but if you wanted to build lets say xfree with the optimizations you could set the flags and enable it it, then goto /usr/abs/....... and issue makepkg and get an optimized pkg. just a thought
....but i do think this would be a cool idea. if somehow the abs used a global file for optimizations, like gentoo, but if you wanted to build lets say xfree with the optimizations you could set the flags and enable it it, then goto /usr/abs/....... and issue makepkg and get an optimized pkg. just a thought
Your thought is also what I have in my mind. On topic: "What will Arch Linux 1.0 become?" is a discussion about it.
File /etc/makepkg.conf could have sample codes like this (copied from Gentoo Linux):
# Pentium Pro/Pentium II/Pentium III+/Pentium 4/Athlon optimized (but binaries # will run on any x86 system) #CHOST="i686-pc-linux-gnu" #CFLAGS="-mcpu=i686 -O3 -pipe" #CXXFLAGS="-mcpu=i686 -O3 -pipe" # Pentium Pro/Pentium II/Pentium III+/Pentium 4/Athlon exclusive (binaries # will use the P6 instruction set and only run on P6+ systems) #CHOST="i686-pc-linux-gnu" #CFLAGS="-march=i686 -O3 -pipe" #CXXFLAGS="-march=i686 -O3 -pipe" # Pentium/Pentium MMX #CFLAGS="-march=i586 -O3 -pipe" #CXXFLAGS="-march=i586 -O3 -pipe" # K6 #CFLAGS="-mcpu=k6 -march=k6 -O3 -pipe" #CXXFLAGS="-mcpu=k6 -march=k6 -O3 -pipe" #Duron # CFLAGS="-march=athlon_xp -O2 -pipe"
This was my codes when running Gentoo:
CFLAGS="-march=pentium3 -mcpu=pentium3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium3 -mcpu=pentium3 -O3 -pipe -fomit-frame-pointer"
Hmmm, why make things more complicated when you can set these options in the environment already? You still have control by overriding them on the command line or the build script if you use one.
Hmmm, why make things more complicated when you can set these options in the environment already?
What do you mean with "environment"? Can you give an example.
I knew when I mentioned this that I would need an example.
Actually, it's very simple to do for standard settings. You can specify these in either the /etc/profile or in the .bashrc file for the user who does the compiling. What we want is to set environment variables somewhat similar to the $PATH or $HOME variables. Some common ones are CC for compiler and CFLAGS for compiler options.
For BASH either of these formats will work. The first is the definition and export and the second example simply exports the text. Quotes are optional but may be necessary for certain text strings to be accepted. Other shells may vary.
You can then bypass these for specific values on a command line or in the configure phase depending on how you compile programs. Of course with bash scripting you have many more options but bash is not my forte'.
[user@pc]$ export CC=g++ && make
Of course, systems may vary as well as options allowed when building programs. Some programs have a lot of options and work best when scripted, IMHO.