Hi.

I was just wondering. When someone say's "Slackware is only available in 32-bit version" what do they mean exactly? Does that mean the kernel is 32-bit or the apps that come with the distro were all compiled against a 32-bit cpu? Also, I've done quite a few kernel compilations, so I'm not a complete newby, but how would I compile a 64-bit kernel instead of a 32-bit kernel? My cpu is a dual-core Pentium T3400 on my laptop. I've always just selected the Pentium 4 under "processor type" in the menuconfig.

thanks

To run a particular application using 64-bits per word, you would need 3 things:
1. A 64-bit version of the application
2. A 64-bit operating system
3. A 64-bit processor

You can run a 32-bit version from the "top down"---in other words, if anything on the list is 32-bit, then everything above it must also be 32-bit.

When a distro is released in a 64-bit version, it means that the kernel has been compiled for a 64-bit processor. Presumably, it also means that the utilities and apps are also 64-bit, but that would not be required. It is quite possible that the distro would include some 32-bit stuff.

When compiling a kernel, are there not options for 64-bit processors?

thanks. I've never seen the option to compile the kernel as 64-bit though. Maybe I'll have a look through menuconfig. By the way, I've also heard that 64-bit can be slower that 32-bit. But, that being known, I don't see what all the fuss is about 64-bit distros; I mean just re-compile your kernel as 64-bit and compile your own apps. I usually compile my own software from source anyway. I don't like pre-compiled stuff; it's more fun to compile it on your own (./configure, make, make install >> log_install). No need for package managment and utils that hide all the complex stuff.

ANY system can be slowed down by not having it configured right too little swap space & too little ram come to mind first
I have a 64bit port of slackware
IT is fast really really fast 4 to 6 times faster than 32bit slackware
same version (same code for every thing )
BUT to run a 64bit distro you need to have 64bit data paths on your mother board at the minim video adepter,hard drive and most importantly memory as well as a 64bit CPU

the 64bit kernel and gcc compiler are about 8years old nothing new here
and are just about the only place assembly code is used any more

some people clame that the 64bit distros are buggy and not ready for prime time WRONG

the only bug I have ever seen in my 64bit distro was in the 32bit distro as well
they seem to forget that linux runs on every thing from cell phones to the worlds fastest computer
why do they think it's such a far leap for linux to support 32 more bits


so IF your CPU and mother board support 64bits try it I cam promise you that you will not only not want to go back to a 32bit distro you will not even to want to run 32bit APPs

BTW
I can run 32bit APPs (it's a mostly matter of having 32bit libraries installed as well as 64bit) the kernel has 32bit emulation built in
BUT
I do not want to

I have a dual-core t3400 and heard it's 64-bit. Does that mean I can run 64-bit?

depends on your mother board
dose it have the 64bit data paths I told you about in my last post
you will need to look up your MoBo chip set on it's OEM's web page
if it dose they will brag about it being 64bit ready
ALL CPUs have been 64bit for the last 5years BUT NOT ALL chip sets are 64bit
and it's best to have more memory I have 2Gig of memory how much you will need
check with the distro you would like to use
IF the computer is vis-stool ready or came with vis-stool then you can run a 64bit distro I think

You usually download the 64 bits version of the distro and use that.



Not usually on x86 However you can force a given arch by doing



Not that easy. In first place to compile 64 bits stuff you need a compiler that's able to compile 64 bits code. And that includes the compiler itself. You can't compile a 64 bits gcc if you don't already have a 64 bits gcc.

About package management, not everyone has hours to devote to dependency resolution. You can get even a greater degree of power using something like Gentoo, which lets you do everything you want without having to manually resolve every single dependency, which is a complete pain and not worth the trouble.


You are not going to have a speed boost of 400%-600% as you describe. Not at all. In most applications there's no noticeable difference at all. In some others (mainly number crunching and media encoding) the difference will be noticeable: yes. But not THAT big as you say.

Yes. That's true. x86_64 is, and has been since almost the beginning just as stable as x86 even was. That *some* developers don't want to port their applications to x86_64 is not the distro's fault.

Not that easy. You probably want to run wine and grub, to say the least. They are 32 bit only. Gentoo also manages this quite well via multilib.

Quote:
Originally Posted by rob.rice View Post
IT is fast really really fast 4 to 6 times faster than 32bit slackware
CPU
You are not going to have a speed boost of 400%-600% as you describe. Not at all. In most applications there's no noticeable difference at all. In some others (mainly number crunching and media encoding) the difference will be noticeable: yes. But not THAT big as you say.

there is NO porting to 64bit for C,C++,Fortran,pascal what have you except for assembly code
IF the compiler has been ported every thing can be built for what ever machine code the compiler can output

gcc can cross compile so a 32bit gcc can compile for 64bits

yes it is that big
almost EVERY THING is faster from the web browser to mplayer is smooth no stalling no blockinesses even in fullscteen mode
even with fast action
every thing with out a timing loop like games (even some games) and audio players is noticeable
I could read the output from a configure script running 32bits not I can't even lock my eyes on the out put from a configure script to read it now
the out put from tar -xzvf turns the left edge of the gray it's not even a blur it's just gray
I could just read the output from tar -xjvf it's a blur now about like gzip was
and this is running in an xterm
you must have forgotten how much time the CPU spends moving data around it's not just crunching numbers most of it's time is spent moving data like from the CPU to&from FPU,memory to&from cache,cache to&from cpu,cach to&from I/O ports in 32bit mode it's done 32bits at a time in 64bit mode it's done 64bits at a time and there's the instructions to do these moves integer calculations run about 6 to 12 times faster(don't believe me on this look at some assembly code) plus there are registers that only work in 64bit mode
you computer must not have a 64bit mother board if you didn't see a speed boost of 4 to 6 times

That's plain impossible. And besides what pure logic dictates, I've been running x86_64 installations for years now. So I know from experience. Placebo effect, who knows. But x86 vs x86_64 only means that you have some extra cpu instructions and a bigger word size, but nothing else. Even in the best case, like media encoding, you can gain at most a rough 20-50% on speed gain. And only if the programs have been designed to use all the extra power.

Well, I will not argue with you to convince you. I know what hardware I have because I buy and assemble it myself. If x86 is much much much slower for you that's because your x86 install had some problem.

Yes, but rarely by enough to care about. More likely 64-bit will be faster by not enough to care about.

I don't think that would work. I don't think you can drop a 64-bit kernel into an installed 32-bit distribution and have it work.

You can run 32-bit applications in most 64-bit distributions, but I think some of the support for that is outside the kernel and also not in 32-bit distributions.

You are most likely mistaken. Otherwise something was seriously wrong with the 32bit slackware you tried.

Nonsense. To run a 64bit distro, you need a 64bit CPU. Most 32bit systems have 64bit data paths on the motherboard, but if you have 32 bit data paths on a motherboard with a 64 bit CPU that is no problem for a 64bit kernel. 32 bit data paths on your video, again no problem. Even 16 bit or 8 bit data paths to and on the video is no problem and some of those weird mixes of obsolete parts with newer CPUs are really in use. 32 bit memory, similarly no problem except for performance. But even most 32 bit systems have "dual channel" (meaning 64-bit) memory.

Correct, and in a 32-bit distribution the compiler might not be able to compile 64 bit, so you'd need to recompile the compiler before you recompile the kernel (even if you could use that recompiled kernel).

False. Whether GCC itself is a 64bit program and whether gcc can compile 64bit programs are two independent features. A 32bit gcc only able to compile 32bit code could compile a 32bit gcc that can compile 64bit as well (just select that when you configure gcc).

I agree.

There is almost no bound on how much faster some obscure program might get as a result of using 16 SSE registers and/or native support for 64 bit integers, especially if either of those features shrinks a key inner loop enough to fit in L1 cache. Certainly it could run more than four times faster. But such programs are very uncommon.

That is very different from the results almost everyone else see.

More nonsense. Almost all data transfers will be the same size in 32bit mode as in 64bit mode. Most of the exceptions will be cases where 64bit mode needs to transfer more to do the same job, so it is at a disadvantage to 32bit mode. I understand that you expect 64bit mode to be able to do a smaller number of larger transfers. But very little actually works that way. Transfers between the CPU chip and motherboard memory will be the same size regardless of 32/64 CPU mode. Transfers between the L2 cache and anything else will be the same size regardless of 32/64 CPU mode. Most of what passes from the L1 cache to the main CPU will be the same size regardless of 32/64 CPU mode.

It's the compiler that's designed to use the power not the program
all any HLL programmer dose is express an algorithm
the HLL programmer has vary vary little control over how the algorithm is translated in to machine code and then only through command line options
computers run machine code never C,C++,Fortran,Java what ever

NOW IF most programming was done in assembly you would have a very valid point about the need for programs to be designed to tack advantage of the
extra power and I would agree with you BUT there NOT there written in HLLs

the gcc compiler was for the most part ported by ADM before the 64bit CPUs even went to market and the gcc team has been tuning it ever sense then
the data bus (do you even know what that is ) is 64bit's as well
there is also fewer instruction fetches as well

you must have been buying 32bit mother boards
a 64bit CPU can run in 64bit mode on a 32bit mother board but much slower
or you had some problems with your x86_64 installs

I have bench marked this computer on 64bits and it is comparable to computers with CPUs that coast twice as much as this laptop did

sorry but I can't help but question your expertises because you didn't know gcc IS a cross compiler

Well, and that's why mplayer, mencoder and programs that actually perform better in 64 bits do have specific code for sse, mmx and stuff like that. That's also why most programs perform the same on either x86 or x86_64.

For the rest, well, whatever suits you. I am not going to argue here as I said before. I know the hardware I buy, and I have a broad experience with both x86 and amd64, I don't have to convince anyone.

By the way, I know gcc can cross compile, it's not that trivial though. First thing you need is to setup a cross-compiling environment because to start with if you throw a 64 glibc in your system you break ALL you binaries and hose the entire OS.

If your system is 400% faster by changing to amd64, I am happy for you. But as said, it's surely some problem with your x86 installs.

for mplayer the improvement was is from an improvement in real time data through put

but I'm talking about mplayer on the same computer NOT a better computer just a better O/S that allows a higher system bandwidth

yes to cross compile another environment needs to be built for the cross compiler the whole process is explained in the linux from scratch how to

my first slackware install was 3.5
I had one system that was installed as slack 8 and upgraded all the way through to slack 12
I have installed slackware on about 20 deferent computers
DUDE I know how to install slackware

If your not seeing a huge speed boost over 32bit I suggest you check out what chipset your running on

it is enormously complex to upgrade a 32bit CPU to 64bit nobody would have done this unless there was an enormous improvement to be gained from doing so it is a huge improvement in speed
(it was not just a marketing gimick at the time the only O/S that would run on them in 64bit mode was linux )

Can you give some concrete reason why this should be so on the same hardware? The PCI bus (most of your hardware) is still going to be 32 bits wide. The bus-width out to your disk doesn't suddenly become 64 bits wide, nor does the platter spin faster. Sure, the memory path is faster, but that is compensated for, to some extent, by 32-bit programs being smaller on the slower pieces - i.e on the hardware. They don't run the processor at 1/2 speed when its running in 32-bit mode.

The consensus is that you should switch to 64-bits if you need to, otherwise there is no noticeable (as opposed to measurable) speed difference. Examples of "need to" would be when crunching massive amounts of numbers and programs that are larger than 4GB.

Probably a common misconception, but wrong, nonetheless. Things are done because they can be done, and because they're the next step. When we went from 8-bit through 32-bit, there was an obvious need all along the way. 16-bits just isn't large enough to get anything done when you need a GUI or want to work with large data sets. However, our needs increase linearly whereas these increases are exponential. At some point, we will probably have a need that is exponentially larger than what most of us currently have. When that point occurs, everyone will pretty much need to switch to 64-bit. Until then, it's a big yawn for most of us.

I don't know what's that complex about "upgrading" to 64 bits. And cheers for you if you use LFS and Slackware. I am not competing with anyone here (anyone can use LFS, all you need to qualify is to be able to read, just like Gentoo which is what I use). It's not different in any aspect at all in which regards the end user nor the administrator. The complexity level is exactly the same that you get on x86.

And yes, things are done because they can be done.

There's no point in upgrading the sport wear of your football team, but people do so from time to time.