Ubunut 12.04 LTS, 32 or 64 bit?

[Hank Czerwick]

In the debian files I see repositories for 12.04LTS, are these for the
32 or 64 bit version?

Hank AB2XG

[Stuart Longland]

A squiz at http://files.freedv.org/debian/pool/main/f/fdmdv2/ I see both
amd64 (64-bit) and i386 (32-bit) binaries.

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

[John D. Hays]

Do you have more than 4 GB RAM in the computer? If not, go 32-bit.

---

John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 

  

--
You received this message because you are subscribed to the Google Groups "digitalvoice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice...@googlegroups.com.
To post to this group, send email to digita...@googlegroups.com.
Visit this group at http://groups.google.com/group/digitalvoice?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

[Bruce Perens]

Linux will use all of your RAM up to 64 GB even if it's 32 bit. Windows, for some odd reason, can only use 2 G in its 32-bit version.

You should always use a 64 bit kernel if your hardware is capable of it, because it provides some extra CPU features and utilizes the available hardware most effectively.

You should probably stick with 32-bit user mode, though, for a desktop that doesn't run any application that specifically needs huge RAM. 64 bit kernels will run 32 bit executables (again, unlike Windows). There is a RAM cost from 64-bit pointers and integers that makes little sense if you don't need a big address space.

Servers that face the Internet should probably be 64 bit user mode to make use of some additional memory access protection.

Debian has been making it easier to run "multiarch", having both 32 bit and 64 at the same time. You must have a 64-bit kernel to do this. There is some RAM inefficiency from having both 32 and 64 bit versions of shared libraries in RAM at the same time.

Thanks

Bruce

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[Stuart Longland]

On 09/06/13 14:20, John D. Hays wrote:
> Do you have more than 4 GB RAM in the computer? If not, go 32-bit.

Wrong answer.

Correct question and answer is: Is your OS 64-bit? If not, go 32-bit.

PAE support (as Bruce points out) is much better under Linux than
Windows, however there are other reasons than just RAM that make 64-bit
a better choice in many cases.

The decision of 64 vs 32-bit, is one to make when picking the OS. Once
chosen, you should use applications configured/compiled for that
architecture for maximum compatibility.

If you have a 64-bit operating system, then you either need to use
64-bit versions of the program, or if you really must use 32-bit, you'll
need to procure 32-bit versions of the dependencies, and install those
in parallel to any 64-bit versions of the same package. This is
something many distributions of Linux still haven't got a clean solution to.

Alternatively, if you're running a 32-bit OS, then the choice is easy,
you can only use 32-bit binaries. Very few 32-bit kernels will run
64-bit code (MacOS X is one that springs to mind).

[Brian Litzinger]

Unless you have a specific need for 64 bit, go 32.

If you choose 64bit your default integer will be 8 bytes instead of 4.
Your programs
dataset's will tend to be twice as large chewing up memory much more quickly.
Similarly, machine instructions will be using 8 byte pointers instead
of 4 byte pointers
making many memory references twice as large. These larger
instructions will chew
up your cache memory more quickly, and so on.

[Bruce Perens]

I think the word "OS" is confusing because it means both the kernel and the user mode. You can run a 32 bit or 64 bit kernel, and if you have a 64 bit kernel you can run 32 bit or 64 bit user-mode, or multiarch which is both. There are very few compatibility issues between 64 bit kernels and 32 bit applications, I think they are mostly in stuff like Xen. But KVM is good enough now that it's time to give up Xen anyway.

Does Red Hat not have multiarch yet?

Thanks

Bruce

[Steve]

It seems like anymore, you have to pay more for 32-bit mother boards :-) Cheap is better...

What's really needed is an 8-bit CPU with two 12-bit A/D-D/A, and maybe a couple of these FP chips: https://www.sparkfun.com/products/8129

A simple RTOS to blink all the lights...

[Stuart Longland]

On 09/06/13 15:53, Bruce Perens wrote:
> I think the word "OS" is confusing because it means both the kernel and
> the user mode. You can run a 32 bit or 64 bit kernel, and if you have a
> 64 bit kernel you can run 32 bit or 64 bit user-mode, or multiarch which
> is both. There are very few compatibility issues between 64 bit kernels
> and 32 bit applications, I think they are mostly in stuff like Xen. But
> KVM is good enough now that it's time to give up Xen anyway.

Indeed... it's ambiguous, when I refer to 64-bit OS, I mean kernel and
userland libraries. multilib is the way it's commonly handled to allow
32-bit applications to run, often this is achieved by "emulation"
packages ... a bit of a kludge.

Gentoo did it this way; app-emulation/emul-linux-x86-* packages. About
the time I retired from Gentoo, they were starting to look into proper
multilib support in portage (wherein it'd track dependencies per ABI).

> Does Red Hat not have multiarch yet?

Not sure, AMD64 didn't exist last time I used Red Hat. Neither did Fedora.

[Richard Shaw]

On Sun, Jun 9, 2013 at 12:53 AM, Bruce Perens <br...@perens.com> wrote:

I think the word "OS" is confusing because it means both the kernel and the user mode. You can run a 32 bit or 64 bit kernel, and if you have a 64 bit kernel you can run 32 bit or 64 bit user-mode, or multiarch which is both. There are very few compatibility issues between 64 bit kernels and 32 bit applications, I think they are mostly in stuff like Xen. But KVM is good enough now that it's time to give up Xen anyway.

Does Red Hat not have multiarch yet?

Reply to the thread in general:

This day in age, I'm not sure there's any compelling reason to choose 32bit over 64 *for general computing*. Sure, you type up a little more memory, but memory is cheap and the advantages outweigh the disadvantages. 

Embedded computing, or systems with very limited memory, which I assume we're not talking about, is another story.

To Bruce:

Yes, Fedora has been multilib for as long as I've been using it (Fedora 10) and RHEL since at least RHEL 5, I haven't used anything earlier. 

I'm not sure what "emulation" Stuart is talking about but beyond some kernel stuff, there's nothing really special needed to run 32bit apps on a 64bit kernel other than having the correct 32bit library dependencies installed.

Richard

[Steve]

I drifted off topic, sorry :-)

Although I like the built-in FFT of the co-processor chip. I wonder if 128 real FFT bins would be good enough for codec2. I suspect 256 was a compromise, and more would be better.

oops, drifting again...

[Bruce Perens]

On 6/9/2013 1:20 AM, Steve wrote:
>
> and maybe a couple of these FP chips:
> https://www.sparkfun.com/products/8129

This is obviously a generic microprocessor with a program burned in.
It's for people who are stuck with the PIC, Basic Stamp, or Arduino as
their main design and want to bolt floating point on to the side. It's
awkward to interface compared to just calling a floating point
instruction (send the command and data to the coprocessor via a one-wire
bus to be computed, and then read back the return data and status bits)
and it's more expensive than doing it right, which would be using a CPU
that has floating point instructions.

We can give you a "codec2 chip" for the price of this thing. It would
just be a STM4F or similar floating point microprocessor with the
program burned in.

Thanks

Bruce

[Bruce Perens]

On 6/9/2013 3:25 AM, Stuart Longland wrote:
> ous, when I refer to 64-bit OS, I mean kernel and
> userland libraries. multilib is the way it's commonly handled to allow
> 32-bit applications to run, often this is achieved by "emulation"
> packages ... a bit of a kludge.

I think this was using BOCHS or something. Nobody does it that way any
longer, there is no emulation necessary to run a 32 bit process on a 64
bit kernel. The kernel is able to start a process in 32 bit or 64 bit
mode, and will handle system calls with both the 32 and 64 bit data. The
32 and 64 bit versions of ld-linux.so and all of the shared libraries
and executables run in "native mode".

BOCHS is mostly useful these days for virtualizing
virtualization-unaware operating systems or filling in for a lack of
virtualization support. Or once in a while for running Intel binaries on
non-Intel architectures.

Thanks

Bruce

[Steve]

I used to work on a SuSE linux supercomputer running on Itanium.

It was a sad deal, as some of the expensive complex math applications had to run in a 32-bit X86 emulator.

Course, I think those days are over, as Itanium is end-of-life.

[Stuart Longland]

On 10/06/13 06:33, Bruce Perens wrote:
>> often this is achieved by "emulation"
>> packages ... a bit of a kludge.
> I think this was using BOCHS or something. Nobody does it that way any
> longer, there is no emulation necessary to run a 32 bit process on a 64
> bit kernel. The kernel is able to start a process in 32 bit or 64 bit
> mode, and will handle system calls with both the 32 and 64 bit data. The
> 32 and 64 bit versions of ld-linux.so and all of the shared libraries
> and executables run in "native mode".

Yeah, I know of Bochs, but no, this was not using Bochs. These
"emulation" packages... note my use of quotes... were just packaged
32-bit versions of libraries set up to slot into the multilib directory
paths.

They "emulated" the 32-bit environment that a 32-bit application would
expect to see by supplying libraries with the correct ABI. Basically
take the equivalent 32-bit library, strip out the stuff that goes in
/usr/bin, etc,... move the stuff in /usr/lib to /usr/lib32, and package
that up.

Messy, but it works, since ld then finds the libraries for the right
ABI. It's less painful if your distribution is binary-based, more a
problem for source-based distributions.

The correct fix is for the package to be split up into ABI-specific and
ABI-nonspecific parts, and have the package manager know to manage the
dependencies for the separate ABIs. This is the approach that Gentoo
was moving towards. I don't know about other distributions.

[Stuart Longland]

Interesting device... but I note they only run at just under 30MHz, and
I'll bet they're implemented on a general purpose 8 or 16-bit MCU. Nice
if you're stuck with a lesser MCU, but I'd imagine painful to use and
slower than an on-chip FPU.

[Jasmine Strong]

On 9 Jun 2013, at 19:03, Stuart Longland <stu...@longlandclan.yi.org> wrote:

> On 09/06/13 18:20, Steve wrote:
>> It seems like anymore, you have to pay more for 32-bit mother boards :-)
>> Cheap is better...
>>
>> What's really needed is an 8-bit CPU with two 12-bit A/D-D/A, and maybe
>> a couple of these FP chips: https://www.sparkfun.com/products/8129
>> A simple RTOS to blink all the lights...
>
> Interesting device... but I note they only run at just under 30MHz, and
> I'll bet they're implemented on a general purpose 8 or 16-bit MCU. Nice
> if you're stuck with a lesser MCU, but I'd imagine painful to use and
> slower than an on-chip FPU.

Why not just use an LPC1758? They run at 100 MHz, are 32-bit, and cost less than $5 in 1000-off.

-J.

[Stuart Longland]

On 10/06/13 12:10, Jasmine Strong wrote:
> Why not just use an LPC1758? They run at 100 MHz, are 32-bit, and cost less than $5 in 1000-off.

No FPU, so not really suited for Codec2 work since it's very
float-intensive.

I suppose if you push the speed up high enough you'll overcome the
softfloat overhead, but hardfloat ICs aren't that much more expensive.

[Steve]

I'm always a sucker for FFT on a chip :-)

Alas, the FFT is too small/slow for this application.  No Unix or Windows required though...

[Stuart Longland]

On 10/06/13 23:43, Steve wrote:
> I'm always a sucker for FFT on a chip :-)
>
> Alas, the FFT is too small/slow for this application. No Unix or
> Windows required though...

No, there'd be windows involved... perhaps Hamming or Kaiser windows,
rather than Microsoft Windows. ;-)