The problem is that said kind of reasoning rarely works nowadays. Your compiler and operating system do all sorts of things behind your back. More seriously, CPUs today are far, far more complex and hard to reason with than Knuth's simple MIX CPU (unless you are working with a simple embedded system).
Well, I agree and I don't. The MIX architecture has, what, like 12 registers? The MIPSIV architecture that I'm familiar with has dozens, of all shapes and sizes. So yeah, trying to twiddle with things at the register level is often a futile effort.
But some issues still apply. For example, it's often important to arrange your structures so they're divisible by four or eight bytes. That's a pretty low-level thing, and having a working knowledge of assembly and architectures helps you get that. And, of course, the technique of making your data fetches an even multiple of your cache line is always a good trick.
That's cool and all, if true, but XFS has been able to handle 9 million TB files and 18 million TB filesystems for years and years.
(Can't really handle the term "exabyte" ever since that tape drive company comandeered it. Besides, a million terabytes sounds bigger than one exabyte.)
SGI hasn't been able to hold a candle to high-end PC graphics boards for probably 3 years, and they [used to] cost ~10x as much. I know because we used to use SGIs exclusively at work, now we use Linux-based PCs.
What, exactly, do you do? If you have replaced your SGI systems with PCs, good for you, but that probably means the thing you're doing isn't terribly difficult.
Give me a nine-channel system, each channel 4000x3000 RGBA double-buffered. Oh, and I use shared memory arenas for my IPC, so it has to be a single system image. I'll need, let's see, two procs each for each channel (cull/draw), plus a proc for the router and a proc for the database pager. Plus a proc for the app, and one for the serial device handlers.
Shouldn't be a problem, right? PCs can do that. I just need a 22-processor Athlon motherboard with 9 Geforce 3 cards. 'Scuse me while I dash off to Fry's. Back in a flash.
You're wrong. Hexachrome is neither new nor revolutionary.
The process of creating colors by overlaying color halftones in a rosette, that was new and revolutionary. Hexachrome is just another way of doing that same thing. Six colors instead of four, but the same idea.
If I had to pick something going on right now that is closest to being called revolutionary, I'd choose stochastic screening. Us computer types know it better as dithering. Basically, instead of printing dots in a pattern and varying their sizes to give the impression of tone, stochastic screening prints equally sized-- and very small-- spots of color, but places them randomly, varying their distribution to produce tones.
Personally, I haven't cared too much for the stochastic samples I've seen, but that's a matter of execution and preference. It may be that stochastic printing will have a lot going for it as the process of generating the screens becomes more refined.
Reality Engine and Reality Engine 2 were predecessors to InfiniteReality. Around '96 there was a stripped down version of InfiniteReality, called, simply, Reality, that kind of took the place of RE2 in the product line, but that was only available in the Onyx2 deskside, so not too many were sold compared to IR systems.
The majority of the opinions here so far seem to say that learning assembly isn't important for non-hardcore-programmer types.
I agree, if we're talking about any particular assembly. PowerPC assembly, for instance, or MIPS assembly.
But everybody who programs-- even people who just want to understand programming-- should slog their way through Knuth's TAOCP. The abstract stuff in that book is implemented in concrete terms through a really simple fictional assembly language called MIX. When you're reading the first chapter of Volume 1, you'll be so frustrated with it that you'll wanna strangle the first person you see. But by the time you get through it, you won't be an assembly programmer, but you will find yourself saying things like, "I should arrange the loops this way, because then the inner loop will fit entirely in registers and the data fetches will be less than one cache line."
Saying stuff like that makes you sound really smart, which leads directly to better paying jobs.
The reason why they "yanked" the IA-32 line was because they were all OEM'd VA-linux systems.
Not entirely. The 1400, 1450, 1200, and 1100 were all OEM machines-- I'm not sure by whom; maybe VA Linux or maybe somebody else-- and they were cancelled. The 230, 330, and 550 were also OEM systems-- definitely not by VA Linux; I think by Acer, maybe?-- and they were cancelled.
But SGI had also just recently acquired the Zx10 product line from Intergraph, and that stuff was all killed, too.
The IA-32 shutdown was complete and total, across all of SGI's products, not just the OEM servers.
They've been doing this sort of thing since you and I were using our "cutting edge" unaccelerated 2D graphics cards running at an "insane" 1024x768.
A simulator project I worked on in '98-'99 used a 32-processor Onyx2 with eight pipes (4 RMs each) to drive seven out-the-window channels at 3200x3400@60 plus a heads-up display.
Not a type: 3,200 pixels across, 3,400 pixels down, 60 frames per second. Times seven channels.
I've been doing this for a while, and it made me stop and say, "Holy crap."
SGI is caught in the classic problem that killed DEC, and is killing Tandem, Stratus, DG, and many others: the performance of the lowend is improving so quickly that we can do things on $1K machines that used to require $1M machines.
In a way, you're right. Every day I deal with the fact that SGI computers aren't cost-effective for general purpose tasks like file serving or database applications.
But at the same time, you've pointed out the reason why SGI is trying to do what they're trying to do. Some tasks that could previously only be done on SGI workstations can now be done on cheap(er) PC-type computers. I'm thinking of 3D modeling and image exploitation specifically, but there are lots of other examples, too.
So okay, SGI needs to get out of the desktop workstation business except where they can justify it. So they're doing that.
But there are some tasks that you've never been able to do cost-effectively on a PC-type system. Like high-definition or film compositing and editing. Sure, you can do film-resolution work with After Effects or Final Cut Pro, but it'd be so slow that you couldn't turn a profit doing it. So instead you buy a half-million-dollar Onyx and go to sleep every night on a big pile of money.
Now, for the first time, there's a desktop workstation that's capable of doing most of what an Onyx can do: Octane2. So now SGI is going to a lot of those customers that have Onyxes and asking them if they'd like to buy three or four smaller systems that do 80% of what the Onyx can do to augment their existing stuff. And many of them are saying yes, because (and this is the key) they already know they can be profitable doing it.
Of course, when SGI pushes down too far into the market space, they tend to get spanked a little. If you're doing standard-definition video editing, or god forbid compressed, you can do most of what you need with an Avid or Final Cut Pro on a G4. So SGI loses a lot there.
The trick: find the sweet spot, where the market is broad enough that you have a lot of customers to call on but not so broad that you get beat on price-performance, and sit there.
At the other end of the spectrum, there's the really high end. The Grand Challenge type stuff, like the project that motivated ASCI Blue Mountain at Los Alamos. If you're going to try to simulate a nuclear explosion instead of just setting one off and watching the pretty colors, you're going to need a computer that is several hundred times bigger than anything that had ever been built before. So there's an opportunity there to sell some of your big iron to the government, and (more importantly) to fund some R&D that will then trickle down to your commercial products so you can get back to beating the competition on features instead of fighting over price.
So yeah, in a way you're right. The low end keeps getting better. But as it does, we keep thinking of things to do-- both commercially and in the sciences-- that the low end can't handle. It's like swimming in the ocean. The waves are moving under you, and if you just sit still you're going to get dunked. But if you swim in the right direction at the right speed you can stay at the crest of the wave. That's the trick: to stay on the crest of the technology wave.
I believe that by 2005 SGI will no longer be in the low to mid-range workstation market.
I'm not sure how you define that market, but for my money SGI isn't in it now.
SGI's workstation products include O2+ (a special purpose machine), Octane2 (definitely high end), and Onyx 3000 (the highest of the high). There's going to be a new product coming early next year-- this is not a secret, although the details and case color are-- that sits below Octane2 on the price graph, but it isn't going to be a low- or mid-range desktop computer either.
But the thing that sealed their doom was when they didn't take the opportunity offered by Nintendo purchasing a huge number of R4000 chips.
The Nintendo 64 was built around the MIPS R4300i embedded processor. It had limited R4000 instruction-set compatibility and a 64-bit execution unit, but it wasn't really related to the chips SGI used at the time at all.
So while selling tons more embedded processors would have been a nice bonus for SGI's MIPS subsidiary, it wouldn't have affected their core business on bit.
SGI used to be a real innovator in the field of graphics. Now it seems like companies like ATI and Nvidia are actaully doing more for that field.
You know, that's the funny thing about SGI's graphics hardware. InfiniteReality graphics first came out in January, 1996. Since then, SGI has put the same graphics processors on a new system interface for the Onyx2, and tweaked some components in the system twice (called IR2 and IR3, even though the changes were very minor).
InfiniteReality--apart from having the coolest name of any graphics subsystem--has remained essentially unchanged since 1996. IR today has slightly faster geometry processors and much more TRAM than the original IR, but in every other way it is identical.
That's six year old technology, baby. And the rest of the world is just now starting to catch up.
Guess that's why SGI has been selling the same graphics hardware for all this time. Because they can.
I have an original, still-in-the-jewel-case "Octane: The Sound Track" CD. These five classic songs make a great addition to any collection.
1. Ignite Your Mind 2. I Have a Dream 3. OCTANE Swing (featuring the can't-get-it-out-of-your-head lines, "Octane / you're gonna rock-tane!" and "Competition is in shock-tane!" and "Octane, danke shoen!")
4. Retro OCTANE 5. Knee Deep in 3D
I wouldn't part with this disc for all the tea in China, but I'll encode it and send you the files for the right price.;-)
I don't mean to be morbid, but from reading the article it seems clear that this building couldn't handle a fully fueled passenger jet being crashed into it.
It's all well and good to defend against those who want to steal, but beyond a certain point, you can't really defend against those who wish to destroy.
Remember back in 2000 when an accident took out a huge fraction of Australia's international bandwidth? Better make sure those "divergent path links" don't just end up in the same undersea cable....
Is to scrub Linux and go with a Solaris variant. The software you mention is easily available for these platforms. The point of Linux is that it is a free O/S, but remember that the cost of a proprietory Unix is only a teeny-tiny fraction of the overall licensing fees for the Enterprise software you require. You get what you pay for, I guess.
How did this happen? Somebody makes a frank recommendation, on-topic and non-flamebaity, and it gets modded down to -1? Just because it recommends going with Solaris over Linux? Sometimes peer moderation sucks.
I first saw HDTV on a large runco projector... they brought in a studio-quality deck to play the source material since there were no on-air broadcasts at the time...
It's important to note that full-bandwidth 1080i is over a billion and a quarter bits per second of data[1], while over-the-air terrestrial broadcast is encoded with MPEG-2 at just over 19 million bits per second. HDTV over satellite is even lower than that, sometimes as low as 6 million bits per second.
The Sony HDCAM deck uses DCT compression at a ratio of around 10:1, and you have to be pretty sharp to see the difference between that format and uncompressed 1080i. But even uneducated eyes, like mine, can see the difference between uncompressed 1080i or HDCAM and over-the-air 19 Mbit, and 6 Mbit direct-broadcast satellite isn't even in the same ballpark.
Of course, your point was that the monitor makes a difference. This is absolutely true. The difference between a consumer set (about $4000) from Sony and a broadcast monitor (about $40,000) from Sony can also be perceived by mere mortals.
Funny story about that. I was told by a Sony rep at NAB two years ago that they manufacture all of their picture tubes on the same assembly line, then they test them. Depending on the quality of the finished tube, they'll put it in their broadcast monitors (if it can resolve 1000 lines), or their high-end consumer TVs (if it can resolve 600 lines) or their low-end consumer TVs (if it lights up when you run current through it). Is it true? Don't know. But it's amusing anyway.
[1] Screw this "giga," "gibi," "goober," "bippi" crap.
I guess your ideas are kind of on the right track, but you should probably familiarize yourself with modern system architecture trends.
Crossbar-style system interconnects are not new ideas. I'm not an authority on the subject, but I know that the Cray Y-MP had a 32-port switch architecture that provided about 1.3 GB per second of memory bandwidth per processor (hope I'm remembering these numbers right!)
The DEC VAX 9000 series had a 1 GB/second CPU-to-memory pathway that utilized a crossbar switch, also.
Both of these systems were in wide use around 1990, give or take a few years. And, of course, the ideas go back much further than that. I used to have a copy of a paper by Wulf in Communications of the ACM dated 1974 that described a switch-based multiprocessor system. Can't find it right now, alas.
Things have come a long way. From 1 GB/sec aggregate in 1990 to 22 GB/sec aggregate in 1998 (the Cray SV1) to 40 GB/sec aggregate in 2001 (the SV1ex). The SV1ex provides each processor with 6.4 GB/sec of bandwidth into and out of main memory.
Increasing the speed of the RAM isn't the issue-- the SV1ex uses commodity SDRAM. The issue is building sufficiently large parallel paths for the memory controllers to execute very large parallel fetches into a vector cache.
So I guess you could say that you're headed in the right direction, but you've got a long way to go.;-)
As to memory bandwidth. Modern CPU caches make the question nearly moot.
This is simply not true. Your other points are pretty wacked, too, but I'll take this one because I have personal experience.
I have some image processing code that runs on IRIX, and I recently did a shoot-out between an Origin 2000 and an Origin 3000. Both machines had eight 400 MHz R12000 processors with 8 MB of secondary cache and 4 GB of RAM, and both were equivalently equipped for disk.
The Origin 3000 was almost twice as fast as the 2000 was, with identical CPUs, memory, and disk. (The actual numbers are on a spreadsheet at the office, unfortunately.) The difference? Memory and interprocessor bandwidth. The Origin 3000 platform has a specified memory bandwidth of about 2.5 times the bandwidth of the Origin 2000.
The test involved taking a big multispectral image, splitting it up into tiles, handing each tile off to a thread, and doing some processing on the tiles. The data set was pretty huge, but not so big that it couldn't be cached entirely in RAM, so the first step was to load the whole thing into memory. But for the actual test run, there was a lot of fetch-operate-fetch, which really exercised the memory bandwidth of the system.
So your comment about memory bandwidth being moot is completely off base.
Even the KLAC machine discussed only barely qualifies as a supercomputer, 64 processors is at the low end of the scale. People have Web servers with that number of CPUs.
I know this is completely off topic, but Travelocity (the travel web site, you know) has lots and lots and lots of SGI Origin systems for running their front-end app-- it does session management and HTML generation, and passes data back and forth from the user to the database, so it's basically just a web server.
I've lost count, but I know they've been buying at least one 32-processor system per quarter for several years now. And, if I remember right, they recently bought something like four 32-proc Origin 3000 systems, too.
So, yeah, they've got a hell of a big web server.;-)
We're trappist monks, trapped by the bounds of syntax. The time for change is near.
Meanwhile, tons of the image processing code in the application I'm currently working on is hand-coded in MIPS assembly. It's not old code; it's actively maintained stuff. I don't think anyone did that because they thought it'd be fun. I think they did it because it resulted in a better end-product.
Use all the drag-and-drop GUI tools you want. I still believe the things that separate a good program from a bad program lie at opposite ends: the overall design, and the twiddly optimizations. A computer might be able to help with the stuff in the middle-- linking objects to interfaces to objects, or whatever-- but it simply can't generate those two main things for you.
Efficient programming tools. If four programmers could write a better Photoshop in two months and distribute it electronically, then things will change.
Do you seriously think the tools are what makes this impossible? Ha!
Don't you get it? The reason why software monopolies and practical monopolies exist is because writing good software is hard. If I took ten random programmers, selected from among all the programmers in the world, and gave them a copy of "I Can't Believe It's an IDE!" they would still be lousy programmers. They'd just write lousy programs faster.
You wanna talk about changing things in 2002? How about one job applicant-- just one!-- who doesn't give me a blank stare when I ask if they've read Knuth.
I'm not sure where you got the idea that I'm advocating humanity as the be-all, end-all of anything. If I gave you that idea, I misspoke somewhere.
Yes, humanity appears to have evolved from other, less complex, life forms, and yes, it's reasonable to guess that that process of change-over-time might continue. But are you completely, totally, 100% certain that that's the whole story?
Human beings, as I've tried to say before, are distinctly different from any other species that we've found so far. You seem to disagree with me on this fundamental point. That's fine, but I must say that I can't understand how you can see the evidence of our distinctiveness with your own eyes and still deny it.
You haven't stated anything yet that changes my mind that we will create what will amount to artificial life in the form of machine intelligence (at least) at some future point.
How about this: hypothesize that there is some necessary ingredient for intelligence (whatever that really means) that we have, but that all other life forms on this planet lack. I won't speculate about what that requirement might be, but just imagine that it's there. Maybe it's paprika; it doesn't matter.
It would explain a lot. It would explain why, in all the world, there is no other species like ours. We live only on land, and yet there is no species comparable to ours in the vast ocean. There's room enough in the sea for just about anything, and yet still we are unique. Why? According to our hypothesis, it's because only we humans have the necessary ingredient.
A natural consequence of this hypothesis is the idea that intelligence doesn't just spontaneously appear out of nowhere. If that's true (just bear with me) then making computers that are bigger and faster and more complex (and only the five richest kings of Europe...) will result in bigger, faster, more complex computers, but not intelligent ones. Because, going along that path, we will not have built a computer that includes... paprika. The ingredient. Whatever it is.
Now that our little thought-experiment is over, ask yourself whether any evidence to the contrary exists. We've come up with a hypothesis that would explain some things, so now we have to either prove it or disprove it with real evidence.
Is there any evidence to support either point of view? No, there isn't. Then why jump to the conclusion that one point of view must be the correct one?
I'll acknowledge that it's possible that you may be right. But it seems to me that there are some unexplained facts about the world, and there's an awful lot of room in your world-view for some factor, some ingredient, about which you know nothing. That's all I want: just admit the possibility that I may be right.
The problem is that said kind of reasoning rarely works nowadays. Your compiler and operating system do all sorts of things behind your back. More seriously, CPUs today are far, far more complex and hard to reason with than Knuth's simple MIX CPU (unless you are working with a simple embedded system).
Well, I agree and I don't. The MIX architecture has, what, like 12 registers? The MIPSIV architecture that I'm familiar with has dozens, of all shapes and sizes. So yeah, trying to twiddle with things at the register level is often a futile effort.
But some issues still apply. For example, it's often important to arrange your structures so they're divisible by four or eight bytes. That's a pretty low-level thing, and having a working knowledge of assembly and architectures helps you get that. And, of course, the technique of making your data fetches an even multiple of your cache line is always a good trick.
So I think we agree more than we disagree.
OS X can handle filesizes up to eight exabytes
That's cool and all, if true, but XFS has been able to handle 9 million TB files and 18 million TB filesystems for years and years.
(Can't really handle the term "exabyte" ever since that tape drive company comandeered it. Besides, a million terabytes sounds bigger than one exabyte.)
SGI hasn't been able to hold a candle to high-end PC graphics boards for probably 3 years, and they [used to] cost ~10x as much. I know because we used to use SGIs exclusively at work, now we use Linux-based PCs.
What, exactly, do you do? If you have replaced your SGI systems with PCs, good for you, but that probably means the thing you're doing isn't terribly difficult.
Give me a nine-channel system, each channel 4000x3000 RGBA double-buffered. Oh, and I use shared memory arenas for my IPC, so it has to be a single system image. I'll need, let's see, two procs each for each channel (cull/draw), plus a proc for the router and a proc for the database pager. Plus a proc for the app, and one for the serial device handlers.
Shouldn't be a problem, right? PCs can do that. I just need a 22-processor Athlon motherboard with 9 Geforce 3 cards. 'Scuse me while I dash off to Fry's. Back in a flash.
You're wrong. Hexachrome is neither new nor revolutionary.
The process of creating colors by overlaying color halftones in a rosette, that was new and revolutionary. Hexachrome is just another way of doing that same thing. Six colors instead of four, but the same idea.
If I had to pick something going on right now that is closest to being called revolutionary, I'd choose stochastic screening. Us computer types know it better as dithering. Basically, instead of printing dots in a pattern and varying their sizes to give the impression of tone, stochastic screening prints equally sized-- and very small-- spots of color, but places them randomly, varying their distribution to produce tones.
Personally, I haven't cared too much for the stochastic samples I've seen, but that's a matter of execution and preference. It may be that stochastic printing will have a lot going for it as the process of generating the screens becomes more refined.
what happened to the reality engine?
Reality Engine and Reality Engine 2 were predecessors to InfiniteReality. Around '96 there was a stripped down version of InfiniteReality, called, simply, Reality, that kind of took the place of RE2 in the product line, but that was only available in the Onyx2 deskside, so not too many were sold compared to IR systems.
The majority of the opinions here so far seem to say that learning assembly isn't important for non-hardcore-programmer types.
I agree, if we're talking about any particular assembly. PowerPC assembly, for instance, or MIPS assembly.
But everybody who programs-- even people who just want to understand programming-- should slog their way through Knuth's TAOCP. The abstract stuff in that book is implemented in concrete terms through a really simple fictional assembly language called MIX. When you're reading the first chapter of Volume 1, you'll be so frustrated with it that you'll wanna strangle the first person you see. But by the time you get through it, you won't be an assembly programmer, but you will find yourself saying things like, "I should arrange the loops this way, because then the inner loop will fit entirely in registers and the data fetches will be less than one cache line."
Saying stuff like that makes you sound really smart, which leads directly to better paying jobs.
The reason why they "yanked" the IA-32 line was because they were all OEM'd VA-linux systems.
Not entirely. The 1400, 1450, 1200, and 1100 were all OEM machines-- I'm not sure by whom; maybe VA Linux or maybe somebody else-- and they were cancelled. The 230, 330, and 550 were also OEM systems-- definitely not by VA Linux; I think by Acer, maybe?-- and they were cancelled.
But SGI had also just recently acquired the Zx10 product line from Intergraph, and that stuff was all killed, too.
The IA-32 shutdown was complete and total, across all of SGI's products, not just the OEM servers.
They've been doing this sort of thing since you and I were using our "cutting edge" unaccelerated 2D graphics cards running at an "insane" 1024x768.
A simulator project I worked on in '98-'99 used a 32-processor Onyx2 with eight pipes (4 RMs each) to drive seven out-the-window channels at 3200x3400@60 plus a heads-up display.
Not a type: 3,200 pixels across, 3,400 pixels down, 60 frames per second. Times seven channels.
I've been doing this for a while, and it made me stop and say, "Holy crap."
SGI is caught in the classic problem that killed DEC, and is killing Tandem, Stratus, DG, and many others: the performance of the lowend is improving so quickly that we can do things on $1K machines that used to require $1M machines.
In a way, you're right. Every day I deal with the fact that SGI computers aren't cost-effective for general purpose tasks like file serving or database applications.
But at the same time, you've pointed out the reason why SGI is trying to do what they're trying to do. Some tasks that could previously only be done on SGI workstations can now be done on cheap(er) PC-type computers. I'm thinking of 3D modeling and image exploitation specifically, but there are lots of other examples, too.
So okay, SGI needs to get out of the desktop workstation business except where they can justify it. So they're doing that.
But there are some tasks that you've never been able to do cost-effectively on a PC-type system. Like high-definition or film compositing and editing. Sure, you can do film-resolution work with After Effects or Final Cut Pro, but it'd be so slow that you couldn't turn a profit doing it. So instead you buy a half-million-dollar Onyx and go to sleep every night on a big pile of money.
Now, for the first time, there's a desktop workstation that's capable of doing most of what an Onyx can do: Octane2. So now SGI is going to a lot of those customers that have Onyxes and asking them if they'd like to buy three or four smaller systems that do 80% of what the Onyx can do to augment their existing stuff. And many of them are saying yes, because (and this is the key) they already know they can be profitable doing it.
Of course, when SGI pushes down too far into the market space, they tend to get spanked a little. If you're doing standard-definition video editing, or god forbid compressed, you can do most of what you need with an Avid or Final Cut Pro on a G4. So SGI loses a lot there.
The trick: find the sweet spot, where the market is broad enough that you have a lot of customers to call on but not so broad that you get beat on price-performance, and sit there.
At the other end of the spectrum, there's the really high end. The Grand Challenge type stuff, like the project that motivated ASCI Blue Mountain at Los Alamos. If you're going to try to simulate a nuclear explosion instead of just setting one off and watching the pretty colors, you're going to need a computer that is several hundred times bigger than anything that had ever been built before. So there's an opportunity there to sell some of your big iron to the government, and (more importantly) to fund some R&D that will then trickle down to your commercial products so you can get back to beating the competition on features instead of fighting over price.
So yeah, in a way you're right. The low end keeps getting better. But as it does, we keep thinking of things to do-- both commercially and in the sciences-- that the low end can't handle. It's like swimming in the ocean. The waves are moving under you, and if you just sit still you're going to get dunked. But if you swim in the right direction at the right speed you can stay at the crest of the wave. That's the trick: to stay on the crest of the technology wave.
I believe that by 2005 SGI will no longer be in the low to mid-range workstation market.
I'm not sure how you define that market, but for my money SGI isn't in it now.
SGI's workstation products include O2+ (a special purpose machine), Octane2 (definitely high end), and Onyx 3000 (the highest of the high). There's going to be a new product coming early next year-- this is not a secret, although the details and case color are-- that sits below Octane2 on the price graph, but it isn't going to be a low- or mid-range desktop computer either.
But the thing that sealed their doom was when they didn't take the opportunity offered by Nintendo purchasing a huge number of R4000 chips.
The Nintendo 64 was built around the MIPS R4300i embedded processor. It had limited R4000 instruction-set compatibility and a 64-bit execution unit, but it wasn't really related to the chips SGI used at the time at all.
So while selling tons more embedded processors would have been a nice bonus for SGI's MIPS subsidiary, it wouldn't have affected their core business on bit.
SGI used to be a real innovator in the field of graphics. Now it seems like companies like ATI and Nvidia are actaully doing more for that field.
You know, that's the funny thing about SGI's graphics hardware. InfiniteReality graphics first came out in January, 1996. Since then, SGI has put the same graphics processors on a new system interface for the Onyx2, and tweaked some components in the system twice (called IR2 and IR3, even though the changes were very minor).
InfiniteReality--apart from having the coolest name of any graphics subsystem--has remained essentially unchanged since 1996. IR today has slightly faster geometry processors and much more TRAM than the original IR, but in every other way it is identical.
That's six year old technology, baby. And the rest of the world is just now starting to catch up.
Guess that's why SGI has been selling the same graphics hardware for all this time. Because they can.
Its due to their great songs!
;-)
I have an original, still-in-the-jewel-case "Octane: The Sound Track" CD. These five classic songs make a great addition to any collection.
1. Ignite Your Mind
2. I Have a Dream
3. OCTANE Swing (featuring the can't-get-it-out-of-your-head lines, "Octane / you're gonna rock-tane!" and "Competition is in shock-tane!" and "Octane, danke shoen!")
4. Retro OCTANE
5. Knee Deep in 3D
I wouldn't part with this disc for all the tea in China, but I'll encode it and send you the files for the right price.
I don't mean to be morbid, but from reading the article it seems clear that this building couldn't handle a fully fueled passenger jet being crashed into it.
It's all well and good to defend against those who want to steal, but beyond a certain point, you can't really defend against those who wish to destroy.
http://www.hostworks.com.au/networks.html
Remember back in 2000 when an accident took out a huge fraction of Australia's international bandwidth? Better make sure those "divergent path links" don't just end up in the same undersea cable....
Designed as a southern Fort Knox, the structure is earthquake proof, bomb resistant, and provides anti ram capabilities.
From the movie Strange Days by James Cameron:
MACE
Take it easy. The glass is bullet resistant.
LENNY
Bullet resistant? Whatever happened to bullet proof?
Is to scrub Linux and go with a Solaris variant. The software you mention is easily available for these platforms. The point of Linux is that it is a free O/S, but remember that the cost of a proprietory Unix is only a teeny-tiny fraction of the overall licensing fees for the Enterprise software you require. You get what you pay for, I guess.
How did this happen? Somebody makes a frank recommendation, on-topic and non-flamebaity, and it gets modded down to -1? Just because it recommends going with Solaris over Linux? Sometimes peer moderation sucks.
I first saw HDTV on a large runco projector... they brought in a studio-quality deck to play the source material since there were no on-air broadcasts at the time...
It's important to note that full-bandwidth 1080i is over a billion and a quarter bits per second of data[1], while over-the-air terrestrial broadcast is encoded with MPEG-2 at just over 19 million bits per second. HDTV over satellite is even lower than that, sometimes as low as 6 million bits per second.
The Sony HDCAM deck uses DCT compression at a ratio of around 10:1, and you have to be pretty sharp to see the difference between that format and uncompressed 1080i. But even uneducated eyes, like mine, can see the difference between uncompressed 1080i or HDCAM and over-the-air 19 Mbit, and 6 Mbit direct-broadcast satellite isn't even in the same ballpark.
Of course, your point was that the monitor makes a difference. This is absolutely true. The difference between a consumer set (about $4000) from Sony and a broadcast monitor (about $40,000) from Sony can also be perceived by mere mortals.
Funny story about that. I was told by a Sony rep at NAB two years ago that they manufacture all of their picture tubes on the same assembly line, then they test them. Depending on the quality of the finished tube, they'll put it in their broadcast monitors (if it can resolve 1000 lines), or their high-end consumer TVs (if it can resolve 600 lines) or their low-end consumer TVs (if it lights up when you run current through it). Is it true? Don't know. But it's amusing anyway.
[1] Screw this "giga," "gibi," "goober," "bippi" crap.
I guess your ideas are kind of on the right track, but you should probably familiarize yourself with modern system architecture trends.
;-)
Crossbar-style system interconnects are not new ideas. I'm not an authority on the subject, but I know that the Cray Y-MP had a 32-port switch architecture that provided about 1.3 GB per second of memory bandwidth per processor (hope I'm remembering these numbers right!)
The DEC VAX 9000 series had a 1 GB/second CPU-to-memory pathway that utilized a crossbar switch, also.
Both of these systems were in wide use around 1990, give or take a few years. And, of course, the ideas go back much further than that. I used to have a copy of a paper by Wulf in Communications of the ACM dated 1974 that described a switch-based multiprocessor system. Can't find it right now, alas.
Things have come a long way. From 1 GB/sec aggregate in 1990 to 22 GB/sec aggregate in 1998 (the Cray SV1) to 40 GB/sec aggregate in 2001 (the SV1ex). The SV1ex provides each processor with 6.4 GB/sec of bandwidth into and out of main memory.
Increasing the speed of the RAM isn't the issue-- the SV1ex uses commodity SDRAM. The issue is building sufficiently large parallel paths for the memory controllers to execute very large parallel fetches into a vector cache.
So I guess you could say that you're headed in the right direction, but you've got a long way to go.
As to memory bandwidth. Modern CPU caches make the question nearly moot.
This is simply not true. Your other points are pretty wacked, too, but I'll take this one because I have personal experience.
I have some image processing code that runs on IRIX, and I recently did a shoot-out between an Origin 2000 and an Origin 3000. Both machines had eight 400 MHz R12000 processors with 8 MB of secondary cache and 4 GB of RAM, and both were equivalently equipped for disk.
The Origin 3000 was almost twice as fast as the 2000 was, with identical CPUs, memory, and disk. (The actual numbers are on a spreadsheet at the office, unfortunately.) The difference? Memory and interprocessor bandwidth. The Origin 3000 platform has a specified memory bandwidth of about 2.5 times the bandwidth of the Origin 2000.
The test involved taking a big multispectral image, splitting it up into tiles, handing each tile off to a thread, and doing some processing on the tiles. The data set was pretty huge, but not so big that it couldn't be cached entirely in RAM, so the first step was to load the whole thing into memory. But for the actual test run, there was a lot of fetch-operate-fetch, which really exercised the memory bandwidth of the system.
So your comment about memory bandwidth being moot is completely off base.
Even the KLAC machine discussed only barely qualifies as a supercomputer, 64 processors is at the low end of the scale. People have Web servers with that number of CPUs.
;-)
I know this is completely off topic, but Travelocity (the travel web site, you know) has lots and lots and lots of SGI Origin systems for running their front-end app-- it does session management and HTML generation, and passes data back and forth from the user to the database, so it's basically just a web server.
I've lost count, but I know they've been buying at least one 32-processor system per quarter for several years now. And, if I remember right, they recently bought something like four 32-proc Origin 3000 systems, too.
So, yeah, they've got a hell of a big web server.
We're trappist monks, trapped by the bounds of syntax. The time for change is near.
Meanwhile, tons of the image processing code in the application I'm currently working on is hand-coded in MIPS assembly. It's not old code; it's actively maintained stuff. I don't think anyone did that because they thought it'd be fun. I think they did it because it resulted in a better end-product.
Use all the drag-and-drop GUI tools you want. I still believe the things that separate a good program from a bad program lie at opposite ends: the overall design, and the twiddly optimizations. A computer might be able to help with the stuff in the middle-- linking objects to interfaces to objects, or whatever-- but it simply can't generate those two main things for you.
Efficient programming tools. If four programmers could write a better Photoshop in two months and distribute it electronically, then things will change.
Do you seriously think the tools are what makes this impossible? Ha!
Don't you get it? The reason why software monopolies and practical monopolies exist is because writing good software is hard. If I took ten random programmers, selected from among all the programmers in the world, and gave them a copy of "I Can't Believe It's an IDE!" they would still be lousy programmers. They'd just write lousy programs faster.
You wanna talk about changing things in 2002? How about one job applicant-- just one!-- who doesn't give me a blank stare when I ask if they've read Knuth.
Humbug.
Mega-ma-bytes
Giga-ma-bytes
Saxa-ma-phone
Baba-ma-bushka....
(who needs karma when you have funny?)
I'm not sure where you got the idea that I'm advocating humanity as the be-all, end-all of anything. If I gave you that idea, I misspoke somewhere.
Yes, humanity appears to have evolved from other, less complex, life forms, and yes, it's reasonable to guess that that process of change-over-time might continue. But are you completely, totally, 100% certain that that's the whole story?
Human beings, as I've tried to say before, are distinctly different from any other species that we've found so far. You seem to disagree with me on this fundamental point. That's fine, but I must say that I can't understand how you can see the evidence of our distinctiveness with your own eyes and still deny it.
You haven't stated anything yet that changes my mind that we will create what will amount to artificial life in the form of machine intelligence (at least) at some future point.
How about this: hypothesize that there is some necessary ingredient for intelligence (whatever that really means) that we have, but that all other life forms on this planet lack. I won't speculate about what that requirement might be, but just imagine that it's there. Maybe it's paprika; it doesn't matter.
It would explain a lot. It would explain why, in all the world, there is no other species like ours. We live only on land, and yet there is no species comparable to ours in the vast ocean. There's room enough in the sea for just about anything, and yet still we are unique. Why? According to our hypothesis, it's because only we humans have the necessary ingredient.
A natural consequence of this hypothesis is the idea that intelligence doesn't just spontaneously appear out of nowhere. If that's true (just bear with me) then making computers that are bigger and faster and more complex (and only the five richest kings of Europe...) will result in bigger, faster, more complex computers, but not intelligent ones. Because, going along that path, we will not have built a computer that includes... paprika. The ingredient. Whatever it is.
Now that our little thought-experiment is over, ask yourself whether any evidence to the contrary exists. We've come up with a hypothesis that would explain some things, so now we have to either prove it or disprove it with real evidence.
Is there any evidence to support either point of view? No, there isn't. Then why jump to the conclusion that one point of view must be the correct one?
I'll acknowledge that it's possible that you may be right. But it seems to me that there are some unexplained facts about the world, and there's an awful lot of room in your world-view for some factor, some ingredient, about which you know nothing. That's all I want: just admit the possibility that I may be right.