Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
The preinstalled OS is not even using 64-bit modeThe preinstalled OS is not even using 64-bit modePosted Feb 20, 2007 21:15 UTC (Tue) by proski (subscriber, #104)Parent article: Dell users demand more Linux options (ZDNet UK)
I find it ridiculous that Dell is selling 64-bit machines with a 32-bit OS preinstalled. 32-bit Windows XP underutilizes the hardware Dell customers are paying money for. I'm not even talking about stability of software freedom here. It's just about getting something decent for the money paid. I know, some configurations can be bought with 64-bit Windows XP or Vista, but not all of them. I didn't have such option with my Latitude D520 I bought in December 2006.
(Log in to post comments)
The preinstalled OS is not even using 64-bit mode Posted Feb 20, 2007 21:19 UTC (Tue) by moxfyre (guest, #13847) [Link] Linux wins again :-)
I have not found more than one or two open-source Linux applications that don't run perfectly in 64-bit mode. When I made the jump to 64-bit about a year ago, I thought it would be a big hassle and that lots of stuff wouldn't compile... nope! I just popped in the 64-bit Ubuntu CD and off I went.
Ya gotta love open source. We've had AMD64 for several years now and hardly any 32-bit apps yet under MS Windows. Kind of pathetic.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 11:26 UTC (Wed) by gouyou (subscriber, #30290) [Link] *cough* openoffice *cough*
The preinstalled OS is not even using 64-bit mode Posted Feb 23, 2007 23:30 UTC (Fri) by kamil (subscriber, #3802) [Link] Isn't version 2.1 supposed to compile on amd64? That's what I seem to remember reading on Gentoo forums, though I haven't tried it myself (openoffice is not something I normally use).
The preinstalled OS is not even using 64-bit mode Posted Feb 24, 2007 22:56 UTC (Sat) by liamh (subscriber, #4872) [Link] I've had no trouble with OOo in Debian amd64 from about 2.0.1 onward. The real hit you take in amd64 is with non-free software: flashplayer, Java (Sun Java is all available for amd64 except the browser plugin), acrobat reader if you use that. I recently acquired a Thinkpad T60 whose wireless Atheros chipset doesn't yet have a Linux driver, and because I'm using amd64, ndiswrapper is not an option.
The preinstalled OS is not even using 64-bit mode Posted Feb 24, 2007 23:22 UTC (Sat) by kamil (subscriber, #3802) [Link] Totally agreed regarding non-free software. And add googleearth and skype to that list (though they all work if 32-bit libraries are installed).
So far as your wireless problems go, at least some Thinkpads T60 come with Intel cards, which are supported. If you need wireless right here, right now, I would consider ordering one of those cards; replacement is usually quite easy. You can find them pretty cheaply on eBay, though watch out, as at least some Thinkpads apparently won't work with a generic version due to a BIOS lock.
The preinstalled OS is not even using 64-bit mode Posted Feb 26, 2007 10:18 UTC (Mon) by gouyou (subscriber, #30290) [Link] Supposed to, yes, but you still cannot download an x86-64 binary (the only one I've seen on the website is for 2.1 in the macedonian locale). But I agree the biggest problem is for proprietary applications.
The preinstalled OS is not even using 64-bit mode Posted Feb 20, 2007 22:47 UTC (Tue) by rfunk (subscriber, #4054) [Link] If you don't have more than 4GB of memory, and your apps have have massive virtualmemory requirements (i.e. they *work* in 32-bit mode), what's the point of running a 64-bit OS today? As far as I can tell, you'll use a bit more memory and run a bit slower moving that extra memory around, with no real gain.
The preinstalled OS is not even using 64-bit mode Posted Feb 20, 2007 23:18 UTC (Tue) by cwitty (subscriber, #4600) [Link] For most architectures that have 32 and 64 bit versions, this is correct--32-bit code runs a little bit faster than 64-bit code. However, AMD64 does more than just increase the word size; it also doubles the number of available general-purpose registers. Since the x86 is register-starved by modern standards (it only has 8 general-purpose registers, and usually two are dedicated to the stack pointer and the frame pointer), moving to 16 registers will often improve performance.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 0:16 UTC (Wed) by mikov (subscriber, #33179) [Link] Most benchmarks do not confirm this. I believe it has been shown that for apps which are not constrained by virtual memory space, going to 64GB offers very little improvement, if any at all. Don't forget that making all pointers 64-bit increases memory and cache pressure significantly. At least one 64-bit Java VM implements "pointer compression" - when possible using 32-bit pointers even in a 64-bit application. The existence of such complex solutions and the fact that they are actually beneficial illustrates the severity of the problem.
Bottom line, unless you _really_ need 64-bit, you are much better off with 32-bit, even on a 64-bit CPU.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 1:47 UTC (Wed) by dlang (subscriber, #313) [Link] I've seen speedups when switching to 64 bits, even with <4g
like all benchmarks, your mileage may vary.
if your task is primary moving data around then the fact that you have more data to move around makes it a loss.
if you are compute bound then the increase in registers can make a huge difference.
java is far from the most efficiant system available, so don't take it's performance as representing everything ;-)
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 18:03 UTC (Wed) by mikov (subscriber, #33179) [Link] I did a quick trawl through the Spec database to compare 32-bit and 64-bit results of the same system. There aren't that many, but here are a couple I found (the first ones in the output sorted by system name).
I am looking at the baseline results, because they are much more representative for typical non-benchmark apps.
32-bit: 1666 http://www.spec.org/osg/cpu2000/results/res2006q1/cpu2000...
32-bit: 1831 http://www.spec.org/osg/cpu2000/results/res2006q4/cpu2000...
32-bit: 1688 http://www.spec.org/osg/cpu2000/results/res2006q1/cpu2000...
It is interesting that the peak results usually reverse the situation, making the 64-bit faster. Also, different compilers are being used for 32-bit and 64-bit, but this is the closest to a comparison I could find.
Basically, no matter how you look at it, 64-bit doesn't seem to offer significant performance advantage, even if I would not call it slower.
About Java's slowness: I was using that as an example for the benefit of pointer compression. Obviously it can't be tested in a native environment. The point is that its benefits are measurable, and consequently the slowdoan from 64-bits is not negligible.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 3:25 UTC (Wed) by rafdz (guest, #41427) [Link] i think that pointer compression should be used even on 32 bits by compressing pointers to 16 bits or even 8 bits.i don't think that this is that complicated, one could simply implement custom allocators with memory areas of say 256 Kbytes (64K words ) or 512Kbytes.i think that neither gcc nor linux kernel should use 64 bits pointers in general(they should be used only in some specific cases).switching to compressed pointers would take some efforts, but it's the only way to fully exploit current hardware capabilities.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 18:32 UTC (Wed) by RareCactus (guest, #41198) [Link] Hardware is a moving target.
No doubt in a few years, 64-bit pointers will be the norm, and 32-bit pointers will be supported the same way real-mode applications are in Windows-- poorly, and slowly through emulation.
Using 16-bit pointers (which is only possible in real mode) is already a huge performance hit. The chip designers support it, but they don't care how fast it is, because most people only ever are in this mode when they're looking at the BIOS.
I don't understand what you're talking about with 8-bit pointers, since the x86 has never had those.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 7:33 UTC (Wed) by k8to (subscriber, #15413) [Link] On the 10-20 real-world performance-limited applications I've tested, the amd64 compiled code is 5-20% faster. Mostly these are silly things like compresion software, codecs, emulators and so on. But I've seen basically 0 cases where the performance is equivalent.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 18:14 UTC (Wed) by mikov (subscriber, #33179) [Link] I don't have any hard data, but see my reply to dlang above in this thread with a couple of references to SPEC2k results (which are debatable). I also remember reading about a benchmark of a 64-bit and 32-bit game on Windows where the 64-bit build was slower, so it was concluded that game developers have absolutely no incentive of testing and releasing 64-bit builds (considering WOW64). Alas, I can't find the link :-(
As far as I can tell, a typical desktop user would not see in any noticable performance difference between 32 and 64 bit, so the trouble of going to 64-bit is usually not worth it for them.
For CPU-bound stuff like codecs and compression, it sure seems that the improvement should be significant - they use little pointers, so there should be no disadvantage of 64-bits. However if you take any Java app, it has lots and lots of pointers, so it will suffer greatly. Which is ironic, because Java is supposed to be good for servers, and precisely servers are switching to 64 bit .. :-)
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 20:11 UTC (Wed) by rafdz (guest, #41427) [Link] i admit that using 8 bits pointers is not realistic.however 16 bits pointers i am talking about are not real pointers.they are in fact indexes that must added to a base 64 bits or 32 bits real pointers.the pointer compression methdo is explained in the following paper.http://llvm.org/pubs/2005-06-12-MSP-PointerComp.ps. according to that paper pointer compression is beneficial only when working set of program doesn't fit into L2 cache.on other papers it has also been proved that automatically transforming memory heap allocation into automatic pool allocation could also improbe locality and hence improve performance.it would be nice if gcc could integrate the two approaches (pointer compression and automatic pool allocation) but this obviously will require a lot of research and hard work before it will be possible.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 15:53 UTC (Wed) by tyhik (subscriber, #14747) [Link] Depends on your definition of "real gain". Almost all the time I underuse the speed and memory of my 64-bit desktop machine; if I'd need more speed, i'd overclock or buy a faster desktop. For me the real gain is that now I can build and test my SW for 64-bit at home.
I imagine some people may find a real gain the ability to run unmodified kernels on top of kvm with recent cpus and the like.
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 0:18 UTC (Wed) by irios (guest, #19838) [Link] Well, Dell sells 64-bit machines with such buggy BIOS that 64-bit Linux won't run at all. In fact, the original BIOS for the Dimension E521 sucked so bad that it wouldn't run ANY Linux distribution at all unless you plugged the keyboard and mouse into a lucky (meaning not just any), powered, USB hub or PCI USB card.
Hell, it was so bad that it wouldn't even run an unpatched version of Windows XP or 2000!
Thankfully, after about 4 months, they have released a BIOS upgrade that cures it for 32-bit Linux (even though they have not acknowledged the problem yet -- the new BIOS is supposed to fix something else). As for 64-bit Linux (and probably Windows) would-be users, well, bugger them.
There's a support thread in their system that has dragged on for months, with hundreds of entries, without Dell ever showing any interest.
Most funny is that the E521 was sold OS-less in the States and promoted as a computer whereupon to install Linux -- evidently not much testing went on.
Don't expect good quality control from Dell, or good support for Linux. Hell, don't expect good support at all from Dell, for what I've seen!
The preinstalled OS is not even using 64-bit mode Posted Feb 21, 2007 8:01 UTC (Wed) by skvidal (subscriber, #3094) [Link] I'd argue this isn't true. Dell's poweredge linux list and linux.dell.com have been extremely useful in figuring out what's going on with some piece of hardware. We have a large number of dell servers and workstations and I've found working with them on linux-related problems to be pretty well supported.
-sv
Dell Posted Feb 22, 2007 18:40 UTC (Thu) by rfunk (subscriber, #4054) [Link] I'm sure that Dell treats the PowerEdge line (and customers) much better than theDimension line.
The preinstalled OS is not even using 64-bit mode Posted Feb 23, 2007 23:43 UTC (Fri) by kamil (subscriber, #3802) [Link] Even now if you order a Dell XPS M1210 notebook (which features a 64-bit Core 2 Duo), it comes pre-installed with a 32-bit version of Vista, not 64-bit.
I found it weird, but then again, what do I care: I'm running 64-bit Linux (Gentoo) on it :-).
And, answering another thread, yes, not all video codecs are supported by the 64-bit mplayer, but most stuff works (including wmv, which is now supported by ffmpeg). One can always install a 32-bit version of mplayer if that one missing codec is *really* needed.
|
|||||||||||