knoppix 32-bit versus 64-bit distros

[michael7]

I've been conducting an unscientific study of how quickly distros boot. I'm sharing this with you because I was really surprised by how well Knoppix 3.8.1 (32-bit) compares to a couple of 64-bit distros. (I have a new computer with an AMD64 processor and 1 gig of RAM.) I've ordered several more 64-bit distros and will load and try them when they arrive. So far, here's the information I have. For each, there are two measures-- how many seconds from the GRUB screen to the Login screen and how many seconds from the Login screen to a full desktop initialization.

Knoppix 3.8.1 (32-bit) 29-6
Kanotix (64-bit) 30-7
Ubuntu (64-bit) 22-8

[jjmac]

(grin) ...

They seem to range out a bit ???

30 to 7 seconds ... dosen't make much sense really .

Aside from that though ... how do you find the general usage of the two 64bits compared to the 32.


jm

    -|-  If the systems the answer, then the question
                   must  have been really stupid              -|-

[michael7]

I think all 3 are exceptionally fine distros. Because I'm accustomed to the KDE desktop, I'm somewhat prejudiced toward Knoppix and Kanotix but Ubuntu is professional grade. All three are quick, smooth and responsive. Hardware detection on each is very good. I had a small problem configuring my Internet connection with Kanotix but it turned out to be an easy fix.

I'm not surprised that Ubuntu 64 was that fast. I am surprised, however, that the 32-bit Knoppix loaded faster than the 64-bit Kanotix on my 64-bit computer. I have another 32-bit distro installed, Mepis 3.3. While I like Mepis, especially for its hardware detection, it is very slow compared to these. Mepis takes about 54 seconds from the GRUB menu to the Login screen and 9 seconds from the Login screen to the a full desktop initialization. That's glacial compared to these. I've ordered the 64-bit versions of Debian, Suse, Mandriva and a couple of others. When the DVDs arrive, I'll install and test them the same way. If anyone is interested, I'll post my results for those, too.

At this moment, I do not see a significant difference in the performance of the 32-bit Knoppix and the two 64-distros I tested, at least on my machine. Frankly, that's somewhat disappointing because I expected the 64-bit distros to run bullet fast. There's another way to look at it, though. Klaus just continues to build a great distro. If you'll excuse the Wild West analogy, he's like an older gunslinger who continues to out shoot the young guns.

[jjmac]

>>
I am surprised, however, that the 32-bit Knoppix loaded faster than the 64-bit Kanotix on my 64-bit computer.
>>

iirc, on amd's site they mention that at system boot the cpu will be in 32 bit mode ... with 64 bit not taking effect untill the OS is fully up and running. And then it depends on the OS.

Also, you would need identicle configurations in each to do a realistic boot comparison.

There is also the consideration on just how the distros were compiled ... concerning the switches that were used in each. That __would__ have an effect overall distro performance. As well as if there is a mix of 64 and 32 bit apps involved. I think most 64's around do tend to mix their apps. And there is variations on the compile levels used.

Personally i'm looking forward to putting a 64 bit install together ... probably using a gentoo 1st stage as an initial base, then compiling everything for 64 bit in a deb style, on top of that. Once i figure out how to compile a 64 bit enabled compiler that is

A fully 64 bit install though, optimised for the cpu being used ... should be faster.


jm

[michael7]

jm,

Good comments. I agree that identical configurations would be appropriate, I'm just not skilled enough to do it. The comment on the AMD site is interesting-- the chip boots in 32-bit mode before running in 64-bit.

michael7

[jjmac]

>>
I'm just not skilled enough to do it.
>>

Not even important really. The fact that people go to the trouble to actually look at things is though ... i use my favourite screensaver out of the xscreensaver collection (spiral) as my main desktop performance benchmarker (grin).

Or if i want to get more serious, i'll do a larg compile ... X or gcc etc. There quite good alround stress testers.

amd have got some good info in pdf formate available ... definitly worth the read/dload

http://www.amd.com/us-en/assets/cont...and_tech_docs/

And other locations.

>>
the chip boots in 32-bit mode before running in 64-bit.
>>

Makes sense ... the mode is a software issue. Iv'e only gone briefly over their pdfs', i'll have to do that again this weekend ... but they have some really interesting discussion on their processor.

I shudder to think of 5 years from now

You mentioned ram above ... don't forget, in terms of cpu performance, aside from just boot time ... ram is going to make a __really__ big difference. Like ... a 2, 2, x, x is going to go wow compared to a 3, 3, x, x or a 2.5, 6, x, x etc. It should cut 30% off the access times. I'm more the later cry.png (grin)


jm

[Cuddles]

Very, very, interesting...

I, too, would have ¨assumed¨ that a 64bit AMD processor, with a 64bit OS, would ¨blow away¨ anything else, in the water, so to speak...

I have the AMD 64 Athlon 3000+ -=- and, many times, I have to have a MHZ speed display running, to watch when it ¨up-shifts¨ and ¨down-shifts¨ ( possibly, another un-fair comparison, between a 32bit and a 64bit processor? )

What I have used for comparison, was glxgears - but that can test against the speeds of your Video Card, possibly, down through, to your processor, and your OS. Having, aproximately, the same hardware as I used to use with the 32bit OS, for my 64bit, I have seen glxgears speeds jump from three figures, well into a high four figures ( say, from 500 FPS, up to around 5000 FPS ) - but, then again, if I watch my MHZ of the processor, it never deems the need to ¨up-shift¨ in speed, so the FPS is going under the ¨down-shift¨ processor speed ( 1.x GHZ and not the 2.x GHZ )

I have played a few ¨video¨ and ¨processor¨ intensive games, and have seen my processor ¨up-shift¨ to allow them to play even faster, blob wars, and even crack-attack, these games, appear to up-shift the processor just as soon as they intitiate, and dont allow the processor to down-shift, until the game is closed down, and exited. Surprising thing is, the up-shift and down-shift thing, doesnt seem to make much notice in the game playing. The games run smooth, video is smooth, and the playing, is also smooth, but, then, again, they did this just as well in a 32bit Operating System.

Examining, and testing, the 64bit AMD processor, as I have tried, has almost become a moot thought, for me, now... I think AMD designed the processor to ¨burn¨ when it needs to, and to ¨go into a reserve¨, or idle, when it doesnt need to. The 64bit processor, in my thinking, is just like the 32bit version, in respect of it runs pretty fast in the ¨idle¨ speed, but, when it needs more ¨ooommmppphhhh¨, it up-shifts for more power.

Another ¨comparison¨ is the overhead needed for the AMD64... When I ran a AMD 32bit processor, I had only a few processes to ¨control¨ the processor, and with the AMD64, a lot more processes have been started, and run, concurrently, for the processor; powernowd, being the one I can think of, off the top of my head.

I realized that a ¨game¨ is not a good tester for ¨speed¨, because any ¨good¨ game creator, would code there game, to accomodate changes in processors speed, delaying there game, as needed, to allow the game to run ¨the same¨ on different speeds, video, and complete hardware differances. Thus, making there game, play, about the same, on any system.

I think that jjmac has the best idea for testing... A large kernel compile, should give good results on ¨total¨ system performance. ( note that, I think this tests the ¨complete¨ system performance, and not just the processor, because the ¨process¨ relies on through-put of hard drive, controller, video, memory, and the processor. ) A good ¨processor¨ test, would allow the ¨processor¨ to do something, without the need of accessing memory, the hard drive, the controller, or even the video. The ¨process¨, for this testing, would probably be something that didnt do any output to video, until the process finished, would run completely in memory, and hopefully run without being ¨swapped out¨, during the testing. The process would load, set a ¨starting time¨, do the hard processing, get the ¨ending time¨, and output the total elapsed time. If the ¨process¨ was a simple script, say a counting program, that runs a counter from one to say, 100000, or higher, the script could be used as a ¨benchmark¨ on multiple systems, targeting the processor, for its brutte speed.

Oh well, I guess I just live with what I have... It runs, it runs pretty fast, when I need it, and doesnt ¨burst into flames¨ when I play an intensive game. I used to ¨break¨ Windows Operating Systems, by starting concurrent, intensive programs, until the OS bogged down to the speed of a snail, and then Windows would just crash, but, with Kanotix and Knoppix, I have never had this same problem, though I have tried, pretty hard, to do this.

Just my thoughts,
Ms. Cuddles

[UnderScore]

linuxhardware.org and anandtech.com have been benchmarking 32 vs 64 and AMD 64 vs Intel 64 specifically on Linux for a couple of months now. See http://www.linuxhardware.org/search....ction=features http://anandtech.com/it/ and http://anandtech.com/cpuchipsets/

If I summarize the tests then I will probably make a mistake. I will say that the tests have shown that the AMD 64 platform (Athlon 64 & Opteron) is better than the existing 32 bit platform (both AMD Athlon & Intel Pentium 4) and in most it is better than Intel's 64 platform (Intel P4 64 bit extended & Intel Xeon 64 bit extended).

[jjmac]

Even if you have a 64bit OS running with a 64bit processor ... the OS can only perform to it's optimisation level. So to for the sw concerned. As all the distro will tend to optimise their sw packes in such a way as to allow it to be run over a range of systems ... I would imagine that 64bit OS/sw collections would do the same. In that they wouldn't know whether the person has an Intell or an AMD processor. A choice of optimised kernels at install time could be usefull there. But it would be asking a lot for the same to be provided for the sw. You would need multi-DVD packs then (grin)


Recompiling different key sw packages with specific support for your platform will produce very noticable results. Very true for anthing on a graphical level including X.

So ... all things being eqaul, long compiles will tend to test the processor it self rather than bring in other elements of the system. Such as X or the type of video card being used.

The only thing that couldn't be removed from the picture would be the RAM that is installed. The type and how much is available. That will give different results to the same test.

And as stated above ... the AMD64 comparision tests against Intell, and AMD32 bit speak for themselves.

The only time the Intell processor seemed to better or equal was on cd/dvd burning ? (grin)

I especially like the cpufrequency scaling feature thats available too. I don't like just reving things out if there isn't a real need. So it all runs quieter, and cooler ... and cheaper


I only wish AMD weren't such a MS crony (grin), all the sites, ASUS ... good grief. One would think that MS XP, 2000,and NT were the only systems in the world


jm