Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Installing Gentoo 2004.3: Stage 1 NPTL on a Stage 3 Tarball
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 12, 13, 14 ... 16, 17, 18  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
Crete
n00b
n00b


Joined: 26 Feb 2005
Posts: 54
Location: Kansas City

PostPosted: Tue Mar 01, 2005 12:28 am    Post subject: Reply with quote

I am not ready for this but I hope to be someday:wink:. Good to know I have alot of room to grow though..heh.
_________________
Crete,

In God We Trust,
All Others Bring Data
Back to top
View user's profile Send private message
kailauro
n00b
n00b


Joined: 19 Feb 2005
Posts: 26

PostPosted: Tue Mar 01, 2005 4:52 am    Post subject: Reply with quote

I DO believe what you say about those binaries being compiled regardles of the toolchain being optimized. This procedure is being applied here with indeed nice results.

I'd stil like to know whats the difference between ...lets say KDE that was build using gcc plus the libraries that were build using :
CFLAGS="-O3 -march=pentium -mtune=pentium -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

and kde that was build using exactly the same flags exept with a compiler that whas build using no O -flags or other optimization at all.

I'd like to know what's the reason for both kde's being exactly the same. and especially...if the kde being build is optimized in both cases....would the compilers STILL give the exact same results.

I'd like to test but I'm sure there are good knowledge about this that I lack. and that someone could also interpret the result.

For a newbie it is kind of hard to believe that a compiler that "omits, forces, hides" and does skip parts in the process...still outputs the same OPTIMIZED binaries.
_________________
is there more to it than zeros and ones
Back to top
View user's profile Send private message
slycordinator
Advocate
Advocate


Joined: 31 Jan 2004
Posts: 3059
Location: Korea

PostPosted: Tue Mar 01, 2005 5:24 am    Post subject: Reply with quote

kailauro wrote:
For a newbie it is kind of hard to believe that a compiler that "omits, forces, hides" and does skip parts in the process...still outputs the same OPTIMIZED binaries.


Optimizing gcc (the compiler itself) will change HOW WELL it performs but not WHAT it performs.

So if gcc isn't optimized at all and you use it to compile a program using optimized cflags what happens is this:
gcc creates the optimized binaries but takes longer than optimal to do it.
Back to top
View user's profile Send private message
kimchi_sg
Advocate
Advocate


Joined: 26 Nov 2004
Posts: 2915
Location: Singapore

PostPosted: Tue Mar 01, 2005 6:16 am    Post subject: Reply with quote

slycordinator wrote:
So if gcc isn't optimized at all and you use it to compile a program using optimized cflags what happens is this:
gcc creates the optimized binaries but takes longer than optimal to do it.

The fun part about using less optimisation is this: You will get to spend more time away from the computer, wondering when on Earth it will ever, ever finish compiling KDE. :lol:
_________________
Murphy's Law of Gentoo installation: If a compile can fail, it will.

MacGillicuddy's Corollary: At the most inopportune time.

Please search and read the FAQs before posting.
Back to top
View user's profile Send private message
kailauro
n00b
n00b


Joined: 19 Feb 2005
Posts: 26

PostPosted: Tue Mar 01, 2005 7:38 am    Post subject: Reply with quote

there was a little linguistic typo earlier...ofcourse the compiler is not compiled to "omit and hide" but aren't those features that are being omitted and hidden NEEDED to build a compiler that is capable of optimizing the binaries to perform faster when run.

so a program is coded to do WHAT it does. and it's optimized with compiler flags to effect HOW it does what it does.

Am I given a better shovel to dig faster with optimization flags? (by for example using features on the CPU)

OR

Am I being taken away the tools to tune up a racing vehicle to run fast ??
_________________
is there more to it than zeros and ones


Last edited by kailauro on Tue Mar 01, 2005 8:09 am; edited 1 time in total
Back to top
View user's profile Send private message
kailauro
n00b
n00b


Joined: 19 Feb 2005
Posts: 26

PostPosted: Tue Mar 01, 2005 8:06 am    Post subject: Reply with quote

here's my question in detail....

if I build the very compiler and libs to:
-fforce-mem
-foptimize-sibling-calls
-fstrength-reduce
-fcse-follow-jumps -fcse-skip-blocks
-frerun-cse-after-loop -frerun-loop-opt
-fgcse -fgcse-lm -fgcse-sm
-fdelete-null-pointer-checks
-fexpensive-optimizations
-fregmove
-fschedule-insns -fschedule-insns2
-fsched-interblock -fsched-spec
-fcaller-saves
-fpeephole2
-freorder-blocks -freorder-functions
-fstrict-aliasing
-falign-functions -falign-jumps
-falign-loops -falign-labels
(the -O2 flag alone does this let alone O3 +)

Does the compiler still have the functionality to make faster binaries?
_________________
is there more to it than zeros and ones
Back to top
View user's profile Send private message
kimchi_sg
Advocate
Advocate


Joined: 26 Nov 2004
Posts: 2915
Location: Singapore

PostPosted: Tue Mar 01, 2005 9:29 am    Post subject: Reply with quote

kailauro wrote:
Am I given a better shovel to dig faster with optimization flags? (by for example using features on the CPU)

Yes.

The follwing point is very important so I will put it in bold, blue and large font:
Using optimisations does not change, reduce or add to the abilities of either the toolchain doing the compiling, or the toolchain being re-compiled. Your newly compiled toochain will have all the functionality of the old, pre-compiled one, only it can do things faster.
(Apologies to Bob P for ripping off his "emergency" reply style. :P )

I will not reply to your second post, because I think by asking so many questions, you are rapidly confusing yourself, and the second post is a good example of your confusion. Please, wait for other people to answer your questions, before you get all worked up wondering if the toolchain will have reduced power if it gets re-compiled. :lol:

Also, I think you have not bothered to read our replies, otherwise Slycoordinator's reply to your first post in this topic would have cleared up the issue for you already. I prefer to think of more meaningful ones, like whether my legs will get tired after running 6km, or whether your forums signature has any meaning at all. ;)
_________________
Murphy's Law of Gentoo installation: If a compile can fail, it will.

MacGillicuddy's Corollary: At the most inopportune time.

Please search and read the FAQs before posting.
Back to top
View user's profile Send private message
Sheepdogj15
Guru
Guru


Joined: 07 Jan 2005
Posts: 430
Location: Backyard

PostPosted: Tue Mar 01, 2005 12:21 pm    Post subject: successful install on AMD64 Reply with quote

well, i'm happy to report that i had a virtually problemless Stage 1 install on Stage 3 tarball on the AMD64 archtecture.

i only had one problem and that was with the Gensplash thing, but it isn't important enough to me to spend time troubleshooting so i'll live contently with a nice system lacking bootsplash. everything else worked fine.

there are a few deviations from the instructions to note for amd64. For one, gcc 3.4.3 is marked as stable for amd64 (but not in x86... figure that one out :lol:). also, the 2004.3 live CD came with 3.4.2, which was also stable for amd64. but despite that i still did the emerge to gcc 3.4.3, assuming that there might be some optimization (even if not as great as from 3.3.4).

when gcc was said and done, 3.4.3 was already set to default, which was strange, but oh well.

also, it should be noted that if someone does this, they should read the supplimental info on amd64 first. for instance, if you want 32bit compatibility (needed if you want nice proprietary crap like flash or real/win codecs), you must have multilib in your USE flags prior to emerging GCC. also make sure you have IA32 Emulation turned on in the kernel, and eventually you might want to emerge these:

emerge app-emulation/emul-linux-x86-baselibs
emerge app-emulation/emul-linux-x86-xlibs
emerge app-emulation/emul-linux-x86-gtklibs
emerge app-emulation/emul-linux-x86-qtlibs

last i checked the qtlibs one was masked. i haven't needed it yet but if need just use ACCEPT_KEYWORDS="~amd64"; but for criminy sakes don't put that in your make.conf.

other than that, there isn't much difference. substitute "amd64" everywhere where the tutorial calls for "x86".

my cflags stuff:
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon-64 -O2 -pipe -fweb -frename-registers"
CXXFLAGS="${CFLAGS}"

as you can see they almost as conservative as Rush Limbaugh. but that isn't a bad thing as i've had woolier cflags break GCC in the past.
Back to top
View user's profile Send private message
kailauro
n00b
n00b


Joined: 19 Feb 2005
Posts: 26

PostPosted: Tue Mar 01, 2005 2:16 pm    Post subject: Reply with quote

Thanks kimchi_sg & slycordinator for your answers.

I had trouble making a point about something that I have a very simple abstraction about and not that much knowledge. No confusion here.

Not that many people seem know what really happens after the source has been sent to compilation. also the toolchain is used to compile the system that includes all kinds of functionality that a computer can possibly have!!

Given the nature of that low-level processing that takes place it's not in my knowlege at all how the binaries are given a faster performing form.

I knew that I'm douting somethign that questions believes about what we're doing and putting lot's of effort to.

So my really and truly last question would be....

Do that answer of yes and no base on a causal knowledge about the inner workings of gcc or is it a belive that has some trial and error evidence to ackowledge??

Should I try to get in touch with makers of gcc. There wasn't that many references to those folks @ gcc home ;)

feel free to erase, simplify or edit my questioning.

I'm so very pleased that this procedure really does have a nice result. No problems whatsoever. Just a great improvement in smoothnes of using computer between a gentoo prepared this way and any other distro I've tried. Giving the computer some extra lifespan.

I'll be doing this on another box as well. Why in the heck not!!

I'll go on with the "press this to get this" -philosopfy for now on this matter...

PS. could you also make bzip2 perform at the speed of tar?
Yours, Kai Lauronen
_________________
is there more to it than zeros and ones


Last edited by kailauro on Tue Mar 01, 2005 11:25 pm; edited 1 time in total
Back to top
View user's profile Send private message
ronvenema
Apprentice
Apprentice


Joined: 16 Jan 2005
Posts: 160
Location: Dewey, Az

PostPosted: Tue Mar 01, 2005 3:02 pm    Post subject: Reply with quote

Removed

Last edited by ronvenema on Sat Mar 05, 2005 3:08 pm; edited 1 time in total
Back to top
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Tue Mar 01, 2005 3:40 pm    Post subject: Reply with quote

--

Last edited by 96140 on Fri Sep 13, 2013 9:51 am; edited 1 time in total
Back to top
View user's profile Send private message
Heidrun
n00b
n00b


Joined: 04 Feb 2005
Posts: 3
Location: Denmark

PostPosted: Fri Mar 04, 2005 9:44 am    Post subject: grub.conf Reply with quote

Just a detail in the guide at the first page section 9.4.1Grub.conf...

Quote:
# By default, boot the first entry.
default 1

# Fallback to the second entry.
fallback 0

shouldn't it be:
Code:
# By default, boot the second entry.
default 1

# Fallback to the first entry.
fallback 0

P.s. Nice guide! will try using it on my AMD64.
_________________
AMD64 3200+ Asus K8N-E Deluxe (nforce3 250GB)
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Fri Mar 04, 2005 8:06 pm    Post subject: Reply with quote

thebigslide wrote:
It is easy to use a file like /etc/portage/package.cxxflags to override cxxflags for specific offenders.

you know, someday when i have a little spare time i am going to get around to learning how to do your package-specific cflags thing. i'm sure that it would save me one hell of alot of time. :idea:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Fri Mar 04, 2005 8:11 pm    Post subject: Reply with quote

kimchi_sg wrote:
How about emerging ccache early on in the installation process?

Ccache is not enabled until you explicitly emerge it, on top of having "ccache" in FEATURES. :o

hmmm.... that would definitely be worth looking into. i have a box that is rebuilding from the ground up right now. i only wish that i had caught this post earlier ...


kimchi_sg wrote:
slycordinator wrote:
So if gcc isn't optimized at all and you use it to compile a program using optimized cflags what happens is this:
gcc creates the optimized binaries but takes longer than optimal to do it.

The fun part about using less optimisation is this: You will get to spend more time away from the computer, wondering when on Earth it will ever, ever finish compiling KDE. :lol:

sly, kimchi_sg: those have to be the two best one-liners i've come across in a long time! :!:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Fri Mar 04, 2005 8:20 pm    Post subject: Re: grub.conf Reply with quote

Heidrun wrote:
shouldn't it be:
Code:
# By default, boot the second entry.
default 1

# Fallback to the first entry.
fallback 0

P.s. Nice guide! will try using it on my AMD64.


geez, we're already into the 13th page of comments on the installation method -- i'm surprised that it took this long for somebody to catch that misteak! :oops:

the idea was to fall back to the non-framebuffer kernel choice if the frambuffer configuration was borked. in reality, it would be better to configure a system to fall back to an older version of a kernel (or to genkernel) if your newly compiled kernel borked the system. at least that's the idea behind the need for a fallback option in grub.conf.

thanks for catching the error. :wink:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Master One
l33t
l33t


Joined: 25 Aug 2003
Posts: 754
Location: Austria

PostPosted: Sat Mar 05, 2005 1:34 pm    Post subject: Reply with quote

Well, just an update for those, who care:

After taking some time to study the gcc onlinedocs, I reverted to the following save set of flags for my IBM ThinkPad T42p:
Code:
CFLAGS="-O2 -march=pentium-m -pipe -fforce-addr -fomit-frame-pointer -fweb"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
LDFLAGS="-Wl,-O1"

The clue is, these few flags most likely will give a much better results, than the formerly used stacked "insane" flags.
I now see the sense of going -O2 instead of -O3, at least one of the "insane" flags had questionable results (-fprefetch-loop-arrays -> "These options may generate better or worse code"), and one definitely broke libs without error on compile (-fvisibility=hidden -> only to be used by developers, at least for now).

I compiled my whole system with these save set of flags, started right from the beginning with Bob P's fabulous installation method, and at the moment I am emerging KDE 3.3.2-r1 (I keep staying on the stable side now, and let others do the KDE3.4.0_rc1 testing).

This time everything looks alright.
_________________
Las torturas mentales de la CIA
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sat Mar 05, 2005 3:31 pm    Post subject: Reply with quote

Master One wrote:
Well, just an update for those, who care:

After taking some time to study the gcc onlinedocs, I reverted to the following save set of flags for my IBM ThinkPad T42p:
Code:
CFLAGS="-O2 -march=pentium-m -pipe -fforce-addr -fomit-frame-pointer -fweb"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
LDFLAGS="-Wl,-O1"

The clue is, these few flags most likely will give a much better results, than the formerly used stacked "insane" flags.
I now see the sense of going -O2 instead of -O3, at least one of the "insane" flags had questionable results (-fprefetch-loop-arrays -> "These options may generate better or worse code"), and one definitely broke libs without error on compile (-fvisibility=hidden -> only to be used by developers, at least for now).


to reach a high degree of success on a wide variety of platforms, i think that its important to be selective about one's choice of cflags. fwiw, i'm still not using the insane set of cflags on my system. i'm still limiting myself to the conservative and performance-enhancing cflags that i've used in the Guide. although the use of some of those other flags (suggested by kimchi-sg) may be alluring, its important to remember that they can act as a double edged sword. some of them cause alot of problems -- more problems than they are worth.

i don't use -funroll-loops, for example. that flag has acquired a deservedly bad reputation. -fprefecth-loop-arrays is another one.

i've said it before, and i'll say it again:

Stage 1/3 Guide wrote:
7.2.1 Updating make.conf

Here are some settings for /etc/make.conf that may be worth considering. They are the actual CFLAGS that I used to build my systems and have proven reliable on multiple installations. They include extreme levels of code optimization (notice the -O3 flag), and some very safe and stable performance-enhancing CFLAGS. Depending upon your individual hardware, you may have to simplify some of the CFLAGS settings. Note that the referenced architecture in this example is Intel Pentium.

Code:
CFLAGS="-O3 -march=pentium -mtune=pentium -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"


If you don't feel comfortable using such extreme levels of optimization, you can ease-up on the CFLAGS settings and fall back to a less-optimized system. This will save you some compile time, at the expense of some system performance. You'll still be getting most of the benefits of GCC 3.4.3, so this isn't a bad compromise. This may be a better approach for those who don't want to be on the bleeding edge or don't want to spend time troubleshooting.

Code:
CFLAGS="-O2 -march=pentium -mtune=pentium -pipe"
CXXFLAGS=${CFLAGS}



these cflags are conservative. they are extensivley tested and they are proven to be safe. in the Guide, i have specifically warned people about the need for troubleshooting that would result from using anything other than the recommended flags. kimchi_sg also made his warnings in bold faced red type. its really surprising to me that in spite of repeated warnings, people decide to use flags other than those that are recommended. its as if there's some overpowering vortex that is pulling everyone into the land of the Gentoo Ricer. not that there's anything wrong with that, of course, as long as the user is willing to accept the responsibility for troubleshooting their own system. unfortunately, that kind of trouble is going to follow for those that insist on adding to the cflags. the funny thing is that the problem is completely avoidable, but people just can't seem to resist the temptation to subject themselves to it.

my personal recommendation is to stick with the cflags that are recommended in the guide. when i wrote the guide, i tested those cflags extensively on a wide variety of PCs. i performed a large number of installations, and i got rid of cflags that caused problems. if the user is going to try out cflags other than those that are listed, they should expect to encounter problems that will require troubleshooting.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
ronvenema
Apprentice
Apprentice


Joined: 16 Jan 2005
Posts: 160
Location: Dewey, Az

PostPosted: Sun Mar 06, 2005 4:35 am    Post subject: Reply with quote

Bob, I can attest that the ccache makes a huge difference in compiling time. I'm in the process of finishing a new install and Kde compiled in about 1/3 less of the time.:D
_________________
Frustration leads to knowledge.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sun Mar 06, 2005 7:17 pm    Post subject: Reply with quote

i haven't had much opportunity to tinker with ccache much in the past few days, other than to verify that the cache feature does indeed work when emerging programs. i haven't had any chance to compare benchmarks with ccache enabled vs. disabled. (i've been rather busy over the past few days, as i've just acquired a new scanner with automatic document feed, and i've been spending the past few days scanning and shredding documents. i've already scanned a couple of drawers worth of paper out of my filing cabinet and replaced them with CDs. WOW! 8O)

regarding ccache, it would seem a good idea to emerge it early enough in the install process to save you some time in compiling, but late enough in the process that its already been built with a stable toolkit. for this reason, i'm thinking about adding the following to the guide:

New Addition to the Guide wrote:
7.3.0 Emerge Ccache We'll now emerge the ccache program to help speed-up our compile times. This should markedly reduce the time required to compile programs when the -O2 or -O3 parameters are in use.
Code:
# emerge ccache

Some people might ask why I chose to emerge ccache at this rather late point in the installation instead of emerging it much earlier, say in Section 6.7.3. Here's the idea that I have about doing it later rather than sooner:

Insofar as I haven't had a chance to actually test build a system using ccache, I am reluctant to recommend emerging ccache as Section 6.7.3 and using it to rebuild the toolkit. In order to be conservative, I don't think that its a good idea to recommend the use of ccache to build the system toolkit until I've had enough time to prove that it is safe and reliable. for this reason, I prefer to start off with the recommendation of delaying the emergence of ccache until after the toolkit has been rebuilt; by doing this we're going to sacrifice some of the potential time-saving during the toolkit build by taking the conservative approach.

I won't have an opportunity to test build systems both ways (emerging ccache early as Section 6.7.2 and emerging it late as Section 7.3.0). So I'd appreciate it if somebody with time on their hands could perform installations on two similar systems, side by side, compare the results, and report back to us.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
ronvenema
Apprentice
Apprentice


Joined: 16 Jan 2005
Posts: 160
Location: Dewey, Az

PostPosted: Sun Mar 06, 2005 8:42 pm    Post subject: Reply with quote

I can second your idea of adding ccache later after the toolchain has been completed as that's how I did it. My main objective was to use it for all those huge programs like Kde.
I also wanted to mention that Section 6.5 in your example make.conf you show the appropriate entries for ccache but you show ccache_size="512M", but the "bible" shows ccache_size="2G" which is what I used. I assume that you would need the larger value in order to compile programs like Kde.
_________________
Frustration leads to knowledge.
Back to top
View user's profile Send private message
ephilli2
n00b
n00b


Joined: 18 Sep 2004
Posts: 27

PostPosted: Mon Mar 07, 2005 3:20 am    Post subject: Reply with quote

I just wanted to thank you for the great install guide. It went off without a hitch...well almost. I used gentoo-dev-sources as my kernel which I didn't realize wouldn't work with my reiser4 partitions. I had used the lxnay RR4 live cd to create the partitions. I tried nitro, morph, but 2.6.11-love1 was the only one that was able to boot successfully. At least now I'm more confident about recompiling kernels if not a little exhausted.

ronvenema: as I understand it ccache is just a bonus feature, if it finds a piece of code that it has compiled before in the cache it will use that instead of compiling again. So, the larger the cache, the more likely a piece of code will be found in it, the shorter the compile time. A huge cache is beneficial to the system as a whole not just for compiling large programs like KDE.

Thanks again Bob P

(edit)
I guess I could have tried using the lxnay cd's kernel by attempting something like this:
http://www.gentoo.org/doc/en/gentoo-x86-tipsntricks.xml#livecd-kernel

I may still try this since they cd was able to get my IPW2200 running ( I haven't attempted this yet on the current install)
_________________
Dell 600m Pentium M 1.5 Ghz, 512MB, 40GB, ATI M9
Stage 1 on 3, NPTL, GCC 3.4.3, 2.6.11-love1, Reiser 4
www.robotskirts.com
Back to top
View user's profile Send private message
slycordinator
Advocate
Advocate


Joined: 31 Jan 2004
Posts: 3059
Location: Korea

PostPosted: Mon Mar 07, 2005 8:21 am    Post subject: Reply with quote

kailauro wrote:
Thanks kimchi_sg & slycordinator for your answers.

I had trouble making a point about something that I have a very simple abstraction about and not that much knowledge. No confusion here.

Not that many people seem know what really happens after the source has been sent to compilation. also the toolchain is used to compile the system that includes all kinds of functionality that a computer can possibly have!!


Lets assume you were right all along and that only an optimized gcc can create optimized binaries.

NOTE: gcc is a binary. An optimized gcc is an optimized binary.

So how does one create an optimized gcc? Based on your assumption this can only be created using an optimized gcc. So when you have no optimized gcc you can't create one. But once one magically appears out of nowhere, you can create one.

That clearly doesn't work. Which means your assumption was false.

Quote:

PS. could you also make bzip2 perform at the speed of tar?


I doubt it.

tar is just an archiving utility. Tar would be like taking 50 pieces of paper and placing them together in one bag.

bzip2 is a compression utility. Using bzip2 would be like taking those 50 pieces of paper and combining the writing to use less paper.

tar's job seems easier. Also, bzip2 is slower than some other compression utilities because it does better compression than many.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Mar 07, 2005 12:23 pm    Post subject: Reply with quote

ephilli2 wrote:
ronvenema: as I understand it ccache is just a bonus feature, if it finds a piece of code that it has compiled before in the cache it will use that instead of compiling again. So, the larger the cache, the more likely a piece of code will be found in it, the shorter the compile time. A huge cache is beneficial to the system as a whole not just for compiling large programs like KDE.

i'm no expert about ccache, but i second your thoughts that the necessary code needs to be in the cache for the cache to do us any good! :D i think that some of the perceived improvements that @ronvenema noticed may not be necessarily real improvements.

remember, for ccache to do anyone any good, the compiled code has to already be in the cache. in the case where you've already compiled KDE on your PC, if your cache size is large enough, then KDE code is already going to be in the cache. this means that the second time that you compile KDE, you'll perceive a whopping increase in performance because KDE is already in the cache! this would definitely NOT be the case when you're compiling KDE for the first time! for obvious reasons, the 30% reduction in compiling time with/without ccache doesn't translate into a reliable 30% reduction in compile times.

so in the big scheme of things, ccache isn't going to impart HUGE performance improvements in building your gentoo system as you follow the guide -- remember, for the most part, when you're following the guide, you're creating a de novo system installation, and no pre-existing code is going to be in your cache. this means that the HUGE performance improvement perceived by @ronvenema will only be realized when recompiling code that you've compiled at least once before.

now this is not to say that ccache won't help you when emerging your programs -- if you're using -O3 optimization, for instance, ccache should find the all of the code that its working on in the cache for at least one compiling pass (as long as the value of your cache is nonzero).

at least that's the way i understand it. but then i don't have any real experience digging into the bowels of ccache, so i could be wrong... :roll:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Mar 07, 2005 12:25 pm    Post subject: Reply with quote

slycordinator wrote:
That clearly doesn't work. Which means your assumption was false.

that's a nice example of applying basic symbolic logic to real life thinking. :wink:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Mar 07, 2005 12:29 pm    Post subject: Reply with quote

ronvenema wrote:
I also wanted to mention that Section 6.5 in your example make.conf you show the appropriate entries for ccache but you show ccache_size="512M", but the "bible" shows ccache_size="2G" which is what I used. I assume that you would need the larger value in order to compile programs like Kde.

ron, my choice of 512M was based on the fact that i was building a router on a pentium-class machine in the example used in the guide. that choice was application-specific for the size of the disk that i had on-hand for that project -- a system upon which a bloated resource hog like KDE would never be installed! insofar as the Guide is not intended as a Universal Installation Handbook, the value of 512M shouldn't be considered as cast in stone -- users are free to change basic things like cache sizes to suit there individual needs.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page Previous  1, 2, 3 ... 12, 13, 14 ... 16, 17, 18  Next
Page 13 of 18

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum