On Sunday 23 January 2005 10:03 pm, kevin wrote:
> Now, I'm honestly not trying to be a jerk, but...that's like saying
> there's no benefit to stage1. I honestly don't understand the
> differences too well, so if I seem way off base, I prolly am... Just
> going by the readme, it say's you'll learn more, and have full control
> over optimizations w/ stage1. Stage3 is touted as being fastest to
> finish... it's downside, is stated as being unable to tweak the base
> system.

The "optimization" part is more for systems without a stage3, like Pentium 2.
With a stage3, you lose the chance to set your USE flags for the system 
packages.

> Are you saying the differences in performance from a stage1 base 
> system, and a stage3 base system, are negligible?

If you want certain USE flags set on your system, you need to use stage1 (or 
recompile the system later from a stage3)

> Really, not trying to be a jerk asking that question, I honestly don't
> know.... It _seems_ to me like having your compiler (that is what you make
> (gcc) during the bootstrap process, no?) optimized would have some
> non-trivial advantages.

All Athlon64 systems at this point, AFAIK, have the same features. Thus, there 
is no system-specific stuff to optimize for the arch yet.

> Again, I'm a newbie, and have to plead ignorance. I've just 
> read a lot about how things are better and faster when compiled from
> source for your architecture (across OS's, not just gentoo)...

Generally, this is true... but only when there is a difference between 
different CPUs for that arch.

> so, stage1 was a no-brainer for me. I never thought of working from 2 or 3.

A stage2 could be a very probably option. You'd still be able to set USE for 
your system and the compilers could be recompiled w/ changes in the 
background once you're up and running.

> It sounds like what you're saying is: there isn't a lot of difference in
> the core system you end up w/, wether you go w/ stage1 or stage3?

Not unless you set USE flags affecting system packages.

>
> > Now, when you start talking about applications, the ability to pass
> > -march and recompiling to the AMD64 native architecture instead of using
> > the x86 generic binaries *will* give you a substantial speed-up.
>
> Yeah, it's those statements exactly, that I hear everywhere in my
> computer travels, that make me try stage1 gentoo.

That's the difference between compiling for a "supported" arch (x86) and the 
native arch (x86_64). If you compile things for a x86, it obviously won't 
take advantage of the features the x86_64 arch provides.

> I'm just trying to get my head around this however... it sounds to me
> like you're saying from a system standpoint, the "base" system (OS, I/O,
> permissions, printing subsystem, networking, etc.) there's very little
> optimization you can do (and what's generic and safe, has already been
> done in the stage3 tarball). Stage1 optimizations's could almost be
> considered dangerous?

An x86_64 stage3 will already be compiled for x86_64. It might include x86 
libraries also, for all I know. In that case, you would want to use a stage1 
if you want a pure 64-bit system (w/o multilib).

> When installing applications however, you say there are significant
> benefits. This I understand. The Analogy given in the portage manual of
> compiling something large like OpenOffice w/ only your window managers
> functions (e.g. Gnome, but not KDE), makes a lot of sense to me. I had
> assumed it was the same at the Base system level (w/ ssl support seems
> non-trivial to me?).

Most people who use OO.o install it from a binary package which, unless it has 
changed recently, would include only x86 32-bit binaries. Actual binary 
ebuilds aren't too common, and I don't think any are included in the system.

>
> As a newbie to Linux it's hard for me to sometimes separate things like
> the GUI from the base-system in my head...  When you talk about the Base
> system, I think you have a very different idea in your head than I do?

IIRC, the "base system" in Gentoo terminology refers to the part of your 
system that packages assume exists. For example, plenty of packages need GCC 
to compile, but many don't actually DEPEND on it.
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

--
[email protected] mailing list

Reply via email to