The move from 32 to 64 bits isn't so much about performance as it is about...size, I guess. The ability to hold huge databases and datasets in a flatly addressable space. The ability to do maths with larger and/or more accurate numbers. That kind of thing.
As I recall, a 286 was slightly faster than a 386 at the same clockspeed. The 486 was the first x86 that was actually designed to go fast. The big deal about the 386 was that it did memory management properly, and had the multitasking abilities, and to do that it needed a large addressable flat memory space (hence 32-bit pointers). The 32-bit registers were that size mainly so they could hold pointers and offsets and things. (Yes, I'm simplifying, I know.)
64-bit CPUs will be faster at a few things, like copying memory and crunching RC5, but most performance benefits in future CPUs will have nothing to do with word-size (clock speeds, cache sizes, clever pipelines, etc.).
I've read Dune Messiah (and the rest of the series, except the prequels). I'd completely forgotten about the son Paul had in the first book, so I'd figured that the son in the mini-series was the son from Messiah, and the result of yet another book-to-TV butchering. (And can you blame me?)
Maybe this means I should go back and read the Dune books again. And I was about to start on the Discworld series...
>...and recount the fall of Paul's empire, with the
> future resting in the hands of Paul's heirs, his
> twin children.
Strange that no-one seems to have mentioned this yet, but Leto II got killed at the end of the mini-series, and he didn't have a sister. (Of course, in the books they didn't have children at all until Messiah.) Let's see how the producers wriggle out of this one...
If you do try 2.4 on your 386, let me know how it goes and how well it runs (use the horribly unobfuscated email address above) - I'd be interested to know for myself...
I've got a 160Mhz 486 (overclocked AMD 5x86) with 32M, and I'm setting 2.4 up on it right now. So far, it's running great - it's doing a lot of compiling, and running no worse than with 2.2, and yes, I've noticed that it seems to be using less memory and the fs performance is a little better - but that might be my imagination. (BTW, try hdparm -T/dev/ with 2.2 & 2.4 - 2.4's buffer cache is twice as fast!) What I'm saying is, 2.4 should run great on your 486-100, and firewalling should not be a problem unless you're trying to firewall a saturated gigabit ethernet or something.
We've also got here a Cyrix 486DRx2. This is one of those 386-to-486 upgrade chips - it's pipelined, clock-doubled (to 50MHz in this case), and has a 1KB cache on it. This machine is our firewall (ADSL/Ethernet), and it's running 2.2, and not sweating it at all. (16M memory, BTW, and we haven't bothered to enable the cache either) I'm planning on moving it to 2.4 once I've had a play with it for a while. So I also say, give 2.4 a try on your 386 if it has the memory (you might get away with 8M) - you might be pleasantly surprised...
The GLX project supports the G200, G400, and the nVidia chips. The driver isn't exactly ready for the naive end user, but it runs the Quake games and the OpenGL hacks in the XScreensaver package, so it's quite functional. It's a bit slow, but it's getting faster all the time, and Matrox have recently made some WARP code available, which will allow use of the geometry engine.
Now, are 3dfx going to do this properly? Are they going to give XFree86/PI/etc their full cooperation, release the specs, maybe write some of the code themselves, and generally do the right thing? Or are we going to see essentially another Glide, where they make their own binary-only, x86-only releases, don't give the code back to XFree86, maybe try to tie it into Glide somehow, and generally try to keep the monopoly they think they have on 3D in Linux? We shall see... (BTW, it's my understanding that 3dfx's Windoze OpenGL drivers are not totally compliant, since they can only do full-screen rendering.)
/Begin soapbox I cannot understand why people still think Voodoo is the best thing since sliced bread or whatever, and go out and buy Voodoo cards by the bucketload. They can't render into a window, can't do 32-bit rendering, don't have a full 32-bit z-buffer, can't render into a window, can't do AGP texturing, and still have that ridiculous 256x256 texture limitation. The only good thing about them is that they're still pretty quick. If you want a 3D card for Linux (or anything else actually), buy a TNT, or better yet, a G400. /End soapbox
P.S. Keeping my fingers crossed for the Glaze3D...
Sorry Bill, but I just spent nearly three days straight recovering two filesystems on my dad's NT machine. Why were they (almost) lost? Because we did 'fdisk/mbr' from MS-DOS (to remove LILO, ironically enough) and NT couldn't cope because it's stupid signature got removed (my theory). After that, you can forgive me if I find it hard to believe that Microsoft tests anything at all thoroughly.
You think I'm going to run something that fragile on my own machine? You think I'm even going to say anything positive about it to anyone else? What do you think my dad (who's a Unix guy anyway) thinks of NT now? You take your company back to the drawing board, and come back with something that works as advertised, then maybe we won't all laugh at you when you claim that the alternatives aren't good for anything.
If the MMU is missing, how do you stop buggy programs interfering with each other or the kernel? How do you stop them accessing hardware they're not supposed to? I just don't see how a modern OS like Linux is going to work without memory management hardware. Someone care to explain?
Slashdot Mirror
The move from 32 to 64 bits isn't so much about performance as it is about ...size, I guess. The ability to hold huge databases and datasets in a flatly addressable space. The ability to do maths with larger and/or more accurate numbers. That kind of thing.
As I recall, a 286 was slightly faster than a 386 at the same clockspeed. The 486 was the first x86 that was actually designed to go fast. The big deal about the 386 was that it did memory management properly, and had the multitasking abilities, and to do that it needed a large addressable flat memory space (hence 32-bit pointers). The 32-bit registers were that size mainly so they could hold pointers and offsets and things. (Yes, I'm simplifying, I know.)
64-bit CPUs will be faster at a few things, like copying memory and crunching RC5, but most performance benefits in future CPUs will have nothing to do with word-size (clock speeds, cache sizes, clever pipelines, etc.).
I've read Dune Messiah (and the rest of the series, except the prequels). I'd completely forgotten about the son Paul had in the first book, so I'd figured that the son in the mini-series was the son from Messiah, and the result of yet another book-to-TV butchering. (And can you blame me?)
Maybe this means I should go back and read the Dune books again. And I was about to start on the Discworld series...
> ...and recount the fall of Paul's empire, with the
> future resting in the hands of Paul's heirs, his
> twin children.
Strange that no-one seems to have mentioned this yet, but Leto II got killed at the end of the mini-series, and he didn't have a sister. (Of course, in the books they didn't have children at all until Messiah.) Let's see how the producers wriggle out of this one...
If you do try 2.4 on your 386, let me know how it goes and how well it runs (use the horribly unobfuscated email address above) - I'd be interested to know for myself...
If you ask me, it should run fine.
/dev/ with 2.2 & 2.4 - 2.4's buffer cache is twice as fast!) What I'm saying is, 2.4 should run great on your 486-100, and firewalling should not be a problem unless you're trying to firewall a saturated gigabit ethernet or something.
I've got a 160Mhz 486 (overclocked AMD 5x86) with 32M, and I'm setting 2.4 up on it right now. So far, it's running great - it's doing a lot of compiling, and running no worse than with 2.2, and yes, I've noticed that it seems to be using less memory and the fs performance is a little better - but that might be my imagination. (BTW, try hdparm -T
We've also got here a Cyrix 486DRx2. This is one of those 386-to-486 upgrade chips - it's pipelined, clock-doubled (to 50MHz in this case), and has a 1KB cache on it. This machine is our firewall (ADSL/Ethernet), and it's running 2.2, and not sweating it at all. (16M memory, BTW, and we haven't bothered to enable the cache either) I'm planning on moving it to 2.4 once I've had a play with it for a while. So I also say, give 2.4 a try on your 386 if it has the memory (you might get away with 8M) - you might be pleasantly surprised...
The GLX project supports the G200, G400, and the nVidia chips. The driver isn't exactly ready for the naive end user, but it runs the Quake games and the OpenGL hacks in the XScreensaver package, so it's quite functional. It's a bit slow, but it's getting faster all the time, and Matrox have recently made some WARP code available, which will allow use of the geometry engine.
Now, are 3dfx going to do this properly? Are they going to give XFree86/PI/etc their full cooperation, release the specs, maybe write some of the code themselves, and generally do the right thing? Or are we going to see essentially another Glide, where they make their own binary-only, x86-only releases, don't give the code back to XFree86, maybe try to tie it into Glide somehow, and generally try to keep the monopoly they think they have on 3D in Linux? We shall see... (BTW, it's my understanding that 3dfx's Windoze OpenGL drivers are not totally compliant, since they can only do full-screen rendering.)
/Begin soapbox
I cannot understand why people still think Voodoo is the best thing since sliced bread or whatever, and go out and buy Voodoo cards by the bucketload. They can't render into a window, can't do 32-bit rendering, don't have a full 32-bit z-buffer, can't render into a window, can't do AGP texturing, and still have that ridiculous 256x256 texture limitation. The only good thing about them is that they're still pretty quick. If you want a 3D card for Linux (or anything else actually), buy a TNT, or better yet, a G400.
/End soapbox
P.S. Keeping my fingers crossed for the Glaze3D...
Sorry Bill, but I just spent nearly three days straight recovering two filesystems on my dad's NT machine. Why were they (almost) lost? Because we did 'fdisk /mbr' from MS-DOS (to remove LILO, ironically enough) and NT couldn't cope because it's stupid signature got removed (my theory). After that, you can forgive me if I find it hard to believe that Microsoft tests anything at all thoroughly.
You think I'm going to run something that fragile on my own machine? You think I'm even going to say anything positive about it to anyone else? What do you think my dad (who's a Unix guy anyway) thinks of NT now? You take your company back to the drawing board, and come back with something that works as advertised, then maybe we won't all laugh at you when you claim that the alternatives aren't good for anything.
If the MMU is missing, how do you stop buggy programs interfering with each other or the kernel? How do you stop them accessing hardware they're not supposed to? I just don't see how a modern OS like Linux is going to work without memory management hardware. Someone care to explain?