Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
is ti worth going to 64 bit?
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo on AMD64
View previous topic :: View next topic  
Author Message
Uncle_Psychosis
Guru
Guru


Joined: 31 Jan 2004
Posts: 387

PostPosted: Tue Dec 28, 2010 9:10 am    Post subject: is ti worth going to 64 bit? Reply with quote

Hi guys

I'm currently running a 32 bit Gentoo system on an intel E4300. I'm about to migrate to a new hard drive and part of me thinks it might be fun/useful to move to 64bit Gentoo when I do so.

What do you reckon? Are things like flash still an issue?

Also, would I need to partition my drives any differently for 64 bit?

Finally---if I wanted to keep my existing make.conf and just alter it for 64bit, what would I need to change?

Cheers

Sam
Back to top
View user's profile Send private message
drwook
Veteran
Veteran


Joined: 30 Mar 2005
Posts: 1324
Location: London

PostPosted: Tue Dec 28, 2010 9:34 am    Post subject: Reply with quote

I've been running 64 bit gentoo for years now, across two main home machines and a few servers.

Nothing's been much of an issue for the last 2-3yrs IMO. back when it was all 'new and shiny' there were a few niggles but they're well behind us in the main.

Partitioning etc should all be fine, make.conf depends on contents but can prob copy what you want/need from the old one into the new (maybe not the whole file, chost etc ;) )


Last edited by drwook on Tue Dec 28, 2010 9:36 am; edited 1 time in total
Back to top
View user's profile Send private message
ppurka
Advocate
Advocate


Joined: 26 Dec 2004
Posts: 3256

PostPosted: Tue Dec 28, 2010 9:36 am    Post subject: Re: is ti worth going to 64 bit? Reply with quote

Uncle_Psychosis wrote:
Hi guys

I'm currently running a 32 bit Gentoo system on an intel E4300. I'm about to migrate to a new hard drive and part of me thinks it might be fun/useful to move to 64bit Gentoo when I do so.
Fun yes. Useful, depends. If you are into encoding videos, or running mathematical simulations, then yes. Otherwise it is mostly no.
Quote:
What do you reckon? Are things like flash still an issue?
Partially. There is a native 64bit beta version available (in portage too). But stability wise, it is just about ok. Not too great.
Quote:
Also, would I need to partition my drives any differently for 64 bit?
no
Quote:
Finally---if I wanted to keep my existing make.conf and just alter it for 64bit, what would I need to change?

Cheers

Sam
Simply your CHOST, CFLAGS and CXXFLAGS. That too depends. When you install gentoo anew using the 64bit tarball, it will set the correct CHOST. As for CFLAGS, if you have a simple one such as CFLAGS="-march=native -O2 -pipe" then you won't need to change anything.

if you do decide to go for 64bit, try to go for multilib system (the default). This will ensure that you can run some 32bit software in your 64bit installation. Some binary programs require this compatibility. So, it will be less painful than a pure 64bit system. Also, set the correct profile and I guess you won't need to change anything else in make.conf.
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Tue Dec 28, 2010 9:44 am    Post subject: Re: is ti worth going to 64 bit? Reply with quote

Uncle_Psychosis wrote:
it might be fun

:lol: If it's for fun then... you are right indeed ! Whatever you will get as advantages / disadvantages will be fun !

The following is just an opinion. I never tried Gentoo 32 but I still get several FreeBSD 32 that will never go 64.

1/ Flash is not an issue. There are 64 bits versions of flash. When Adobe occasionally suspends 64 bits support, you can still rely on the nspluginwrapper.

2/ Moving 64 bits is really usefull if you want to take full advantage of more than 4GB ram without having to play with a PAE kernel that sometimes causes issues with proprietary drivers that are sometimes not PAE compatible.

3/ If 64 bits code does not actually eat twice the amount of space of 32 bits code, it does needs more memory.

- This is not really significant with nowadays hard disks but, yes indeed regarding partitioning, it is wise to increase by 20-40% approx the size of the partitions where most of the code stands (/usr, /opt)
- This is not significant either for the RAM as... If it is worth the move (apart from fun :wink: ) we are supposed to get a fair amount of RAM.

The biggest deal is with performances.
64 bits code does per se bring a significant increase in performance for some applications. It will not give much for things such as openoffice, mails, browsers... and even the kernel's code itself.
It can lead to a significant increase with signal (image, sound...) processing applications.
But... if and only if...
You get a good amount of processor cache (L1/L2)
The move 32 -> 64 bits, increasing the size of the code will decrease the efficiency of these caches proportionally.
That is the biggest impact in performances.

So... You must just... try ! Depending on the applications you run, the amount of cache on your processor... You might well watch... a performance drop !
Back to top
View user's profile Send private message
LukynZ
Apprentice
Apprentice


Joined: 19 Dec 2008
Posts: 230
Location: The Czech Republic

PostPosted: Wed Dec 29, 2010 2:00 pm    Post subject: Reply with quote

64bit system is faster at all. It's not only about ram or just some apps. Entire system is faster. I have no idea, why anybody should wants to run 32bit system at 64bit cpu.
Back to top
View user's profile Send private message
chris...
Apprentice
Apprentice


Joined: 26 Sep 2006
Posts: 179
Location: Melbourne, AU

PostPosted: Mon Jan 03, 2011 8:48 pm    Post subject: Reply with quote

I have 3 computers all dual core all running gentoo and kde, the fastest one is running 64bit, it used to be the quickest, not so anymore. I want to go back to 32bit now
Back to top
View user's profile Send private message
Gusar
Advocate
Advocate


Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia

PostPosted: Mon Jan 03, 2011 8:52 pm    Post subject: Reply with quote

LukynZ wrote:
64bit system is faster at all. It's not only about ram or just some apps. Entire system is faster. I have no idea, why anybody should wants to run 32bit system at 64bit cpu.

In what way is it faster? What exactly is faster?
Back to top
View user's profile Send private message
Thesniperofdeath
n00b
n00b


Joined: 07 Jan 2011
Posts: 32
Location: Canada

PostPosted: Sat Jan 08, 2011 6:03 pm    Post subject: Reply with quote

Gusar wrote:
LukynZ wrote:
64bit system is faster at all. It's not only about ram or just some apps. Entire system is faster. I have no idea, why anybody should wants to run 32bit system at 64bit cpu.

In what way is it faster? What exactly is faster?


64 can support more than 4 GB RAM and it is fast.
Back to top
View user's profile Send private message
nifk
n00b
n00b


Joined: 16 Oct 2010
Posts: 4
Location: Poland

PostPosted: Sun Jan 09, 2011 2:04 am    Post subject: Reply with quote

What about the additional registers? Any performance benefit there?
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2678

PostPosted: Sun Jan 09, 2011 2:38 am    Post subject: Reply with quote

Applications that use doubles and longs for data types run faster on 64 bit. Ok, this does not take into account the default primitive type length for C++, because there is none, but it seems most people like use ints and floats that are 32 bits and doubles and longs that are 64 bits. This means that doubles and longs take only one operation to add/subtract in 64 bit and 2 in 32 bit. This is a very good performance increase.

ram is acesses by using a code using the word length of a processor. The word length of a 32 bit machine is... 32 bits and alows for access to 2 to the 32 bits of ram (4 gigs). A word of 64 bits is 2 to the 64 bits. Try maxing that out!

most video applications run using doubles, so big performance increase there. As a matter of fact, doubles are used much more than floats, so go 64 bit.

basically, run 64 bit linux on a 64 bit machine for best results. There is no real differences in available software and the system runs faster.

more registers is generally good, but you should have access to them all in 32 bit or 64 bit, but I could be wrong about that, I just like playing with software.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Sun Jan 09, 2011 4:37 am    Post subject: Reply with quote

You can chase after technical issues or not, your choice.

Bottom line is, it's quite a bit faster with 64-bit. Especially during compilation. IMO, going to pure 32-bit with 64-bit hardware is like chopping off an arm. At least go multilib. Why waste your hardware?

If you can still buy a 32-bit home computer, you soon will no longer be able to do so. I've been running this box for awhile now, installed a couple different operating systems on it, and it has been going in 64-bit mode ever since I spent some time experimenting with both.

I currently use pure 64-bit. I don't use multilib, but I briefly used nspluginwrapper so flash would work. That's the only concession I've had to make the entire time. That's gone now. There are a few minor irritations but in general the system is much faster with anything that really hogs CPU. Since you're running Gentoo, the biggest thing is portage.

I've put some things like flash in ~arch, but nothing core to operating stability.

Here's my entire package.keywords:
net-im/skype ~amd64
www-plugins/adobe-flash ~amd64

I get good movie speed even in high-def. Some things are flaky, but I think that is more due to flash and similar plugins not being especially polished on Linux, not on ~amd64 in particular.
Back to top
View user's profile Send private message
Gusar
Advocate
Advocate


Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia

PostPosted: Sun Jan 09, 2011 12:09 pm    Post subject: Reply with quote

Thesniperofdeath wrote:
64 can support more than 4 GB RAM

So can 32bit, with PAE. And what if I don't have more than 4GB?

Thesniperofdeath wrote:
and it is fast.

What exactly is fast? In what way? You have any real numbers or just and empty "it's faster" claim? I know x264 encoding is faster by 10-15%, but other than that...
For example, a 64bit Firefox is slower than a 32bit one in JavaScript. Could be because there was no tuning yet for 64bit, and so this might change in the future, but right now Firefox's JavaScript engines are slower in 64bit. It would be no surprise to me if a lot of apps are in this position.
Back to top
View user's profile Send private message
jathlon
Tux's lil' helper
Tux's lil' helper


Joined: 26 Sep 2006
Posts: 89
Location: Canada

PostPosted: Sun Jan 09, 2011 2:08 pm    Post subject: Reply with quote

Gusar wrote:
Thesniperofdeath wrote:
64 can support more than 4 GB RAM

So can 32bit, with PAE. And what if I don't have more than 4GB?

Linus on why PAE sucks.
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2678

PostPosted: Sun Jan 09, 2011 5:11 pm    Post subject: Reply with quote

Quote:
Thesniperofdeath wrote:
and it is fast.

What exactly is fast? In what way? You have any real numbers or just and empty "it's faster" claim? I know x264 encoding is faster by 10-15%, but other than that...
For example, a 64bit Firefox is slower than a 32bit one in JavaScript. Could be because there was no tuning yet for 64bit, and so this might change in the future, but right now Firefox's JavaScript engines are slower in 64bit. It would be no surprise to me if a lot of apps are in this position.


faster in dealing with doubles. For those who don't program, a double is a number with a decimal point that has a range of approximatively, oh heck with it, very small to very big. The standard is to use doubles rather than floats (which are 32 bit) because they are bigger and harder to overflow, and we just use them. Basically, better at math. Math runs the entire box, so faster at decimal calculations.

some things are optimized for 32 bit, but the way things are going 64 bit will be the only one that new hardware will run on. Have you booted Windows vista or 7? with 4 gigs of ram, there is barely enough power to run the system and virus software. Since most of the hardware is made for windows, 32 bit will die at the hands of Microsoft.

Admittedly, gentoo is easer to run than windows, but why wast half you processing power?

On a machine level, 64 bit runs a double in one calculation. A 32 bit runs in two calculations. That is twice the time.

And if performance is the issue, why even look at PAE? PAE = more calculations = more time lost. If you can use 64 bit, that is much faster. Interpreted stuff might not be as fast, but thats an interpreter anyway. Real code will tun faster.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sun Jan 09, 2011 6:15 pm    Post subject: Reply with quote

penguin swordmaster wrote:
more registers is generally good, but you should have access to them all in 32 bit or 64 bit, but I could be wrong about that.

You are wrong about that: The additional registers are not available in 32bit emulation mode.
Back to top
View user's profile Send private message
wjb
l33t
l33t


Joined: 10 Jul 2005
Posts: 600
Location: Fife, Scotland

PostPosted: Sun Jan 09, 2011 9:58 pm    Post subject: Reply with quote

Extra memory is easy to see x64 uses. Speed - anyone got any actual numbers for the same PC with 32 vs 64??
Back to top
View user's profile Send private message
ppurka
Advocate
Advocate


Joined: 26 Dec 2004
Posts: 3256

PostPosted: Sun Jan 09, 2011 10:16 pm    Post subject: Reply with quote

wjb wrote:
Extra memory is easy to see x64 uses. Speed - anyone got any actual numbers for the same PC with 32 vs 64??
In normal desktop usage: no perceptible difference. In fact, if you are unlucky enough, you will hit this bug: https://forums.gentoo.org/viewtopic-t-793263.html
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/
Back to top
View user's profile Send private message
Gusar
Advocate
Advocate


Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia

PostPosted: Sun Jan 09, 2011 10:46 pm    Post subject: Reply with quote

@penguin swordmaster: You're arguing theory. Cna you point me to anything in practice and say "this real world app/environment works better in this way", like I did with x264?

And no matter how much PAE sucks (I didn't know that before, so now I know something new), the fact that it exists means one can indeed use more than 4GB with 32bit if one really wants to. Though even all that ignores the question I asked: What if I don't have more than 4GB?
Back to top
View user's profile Send private message
M
Guru
Guru


Joined: 12 Dec 2006
Posts: 432

PostPosted: Sun Jan 09, 2011 11:00 pm    Post subject: Reply with quote

I am on amd64 for years, I can't tell that something works faster, beside encoding, I noticed in my usage that sdlmame for example works faster.
But, what I do noticed is that now all apps use much more memory, yes you can address more then 3GB but everything will use much much more. Example, my openbox with some apps on old laptop use about 30MB when I start X, I moved that same config to desktop machine, but I can't get it below 120MB! I now think to move desktop back to 32bit, I have only 2GB and I don't see any gain in performance...
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2678

PostPosted: Sun Jan 09, 2011 11:23 pm    Post subject: Reply with quote

Quote:
What if I don't have more than 4GB?


Then you simply have less ram. if you are really pushing it on ram, with like 60 mb or so, then there might be a big diffrance. In my understanding, the opcodes have to be 64 bits long instead of 32, so more ram might be used...

Quote:
You're arguing theory. Can you point me to anything in practice and say "this real world app/environment works better in this way", like I did with x264?


Not really because I don't test the heck out of everything I install. Some of my java apps do seem to run faster, the ones with lots of doubles, but this might just be the jvm. As to theory, 64 bit vs 32 bit is pretty much theory. Faster doubles and bigger opcode is really what every one is talking about.

I would argue, though, that running PAE with 32 bit Gentoo on a 64 bit machine is just a wast of ram and CPU power.

If you use you computer for things like processing allot of data, then I would say that 64 bit pays in theory. In practice, we are talking about micro or nano seconds here... so if you just want to speed you system up, use more ram (if you have the slots for it), if you want to play with 64 bit system, go with 64 bit.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
Gusar
Advocate
Advocate


Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia

PostPosted: Sun Jan 09, 2011 11:31 pm    Post subject: Reply with quote

penguin swordmaster wrote:
In my understanding, the opcodes have to be 64 bits long instead of 32, so more ram might be used...

25-30% more when running the same software was recently measured at the Arch forums.

penguin swordmaster wrote:
In practice, we are talking about micro or nano seconds here...

So like ppurka said, no perceptible difference.
Back to top
View user's profile Send private message
F1r31c3r
Tux's lil' helper
Tux's lil' helper


Joined: 31 Aug 2007
Posts: 107
Location: UK

PostPosted: Mon Jan 10, 2011 10:08 am    Post subject: Reply with quote

64bit canes memory so if you have not got more than 16gb ram 8gb/channel (4gb+4gb) minimum your not going to benefit from memory performance much. Its like jumping back to 512mb on 32bit memory during the millennium.

64 bit memory address is longer as i am sure you can imagine and would technically take up double of 32bit. yet the maximum address space of 64bit is 16 exabytes American units and 16 terabytes Euro units so this is impossible to fit in a system at present.

If a 2^32bit instruction has 4billion (4gb space) address locations in memory and a 64 bit has 2^64 address locations. We just cant use the full potential of 64bit yet but we can do 64bit wide words in a single cycle so all is good. And yes that is very fast. its just getting the GCC to really take advantage of it.
The linux GCC i think is the most advanced and the only compiler on the market at present that really does take advantage of the 64bit system. The Linux kernel does the best job on the market to process multi threads in 64bit so Linux and 64bit is the best choice. Using 64bit compile options in your make.conf can really boost more than you think so for gentoo users 64bit is actually all good with very little down-points.

Interleaved 128bit actually doubles performance of the cut down 64bit at present so that speeds things up if you can afford that form of system and capacity)yes it can read a single 128bit word over 128bit wide pipe AMD did it again). This also assists in massive stability over the addressing issue of the low memory problem exponential mentioned above (2^64) oh god 2^128 urm even a calculator screen output would confuse how many 0 that is. again that in effect ratio's down the memory capacity to each word in effect its like a 32bit system running with 256mb as an example of course. so be warned get lots of memory. Note interleaved is minimum setup of 24gb and max of 64gb unbuffered dual rate or quad rate registered 256gb so get saving pennies.

anyway 64 bits in terms of CPU load would be higher yet a single io would be transferred much faster. that's why you can have more things running without slowdown on 64bit. It is the way forward as we in gentoo linux dont really need that 32bit compatibility model as we compile from source in native 64bit if we want. Its the multi-thread processing that some games use which cause problems with wine as the linux kernel(mentioned above) uses thread models. Weather its hyper threading or cores linux apps see them all as threads which work very well in all honesty. They are improving to better highs but all in all its pretty good.

Hope that gives some good info in today's 64bit multi core world of computing.
_________________
A WikI, A collection of mass misinformation based on opinion and manipulation by a deception of freedom.
If we know the truth, then we should be free from deception (John 8:42-47 )
Back to top
View user's profile Send private message
F1r31c3r
Tux's lil' helper
Tux's lil' helper


Joined: 31 Aug 2007
Posts: 107
Location: UK

PostPosted: Mon Jan 10, 2011 10:38 am    Post subject: Reply with quote

just another quick point in making this decision.

In multicore chip from AMD (Intel triple channel is similar only in sense that the primary core of the CPU has 2 DIMM slots the others have one for 4 core) is that each core has its own dedicated MMU which on AMD systems has 2 DIMM slots/core when both DIMM slots are populated it is 128bit interleaved.

What need be mentioned is that the 2 slots are populated with 2 x 4gb modules unbuffered or at present 2 x 16gb registered. that's used only by that one core then 2 dimms for core 2 and so on. thats how it works so you can only get 8gb unbuffered(high performance memory) and 32gb registered(half the speed but more parallel with quad rank) per core. If you have a multicore 64bit CPU system 99.9% chance it is wired in this manor.

Memory optimization is kernel and software is crucial until we can increase density of memory chips. Slow performance if a core gets choked is a big problem. Understand this by imagining a 12 core system is 12 individual computers which all have 8gb of ram each and each computer is 64bit. The north-bridge and bus is what connects all these individual systems together and can run any task sent to them depending on which thread is used. so when people say one multicore system with 32gb ram etc its actually 32gb/ cores in an 8 core that's 4gb ram per core, not really that much is it especially for 64bit potential.

There is serious software solutions needed to cross access data held in memory from different cores. They are wired together so it can work in software somehow. The CELL CPU has routing which can be optimized to allow you to access memory stored in a different cores memory channel. At the moment i dont think this is working very well so bare that in mind.

How many years do you think before we see a dramatic increase in memory density capable of delivering serious 64bit memory performance. we currently have a 16gb ddr3 DIMM module. at this rate(hypothetically of course) in 20 years time they may hit 512gb dimm. that's only 8192gb in 16 slot system in 20 years not even a scratch on the 64bit address space.

LOL :lol: :P
_________________
A WikI, A collection of mass misinformation based on opinion and manipulation by a deception of freedom.
If we know the truth, then we should be free from deception (John 8:42-47 )
Back to top
View user's profile Send private message
PaulBredbury
Watchman
Watchman


Joined: 14 Jul 2005
Posts: 7310

PostPosted: Mon Jan 10, 2011 11:19 am    Post subject: Reply with quote

F1r31c3r wrote:
cause problems with wine as the linux kernel (mentioned above) uses thread models

Which is fixed by using taskset or schedtool :)

I use wine (for games), so stick with 32-bit and PAE. Multi-lib is just an annoyance (upgrading 2 sets of some libs instead of just one), which no source-based distro handles well AFAIK. In Gentoo in particular, having emul-linux-x86-* as binary files is a bit of a joke - binaries for important libs, in a source-based distro :roll:
Back to top
View user's profile Send private message
nifk
n00b
n00b


Joined: 16 Oct 2010
Posts: 4
Location: Poland

PostPosted: Mon Jan 10, 2011 6:02 pm    Post subject: Reply with quote

penguin swordmaster wrote:

In my understanding, the opcodes have to be 64 bits long instead of 32, so more ram might be used...


I think that the instructions are of variable length.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on AMD64 All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
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