vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| Hadron wrote: > Andrew Halliwell <spike1@ponder.sky.com> writes: > >> Aragorn <aragorn@chatfactory.invalid> wrote: >>>> Are there any advantages and disadvantages between 686 and amd64 beside >>>> being able to use more memory which I doubt I am going to (2 GB is >>>> enough). >>> Well, the /AMD64/ kernels are more likely to contain some processor-specific >>> code optimizations than a generic /i686/ kernel, >> There's a bit more to it than that.... >> x86-64 is more than just a wider address bus, it also contains a shedload >> more cpu instructions, such as SSE3, iirc. There're also a lot more >> registers available in 64bit mode. Which means less fetching from RAM during >> calculations. >> >> These enhancements may (in some situations) make it faster... >> But I think the general consensus is, speed is generally slightly slower >> because 64 bit applications tend to be slightly bigger due to the extended >> instruction set and data-width taking more memory/disk space. > > This was hotly contested by some in comp.os.linux.advocacy but is > effectively correct. I saw no speed improvement in 64 bit over 32 bit > and just suffered from a far less stable system. > >> If you don't need more than 4gig of RAM, chances are, you're fine in 32 bit >> mode, and may even be slightly better off, performance wise. > > And certain things like flash do not work properly. > > See: > > http://groups.google.com/group/comp....5d987c45c9499c > > It is however getting better. > I think this is largely correct: I had this choice to make..for a moderately loaded server. Looking at some of the problems associated with the 64 bit kernels, and realizing that by and large my actual applications were not hugely computationally intensive, but more disk I/O bound, there seemed little point in taking the small risk of a 64 bit kernel and libraries. If I were building a massive server to handle many processes, then yes, 4gig RAM plus, and a 64 bit kernel would be indicated. Or a desktop to do graphics work. |
| |||
| The Natural Philosopher <a@b.c> writes: > Hadron wrote: (snip) >> This was hotly contested by some in comp.os.linux.advocacy but is >> effectively correct. I saw no speed improvement in 64 bit over 32 bit >> and just suffered from a far less stable system. >> >> Andrew Halliwell <spike1@ponder.sky.com> writes: >> >>> If you don't need more than 4gig of RAM, chances are, you're fine in 32 bit >>> mode, and may even be slightly better off, performance wise. >> >> And certain things like flash do not work properly. (snip) > I think this is largely correct: I had this choice to make..for a > moderately loaded server. > > Looking at some of the problems associated with the 64 bit kernels, and > realizing that by and large my actual applications were not hugely > computationally intensive, but more disk I/O bound, there seemed little > point in taking the small risk of a 64 bit kernel and libraries. This has been quite interesting for me to read. I've been running AMD-based (Opteron and Athlon) systems for years, at home and at work, with 64-bit kernels and not run into any problems, with stability or otherwise, that were caused by doing that. For instance, our twin-dualcore-CPU (two Opteron 275s) compute server has been rock-solid. My experience with 64-bit Intel has been more recent (for example, I am writing this on a T5200 system that can't be much over a year old, but for that I am using CONFIG_MCORE2) but also very good. I have flash working just fine with the help of Debian's ia32-libs package. (-: I will, however, happily admit that I tend to be unusually lucky when I run new things (for example, I've been running kernel 2.6.24 for quite some time now), that even our servers at work are fairly lightly loaded (I try to overspec them to avoid future headaches), and that I can't claim to have measured any actual speed improvement from choosing 64-bit instead of 32-bit. So I may have dodged some problems without really gaining much. Mark |
| |||
| Mark T.B. Carroll wrote: > I will, however, happily admit that I tend to be unusually lucky when I > run new things (for example, I've been running kernel 2.6.24 for quite > some time now), that even our servers at work are fairly lightly loaded > (I try to overspec them to avoid future headaches), and that I can't > claim to have measured any actual speed improvement from choosing 64-bit > instead of 32-bit. So I may have dodged some problems without really > gaining much. From professional experience: 64-bit is wonderful for tools that have been out long enough to be properly tested in 64-bit. I got involved in porting Wacom tablet drivers to 64-bit SuSE some time ago, and it's possible to do things like that, but I don't recommend it for people who expect things to "just work", anymore than I recommend they try new combinations of high-end components. |
| |||
| Meat Plow <meat@petitmorte.net> wrote: > Where can I fetch an AMD64 kernel to play with? I could easily note the > differences in performance if any. If you want to play about with one to test performance, you're probably better off downloading a generic kernel from kernel.org and compiling 2 to test yourself, that way you know the only compile options that change are the architecture (i686 and AMD64) so you have a good baseline to compare them against. -- | spike1@freenet.co.uk | | | Andrew Halliwell BSc | "ARSE! GERLS!! DRINK! DRINK! DRINK!!!" | | in | "THAT WOULD BE AN ECUMENICAL MATTER!...FECK!!!! | | Computer Science | - Father Jack in "Father Ted" | |
| |||
| On Sun, 20 Apr 2008 20:37:44 +0100, Andrew Halliwell wrote: > Meat Plow <meat@petitmorte.net> wrote: >> Where can I fetch an AMD64 kernel to play with? I could easily note the >> differences in performance if any. > > If you want to play about with one to test performance, you're probably > better off downloading a generic kernel from kernel.org and compiling 2 to > test yourself, that way you know the only compile options that change are > the architecture (i686 and AMD64) so you have a good baseline to compare > them against. Thanks. I thought about that right after I hit the send button. |
| ||||
| Meat Plow <meat@petitmorte.net> writes: > On Sun, 20 Apr 2008 20:37:44 +0100, Andrew Halliwell wrote: > >> Meat Plow <meat@petitmorte.net> wrote: >>> Where can I fetch an AMD64 kernel to play with? I could easily note the >>> differences in performance if any. >> >> If you want to play about with one to test performance, you're probably >> better off downloading a generic kernel from kernel.org and compiling 2 to >> test yourself, that way you know the only compile options that change are >> the architecture (i686 and AMD64) so you have a good baseline to compare >> them against. > > Thanks. I thought about that right after I hit the send button. > Or you could not bother and compare the config files that ship with the bespoke debian kernels. You will find little difference. You would be far more interested in "standard" kernel stability and performance than some optimised mish mash assuming you want to use it on your desktop. Clearly if you have very specialised needs then the above might not be so valid. I know that whenever I have compiled my own there is very, very little difference in performance and one of the only times I would consider it would be for very specialised HW situations where I know I can leave out 90% of the default drivers. |