Overclock.net banner

1 - 20 of 30 Posts

·
Registered
Joined
·
129 Posts
Discussion Starter · #1 ·
Currently have a small home raid 5, it's 32bit, 512mb ram, 1.8ghz amd.

I have 3 more 3tb cudas on order, and I acquired for free an amd64 with 512mb

Is it worth the performance to hassle and move everything to the 64bit and reinstall (only a few software packages, it's headless) before growing to raid6?

Some googling says such small ram it's pointless, but I'm curious for cpu crunching for parity checking.

Sent from my rooted HTC Supersonic using Tapatalk 2 Pro
 

·
Registered
Joined
·
3,706 Posts
No, you'll probably see a performance decrease
 

·
Premium Member
Joined
·
10,324 Posts
If you really wanted to, you could add the x64 architecture and just update and reboot your system
thumb.gif


No reason to reinstall.
 

·
AMD Fangirl
Joined
·
1,658 Posts
If you have less than 3GB of RAM, stay with 32bit OS....less overhead and they're leaner.
 

·
Registered
Joined
·
129 Posts
Discussion Starter · #5 ·
Quote:
Originally Posted by Shrak View Post

If you really wanted to, you could add the x64 architecture and just update and reboot your system
thumb.gif


No reason to reinstall.
Talked with irc in debian, they said just try the kernel. No need to redo user space.

I've been trying the board in a different box, no raid yet. Testing the cpu. The tab was broke to hold the heat sink down. So I did some ******* fitting, automotive wire and wire eyelet crimps. and bench testing the used cpu paste and softened with alcohol, balled up, and set back down. Heh.

Can't get it to overheat yet. Might be golden.

So moving from pci and 1.8 to pci-express and 2.8. Should notice some improvement.

But thanks.

Sent from my rooted HTC Supersonic using Tapatalk 2 Pro
 

·
10 year OCN Vet
Joined
·
3,426 Posts
When considering overall performance on a Linux system, unless you're just concerned with benchmark numbers, what you really mean is some subjective "user experience". So you can avoid the TLDR syndrome, let me state right here that while I'm running an Asrock Z77 Extreme with an i5-3550 with 8 Gigs of RAM, and at any given time have 3-6 Operating Systems on it, some (especially Windows) 64bit, my main OpSys is still 32bit and I notice very little if any difference in performance on many benchmarks, games or what have you.

My overall user experience is what keeps me from moving to 64bit on my main. It's less work that has little gain..not yet a good tradeoff. For my reasons why, just keep reading. If you just want one opinion from someone who has both you can stop here. There is barely a noticeable difference for most people not doing lots of video decoding and the like.

The extended version (underlying causes) -

It is difficult to get a truly objective answer on 32bit vs/ 64bit for several reasons. Obviously 64bit has greater potential and at some point the number of 64bit programs will so far outweigh 32bit that 32bit will become all but obsolete. So devs encourage us to move to 64bit now to possibly more quickly effect that changeover. Some reasons for this are further down this post. Additionally, since it is a Windows World still and Windows PAE bloze goats, one really has to go 64bit with Windows.

Linux PAE is substantially superior. One example is that Windows limits PAE to 4 GB for licensing purposes ONLY, while Linux PAE can address up to 64 GB RAM on a 32 Bit CPU/System. You may notice that even here on a Linux board people refer to "The 4GB Tipping Point" as if it applied in Linux when in fact it does not.

One can set how much memory is addressable by PAE in the Linux Kernel and apparently when one exceeds 32GB there are some penalties and considerations but up to 32GB works a treat. I've worked on 32GB Linux PAE machines that are solid and fast. 4GB is a walk in the park. So as far as hardware and it's support within the kernel goes, there is almost NO DIFFERENCE (less than 1%) in performance, with the exception of some benchmark programs that are weighted in favor of 64bit. Phoronix verifies this BTW.

Another reason many tout 64bit over 32bit is simply because that's what they have chosen (and as you can already see, often for mistaken reasons) and people tend to justify their choices to others to justify it to themselves. Hopefully I am somewhat less subjective because I use both and have not made a hard choice yet simply because it isn't time yet in my estimation. Here's why I think that.............

Still a very large number of programs are 32 bit and very few are exclusively 64 bit. So there is almost no penalty (programs that can't be run) with 32bit. Plus, if you use a 64bit system and have any programs that are 32bit, and almost everyone does, this requires MultLib.

When compiling programs to satisfy Multilibs, they are compiled by gcc at least twice and often multiple times. Additionally one must have two sets of libraries for those programs to make specific, non-conflicting calls. I hesitate to refer to these as "bloat" but anyone can see this is less simple than it presently has to be. To be clear, I'm not saying this takes a noticeable increase in human time to run such multilib programs, just that it makes ones' system more complicated, especially if one compiles anything from source.

To avoid the inevitable flames, let me state that nobody presently running 64bit has any compelling reason to reinstall as 32bit. Again, the difference is on the order of 1% for over 90% of common programs performance. My point is simply that, at least for now and a few more years, there is also no compelling reason for most people to choose 64bit over 32bit in Linux, unless you have more than 32GB RAM. There are only minor differences that most Linux users will never feel.

The bottom line is that you can feel free to experiment, unless you're running the likes of CAD, Video Decoding, etc. with almost no penalty and with some gain in simplicity.
 

·
Registered
Joined
·
129 Posts
Discussion Starter · #7 ·
Just mdadm, nfs, samba, and ssh, and screen, 2 pci cards and 6 hdds, eventually 12.

2 cords, power and cat5. Sits in the garage with filters duct taped together for a "filter box" that sits over it.

Guess I'll move motherboards, combine the ddr, and call it done.

Thanks for the detailed reply.

Sent from my rooted HTC Supersonic using Tapatalk 2 Pro
 

·
Linux Lobbyist
Joined
·
2,040 Posts
Quote:
Originally Posted by enorbet2 View Post

*snip*
It's also important to note that while there are no truly notable performance gains in most cases moving from 32 to 64bit, and that PAE covers the memory needs. There are many commercial and enterprise applications that are only 64-bit. Also, on the topic of photo and video editing, and large data set processing; 32-bit becomes insufficient not because of the performance gains that (used to be) offered by 64-bit processing over 32-bit; but rather that even with LAA and page tables to work around the 3gb barrier (Not at the kernel level, but the application level - it's 2gb with LAA and 3gb with) or even a separate memory management thread and many satellite threads to achieve a massive mappable memory range... Its just more logical to use a 64-bit application..
 

·
Registered
Joined
·
129 Posts
Discussion Starter · #9 ·
Meh, I moved everything over. Alot of I/O wait,,still in the 80mb/sec synch times.

I have 4 3tj drives full, and another 4 on order. I think I'll remake another array double check sector alignment, copy over, destroy the first, add old drives to new array, and grow/resize2fs.

Sent from my rooted HTC Supersonic using Tapatalk 2 Pro
 

·
Linux Lobbyist
Joined
·
2,040 Posts
Are you using a cache drive with high iops? That's a good way to avoid QB 32 for a good while; obviously more expensive of a setup though.
 

·
Registered
Joined
·
413 Posts
Quote:
Originally Posted by anywhere View Post

Currently have a small home raid 5, it's 32bit, 512mb ram, 1.8ghz amd.

I have 3 more 3tb cudas on order, and I acquired for free an amd64 with 512mb

Is it worth the performance to hassle and move everything to the 64bit and reinstall (only a few software packages, it's headless) before growing to raid6?

Some googling says such small ram it's pointless, but I'm curious for cpu crunching for parity checking.

Sent from my rooted HTC Supersonic using Tapatalk 2 Pro
The only time you'll see a strong performance increase switching from 32-bit to 64-bit is if you have more than 3-4GB of RAM otherwise I'd stick with 32-bit
 

·
Premium Member
Joined
·
8,041 Posts
Quote:
Originally Posted by DonDizzurp View Post

The only time you'll see a strong performance increase switching from 32-bit to 64-bit is if you have more than 3-4GB of RAM otherwise I'd stick with 32-bit
Not necessarily. Some software really takes advantage of 64bit addressing and such like. ZFS, for example, really comes to life on 64bit systems. Some PostgreSQL functions run significantly faster in 64bit as well.
 

·
Registered
Joined
·
413 Posts
Quote:
Originally Posted by Plan9 View Post

Quote:
Originally Posted by DonDizzurp View Post

The only time you'll see a strong performance increase switching from 32-bit to 64-bit is if you have more than 3-4GB of RAM otherwise I'd stick with 32-bit
Not necessarily. Some software really takes advantage of 64bit addressing and such like. ZFS, for example, really comes to life on 64bit systems. Some PostgreSQL functions run significantly faster in 64bit as well.
Sure but with limited RAM, those advantages of a 64bit OS and CPU are limited as well

Sent from my Galaxy Nexus using Tapatalk
 

·
Linux Lobbyist
Joined
·
2,040 Posts
Quote:
Originally Posted by DonDizzurp View Post

Sure but with limited RAM, those advantages of a 64bit OS and CPU are limited as well

Sent from my Galaxy Nexus using Tapatalk
Actually, ram quantity has a null impact on the advantages of 32 or 64 bit; 32-bit operating systems can utilize up to 64gb of ram. Microsoft put pseudo limitations on different licenses of Windows Vista+ and prior to Windows Vista, Windows XP didn't have PAE enabled in the kernel (although the code was there), Windows Server 2003 (which was XP's server iteration) did have PAE and could handle 64gb of ram. From there, a single 32-bit image can handle up to 3gb of ram without a memory paging thread using LAA. With a memory paging thread and several 'images' it can take advantage of PAE and allocate as much ram as is available. It can only address the first 3gb directly however, but that's not really an issue when working with large datasets you can page as you need anyways. The real advantage comes from 64-bit instructions and properly taking advantage of them, most math done in menial applications doesn't even fill a 32-bit register, so the 64-bit function is actual a waste the majority of the time. As Plan9 pointed out, there are obvious exceptions to this rule.

In general:
(De)Compression (including video encoding, decoding)
Post Processing/Filtering (I.e. photoshop filters)
High point count manipulation (detailed models in basically any 3d modeling program)

All see large benefits from 64-bit instructions. Even further, most of the above also can take advantage of AVX 256-bit instructions for even further performance gains. There are several other instances where the gains are quite large, but the above are the most commonly occurring.

Data streams take almost zero calculation, so the register size is really negligible. If he was working with a large data set and the processor was pegged at 100% usage and that was limiting his write speed, I'd say 64-bit would help. But it's being limited by I/O count, he's seeing Queue Depth start to take effect, a high-speed high IOPS cache array would mitigate this, but add the risk of data loss (since you'd want probably 2 SSD's in Raid 0 for the cache, that'd be plenty of IOPS and a huge data throughput pipe ~1gb/s, which is more than the mechanical drives could hope to catch up with)

Here's a question - how many iops does iostat report for the process doing the writing? (that would be block read/s and block write/s) That's probably more important than the throughput of your drives for the application.
 

·
Registered
Joined
·
413 Posts
Quote:
Originally Posted by Xaero252 View Post

Actually, ram quantity has a null impact on the advantages of 32 or 64 bit; 32-bit operating systems can utilize up to 64gb of ram. Microsoft put pseudo limitations on different licenses of Windows Vista+ and prior to Windows Vista, Windows XP didn't have PAE enabled in the kernel (although the code was there), Windows Server 2003 (which was XP's server iteration) did have PAE and could handle 64gb of ram. From there, a single 32-bit image can handle up to 3gb of ram without a memory paging thread using LAA. With a memory paging thread and several 'images' it can take advantage of PAE and allocate as much ram as is available. It can only address the first 3gb directly however, but that's not really an issue when working with large datasets you can page as you need anyways. The real advantage comes from 64-bit instructions and properly taking advantage of them, most math done in menial applications doesn't even fill a 32-bit register, so the 64-bit function is actual a waste the majority of the time. As Plan9 pointed out, there are obvious exceptions to this rule.

In general:
(De)Compression (including video encoding, decoding)
Post Processing/Filtering (I.e. photoshop filters)
High point count manipulation (detailed models in basically any 3d modeling program)

All see large benefits from 64-bit instructions. Even further, most of the above also can take advantage of AVX 256-bit instructions for even further performance gains. There are several other instances where the gains are quite large, but the above are the most commonly occurring.

Data streams take almost zero calculation, so the register size is really negligible. If he was working with a large data set and the processor was pegged at 100% usage and that was limiting his write speed, I'd say 64-bit would help. But it's being limited by I/O count, he's seeing Queue Depth start to take effect, a high-speed high IOPS cache array would mitigate this, but add the risk of data loss (since you'd want probably 2 SSD's in Raid 0 for the cache, that'd be plenty of IOPS and a huge data throughput pipe ~1gb/s, which is more than the mechanical drives could hope to catch up with)

Here's a question - how many iops does iostat report for the process doing the writing? (that would be block read/s and block write/s) That's probably more important than the throughput of your drives for the application.
"Actually, ram quantity has a null impact on the advantages of 32 or 64 bit"

LOL what?

"32-bit operating systems can utilize up to 64gb of ram. "

I stopped reading right there.

2^32 = 4,294,967,296 bytes = 4GB

You have a total of 4GB of available memory for RAM and other resources on a 32-bit OS and CPU. Page filing is irrelevant.

Real world test: install a 32-bit Windows 7 on a PC with 1GB of RAM and then a 64-bit Windows 7 on that same PC. I can almost guarantee the 32-bit one will but quicker.
 

·
Linux Lobbyist
Joined
·
2,040 Posts
Quote:
Originally Posted by DonDizzurp View Post

"Actually, ram quantity has a null impact on the advantages of 32 or 64 bit"

LOL what?

"32-bit operating systems can utilize up to 64gb of ram. "

I stopped reading right there.

2^32 = 4,294,967,296 bytes = 4GB

You have a total of 4GB of available memory for RAM and other resources on a 32-bit OS and CPU. Page filing is irrelevant.

Real world test: install a 32-bit Windows 7 on a PC with 1GB of RAM and then a 64-bit Windows 7 on that same PC. I can almost guarantee the 32-bit one will but quicker.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#physical_memory_limits_windows_server_2003_sp2

Please, do your research before personally attacking someone for their knowledge.

Windows Server 2003 32-bit CLEARLY supports 64gb of memory. As I stated in my post - Microsoft imposes pseudo limitations on Windows releases BY LICENSE. For example, the "Standard" edition of Windows Server 2003 only supported 4GB of memory, however the Enterprise and DataCenter editions of the operating system each supported 64gb of memory on 32-bit.

Yes, 2^32 is 4GB - the kernel can allocate one single 4GB contiguous portion of memory per pool. That doesn't mean the kernel cannot allocate multiple pools of memory. In theory, the kernel could allocate 2^32 pools of 4GB in size. This technique for memory allocation is called "paged pool" and has nothing to do with the page file which as you pointed out would be a very dumb statement indeed.

Congratulations - You agreed with me on your last point - everything about loading an operating system would be faster with 32-bit instructions. Because NONE of those operations would be able to utilize a 64-bit register - which inherently takes longer to process than a 32-bit one.

Oh, and a bit of further reading on PAE; The technology that enables 32-bit CPUs to access the memory ranges beyond 4GB:
Http://en.wikipedia.org/wiki/Physical_Address_Extension
 

·
Registered
Joined
·
413 Posts
Quote:
Originally Posted by DonDizzurp View Post

"32-bit operating systems can utilize up to 64gb of ram. "

I stopped reading right there.

2^32 = 4,294,967,296 bytes = 4GB

You have a total of 4GB of available memory for RAM and other resources on a 32-bit OS and CPU.

I have noooooo how you came up with a blatant lie like that.
Quote:
Originally Posted by Xaero252 View Post

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#physical_memory_limits_windows_server_2003_sp2

Please, do your research before personally attacking someone for their knowledge.

Windows Server 2003 32-bit CLEARLY supports 64gb of memory. As I stated in my post - Microsoft imposes pseudo limitations on Windows releases BY LICENSE. For example, the "Standard" edition of Windows Server 2003 only supported 4GB of memory, however the Enterprise and DataCenter editions of the operating system each supported 64gb of memory on 32-bit.

Yes, 2^32 is 4GB - the kernel can allocate one single 4GB contiguous portion of memory per pool. That doesn't mean the kernel cannot allocate multiple pools of memory. In theory, the kernel could allocate 2^32 pools of 4GB in size. This technique for memory allocation is called "paged pool" and has nothing to do with the page file which as you pointed out would be a very dumb statement indeed.

Congratulations - You agreed with me on your last point - everything about loading an operating system would be faster with 32-bit instructions. Because NONE of those operations would be able to utilize a 64-bit register - which inherently takes longer to process than a 32-bit one.

Oh, and a bit of further reading on PAE; The technology that enables 32-bit CPUs to access the memory ranges beyond 4GB:
Http://en.wikipedia.org/wiki/Physical_Address_Extension
It supports 4GB by design. 64GB requires you have PAE as you clearly stated several times.

"With PAE, IA-32 architecture is augmented with additional address lines used to select the additional memory, so physical address size increases from 32 bits to 36 bits."
^ Straight from the Wiki article you linked

I didn't say compare a 32-bit program running in a 32-bit vs 64-bit OS. I said simply a 32-bit OS vs 64-bit OS as they come.

No need to get upset and take it as a "personal attack". It's only the internet.
 

·
10 year OCN Vet
Joined
·
3,426 Posts
Quote:
Originally Posted by DonDizzurp View Post

It supports 4GB by design. 64GB requires you have PAE as you clearly stated several times.

I didn't say compare a 32-bit program running in a 32-bit vs 64-bit OS. I said simply a 32-bit OS vs 64-bit OS as they come.
Which design? an old one or the one currently in use?

Since this thread is in a Linux Forum and OP specifically was asking about Linux, and also considering that essentially all recent 32bit distros ship with PAE enabled kernels, in fact you are NOT comparing Linux 32bit vs/ Linux 64bit "as they come".
 

·
Premium Member
Joined
·
8,041 Posts
Quote:
Originally Posted by DonDizzurp View Post

"Actually, ram quantity has a null impact on the advantages of 32 or 64 bit"

LOL what?

"32-bit operating systems can utilize up to 64gb of ram. "

I stopped reading right there.

2^32 = 4,294,967,296 bytes = 4GB

You have a total of 4GB of available memory for RAM and other resources on a 32-bit OS and CPU. Page filing is irrelevant.

Real world test: install a 32-bit Windows 7 on a PC with 1GB of RAM and then a 64-bit Windows 7 on that same PC. I can almost guarantee the 32-bit one will but quicker.
I suggest you Google PAE before calling people liars
 

·
Premium Member
Joined
·
8,041 Posts
Quote:
Originally Posted by DonDizzurp View Post

It supports 4GB by design. 64GB requires you have PAE as you clearly stated several times.

"With PAE, IA-32 architecture is augmented with additional address lines used to select the additional memory, so physical address size increases from 32 bits to 36 bits."
^ Straight from the Wiki article you linked

I didn't say compare a 32-bit program running in a 32-bit vs 64-bit OS. I said simply a 32-bit OS vs 64-bit OS as they come.

No need to get upset and take it as a "personal attack". It's only the internet.
You're doing this thing that people do when they're too proud to admit they were wrong where you argue the semantics of your original post narrowly describes your point, despite the fact that everyone knows the semantics were not only an accident at the time of writing but also completely irrelevant to the point if the discussion. However we're now arguing the semantics, which you do understand, rather than 64bit addressing, which you don't understand, and theargument has shifted focus away from your original falsehood.

So in the interest of keeping this discussion on topic let's stick to the crux of the argument. Regardless of PAE, nor available RAM, some software will perform better on 64bit platforms.
 
1 - 20 of 30 Posts
Top