Slashdot Mirror
Benchmarks of Debian GNU/kFreeBSD vs. GNU/Linux
An anonymous reader writes "The Debian Squeeze release is going to be accompanied by a first-rate kFreeBSD port and now early benchmarks of this port have started coming out using daily install images. The Debian GNU/kFreeBSD project is marrying the FreeBSD kernel with a GNU userland and glibc while making most of the Debian repository packages available for kfreebsd-i386 and kfreebsd-amd64. The first Debian GNU/kFreeBSD benchmarks compare the performance of it to Debian GNU/Linux with the 2.6.30 kernel while the rest of the packages are the same. Results are shown for both i386 and x86_64 flavors. Debian GNU/kFreeBSD may be running well, but it has a lot of catching up to do in terms of speed against Linux."
32-bit was faster in a few tests, but it seems like overall the 64-bit still came ahead in more tests than it fell behind in.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
We can't start a holy war now! My armor is at the cleaners.
Cue nerd rage
Sheldon
I am TheRaven on Soylent News
Yep, because we ALL KNOW speed is EVERYTHING when running a computer.
Of course it's not everything - but it IS a major part. Cost is another. We're at a tie there.
So what's left? User friendliness? These systems use the same apps - tie there too.
We're basically left with security and stability. If you want to write and article on those feel free - I'm sure Linux won't fare too bad there, but I'd like to see the results.
Still though, to dismiss speed as a criteria is just being naive.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
While they're really the only group that does a lot of linux benchmarking, I'd put a *large* grain of salt in their results.
They have no problem blindly accepting something like this without investigating why it is so much faster and seeing if there's a problem with their testing.
Your hair look like poop, Bob! - Wanker.
I think speed is everything when you're writing an article for a benchmark site. Note that I'm not disagreeing with your ironic implication that there are other things to look at, but obviously it's a lot easier to churn out some graphs than to try to compare two OSes/suites/whatever on other important metrics, such as security or usability. Leave that to the media troll sites--there's no shortage of them.
I am literally 3000 tokens away from the chaotic crossbow --Stephen
Didn't Debian switch to eglibc because Drepper was being an asshole?
I don't use BSD, I just wanted to see if the "BSD is dying" troll still posted. It has been years, eh?
It does also seem to me that the FreeBSDk thing is meant to make certain features available to developers, maybe be more reliable, and "faster, faster" isn't being sold as part of the bill of goods. Yet, the talk returns to speed, speed, speed.
But what do I know... I work as a nurse. Although... I DO love a fast computer.
As a long time debian user who also has to work with freebsd sometimes I don't get it. Why use freebsd with GNU apps, when you can just run freebsd? And why freebsd and not lets say, openbsd or netbsd? What is the advantage in using the freebsd-kernel instead of the linux-kernel? I have access to every linux app when I use freebsd and to be honest, if I knew my way around bsd as I do under debian I would probably switch. But I am missing the improvement for Debian here. Can someone please clear this up for me a bit?
Before seeing this benchmark I took for granted that 64 bits would be faster or at least come to par in all tests. How do you explain that 32 bits is faster in some tests ?
The only way I can explain it is that some piece of code is not optimized yet to run on 64 bits. This kind of prove my impression right; I can still wait for a while before upgrading to 64 bits OSes. The overall performance
gain might or might not be there depending on your use cases.
Of course, I will upgrade to 64 bits some day. Stability is also so a major concern and often, newer equals less stable or at least a new set of problems to troubleshoot.
Everything I write is lies, read between the lines.
Where many is ~20% of them.
And why would that be surprising? 64 bit lets you address more memory and they did the tests in a machine with memory that 32 bits could address all of. 64 bit pointers are obviously larger too, so the 32 bit version has effectively more memory and better cache usage.
Some programs aren't going to take advantage of 64 bit registers and so on, but are going to suffer from worse cache performance.
Stick 8 or 12 GB of RAM in and things might be different
64-bit data structures can take up more space in the L1/L2/L3 caches which may cause code to run somewhat slower.
> 64 bit pointers are obviously larger too, so the 32 bit version has effectively more memory and better cache usage.
Very good point ;-))
Everything I write is lies, read between the lines.
I'm sorry, what?!
What are "many tests" you speak of?
32-bit Debian Linux was notably better only on compilation (which isto be expected) and POVRay. A couple of tests have shown very small advantage towards 32-bit system, but 64-bit has won MOST of 27 test hands down.
What about a performance comparison with original FreeBSD?
The Tao of math: The numbers you can count are not the real numbers.
64bit code uses more memory, which can in some cases result in decreased performance..
Also, i believe on some intel cpus some performance features are not available in 64bit mode (i forget the exact details)...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
As others have said, 64-bit programs take more memory to run. There's nothing inherently faster about 64-bit registers and operations unless you're dealing with integers that get that big (which in most everyday programs, they don't). What makes 64-bit faster isn't just "more bits", but optimizations. 32-bit code is typically compiled for the lowest common denominator: i386. However, x86-64 CPU's are guaranteed to be at least i686 compatible (you're also guaranteed up to a certain level of SSE compatibility and such). In that regard, it's the code optimization that we can rely on and not "more bits" (which due to extra memory usage, will typically make things SLOWER, not faster) to make things faster.
However, not every app or test really benefits that much from i686 optimizations. For those that don't, and don't deal in larger numbers (AND that don't use so much memory that a 64-bit chip is needed to address it), 32-bit processors will typically be faster.
As to stability, x86-64 is well past the "new" stage. The specification is 10 years old and processors based on it 7 years old - Linux support was almost immediate. Just how long does it take for you to consider it not bleeding edge anymore? :)
"People who think they know everything are very annoying to those of us who do."-Mark Twain
On most architectures, 64-bit code is slower. Pointers are bigger, which means you need more memory bandwidth to load them and you use more cache holding them. On x86-64, the situation is confused by the fact that 64-bit means 'using Long mode,' as well as 'using 64-bit pointers'.
Long mode gives you 64-bit registers (so you can store 64-bit values in a single register, rather than spread across two, doubling the number of 64-bit values you can store in registers), more registers, and a few other benefits like removing the 'must use EAX as the target' restriction on a lot of instructions (reducing the number of register-register moves, and decreasing instruction cache usage as a side effect). 64-bit pointers use more memory bandwidth and data cache.
For best performance on x86-64, you want pointers to remain 32 bits, but still run in Long mode. The OS should make sure that everything is mapped below the 4GB line for the process. As far as I am aware, no operating systems actually support this mode of operation. Without that, for any process using less than 4GB of address space, you have some advantages and some disadvantages when running in 64-bit mode. Whether the advantages outweigh the disadvantages, or vice versa, depends on the code.
I am TheRaven on Soylent News
So can I run Flash-enabled browser on this port?
The speed difference is a few percent. For most people, that's not noticeable. My kernel CPU usage stays well below 10% most of the time, even when the CPU is busy, so even a 50% difference in kernel performance wouldn't be particularly important. Much less important, for example, than things like ZFS, DTrace, a decent kernel sound system, and so on.
I am TheRaven on Soylent News
You missed out on the fact that there are more registers on 64 bit than the famously register starved 32 bit x86. More places to put things can't hurt even if your not dealing in 64 bit values.
The problem with 64 bit is that a lot of code is still hand tuned to the maximum possible performance on 32 bit arches and in at least a couple of the cases listed in the benchmarks I wouldn't be shocked if there was some hand done assembler involved. I have also noticed GCC has some performance tweaks that work around the lack of registers on 32 bit that also tend to get enabled in 64 bit..
glibc is a much more complex libc than the one FreeBSD uses. FreeBSD doesn't use libc as the "glue layer" nearly as much as Linux, so the extra overhead of glibc is wasted.
I have been using SuSE Linux 64 since 2005 with no problems.
The other day, I was installing an old FreeBSD system for compatibility with some stuff I had. I figure it's like installing an old Linux, right?
Wrong. When I install an old Linux, I can install all the old software. The *.rpm or *.deb files exist. FreeBSD doesn't work like that. It has ports. If your system is old, you're screwed. The ports system is only 100% available for the latest release. For older releases, there is a sort of weak idea that maybe it kind of sort of ought to be maintained when somebody bothers, but probably it'll just FAIL.
Really, that's crap. An OS shouldn't become unavailable as it ages. I might need it!
Slackware from 1994 still works as well as it did back then, 16 years ago. What's FreeBSD's problem?
> Whether the advantages outweigh the disadvantages, or vice versa, depends on the code.
That is exactly what I had figured out by intuition I guess ;-))
I have learned (or got refreshed on?) some logical explanations to this fact here today, thanks to you and some others.
I have to admit that I don't remember taking the time to evaluate 32 bits vs 64 bits advantages, just postponing that analysis and an eventual upgrade to later. I though I was past due on that matter but with what I have read today, I will postpone my upgrade for another 2 or 3 years. Ah, problems quickly solved, I like this.
Yet, I think some people might be under the impression that 64 bits performs way better than it actually does, like say, up to twice as fast ;-) This was almost the case when we went from 8 bits to 16 bits for obvious reasons like a few applications used only bytes (8 bits) in their code. Most of them were using types that typically require more than 8 bits, almost doubling the time to store/compute on 16 bits types on a 8 bit machine.
This brings an interesting point: Will 64 bits architectures be "enough for everybody" ?
Will there ever be a point where we might want to go 128 bits or above ?
Thanks for your reply,
Everything I write is lies, read between the lines.
> I have been using SuSE Linux 64 since 2005 with no problems.
Patrick Volkerding has just released the first version of Slackware 64 bits about 5 months ago and it doesn't seem to have had any impacts on the perception Slackware users have ;-))
Granted, there was unofficial ports before that ;-))
Thanks for letting me know it is stable on your side although ;-)
Everything I write is lies, read between the lines.
> Because every 64-Bit CPU I've ever used always had more than twice as much L2 cache as 32-bit Systems.
I am glad I am using 64 bits CPUs to run my 32 bits OSes then ;-)
Well unless somehow, the "twice as much" doesn't get used with 32 bits OSes running...
What do you think ?
Everything I write is lies, read between the lines.
If you're talking about x64, the primary 64-bit consumer desktop / laptop CPU architecture, has it occurred to you that code running in the CPU's 32-bit mode also benefits from the doubled cache? It's not like the 32-bit code only uses half the cache, with 64-bit code using the full cache.
It's not noticeable for most people...but for those of us in situations where it is noticeable that sort of difference is interesting. For example, my office has a debian box that runs at a continuous load average of around 5. Shave 10% off that & we'd notice.
Now, I am really surprised to see that Debian Linux 32 bits is actually faster than Debian Linux 64 bits in many tests !
I'm not so surprised to see that somebody didn't read the graphs very well. 32 bit was faster in only 4 out of 25 tests (16%). Further, 2 of those were only marginally faster to the point where they barely count as a clear lead. Conversely in the majority of cases, 64 bit was not only faster but significantly faster. To the point where I wonder if there were other configuration differences -- for example I don't understand why you'd see a much higher hard drive TPS rate under 64 bit (something like 4x) -- unless they're using a different IO scheduler...
All that said, is it really so unreasonable to ask for results to be laid out in a simple grid for all tests? Raw data is what we like here... (To answer my own question - of course it is. That would mean fewer page hits...)
Before seeing this benchmark I took for granted that 64 bits would be faster or at least come to par in all tests. How do you explain that 32 bits is faster in some tests?
For most, its generally considered a wash. Larger data structures require more cache and more memory and more memory to be accessed. On the other hand, you also get more registers in 64-bit mode. As a result, some things run slower and some things run faster, depending on the nature of the application. On average its likely to be a wash.
The big exception are those that use the PAE 32-bit extensions. Generally speaking, 64-bit is going to be a lot faster. Even still, there are some odd exceptions which will hopefully fuel the imagination of possibilities.
One such exception comes from the PostgreSQL guys. For example, on Windows, they strongly recommend running 32-bit PostgreSQL on 64-bit Windows. This seems really non-obvious at first but there is a good reason for it. If you use 64-bit OS, that means you get large pointers which can access large quantities of memory without using PAE tricks. But, since PostgreSQL spawns processes for each back-end, that means you can run more heavy hitting (very large data sets, heavy queries, etc), concurrent back-ends without taking a performance hit. Additionally, PostgreSQL relies heavily on the OS to cache files. With a 64-bit OS cache, large data sets can be readily cached by the OS and quickly return results to the 32-bit PostgreSQL. This means PostgreSQL directly benefits from 64-bit size file caches; despite running as a 32-bit application. And best of all, a 32-bit PostgreSQL means smaller data structures and more efficient cache use, with twice the available cache a 64-bit application would require. Its almost the best of both worlds.
As the above example illustrates, sometimes a mix can provide ideal results, but on average, consider it a break even unless you plan on having 4GB or more in your box. And even then... ;)
But on x86, you are only guaranteed 4 *real* general purpose registers. x86_64 increases this number. With a good compiler, the register allocator would use all of these, and you would have much fewer loads from main memory, which can take on the order of 75+ cpu cycles on a cache miss, or 5+ cycles on a cache hit.
I fear the Y2038 bug
the tricky part is to NOT use half the caches when running 32 bit apps :-p
The Cloud - because you don't care if your apps and data are up in the air.
Whoa, wait just a second. Before asking if the operating system support this, shouldn't we first ask "does the hardware support this?" or more specifically "does Intel's implementation support this?" because as far as I can tell from Wikipedia, it doesn't.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Why even swap the kernel out? The Linux kernel supports more hardware and has better stock performance then the FreeBSD kernel. In fact most friends I have that use FreeBSD are snotty to Linux users anyway. I say give them there OS and it's sorry performance (at least I've never seen anything comparable) and I'll stick with my stage 1 Gentoo which is fast, optimized and ready to go.
Sorry if this offends any FreeBSD user as that's not my point but I've installed it a ton of times to try it out and I'm still waiting for an install that lets me say "Woah" from the get go. Sure you can optimize after the fact but that's not the point, fast out of the box, faster after the tweak! that's what I want and FreeBSD has never given that to me .
If your a FreeBSD user great and if you a Linux user great, but lets not mix the two please!
The architecture doesn't have to support it. It is a chastity vow from the program, that while it may use 64bit, it simply opts to only use 32bit while still running in 64bit mode. Sounds confusing but is really simple.
The register is still 64bit (because CPU is in 64bit mode).
The memory slot used to store pointers is 32bit (because no more is needed).
The 64bit instruction set still has "load 32bit from memory" which may be used to load 32bit pointers into 64bit registers.
Now: The reason no one is doing it is becaue the C api states that the pointers should be 64bit when in 64bit mode. If you use a trick like this, your application will no longer be following standards, making it unable to use standard libraries.
It would be interesting if this ends up being forked into a GPLv3 project and forms the basis for the first ever pure GPLv3 distribution.
-1 Uncomfortable Truth
Hehe, sorry, my fault. I used "many" to mean "more than one" and that was a mistake. After reviewing the English dictionary, it seems that in English, "more than one" is expressed by "several". I used to think that they were almost synonyms but "many" means more "a lot" than "several".
My God, how many times must I have sounded like bullshitting before ;-))
Again, my mistake, I even learned the real signification of the word "many" today !! ;-)) /. teaches me all kind of stuff, including getting better in English ;-)
Cheers,
Everything I write is lies, read between the lines.
Of course we shouldn't ask that, because it would be a stupid thing to ask. The hardware doesn't care. If you use 32-bit pointers then you zero-extend them when you load them into 64-bit registers. From the hardware's perspective, you're using 64-bit pointers, but the top 32 bits are always 0. It's up to the OS (and compiler) and has absolutely nothing to do with the hardware. It is the responsibility of the OS to define the memory layout for the application and if the OS refuses to map anything above the 4GB line then the app can safely use 32-bit pointers everywhere.
I am TheRaven on Soylent News
By the way, when we went from 8-bit to 16-bit architectures, we got 16-bit integer registers. When we went to 32-bit, we got 32-bit registers. We already have 128-bit vector registers on most architectures, and most vector units can treat these as single 128-bit integer or floating point values already, so the only advantage of a 128-bit architecture would be for
I am TheRaven on Soylent News
Are they able to store double the words in 32 bit mode though? Or does it just stick a 32bit word in a 64bit register, and waste half of it?
If that's the case, it shouldn't give x64 a performance hit...
Sent from my PDP-11
as far as I can tell from Wikipedia, it doesn't.
nah, it does. i edited the wikipedia article to screw with you.
The extra registers do help, but x86 has register renaming going on in microcode, and it's pretty good at it. It's only some very specific kinds of code that see dramatic benefit from the extra visible registers.
Mind you any app that uses 64-bit ints, like databases, usually sees dramatic improvements.
But you'll see - and the numbers in the article back this up - that the real performance impact of this is minimal and the performance benefits outweight the defecits in the majority of cases.
> so the only advantage of a 128-bit architecture would be for
supporting the full length of a message on /. ?? ;-))
Thanks for your reply anyway,
Cheers,
Everything I write is lies, read between the lines.
No, not necessary.
It's not because your CPU is running a 64bits OS that suddenly every data format has to be replaced with one using 64bit integers.
It's not because your CPU is running a 32bits OS that you aren't allowed to manipulate anything bigger 32bits.
The OS bittage has almost no impact on what data format can be used. Only how fast those format will be processed, and how many memory can easily be addressed in a straight-forward way.
A 256 x 256 bitmap, RGBA, with 8bits per channel, will always take the same amount of memory wherever the OS is running 32bits or 64bits code. Only with a 64bits OS it will be much more easy to store more than 3GiB worth of textures.
And even a 32bits OS can manipulate 1024bit data structures like crypto key (only a little bit slower, because the CPU internally won't be able to do 64bit operations).
Also most OSes are LLP64 or LP64, meaning that the default "int" still is 32bits. Thus code recompiled in 64bits will tend to approximately use the same amount of data as original code in 32bits.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The reason no one is doing it is becaue the C api states that the pointers should be 64bit when in 64bit mode. If you use a trick like this, your application will no longer be following standards, making it unable to use standard libraries.
Correction: The C ABI says that, and the C ABI is defined on a per-platform basis (for example, FreeBSD and Linux use slightly different calling conventions on IA32). It's up to the operating system to define the ABI or ABIs that it supports. Solaris, IRIX, and most other commercial UNIX variants have been happily supporting 32-bit and 64-bit ABIs on 64-bit platforms for a couple of decades.
I am TheRaven on Soylent News
I can see a really good usage case for this.
You're a sysadmin, and you're running Debian almost exclusively. You have a large number of automation scripts that you use to do your job (security updates, auditing, provisioning, general maintenance, etc). All of them are expecting to run on Debian, because all you run is Debian. So you, as a sysadmin, decide you want to use ZFS somewhere.
You have a few options:
1) Run Solaris
2) Run some derivative of BSD (FreeBSD, OpenBSD, NetBSD, etc)
3) Run Debian w/ ZFS in Fuse
4) Run Debian kFreeBSD
Options 1 and 2 will most likely require you to tweak or rewrite a lot of your scripts. I shouldn't need to explain why option 3 is a bad idea. Since you're working with Debian userland, going with option 4 seems like it would be the path of least resistance. Seems pretty useful.
Because Postgres is really a Unix-type program and not an NT-type program, you mean; NT has cheap thread creation and expensive process creation, while Unix generally features the reverse situation. If Postgres were NT-ized and used multiple threads instead of multiple processes... perhaps things would be different. The bit-width of the system makes no difference to the amount of RAM used for file caches; are you talking about how fast you can shovel data with a 64-bit processor? Data shoveling is the only thing that actually does get dramatically faster.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
After reviewing the English dictionary, it seems that in English, "more than one" is expressed by "several".
Nope. "More than one" means "more than one", and it is a common figure of speech. "Several" means "enough to be worth mentioning."
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
It would also be interesting to see benchmarks of functionality actually provided by the respective kernels. E.g. performance of fork, fork+exec, socket, accept, reads and writes on IPC, multiprocessor/multicore/hyperthreading performance, etc. Past benchmarks have shown that there can be dramatic differences between operating systems especially when large numbers of something (processes, filehandles, CPUs, etc.) are being used simultaneously.
Also, I am missing a description of exactly how they measured. Did they recompile the benchmark suite from scratch on each platform? Which compiler was used, and with which settings? Are they running the same binaries on both? How exactly did they arrive at the presented values? Is each bar the result of a single run, or did they run each benchmark multiple times and account for any variation in observed scores somehow?
As others have already mentioned, it would also be interesting to see how a regular FreeBSD system would fare.
All in all, interesting benchmarks. My conclusion: there isn't that much of a difference between the tested versions of Linux and kFreeBSD in there benchmarks. The difference between 32-bit and 64-bit is usually more pronounced. If you need the highest performance for your application, you'll still have to run your own tests.
Please correct me if I got my facts wrong.
That said - I still wish they'd just give us the numbers in a usable format instead of spreading it across 10 pages with three charts each.
PS: and it's just like you furriners, claiming the language is too hard iffn yer not unnerstood! Why can't yous just talk good English like us reglar folk! ;)
The bit-width of the system makes no difference to the amount of RAM used for file caches;
With the exception, of course, that non-server 32bit editions of Windows won't let you use above 4GB of RAM, even though it's supported with PAE (and PAE is enabled for hardware DEP support). Heck, it isn't even a "4GB of RAM" limitation, but "you can only use lower 4GB PhysicalAddresses", which is different... BIOS remapping and all.
Capping to 4GB was a marketing decision, which kinda sucks but is sorta fair enough. Capping to 32bit PhysicalAddresses sucks because you can lose a lot of memory that way, but was done for compatibility reasons; really sucky driver developers thinking they only need to use addr.LowPart instead of addr.QuadPart when dealing with PhysicalAddresses, because they're on a 32bit system...
Coffee-driven development.
Glad to hear you're improving your English. Keep up the effort.
"many" implies a significant percentage of the whole. That's obviously not the case here.
"several" would be close, but I wouldn't use it for this situation. It indicates a moderate amount. My instinct is that this is a tad greater than what you want to describe.
I would use "few". It represents more than one, but also signifies a minority.
Ironically, the phrase "quite a few" actually means a large amount, and would be synonymous with "many". English can sometimes behave this way, just to make sure you're alert and paying attention, of course.
"some" may also be a good choice, but it is more indicative of an unspecified amount. It is not as accurate as "few".
> Nope. "More than one" means "more than one", and it is a common figure of speech. "Several" means "enough to be worth mentioning."
OK, about "a few" then instead of "more than one" ? ;-))
Everything I write is lies, read between the lines.
> PS: and it's just like you furriners
Hey I am not a furriners ! ;-)
My ancestors were in North America probably long before yours or at least before the ones of most Americans were! ;-)
Granted, English ain't my first language although. This doesn't constitute a valid excuse although and I don't try to use that fact as an excuse ;-))
I was merely admitting that I still do mistakes that seem obvious to the rest of the /. community and I actually enjoy being corrected ;-))
Thanks a lot or many thanks or several thanks which ever is the best ;-)
Everything I write is lies, read between the lines.
Thanks ;-)
Everything I write is lies, read between the lines.
The parent poster mentioned problems with *data* structures, not with code.
And the code it self is less likely to increase. First there isn't a big different in length between x86_64 and stock x86 op codes. The whole x86 family has been using opcodes of varying length since day 1.
There's nothing as dramatic as the differences between ARM native 32bits and Thumb 16bit modes.
Second, in 64bits the number of available registers increases dramatically, as said elsewhere in this thread.
As such, the net result is more compact code (less instructions are lost copying values around between the few registers - and the microcode doesn't have a hard time keeping track of this for its register renaming) and is one of the reason why 64bits code tends to sometimes even run faster as 32bit code on x86 platforms.
The only thing which is going to take more place are the memory pointer tables (they'll be using 48 and 64bits pointers).
But even they won't matter much as - as big as they are - these tables represent only a tiny fraction of all the data going through a CPU and occupy not that much cache-space. And the preferred memory model for 64bit code is flat, to begin with.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Unix-type program and not an NT-type program
Yes, process model vs threaded model. For NT, a threaded application would be limited to its maximum addressable space per process, of one process, for all back-ends. Since PostgreSQL is a process model, that means each back-end is limited to the maximum addressable process space. Thus on a Windows 64-bit box, you can load it up with memory and EACH back-end can manipulate up to its 2GB-4GB of address space, depending on configuration.
The bit-width of the system makes no difference to the amount of RAM used for file caches
Absolutely it does. I have no idea why you would believe otherwise. Cache is a function of address space available to the OS. A 64bit OS has a vastly larger address space. This means while a 32bit OS is pragmatically limited to no more than perhaps 1BG of cache after you account for OS+PostgreSQL+Backends. Whereas a 64bit OS is pragmatically limited to how much memory you can afford to place into your box; meaning tens of GB or more; depending on the hardware. That's a HUGE difference.
Yes, a "few" would probably work. It often is used to mean three, however; a "couple" being two. After that it gets hazy, but "handful" is probably next :)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Like the other poster said there's register renaming - this allows pipelined stuff to be executed in parallel even though they happen to be using the same registers.
:).
For example, if you have a pipeline of 8 instructions, the first four instructions might be using R1, and the second set of four instructions might be using R1 too - but for different _independent_ reasons. Now you can't store the same R1 values to two different locations since the second four instructions would generate a different "R1" value. So the CPU figures out that there are no dependencies and so the second set of four instructions actually use R1' to do stuff.
Register renaming can still help when you have 32 registers, but you just have less pressure to do it
Also while you are right that the x86 processor has to store and load from main memory more often, the CPU doesn't always have to wait for it to happen. When conditions are right it writes and reads from the cache and runs merrily along at higher speeds. Only later is the final value committed to main memory. This is not as fast as pure register access, but I'm sure there are other tricks the x86 CPU designers do for performance.
Absolutely it does. I have no idea why you would believe otherwise.
It only makes a difference, as you say, over 4GB. Or on castrated platforms, 3GB. But since you can't actually use more than 4GB without ugly, performance-killing hacks, anyone using more than 4GB is going to need to use 64 bit just to use all their memory. But that's not just the file cache, that's everything.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I think somewhere I lost you and I'm not really sure how since the conclusion is extremely obvious. You're even making exceptions which were already clearly spelled out or flat out obvious.
Which is faster? 1GB of DB files cached? 10GB of DB files cached? The later is only possible on a 64Bit OS. Thusly, even 32bit applications can benefit in this environment, despite the fact they are 32bit and are not directly accessing all of that data within its own 32bit address space. That's entirely the point of everything I said. Yet despite being extremely obvious, it stills seems to go over your head - I think - I'm really not sure based on your comments.
In other words, it gets 32bit cache benefits, non-shared back-end providing access to its full 32-bit address space, and speedy access to 64bit cached files. Remember, the application doesn't need to be 64.bit for the OS to be 64bit. Thusly, a 64bit OS is directly benefiting a 32bit application; whereby the 32bit application is likely to be faster than its 64bit equivalent.
Considering everything I've stated is correct, and now its been stated multiple times, I'm very confused about what it is you're trying to clarify or even what you're point is? Do you have a point? If so, can you state it so I can understand?
Does FreeBSD boot you into X by default yet? I installed the latest and told it "everything" and booted to a command shell. 'startx' returned an error. What gives?
I want to delete my account but Slashdot doesn't allow it.
Whether raw throughput or responsiveness is important depends on your application.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
in the case of Linux, a 32-bit OS does mean there is a 32-bit limit on general registers (EAX, EBX, ECX, EDX, ESP, EBP, EIP, ESI, EDI).
Well that's still 8regs * 4bytes = 32bytes per task, vs. 16regs * 8bytes = 128bytes per task.
You'll need quite a lot of task switching in order to fill the cache.
And even then, switching tasks is a rather rare event on the scale of other computations (Linux can switch task at 1000Hz when the low-latency desktop option is compiled into the kernel), so it is less dramatic if the switch does force a reload from RAM.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]