Why do newbies go for 64 bits?
in [UK Linux]
|
Prev: ACPI problems with Centrino processor
Next: Just $15
From: Richard Kettlewell on 24 Nov 2009 04:09 Nix <nix-razor-pit(a)esperi.org.uk> writes: > On 23 Nov 2009, spike1(a)freenet.co.uk said: >> And verily, didst Tony Houghton <h(a)realh.co.uk> hastily babble thusly: >>> But what's the disadvantage of using 64-bit Linux nowadays? 32-bit >>> WINE works for me on Debian amd64. Certain browser plugins used to >>> be problematic, but there are decent (well, not really any worse >>> than the 32-bit versions) 64-bit versions now. >> >> One disadvantage is that programs compiled for 64bit require more >> memory due to the extra instructions, > > ITYM 'increased alignment requirements'? I'd have thought the double-sized pointers would be the biggest additional consumer of memory. -- http://www.greenend.org.uk/rjk/
From: anahata on 24 Nov 2009 04:42 On Tue, 24 Nov 2009 09:09:37 +0000, Richard Kettlewell wrote: > Nix <nix-razor-pit(a)esperi.org.uk> writes: >> On 23 Nov 2009, spike1(a)freenet.co.uk said: >>> >>> One disadvantage is that programs compiled for 64bit require more >>> memory due to the extra instructions, >> >> ITYM 'increased alignment requirements'? > > I'd have thought the double-sized pointers would be the biggest > additional consumer of memory. I know nothing about current 64 bit instruction sets, but by analogy with the 16 bit and 32 bit world, just because it's capable of 64 bit addresses doesn't meant that all pointer values are 64 bits. For example, relative jumps could still be encoded in a 16 or 32 bit variety. The instruction set could be richer too, allowing for things to be done in fewer (more complex) steps, and as has been mentioned, having more registers should also make some sequences more efficient. Is AM64 code variable length like x86? -- Anahata anahata(a)treewind.co.uk ==//== 01638 720444 http://www.treewind.co.uk ==//== http://www.myspace.com/maryanahata
From: chris on 24 Nov 2009 05:02 Martin Gregorie wrote: > On Sat, 21 Nov 2009 23:23:09 +0000, Folderol wrote: > >> Try using hydrogen + zynaddsubfx + jamin + rosegarden with qjackctl - >> you'll notice the difference then alright :o >> > I know next to nothing about music programs. I can rip vinyl onto CD with > Audacity, but that's about it, so why do you say that? I mean, how many > of these programs' memory requirements bust the 32 bit addressing limit. There's more to 64bit than just being able to access >4Gb natively. Increased precision of floats and the use larger ints without having to resort to doubles and long ints is a significant benefit. It increases the speed of RAM look-ups for processes which require this. Particular examples are compression, encoding or graphics/video processing. /If/ they have been optimised for 64bit, rather than just been recompiled. > IOW does running a 64 bit OS buy you anything with that process mix that > a few more cores and the odd extra GB of RAM wouldn't also solve? Yes. See above. But, as you say in your OP the average desktop usage of email/web/openoffice is unlikely to gain any noticeable benefit.
From: chris on 24 Nov 2009 05:06 Dave Farrance wrote: > Dave Farrance <DaveFarrance(a)OMiTTHiSyahooANDTHiS.co.uk> wrote: > >> I'm tempted to install the i586 version of this distro in a >> separate partition to do some timing tests. > > Done that. I've tried running glxgears, and gzip'd a 100Mb file a few > times, and there's no difference in the average speeds between the i586 > and x86_64 distros with those tests. Ho hum. The gzip might be too small. Try a 1-2Gb file. Also, try audio or video compression. ISTR that they were some of the biggest gainers in going 64bit.
From: Richard Kettlewell on 24 Nov 2009 06:42
anahata <anahata(a)treewind.co.uk> writes: > Richard Kettlewell wrote: >> I'd have thought the double-sized pointers would be the biggest >> additional consumer of memory. > > I know nothing about current 64 bit instruction sets, but by analogy > with the 16 bit and 32 bit world, just because it's capable of 64 > bit addresses doesn't meant that all pointer values are 64 bits. For > example, relative jumps could still be encoded in a 16 or 32 bit > variety. Jumps can be encoded in as little as a single byte in amd64 (not counting the opcode itself). But many running programs will be full of non-constant pointers (object addresses), which are 64 bits long. > The instruction set could be richer too, allowing for things to be > done in fewer (more complex) steps, and as has been mentioned, > having more registers should also make some sequences more > efficient. > > Is AM64 code variable length like x86? Yes, it is. -- http://www.greenend.org.uk/rjk/ |