[gentoo-amd64] 64 or 32?

[gentoo-amd64] 64 or 32?

[Thierry de Coulon]

Hello,

I'm testing several distributions on my new dual-opteron. I did a gentoo-64 
install - and managed to screw it up, but this was expected as I was testing. 
I have confirmed that I dislike (k)ubuntu for several reasons, either 64 or 
32 bit. SuSE 64 hasn't impressed me either. I have managed to install Simply 
Mepis (32bit) and compile an Opteron kernel and it works well.

Now is time to re-install Gentoo, however after a lot of thinking I have come 
to the following conclusions (which may be wrong):

- for what I'd like to do with video (ripping and converting DVDs and DV 
processing) 64 bit software is not ready: I did not check directly if 
transcode works, but DVDRip would not start. Cinelerra didn't install either, 
only kino worked - and MainActor is still 32 bit, if it works at all.
- regarding audio, 64bit is not an issue. Ripping the CD allready took more 
time than converting to ogg on my dual Athlon.
- standard desktop applications, as far as I am concerned, heavily rely on 
OpenOffice.org and that is still 32 bit
- gaming also requires 32bit

So I am thinking that a 32bit Gentoo is the way to go. I may switch to 64bit 
later, when it really (?) brings something

Does anyone have other arguments to justify the troubles of working with a 
64bit install at the moment?

Thierry

-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] 64 or 32?

[Martins Steinbergs]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On Friday 10 February 2006 02:35, Thierry de Coulon wrote:
> Hello,
>
>
> - for what I'd like to do with video (ripping and converting DVDs and DV
> processing) 64 bit software is not ready: I did not check directly if
> transcode works, but DVDRip would not start. Cinelerra didn't install
> either, only kino worked - and MainActor is still 32 bit, if it works at
> all. - regarding audio, 64bit is not an issue. Ripping the CD allready took
> more time than converting to ogg on my dual Athlon.

transcode, DVDRip, ffmpeg, mencoder works well here

m
-- 
Linux 2.6.15-ck3-r1 AMD Athlon(tm) 64 Processor 3200+
 01:52:36 up  7:32,  4 users,  load average: 1.03, 1.39, 1.72

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] 64 or 32?

[Bob Sanders]

Thierry de Coulon, mused, then expounded:
> Hello,
> 
> 
> - for what I'd like to do with video (ripping and converting DVDs and DV 
> processing) 64 bit software is not ready: I did not check directly if 
> transcode works, but DVDRip would not start.

DVDrip and transcode work fine for me under 64-bit.  While there are
issuse with 32-bit only codecs, they can be worked around in multiple
ways, including a 32-bit chroot environment.

Try adding the following for video output - "-vo sdl"

It solves some of the issues.


> - regarding audio, 64bit is not an issue. Ripping the CD allready took more 
> time than converting to ogg on my dual Athlon.

I suggest that something is set up incorrectly or your comparision is off for some
reason.  Though, the Opterons do transfer a full 64-bit word containing a 32-bit
value for each audio packet.  In general, I've not seen my dual Opteron to be
slower than the dual AthlonMP I ran.  Converting to ogg with grip, is faster
on my dual Opteron system.


> - standard desktop applications, as far as I am concerned, heavily rely on 
> OpenOffice.org and that is still 32 bit

Desktop apps are fine at 16-bit.  Why go to 32-bit?

> - gaming also requires 32bit
>

Perhaps you don't run the 64-bit version of ut2004 or doom3?
 
> So I am thinking that a 32bit Gentoo is the way to go. I may switch to 64bit 
> later, when it really (?) brings something
> 
> Does anyone have other arguments to justify the troubles of working with a 
> 64bit install at the moment?
>

Simple, at 64-bit, one can run both 64-bit apps and 32-bit apps.  At 32-bit,
one can only run 32-bit apps.  And 64-bit apps will take advantage of the
extra register set.  A 64-bit kernel provides a faster os due to being more
efficient, and having access to the extra registers.

In gentoo the make.conf CFLAGS becomes - "-mach=k8", while for 32-bit, both
"-mach=k7" and the USE flags - mmx, sse, sse2, (perhaps) sse3, 3dnow, and 
3dnowext, all need to be set.  Otherwise, your performance suffers when doing
video.

Bob 
-  
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] 64 or 32?

[Patrick McLean]

Bob Sanders wrote:
> 
>> - standard desktop applications, as far as I am concerned, heavily rely on 
>> OpenOffice.org and that is still 32 bit
> 
> Desktop apps are fine at 16-bit.  Why go to 32-bit?
> 
If you can convince OpenOffice to run in 64kb (the maximum amount of memory a
16-bit program is capable of using) of address space, I think Sun or Google
would very much like to hire you to do so.

Sometimes I wonder if 32bits is enough for it...

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] 64 or 32?

[Bob Sanders]

Patrick McLean, mused, then expounded:
> Bob Sanders wrote:
> > 
> >> - standard desktop applications, as far as I am concerned, heavily rely on 
> >> OpenOffice.org and that is still 32 bit
> > 
> > Desktop apps are fine at 16-bit.  Why go to 32-bit?
> > 
> If you can convince OpenOffice to run in 64kb (the maximum amount of memory a
> 16-bit program is capable of using) of address space, I think Sun or Google
> would very much like to hire you to do so.
> 
> Sometimes I wonder if 32bits is enough for it...
>

Having been around awhile, I've used/supported Word Processing systems starting
with IBM selectric's electonically connected to and overgrown shift register
and tape storage, to PDP8s and VT278s running DEC's Gold Key packages (12 bits)
to integrated packages - AtariWorks (16-bits, well, 32-bits internally). 

The problem isn't with the number of bits.  The problem is trying to emulate
Microsfot Office which is, sadly, accepted as the pinnacle of office suites.

Bob
-  
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] 64 or 32?

[Brian Litzinger]

On Fri, Feb 10, 2006 at 12:35:08AM +0000, Thierry de Coulon wrote:
> Now is time to re-install Gentoo, however after a lot of thinking I have come 
> to the following conclusions (which may be wrong):

Running 64 and 32 bit simultaneously has not had any issues for me.
Certainly since release 2005.0.
Well maybe a minor one here or there.

I run native 64, with 32 emul, and native 32 chroot.  I've read
that some people have had some issues somewhere with X, but I
never ran into them.

-- 
Brian Litzinger
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] 64 or 32?

[Hemmann, Volker Armin]

On Friday 10 February 2006 01:35, Thierry de Coulon wrote:

>
> - for what I'd like to do with video (ripping and converting DVDs and DV
> processing) 64 bit software is not ready: I did not check directly if
> transcode works, 

well, it should. At least I have it installed.

> but DVDRip would not start. Cinelerra didn't install 
> either, only kino worked - and MainActor is still 32 bit, if it works at

wgich should all work with the 32 bit emul libs.

> all. - regarding audio, 64bit is not an issue. Ripping the CD allready took
> more time than converting to ogg on my dual Athlon.
> - standard desktop applications, as far as I am concerned, heavily rely on
> OpenOffice.org and that is still 32 bit
> - gaming also requires 32bit

no it does not

ut2004 for example is available in a 64bit version.
And even if not, it would work with the emul-libs.

>
> So I am thinking that a 32bit Gentoo is the way to go. I may switch to
> 64bit later, when it really (?) brings something

It does bring something today:
8 more registers.
And for encoding stuff, it should make a difference.
>
> Does anyone have other arguments to justify the troubles of working with a
> 64bit install at the moment?
>

there are no troubles?
Only if you need flash and or the win32codec package, you have to install 
firefox-bin and mplayer-bin.

And since it does not make sense to compile firefox, it does not hurt.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] 64 or 32?

[Brett Johnson]

On Fri, Feb 10, 2006 at 12:35:08AM +0000, Thierry de Coulon wrote:
> 
> - for what I'd like to do with video (ripping and converting DVDs and DV 
> processing) 64 bit software is not ready: I did not check directly if 
> transcode works, but DVDRip would not start. Cinelerra didn't install either, 
> only kino worked - and MainActor is still 32 bit, if it works at all.
I use mencoder (mplayer) in 64 bit mode to rip dvd's to mpeg4 (divx)
without issues.

> - regarding audio, 64bit is not an issue. Ripping the CD allready took more 
> time than converting to ogg on my dual Athlon.
I am finishing up re-ripping my CD library to flac and then to ogg. I
don't have any benchmarks, but I swear it's faster in gentoo64 then when
I did it the first time with WinXP (32) on the same hardware.

> - standard desktop applications, as far as I am concerned, heavily rely on 
> OpenOffice.org and that is still 32 bit
OOo works fine in bin format

> - gaming also requires 32bit
cedega works fine here with emul- libs, no major performace difference
between 32 and 64 that I've seen in my testing (playing  WoW)

> Does anyone have other arguments to justify the troubles of working with a 
> 64bit install at the moment?

No arugments here, the wonderful thing about gentoo is the freedom to
choose what is best for you. If there are applications you have found
that aren't 64 bit ready, and don't feel like setting up a 32 bit
chroot, then the 32 bit install is probably your best choice. If you
like to push the technology to it's limits, and are willing to deal with
minor issues, then maybe go 64 bit now, as it only gets better with
time. It could save you a lot of time down the road since switching from
32 to 64 will take a full reinstall.

Brett
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: 64 or 32?

[Duncan]

Thierry de Coulon posted <200602100035.08352.tcoulon@decoulon.ch>,
excerpted below,  on Fri, 10 Feb 2006 00:35:08 +0000:

> Hello,
> 
> I'm testing several distributions on my new dual-opteron. I did a gentoo-64 
> install - and managed to screw it up, but this was expected as I was testing. 
> I have confirmed that I dislike (k)ubuntu for several reasons, either 64 or 
> 32 bit. SuSE 64 hasn't impressed me either. I have managed to install Simply 
> Mepis (32bit) and compile an Opteron kernel and it works well.

Gratifying that Gentoo has impressed you enough to continue with it, after
having rejected most of the other distributions.

> So I am thinking that a 32bit Gentoo is the way to go. I may switch to
> 64bit later, when it really (?) brings something
> 
> Does anyone have other arguments to justify the troubles of working with
> a 64bit install at the moment?

The others have dealt with the specific apps you mentioned, so I'll do an
overview, which seems somewhat missing in most of the posts so far.

Technically, amd64 does very well in 32-bit mode, so there's no reason to
run 64-bit if it's doing nothing for you ATM.  That may or may not be the
case, however, provided of course you get the 64-bit side setup correctly
and optimized for your usage.

There's no doubting that 64-bit is currently somewhat more complex, in
particular for those who need to run 32-bit stuff not yet available in
64-bit.  For that reason, it could be argued that staying with 32-bit for
the moment is a better choice.  However, 64-bit amd64 *IS* the successor
to 32-bit x86, that seems rather self-evident by this point.  It could be
argued that getting in on the 64-bit stuff now will not only give you a
head-start later, but a better understanding, as you /do/ still have to
deal with some additional complexity in the 32-bit/64-bit stuff, that will
be pretty much taken care of down the road.  Whether that better
understanding is valuable enough to you to justify the complexity
tradeoff or not only you can answer, BUT I believe it's critical that you
don't short-change yourself in making that decision by having a wrong
impression of just how powerful the 32-bit/64-bit dual-bitness of amd64
can be.

Realistically speaking, there's very little technical reason to run 32-bit
x86 where 64-bit amd64 (aka x86_64) is available.  It's all down to the
complexity of the solution.  The extra registers and the like available to
64-bit mode almost always more than make up for the additional length of
the address space, even where 32-bits of data is plenty for the
application being handled.

If you have significant reason to need 32-bit-only binary codecs (which
will almost certainly eventually be available in 64-bit as well, as even
MS is headed that direction), or run 32-bit only games, then yes, the
compound 32/64-bit solution is more complex.  However, even those should
run as good, and likely better, on a 64-bit base system, due to the
additional efficiencies in the 64-bit system.  There's nothing unavailable
on the 64-bit system that's available on 32-bit, because 32-bit can run on
both, provided the rules are followed, and the 64-bit system in general
should run more efficiently.

If you have no significant reason to run 32-bit only code, than
unquestionably, 64-bit is superior.  However, it does look like that's
going to be a way off, for your usage.  It should come, however, and one
of the questions you have to deal with is whether dealing with the
additional complexity and learning the system now, is worth the hassle,
over having to deal with somewhat less hassle later, given that the
technical side either comes out marginally in favor of amd64 or as a wash.

Basically, it comes down to this.  If you don't view yourself as a power
user, if you'd rather deal with a little less complexity later, than
somewhat more complexity now, and the loss of a marginal bit of
performance in the mean time doesn't significantly bother you, than
honestly, 32-bit is likely going to be the better choice at this time. 
If, however, you consider yourself a power user, if dealing with a bit of
additional technical complexity now as compared to if you wait sounds more
like an enjoyable challenge than drudgery and hassle, if you don't like
the idea of yielding even that marginal performance difference, then you
probably want to go with amd64 now, sooner rather than later.

Personally, I definitely consider myself in the latter category, and
deliberately chose to go amd64 a couple of years ago, in part /because/ I
wanted in on the "ground floor" of the architecture -- I didn't want to
miss out on all those challenges.  Many of them are already gone -- it's a
significantly smoother ride now than it was.  However, there's still
enough left that getting in now and learning how to deal with some of
those remaining issues will give you a better understanding of your
architecture than those who wait until they don't have to run 32-bit at
all, because everything is available in 64-bit.

There is, however, nothing at all wrong with being simply a user (altho
on Gentoo, being a Gentoo user by definition means being the sysadmin of
a Gentoo system as well, with the responsibilities that brings to keep
the system secure and the like), one who prefers a system that "just
works", who has other areas in their life they consider more important,
with all the complexity there they can manage, and thus, who has no
interest in additional complexity when it comes to their computer.  This
sort of user will probably want to stay 32-bit at this point, and
honestly, but for the fact that Gentoo has such a helpful community and
such highly regarded documentation, might be better off choosing another
distribution, as well.

Your reality is actually most likely somewhere in the middle, particularly
as  you've already rejected some of the other distributions, and there
must have been a reason for doing so, which by definition already
self-selected for a Gentoo bias to some extent.  However, it remains a
choice you have to make -- none of us can or should try to make it for
you, and while we certainly have our own biases and certainly do what we
can in the persuasive arena, I doubt any of us would /want/ to make your
decision for you.  =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: 64 or 32?

[Thierry de Coulon]

Thank you all for your answers (I'm not going to quote them all). A special 
thank to Duncan.
I sure have to get more understanding of how to run 32bit apps on a 64bit 
distro - I am willing to learn but you'll probably have to suffer a lot of 
questions from me. But this does not seem to be a problem on this list :)

I'll think it over again, but I think I'll go for a compromise (we swiss are 
well known for this way of doing, aren't we?): I have a working Mepis 32bit 
(the distribution I use on my "old" main machine. SO I'll probably build a 
64bit Gentoo and I can switch the day I feel it works the way I like.

Thanks again for your advices.

Thierry

-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: 64 or 32?

[Duncan]

Thierry de Coulon posted <200602100848.26651.tcoulon@decoulon.ch>,
excerpted below,  on Fri, 10 Feb 2006 08:48:25 +0000:

> I sure have to get more understanding of how to run 32bit apps on a 64bit 
> distro - I am willing to learn but you'll probably have to suffer a lot of 
> questions from me. But this does not seem to be a problem on this list :)

Happily, no.  It's a point of pride for many of us that Gentoo gets high
marks for the friendliness and accessibility of its user community. =8^)

> I'll think it over again, but I think I'll go for a compromise (we swiss are 
> well known for this way of doing, aren't we?): I have a working Mepis 32bit 
> (the distribution I use on my "old" main machine. SO I'll probably build a 
> 64bit Gentoo and I can switch the day I feel it works the way I like.

We'll all be rooting for you! 

Note that I took something like three months to get my Gentoo amd64 system
up and running, in part because  I had some very specific ideas of how I
wanted it to look and work when I was done, and as I result, had to adapt
the installation instructions somewhat.  Some of those adaptations turned
out to be mistakes, or cause something else to break, so I'd have to go
back and "unbreak" things, and actually started over a couple times.  Of
course, the whole time I was learning all the more, because I was breaking
things and learning how they worked and how to fix them in the process,
and the whole time I was keeping up on the user, amd64, and devel lists
(the latter of which I follow in part because I like to have a heads-up on
where Gentoo is headed), so by the time I got a working system, to the
point where I /could/ experience some of the common mistakes of others, I
had not only read all about them and avoided making them myself, but
understood why they could happen and a bit about why the Gentoo devs
hadn't or couldn't simply ensure they didn't happen in the first place!

This was all possible because while I only have a single system going, I
had a fully working Mandrake for AMD64 installation on another set of
partitions, and would routinely have a chroot session going, in which I'd
be setting up something in Gentoo, or trying out some strange alternative
of my own, but it was just a chroot running in a konsole window on my
otherwise normally operating Mandrake system.  Of course, the fact that
my system is a dual Opteron helped with that, keeping all the Mandrake
stuff responsive even as I was emerging something on the Gentoo side for
the Nth time, because I was too stubborn to simply follow instructions. =8^)

Note that this wouldn't have worked if I'd been running a 32-bit OS,
because the 64-bit compilations wouldn't have worked the same way in that
case, but that I had only a single computer to work on, while you can
simply keep running your 32-bit stuff on your current Mepis install, until
as you said, you are comfortable with the 64-bit Gentoo install on your
new machine.

Two hints I like to give to all new users:

1)  Gentoo documentation is considered some of the best in the community. 
Don't be afraid to use it.  In particular, the Gentoo Handbook is *NOT*
just the install section.  To make the best use of your new Gentoo system,
you'll want to read the Working with Gentoo and Working with Portage
sections as well (altho it's OK to skim the chapters dealing with ebuild
details and the like, just getting a bit of how ebuilds work out of them,
as helps in troubleshooting when one /doesn't work for you).  Very often,
it's quite apparent by the questions people ask, that they skipped that
information, and it just makes it harder for them to manage their system,
until the go back and read over it, or pick it up a piece at a time on the
lists and forums.  To me, that's a shame, when they could have avoided
needless pain and mistakes, and be managing their system much more
effectively, had they just read the documentation that's there to read.

2)  Before you get too far along, certainly before your first emerge
--update --deep world and preferrably before you start merging world
packages at all, consider adding "buildpkg" to your FEATURES line in
make.conf. What this does is covered in the handbook, so you'll understand
more about it after reading the sections I recommended above, but the
handbook doesn't quite convey how useful it can be in so many words, and
people often miss it.

What FEATURES=buildpkg does is simple, really.  It tells portage to
create and store a binary package for everything it emerges.  What this
means is that if you upgrade a package and find it isn't working quite
right, it's quite easy to use emerge -K to revert to the earlier version
that portage created a binary package of when it merged it.  Without this
binpkg, you'd have to do the entire remerge from source thing, which on
some packages can take awhile, all to see if it corrected the problem you
discovered with a new version, or if the problem was elsewhere.  If you
find the old version has the problem too, again, it's a very simple
process to remerge the now binpkged new version again.  (For doing the
same thing with already merged packages, there's the quickpkg utility. 
However, you have to know you'll need it to use it, while if portage
automatically creates the binpkgs, they'll be there for you when you need
them, whether you thought you might need them or not.)  There are some
other advantages to buildpkg as well, such as making it easier to recover
if gcc or even portage quits working, because you have a binary package
available, but these are side effects of the primary benefit, that those
binary packages are created and available for you in the first place.

The buildpkg FEATURE typically requires an additional 1-4 gigs of space to
store packages for the entire system.  A gig will usually just barely
cover one version of each package, two gigs gives you room for several
versions of the ones changing the fastest, four gigs gives you plenty
of room for expansion and means you won't have to worry about cleaning out
the oldest stale versions very often. (Newer versions of gentoolkit, a
very useful addition to portage that most folks eventually merge, include
eclean, a tool that helps manage the packages dir, cleaning out the stale
versions of packages.  I think eclean is only in the ~amd64 version,
however, not the stable amd64 version, yet.)  I arrived at the 1-4 gig
figure because I have my packages dir on a separate partition, here.  It's
now 4 gig for expansion, but 2 gig was usable, while a gig was simply
cramped.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list