I've some friends who built a similar machine, but with more primitive construction materials. They did it for a second year design course at the University of Toronto. Details available here.
According to the article, the hardware vendors are looking to Linux to force Microsoft to adopt new features. That's a strong testament to the power of competition! I know that Intel has hated their dependence upon Microsoft for a long time, and that Microsoft is delerious about AMD, since it untied them from Intel.
AMD really needs Linux on the hammer platform. Actually, they need Windows as well, but Linux is the club to force Microsoft to make the port. Intel is less dependent on Microsoft for the success of IA64 platforms, but mainstream adoption of new technologies like SMT (or hyperthreading, as they say) could really distinguish them from AMD performance-wise.
I'm usually pro-Microsoft around here, given the amount of nonsense Linux-propoganda spewed out, but I will be really happy when Linux can compete across the board, instead of just on servers. The benefits of competition are very high.
Well, it's a nice idea, but here's my advice: just find the best coders you can. Most programmers don't mind working on proprietary software. Sure, some think that anything proprietary is evil, but most are not nearly so extreme. They code for fun, or to see people use their stuff. If you just try to get the best, you'll be doing yourself a favour. Consider it an extra qualification if they write free software. Will they apply? For sure. Microsoft has a similar program; they just provide day jobs for people who like hacking.
I kind of agree with your premise, but I think the rest of it is way off. If the Japanese are unafraid of the future, it's because they've been hit over the head by technology enough times that they've become used to it. America on the other hand has usually grown into and with technology pretty peacefully, but that may change as the pace of technological change increases. I think we should take note of that; socially our culture is much more advanced than the Japanese. If you want an example of the risks, look at the North American Indians as an example of people who were kicked in the head by technology and never recovered. For us, and for the Japanese, there is still hope. Don't resist change too much, but go forward carefully, and don't beg change before its time comes. Also, don't believe in our own inferiority or superiority; it is only the whims of fortune that put us in a good position and others in a bad one; it could just as easily have been the other way around.
I'm using an NVIDIA TNT2M64 (wow, lots of upper case), and my experiences have been mixed at best. I'm running 2.4-pre series with XFree86 4.0.1 on an ASUS CuSL2 (i815 based) motherboard.
I can't get the NVIDIA supplied accelerated modules working. All attempts to do so have led to system instability, when it was able to load at all. The nv.o driver that comes with XFree86 works much better, although I'd be lying if I said perfectly.
My advice is to avoid NVIDIA if you want 3D support and are using an i810 or i815 chipset. I hear that the difficulty is conflict with AGP because of the integrated video controllers. I don't know about other platforms.
While having Linux running on Itanium is great, it isn't really surprising. Linux already runs on other 64-bit architectures, so the porting was probably easier than for Windows, which IIRC ditched Alpha some time ago, and has not supported anything other than x86 for some time.
It's not really even significant. I doubt there are going to be a tremendous number of Itanium sales next year, anyway. It's nice that early adopters use Linux, but not Windows, but not very significant.
The more interesting question is about gcc. How is support for Itanium coming with gcc? The EPIC architecture probably requires a lot from the compiler to take good use of it. I assume that gcc *does* support Itanium, since Linux is running on it, and porting Linux to another compiler would probably be more effort than porting it to another platform that gcc targets.
If Microsoft has a significantly better compiler, Windows will probably be a much better system for Itanium. I've heard of Intel's involvement with gcc, so I doubt that MS will do much better, but still, support is just a baby step in the battle for the best system.
Well, I know nothing about the PS2, and just a little about architectures, but I know a bit about software, including compilers, so let me take a stab at it.
Theoretically, 128 bits is exactly the same speed as 32 bits when performing 32 bit operations. 128 bits might be somewhat slower, depending upon where you go on your silicon/ speed tradeoff, because it takes so many more transistors to make a fast adder or multiplier at that many bits (more than linear growth).
I doubt the PS2 is a 128 bit machine, though. It's probably a 32 bit processor, with 128 bit vector operations. Those would take 4 32 bit values and perform the same operation on each of them in the same time a non-vectorized processor would perform just 1 operation. Four times faster, IF your code can take advantage of those constraints.
For graphics, the speedup is probably pretty good; I think transforms are done uniformly on lots of values. I could be blowing steam, though. I'm not a graphics person, either.
Weapons control is probably based on processing of discrete data samples, so I doubt that vectorization would help at all.
So if Saddam is collecting PS2's for weapons systems, he's probably just as dumb as the author who called the PS2 a 32 bit machine then quoted a supporting source calling it a 128 bit machine.
I didn't get to read the page, because it was MIA, but my thought is that for such a specialized application that does not change over time, the old hardware is good.
Replacing the hardware with something better would be cheap and easy. The difficulty would come in porting the software. As long as the software you need runs acceptably well on the hardware you've got, the (rational) motivation to upgrade is low.
That said, fast new hardware is a wonderful thing. For developing, high level languages and reduced compile times make a big difference. For many scientific applications, it just isn't practical to run on slower hardware.
I guess the lesson is, for every task, the best tool is the one that does the job.
I really don't know what the costs of encryption are. I'm basing my claim on personal experience, on a system that is far below what anyone would even consider using for a web server. My poor gateway box (a slow 486) can easily handle routing the full bandwidth of my cable modem, but try to transfer a file to or from it via scp, and it chokes at about thirty kilobytes per second, which is only a tenth the peak bandwidth otherwise. I'm sure you can reduce the overhead a lot by changing the encryption algorithm, but there it was tremendous.
I thought that was a really silly article. He proposes thins that are not practical. If it were not so verbose, it would actually be funny.
Has anyone considered the cost of encrypting the majority of Internet traffic? I always encrypt terminal sessions, but the cost of servers encrypting web traffic would be very high. I wouldn't mind; my PC has enough power to encrypt all MY traffic, but how about a busy web server? How much new hardware would slashdot need to support encrypting everything? If slashdot is going to blow that stupid smoke, then slashdot should encrypt all its traffic.
Second, is his explicit assumption that Linux is the best thing available, and that free software is always better than proprietary software in quality. Linux does have a lot of good points, and in some cases is the best solution. MS Windows has strengths also. Sometimes Microsoft solutions solve a problem better. Sometimes one of the other systems he ignores is better.
Another thing he guessed wrongly about is the interest of people who grow up with computers in hacking. Maybe I'll be proved wrong, but I haven't been yet. People who grow up with computers don't gain any magical insight or understanding of them. Nor do they desire such. They use them as familiar tools, just like adults at work. The difference is how familiar and what they do. Some people will become hackers; probably more. Definitely not everybody.
So, I think the article is nonsense, but if Michael thinks this is the most significant article of the year, then he should put slashdot on the same track by encrypting all its traffic.
Your points are pretty good, but there are two things that take away from your arguement that you do not mention.
First, the lack of registers in the x86 architecture. Having a fast cache is great, but it's not as fast as a register, and it takes extra instructions to load and store, unless you go to the more complicated addressing modes, with the problems that you note.
Second is the relatively finer granularity of the instructions available on a RISC architecture. Although there is some merit to making decisions based on information only available at runtime, that isn't a big factor with today's technology. What a modern x86 looks like is a microcode architecture with somewhat intelligent scheduling of the instructions. In most cases a compiler could do a better job.
Where microcode might really be nice is in mitigating the effects of optimizing for one single processor. You could have write-once, run-optimally-on-any-x86 code, but as we see from the real world, that's working about as well as write-once, run-anywhere is with Java.
I completely agree with you on the importance of higher level parallelism. In most cases, the instruction level parallelism in code is low. SIMD in particular seems a waste to me, since one of the few things less likely than code that doesn't have dependencies is identical code operating on different values that doesn't have dependencies. It has its places, but not that many of them. With all the indirections in neat object code, you get a lot of cache incoherency, so you don't even take as bad a hit as you might think from running threads in parallel on account of that.
Of course, there are alternatives. Running multiple branches so that a wrong prediction won't stall is a decent, although less efficient, use of extra execution units also.
The situation isn't quite the same as with DeCSS and the MPAA. The existance of Ogg Vorbis isn't being threatened. What is being threatend is the development and acceptance of it.
Ogg has much bigger goals than DeCSS. Ogg wants to be an open standard that would allow a free implementation. To be the standard, that has to include hardware implementations and closed source implementations by scared, law abiding corporations.
Development would also slow down. Legitimate corporations don't want to support an illegal product that they can't use. Open and funded, development goes much faster than it does when it has to be done underground.
G3's, the article says
on
IBMs CMOS 9S
·
· Score: 1
It might be significantly harder to scale the G4 with that vector engine. RISC CPU's are much easier. I'm not saying it couldn't be done, but I believe IBM is more likely to apply it to their own G3 successor.
Re:(OT) How about Intel's BIOS efforts?
on
IBMs CMOS 9S
·
· Score: 1
That would be very useful, especially for notebooks. I don't reboot my desktop PC much, so I don't care much on its behalf, but for a mobile device it would be wonderful. For them, instant on is essential. I would rarely, if at all, use my Palm if it took eight seconds to boot.
His view of microkernels is pretty standard, but I wonder one thing. As he says, many code errors are due to poor understanding of API's. A microkernel should proved a smaller and more uniform set of API's that are easier to locate and work with. Wouldn't this make correctness easier to obtain? Or is this a goal that is lost in the real world?
Re:It's a great Pagan holiday fscked up by Christi
on
Gifts For Geeks
·
· Score: 2
We celebrated this Holy Day tens of thousands of years before the Christians came along.
I hope you don't mean literally. I don't know anyone who was even alive tens of thousands of years ago. Personally I'm a Christian, so if you somehow placed me way back when, I wouldn't celebrate the Pagan holiday.
Not that I'd celebrate Christmas, either... I'd probably forget the date and die before it happened, anyway.
Really? I think that most of the kernel in Win2K is pageable, and that it is only about 2 megs that is locked. I have a malfunctioning machine that forgets how much memory it has once in a while, and I've run Win2K on it when it thought it had just 16 megs. I was actually surprised at how well it ran; it wasn't until I opened Photoshop and loaded an image that I realized it had lost most of its memory.
That may be so, particularly on televisions, but I detest trinitron monitors. I can't stand the lines on the side of text. Trinitrons have their uses for many people, but for coding, they can't beat a shadow mask CRT in a well-lit environment.
I remember a few years ago, a Macintosh zealot proclaiming to me the superiority of the Macintosh because "they use DIMM's instead of SIMM's!" Having played just a tiny bit with OS X, I think it really is something superior.
However, please remember that it's Mac OS X, not X. I think X has gone as far toward taking BSD to the consumer market as it ever will. Instead of the ability to run multiple xterms, I think it is the Aqua interface and the BSD stability that will make Mac OS X a success.
This is significantly different from current satellite radio in that you have to be able to receive the signal from a moving vehicle. Tracking and aiming is MUCH more difficult, because a car drives around, loses line of sight and all sorts of other gotchas. That's why it should be here shortly, and isn't already.
I just hope that it isn't a huge step backwards in terms of sound quality, like digital radio is. Despite interference, FM stereo is pretty good next to something that has all the sound quality advantages of a low bitrate mp3. It might work in a car, though. The ambient noise could be enough that you don't notice your music sounds like crap.
A lot of people are in the situation of having any ideas they come up with owned by their employer. I haven't heard of this ever being acted on (the AOL-Gnutella example doesn't fit at all; that was more a get-it-off-our-servers! reaction), but it would discourage a lot of contributions to open projects if it turned out that they were owned by someone else and could be revoked.
This is good because it specifically acknowledges that the employer owns everything they pay you to do, but you can work on projects outside of work, and not be concerned that your employer can assert ownership over them.
"post-modern redundancy"?
on
Nvidia's NV20
·
· Score: 1
Who are you, Jon Katz II: The Conservative? You should write an op-ed piece for Slashdot; you troll almost as well as he does.
You can't just repost a story. Reposts have to fall into some categories.
Repost the story one or two {day(s), week(s), month(s)} later.
Repost the story, with a different keyword (such as replace nanoSUBMARINES with nanoHELICOPTERS).
Repost the story, with a different link attached to it (say, one NYTimes link and one MSNBC copy of the NYTimes article).
Don't repost the story, but have Jon Katz write a treatise on how it impacts the future of all geeks in a post-Columbine corporate society.
Post a link to a different article with exactly the same viewpoint and information.
Post a link to a different article with slight differences in the viewpoint and information.
Post a link to a retraction of the article. This one is preferred, because it demonstrates recursion in a format understandable even by residents of Florida.
That's really what we're waiting for, right? I mean, right now a 450 mHz Macintosh probably beats the x86 processors across the board on mpeg4 compression. Based on Intel's stated goal of making the P4 a powerful chip for media processing in particular, I don't think this will be a long wait.
Slashdot Mirror
I've some friends who built a similar machine, but with more primitive construction materials. They did it for a second year design course at the University of Toronto. Details available here.
According to the article, the hardware vendors are looking to Linux to force Microsoft to adopt new features. That's a strong testament to the power of competition! I know that Intel has hated their dependence upon Microsoft for a long time, and that Microsoft is delerious about AMD, since it untied them from Intel.
AMD really needs Linux on the hammer platform. Actually, they need Windows as well, but Linux is the club to force Microsoft to make the port. Intel is less dependent on Microsoft for the success of IA64 platforms, but mainstream adoption of new technologies like SMT (or hyperthreading, as they say) could really distinguish them from AMD performance-wise.
I'm usually pro-Microsoft around here, given the amount of nonsense Linux-propoganda spewed out, but I will be really happy when Linux can compete across the board, instead of just on servers. The benefits of competition are very high.
Well, it's a nice idea, but here's my advice: just find the best coders you can. Most programmers don't mind working on proprietary software. Sure, some think that anything proprietary is evil, but most are not nearly so extreme. They code for fun, or to see people use their stuff. If you just try to get the best, you'll be doing yourself a favour. Consider it an extra qualification if they write free software. Will they apply? For sure. Microsoft has a similar program; they just provide day jobs for people who like hacking.
I kind of agree with your premise, but I think the rest of it is way off. If the Japanese are unafraid of the future, it's because they've been hit over the head by technology enough times that they've become used to it. America on the other hand has usually grown into and with technology pretty peacefully, but that may change as the pace of technological change increases. I think we should take note of that; socially our culture is much more advanced than the Japanese. If you want an example of the risks, look at the North American Indians as an example of people who were kicked in the head by technology and never recovered. For us, and for the Japanese, there is still hope. Don't resist change too much, but go forward carefully, and don't beg change before its time comes. Also, don't believe in our own inferiority or superiority; it is only the whims of fortune that put us in a good position and others in a bad one; it could just as easily have been the other way around.
I can't get the NVIDIA supplied accelerated modules working. All attempts to do so have led to system instability, when it was able to load at all. The nv.o driver that comes with XFree86 works much better, although I'd be lying if I said perfectly.
My advice is to avoid NVIDIA if you want 3D support and are using an i810 or i815 chipset. I hear that the difficulty is conflict with AGP because of the integrated video controllers. I don't know about other platforms.
It's not really even significant. I doubt there are going to be a tremendous number of Itanium sales next year, anyway. It's nice that early adopters use Linux, but not Windows, but not very significant.
The more interesting question is about gcc. How is support for Itanium coming with gcc? The EPIC architecture probably requires a lot from the compiler to take good use of it. I assume that gcc *does* support Itanium, since Linux is running on it, and porting Linux to another compiler would probably be more effort than porting it to another platform that gcc targets.
If Microsoft has a significantly better compiler, Windows will probably be a much better system for Itanium. I've heard of Intel's involvement with gcc, so I doubt that MS will do much better, but still, support is just a baby step in the battle for the best system.
Theoretically, 128 bits is exactly the same speed as 32 bits when performing 32 bit operations. 128 bits might be somewhat slower, depending upon where you go on your silicon/ speed tradeoff, because it takes so many more transistors to make a fast adder or multiplier at that many bits (more than linear growth).
I doubt the PS2 is a 128 bit machine, though. It's probably a 32 bit processor, with 128 bit vector operations. Those would take 4 32 bit values and perform the same operation on each of them in the same time a non-vectorized processor would perform just 1 operation. Four times faster, IF your code can take advantage of those constraints.
For graphics, the speedup is probably pretty good; I think transforms are done uniformly on lots of values. I could be blowing steam, though. I'm not a graphics person, either.
Weapons control is probably based on processing of discrete data samples, so I doubt that vectorization would help at all.
So if Saddam is collecting PS2's for weapons systems, he's probably just as dumb as the author who called the PS2 a 32 bit machine then quoted a supporting source calling it a 128 bit machine.
Replacing the hardware with something better would be cheap and easy. The difficulty would come in porting the software. As long as the software you need runs acceptably well on the hardware you've got, the (rational) motivation to upgrade is low.
That said, fast new hardware is a wonderful thing. For developing, high level languages and reduced compile times make a big difference. For many scientific applications, it just isn't practical to run on slower hardware.
I guess the lesson is, for every task, the best tool is the one that does the job.
I really don't know what the costs of encryption are. I'm basing my claim on personal experience, on a system that is far below what anyone would even consider using for a web server. My poor gateway box (a slow 486) can easily handle routing the full bandwidth of my cable modem, but try to transfer a file to or from it via scp, and it chokes at about thirty kilobytes per second, which is only a tenth the peak bandwidth otherwise. I'm sure you can reduce the overhead a lot by changing the encryption algorithm, but there it was tremendous.
Has anyone considered the cost of encrypting the majority of Internet traffic? I always encrypt terminal sessions, but the cost of servers encrypting web traffic would be very high. I wouldn't mind; my PC has enough power to encrypt all MY traffic, but how about a busy web server? How much new hardware would slashdot need to support encrypting everything? If slashdot is going to blow that stupid smoke, then slashdot should encrypt all its traffic.
Second, is his explicit assumption that Linux is the best thing available, and that free software is always better than proprietary software in quality. Linux does have a lot of good points, and in some cases is the best solution. MS Windows has strengths also. Sometimes Microsoft solutions solve a problem better. Sometimes one of the other systems he ignores is better.
Another thing he guessed wrongly about is the interest of people who grow up with computers in hacking. Maybe I'll be proved wrong, but I haven't been yet. People who grow up with computers don't gain any magical insight or understanding of them. Nor do they desire such. They use them as familiar tools, just like adults at work. The difference is how familiar and what they do. Some people will become hackers; probably more. Definitely not everybody.
So, I think the article is nonsense, but if Michael thinks this is the most significant article of the year, then he should put slashdot on the same track by encrypting all its traffic.
First, the lack of registers in the x86 architecture. Having a fast cache is great, but it's not as fast as a register, and it takes extra instructions to load and store, unless you go to the more complicated addressing modes, with the problems that you note.
Second is the relatively finer granularity of the instructions available on a RISC architecture. Although there is some merit to making decisions based on information only available at runtime, that isn't a big factor with today's technology. What a modern x86 looks like is a microcode architecture with somewhat intelligent scheduling of the instructions. In most cases a compiler could do a better job.
Where microcode might really be nice is in mitigating the effects of optimizing for one single processor. You could have write-once, run-optimally-on-any-x86 code, but as we see from the real world, that's working about as well as write-once, run-anywhere is with Java.
I completely agree with you on the importance of higher level parallelism. In most cases, the instruction level parallelism in code is low. SIMD in particular seems a waste to me, since one of the few things less likely than code that doesn't have dependencies is identical code operating on different values that doesn't have dependencies. It has its places, but not that many of them. With all the indirections in neat object code, you get a lot of cache incoherency, so you don't even take as bad a hit as you might think from running threads in parallel on account of that.
Of course, there are alternatives. Running multiple branches so that a wrong prediction won't stall is a decent, although less efficient, use of extra execution units also.
Ogg has much bigger goals than DeCSS. Ogg wants to be an open standard that would allow a free implementation. To be the standard, that has to include hardware implementations and closed source implementations by scared, law abiding corporations.
Development would also slow down. Legitimate corporations don't want to support an illegal product that they can't use. Open and funded, development goes much faster than it does when it has to be done underground.
It might be significantly harder to scale the G4 with that vector engine. RISC CPU's are much easier. I'm not saying it couldn't be done, but I believe IBM is more likely to apply it to their own G3 successor.
That would be very useful, especially for notebooks. I don't reboot my desktop PC much, so I don't care much on its behalf, but for a mobile device it would be wonderful. For them, instant on is essential. I would rarely, if at all, use my Palm if it took eight seconds to boot.
His view of microkernels is pretty standard, but I wonder one thing. As he says, many code errors are due to poor understanding of API's. A microkernel should proved a smaller and more uniform set of API's that are easier to locate and work with. Wouldn't this make correctness easier to obtain? Or is this a goal that is lost in the real world?
I hope you don't mean literally. I don't know anyone who was even alive tens of thousands of years ago. Personally I'm a Christian, so if you somehow placed me way back when, I wouldn't celebrate the Pagan holiday.
Not that I'd celebrate Christmas, either... I'd probably forget the date and die before it happened, anyway.
Really? I think that most of the kernel in Win2K is pageable, and that it is only about 2 megs that is locked. I have a malfunctioning machine that forgets how much memory it has once in a while, and I've run Win2K on it when it thought it had just 16 megs. I was actually surprised at how well it ran; it wasn't until I opened Photoshop and loaded an image that I realized it had lost most of its memory.
Go figure. I guess Slashdot really is a tight community, and I'm an outsider. What about acid.com or speed.com; are they for sale?
That may be so, particularly on televisions, but I detest trinitron monitors. I can't stand the lines on the side of text. Trinitrons have their uses for many people, but for coding, they can't beat a shadow mask CRT in a well-lit environment.
However, please remember that it's Mac OS X, not X. I think X has gone as far toward taking BSD to the consumer market as it ever will. Instead of the ability to run multiple xterms, I think it is the Aqua interface and the BSD stability that will make Mac OS X a success.
I just hope that it isn't a huge step backwards in terms of sound quality, like digital radio is. Despite interference, FM stereo is pretty good next to something that has all the sound quality advantages of a low bitrate mp3. It might work in a car, though. The ambient noise could be enough that you don't notice your music sounds like crap.
This is good because it specifically acknowledges that the employer owns everything they pay you to do, but you can work on projects outside of work, and not be concerned that your employer can assert ownership over them.
Who are you, Jon Katz II: The Conservative? You should write an op-ed piece for Slashdot; you troll almost as well as he does.
Repost the story one or two {day(s), week(s), month(s)} later.
Repost the story, with a different keyword (such as replace nanoSUBMARINES with nanoHELICOPTERS).
Repost the story, with a different link attached to it (say, one NYTimes link and one MSNBC copy of the NYTimes article).
Don't repost the story, but have Jon Katz write a treatise on how it impacts the future of all geeks in a post-Columbine corporate society.
Post a link to a different article with exactly the same viewpoint and information.
Post a link to a different article with slight differences in the viewpoint and information.
Post a link to a retraction of the article. This one is preferred, because it demonstrates recursion in a format understandable even by residents of Florida.
That's really what we're waiting for, right? I mean, right now a 450 mHz Macintosh probably beats the x86 processors across the board on mpeg4 compression. Based on Intel's stated goal of making the P4 a powerful chip for media processing in particular, I don't think this will be a long wait.