There are still serious problems with aliasing as the sampled frequency approaches the nyquist limit.
That's why professional gear now uses sampling rates from 96 kHz to 192 kHz. That way the extra information can be used to anti-alias the signal for mastering at 44.1 kHz.
I have built an entire GNU/Linux install from scratch (without patches, without following the LFS document also).
It is true that the Alpha uses 32-bit int, but pointers are 64-bit.
Well there may be assumptions about the size of various varibles, but not dangerous ones. So what if you is assuming that you can only fit 2^32-1 in an int, but you can really fit 2^64-1. The only case where this would matter is if you wanting the number to roll over when run too high.
Also the 64-bit pointers. The Alpha does use those, and I'd think that would be a bigger compatibilty issue. But as I said, I don't have any trouble with it. Because assumptions there don't cause any trouble either. Incrementing and decrementing points do the same, you just can access more memory on a 64-bit machine. Unless you are trying to do math with the pointers, which is a bad idea (and generates warnings in GCC).
I don't think either of the "assumptions" I've talked about really are assumptions anyway, just indifference. Really it is hard to write code that doesn't port from a 32-bit to a 64-bit machine. 32-bit to 16-bit is another issue. Going bigger almost never hurts.
But I wonder how much programming you do. sizeof doesn't return the number of bits, it returns the number of bytes. Also it is sizeof(char*), not *char.
Stop spreading FUD.
P.S. My Opteron will be here next week, ordered it yesterday. Dual 1.6GHz with 8GB of RAM. So I'll be making use of those 64-bit pointers. I'll be building a custom install from scratch, and don't expect any issures, just as I had none from my Alpha.
Why do people continue to spread this myth? Have you ever compiled code on a 64-bit arch.? Have you ever even touched a 64-bit machine? I have an Alpha, which is an even stranger platform than x86-64, and *EVERYTHING* I've ever built has worked flawlessly. I'll have a Opteron machine here soon, and I don't expect anything less from it.
Using a heavy vac or compressed air on a fan can cause it to spin so fast that it burns the bushings out of it.
I've seen that done too. "Hey, listen to this fan spin." WERrrrrr... (Later) "This case fan isn't spinning up anymore, it seems really stiff, but I just cleaned it."
As someone else pointed out, animation is the source for a lot of today's sci-fi entertainment. This makes a perfect pairing. You can do 18 half hour episodes to tell the full story.
Then I'll wait for it to be released on DVD, and I'll get to practice my Japanese.
Japan uses 4/1 also, but they prefix the year. That is the best way, with 0 padding on the month and day so sorting is easy. 04/01/2003 is just messed up, 01/04/2003 is a bit better, at least it is consistant in ordering. But 2003/04/01 is the best for any big endian number system.
There are 66 MHz 64-bit PCI video cards, but the cost for them is so high, as there is no demand for them. I'm hoping that changes with PCI-X, I'm aready seeing more boards with that interface than 64-bit PCI.
But yes, my Alpha which is quite old has 64-bit PCI. And I have two Pentium 2 boards with ServerWorks chipsets that have 64-bit PCI. But that is what I'm saying, for as long as the spec has been around I don't see that many boards, just about every server class board ready to be released has PCI-X now.
That is one place the OS can help too. I know a lot of work has gone into Linux's SMP to try balance favoring one CPU to keep in its cache and the processes running on it in sync, vs. keeping all the processors active.
But yes, part of the Hyper Transport is to allow better cache sharing between chips.
Well I was messing with Bochs emulating (90% of) the x86-64. I was cross compiling and then copying the executables to the drive image. But a 2.6 MHz Opteron just isn't too much fun.
So anyway, I have a 2.4.20 Linux kernel, glibc, gcc, binutils, make, bison, flex, ncurses, perl, texinfo, man, bash, fileutils, textutils, findutils, inetutils, grep, groff, grub, file, less, vim, util-linux, e2fsprogs, procps, sysvinti, sysklogd, shadow suite, sh-utils, sed tar, gzip, bzip2, openssl, openssh, and who a few other things ready to go for when the chips ship.
Not everything runs and I had to watch my level of optimization (had to use the x87 math instead of the mmx/3dnow/sse stuff that gcc wants to use by default). I will actually be compiling on the machine for the machine when I get one.
Re:32 compatibility mode vs. true 64 bit apps...
on
AMD Opteron Due In April
·
· Score: 3, Interesting
I compiled everything from source for my Alpha, not one problem with 64-bit cleanliness. That was a problem in the early 90s. There are enough 64-bit chips around now, that every serious application has been compiled on one at some time.
GCC is already ready for the Hammer chips. If compiling for x86-64 you get code generated that can make use of mmx, mmxext, 3dnow, 3dnowext, sse, and sse2. It actually prefers those instructions over the old x87 functions by default.
I've heard that the Hammer is 2.5 times faster per clock than the lastest Athlons in 32-bit mode, and faster still in 64.
I WILL be building a machine around 2 of these chips as soon as the first Tyan board ships with PCI-X slots.
Slashdot Mirror
There are still serious problems with aliasing as the sampled frequency approaches the nyquist limit.
That's why professional gear now uses sampling rates from 96 kHz to 192 kHz. That way the extra information can be used to anti-alias the signal for mastering at 44.1 kHz.
It's not Slashdotted, they are just serving the images from Mars.
I think I will too. :P
That beats Rimmer's, one up, one down, and one to polish.
I have built an entire GNU/Linux install from scratch (without patches, without following the LFS document also).
It is true that the Alpha uses 32-bit int, but pointers are 64-bit.
Well there may be assumptions about the size of various varibles, but not dangerous ones. So what if you is assuming that you can only fit 2^32-1 in an int, but you can really fit 2^64-1. The only case where this would matter is if you wanting the number to roll over when run too high.
Also the 64-bit pointers. The Alpha does use those, and I'd think that would be a bigger compatibilty issue. But as I said, I don't have any trouble with it. Because assumptions there don't cause any trouble either. Incrementing and decrementing points do the same, you just can access more memory on a 64-bit machine. Unless you are trying to do math with the pointers, which is a bad idea (and generates warnings in GCC).
I don't think either of the "assumptions" I've talked about really are assumptions anyway, just indifference. Really it is hard to write code that doesn't port from a 32-bit to a 64-bit machine. 32-bit to 16-bit is another issue. Going bigger almost never hurts.
But I wonder how much programming you do. sizeof doesn't return the number of bits, it returns the number of bytes. Also it is sizeof(char*), not *char.
Stop spreading FUD.
P.S. My Opteron will be here next week, ordered it yesterday. Dual 1.6GHz with 8GB of RAM. So I'll be making use of those 64-bit pointers. I'll be building a custom install from scratch, and don't expect any issures, just as I had none from my Alpha.
Why do people continue to spread this myth? Have you ever compiled code on a 64-bit arch.? Have you ever even touched a 64-bit machine? I have an Alpha, which is an even stranger platform than x86-64, and *EVERYTHING* I've ever built has worked flawlessly. I'll have a Opteron machine here soon, and I don't expect anything less from it.
Isn't she dead? Oh...
...two of the designers wgo started...
The correct spelling is who, it is like the sound an owl makes.
I thought you were going to mention that they will probably be sued by the Nazis now.
I don't know, but I suspect after this /.ing CmdrTaco will has earned his place high in the arches also.
Using a heavy vac or compressed air on a fan can cause it to spin so fast that it burns the bushings out of it.
I've seen that done too. "Hey, listen to this fan spin." WERrrrrr... (Later) "This case fan isn't spinning up anymore, it seems really stiff, but I just cleaned it."
As someone else pointed out, animation is the source for a lot of today's sci-fi entertainment. This makes a perfect pairing. You can do 18 half hour episodes to tell the full story.
Then I'll wait for it to be released on DVD, and I'll get to practice my Japanese.
Insanity was never a medical term, it has always been legal.
w00t? Don't you mean F00F?
Just not nuclear power plants.
Dune's been done to death. I was hoping he'd get William Gibson's Sprawl (Neuromancer, Count Zero, Mona Lisa Overdrive) trilogy.
Maybe he is aware of everything, and you just fell for his joke? Or perhaps, you are aware that he is aware of the day, and I just fell for you joke?
Japan uses 4/1 also, but they prefix the year. That is the best way, with 0 padding on the month and day so sorting is easy. 04/01/2003 is just messed up, 01/04/2003 is a bit better, at least it is consistant in ordering. But 2003/04/01 is the best for any big endian number system.
Dispite being a "Red" hat, I believe Debian would be the communists, while Red Hat would be the capitalists.
RMS pronounces the '/'.
There are 66 MHz 64-bit PCI video cards, but the cost for them is so high, as there is no demand for them. I'm hoping that changes with PCI-X, I'm aready seeing more boards with that interface than 64-bit PCI.
But yes, my Alpha which is quite old has 64-bit PCI. And I have two Pentium 2 boards with ServerWorks chipsets that have 64-bit PCI. But that is what I'm saying, for as long as the spec has been around I don't see that many boards, just about every server class board ready to be released has PCI-X now.
That is one place the OS can help too. I know a lot of work has gone into Linux's SMP to try balance favoring one CPU to keep in its cache and the processes running on it in sync, vs. keeping all the processors active.
But yes, part of the Hyper Transport is to allow better cache sharing between chips.
Well I was messing with Bochs emulating (90% of) the x86-64. I was cross compiling and then copying the executables to the drive image. But a 2.6 MHz Opteron just isn't too much fun.
So anyway, I have a 2.4.20 Linux kernel, glibc, gcc, binutils, make, bison, flex, ncurses, perl, texinfo, man, bash, fileutils, textutils, findutils, inetutils, grep, groff, grub, file, less, vim, util-linux, e2fsprogs, procps, sysvinti, sysklogd, shadow suite, sh-utils, sed tar, gzip, bzip2, openssl, openssh, and who a few other things ready to go for when the chips ship.
Not everything runs and I had to watch my level of optimization (had to use the x87 math instead of the mmx/3dnow/sse stuff that gcc wants to use by default). I will actually be compiling on the machine for the machine when I get one.
I compiled everything from source for my Alpha, not one problem with 64-bit cleanliness. That was a problem in the early 90s. There are enough 64-bit chips around now, that every serious application has been compiled on one at some time.
GCC is already ready for the Hammer chips. If compiling for x86-64 you get code generated that can make use of mmx, mmxext, 3dnow, 3dnowext, sse, and sse2. It actually prefers those instructions over the old x87 functions by default.
I've heard that the Hammer is 2.5 times faster per clock than the lastest Athlons in 32-bit mode, and faster still in 64.
I WILL be building a machine around 2 of these chips as soon as the first Tyan board ships with PCI-X slots.
Some of those boards have to have PCI-X slots. They can be faster than AGP. Just have to find a PCI-X video card.
(If anyone knows of a maker, point me to them, I think PCI-X is the future, AGP was just a gap bridging hack, who's time has passed.)