Check out Tom's Hardware Page for comparisons of the performance of K6-2 processors and Intel processors on popular games. The K6-2 is slower at floating point than Intel chips, and that's exactly the wrong thing to be slower at for a game machine.
Disappointing, since AMD is much better at designing chips than Intel, but still true.
There are a few fundamental problems with this architecture which the author of the article overlooks:
FPGAs are bulky.
The largest FPGA that I've heard of had a million gates on it. Pick-your-random-processor has 10-20 million transistors, giving it a high single-digit equivalent number of gates. Implementing anything with FPGAs will take up several times more space than using a custom chip.
This means that you will have a _big_ supercomputer.
FGPAs are slow.
While FPGAs are reconfigurable and hence very flexible, the implementations that they come up with for a given logic configuration aren't optimal. This, combined with the performance overhead incurred by the components that make it configurable, mean that an FPGA with a given logic pattern burned into it will be slower than an equivalent, optimized logic pattern implemented in CMOS.
This is another important point - CMOS. While the machine on your desk may use CMOS or might add BiCMOS in there for a speed boost, supercomputers and servers have significant amounts of ECL circuitry in them to speed up critical logic paths. ECL technology is based on bipolar transistors, which switch much more quickly than the MOSFETs used in CMOS but generate far more heat. Used sparingly with aggressive cooling, they can double the performance of a chip or more. This leaves CMOS chips in the dust, and by extension anything built with an FPGA.
Flexibility Is Useful, But Not Phenomenally So.
If you're shelling out the money for a supercomputer, then you have a good idea of the classes of problem that you're going to be running on it. This lets you choose the type of processor and interconnection architecture that you use so that it matches the problems that you plan to be running. If necessary, you design a custom ASIC for even better performance (as was done with Deep Crack). A reconfigurable architecture that was magically as fast as hybrid ECL/CMOS still wouldn't get you much of a performance boost, because you're already fairly close to an optimum hardware implementation. With modern processors, this is expecially true, because the on-chip scheduling and pipelining is good enough to keep most of the chip busy if the problem even approximately matches the chip's logic capabilities.
Communications Can't Be Reconfigured That Easily.
There was much mention in the article about using processors that were tightly coupled. They'd need to be, to share logical functions with each other. However, this is extremely difficult to accomplish even with conventional processors. The communications traffic goes up with the clock speed and as the square of the number of processors (until it saturates the processors, at which point it goes up linearly). Processors have enough trouble communicating with other chips as it is; this is why new memory architectures are coming out. Asking n=lots processors to communicate tightly with each other and with memory in a reconfigurable manner is asking for a motherboard that can't be built. In practice, you'll wind up implementing either an n-cube architecture that allows fast communication but limits connectivity, an anywhere-to-anywhere mesh that has wonderful connectivity but seriously limits the amount of traffic that can be supported, or a hierarchial system using one or both of the above. The system as described just won't work.
The Compiler Will Be A *Bitch*.
It's hard enough to optimize well with hardware that doesn't change. Figuring out the best way to implement an algorithm using both hardware and software feels like an intrinsically hard problem. Your compiler will have to try to solve this. IMO this will result in either a compiler that requires the user to explicitly state what they want done in hardware, or else a compiler that tries to optimize but does it badly, or else a compiler that is never finished.
In summary, I think that there are a number of issues that the writer of the article was not aware of. I hope that the designers of the system took them into account, because otherwise this will be a neat-sounding project that disappears once the investors realize that there isn't going to be a product.
The problem with taking a chip down to liquid nitrogen temperatures is that the circuitry will crack due to the fact that the different materials used to build the chip (silicon, silicon dioxide, aluminum or copper) have different coefficients of thermal expansion. I'm told that freon temperatures still work, though.
This might have a tolerable cost if you made the liquid nitrogen on the fly. This isn't difficult.
Right now BeOS is most certainly a single-user system, and AFAIK making it multi-user is pretty low on Be's priority list. There's no real need to for their target market, and many other things that need to be worked on in the more immediate future.
From what I've seen posted here and what I've heard from other Linux users and advocates, I seriously doubt that a "we're not a competitor" statement would fly. Regardless of whether Linux could in practice compete with Windows, a lot of people want it to.
So, I'd rather that the Linux community leave perjury to Microsoft:>.
Re. BeOS's timeline, it's on the order of 6-12 months between major revisions, and R4 came out fairly recently, which means that 2-4 years would be a good estimate.
Re. open source for development, from what I've seen Be is actively embracing third-party developers, for applications, at least. Check out the BeWare pages on their site for a list of third-party applications. The API is quite easy to write for, is reasonably clean, and isn't hidden (heck, all of the headers are in/boot/develop/headers if you want something that isn't covered in the Be Book). Sample code comes with BeOS, half of the applications on the BeWare pages offer source code, and the Be newsletter has useful programming articles in every issue.
IMO, forcing the OS itself to be open source would just remove the ability of BeOS to develop it, as they'd have trouble finding investors if the product isn't going to produce revenue.
Re. driver development, that's being worked on by both internal and external developers. Development could be faster, but it's adequate IMO.
Re. being a contender in the desktop market, I think that BeOS most certainly is. The interface is nice-looking and easy to use. There aren't any obvious drains on processing performance that I can find. The API is reasonably clean and is easy to write for. All you need is 3D accelleration, and you have the perfect platform for Joe Average User. Hardware accellerated 3D will probably be out for R5.x, IMO. You can already call a software OpenGL library as it stands.
I agree that Be is probably being wise in not calling this a competitor to Windows, but IMO it's still a very good one (though hard-core programmers will still prefer Linux).
DOOM was ported a whle back, though I think that the x86 version is still only for R3. The Heretic source was released recently, and porting that to BeOS wouldn't be too difficult.
Anything that has source available could be ported fairly easily, as the BeOS graphics API is reasonably nice and quite easy to use. There's even software OpenGL if you want it.
I doubt that Be will be doing ports itself, as they are all quite busy developing the OS, and this is a relatively low-priority item. However, they seem to actively embrace third-party software for their system (check the BeWare pages on their web site), so any game ports should be welcome.
Hardware OpenGL support would make porting 3D games extremely easy. R5 is probably a good estimate for the timeline for this, as someone already posted.
In my experience (and yes, I use BeOS frequently), BeOS is more stable than 95/98 and less stable than Linux.
Under normal use, BeOS won't destabilize. Applications also have a very hard time taking down the entire OS, unlike Windows.
However, if you start calling drivers directly, you can wedge the system fairly easily by tying up semaphores. A fork bomb also works quite well. I'm told that memory protection leaves a bit to be desired too, though it certainly seems more stable than Windows in that regard (it survives segmentation faults).
Bear in mind that BeOS is still an OS in development. All of the "R#" releases are preludes to version 1.0. That having been said, however, I doubt that it will ever have quite as much bulletproofing as a good Unix variant, because it's intended for the single user/home user market (as opposed to servers).
I personally think that it looks neat, has a nice interface, is easy to write applications for, and is reasonably efficient. SMP was also handled quite well on the machines that I've tested it with (negligeable overhead, unlike Windows). Unix is still my environment of choice for stability, but I think that BeOS would be a wonderful replacement for Windows for the average home user, once the 3D drivers are finished and there are more 3rd-party applications available (there are still several now).
Are you a troll, or just an idiot? YOU CAN'T GET STEREO VISION WITH JUST ONE EYE!!!!
If you take the time to read the original message:
Obviously the 3d effect would be lost.
You will see that the poster was asking if a recognizable _2D_ image would be visible using 3D display with one blind eye. If you look at the screen for an LCD-shutter display without glasses, you see a blurry mess.
Closing one eye while wearing the glasses, OTOH, gives a clear display. See my other reply.
I'm just wondering if some day most Displays incorporate some similar 3d-ish technology, if they'll work for people who only have one eye to see out of.
You should still see the display clearly. In order to get the 3D effect, both eyes have to be presented with clear images. Losing one image gets rid of the apparent depth, but the other image still looks fine.
I strongly suspect that most displays and platforms will have a 2D mode, as I doubt that 3D glasses will be practical in all contexts even if 3D displays do take off.
The real question is what to do about Voodoo and it's kin? I know that Voodoo can use two cards interlaced, but how hard to get a driver to support the 3d monitor with that?
AFAIK, in SLI mode both voodoo cards are listening to the same bus traffic. One acknowledges register writes, and the other doesn't send acknowledgement signals but still reads triangle and command data. This saves considerably on bus bandwidth (you only need to send the data once), but means that you can't send different triangle data to each card in a SLI pair.
OTOH, it's been a few months since I've seen a detailed description of this, so I might be making a mistake somewhere.
Is it possible to combine red and blue laser beams into a single beam of synthetic white light?
You could combine red, green, and blue beams to get something that looked white, but it would be "white" in the same way that your monitor is "white". Shine it on a prism and you'll get three lines instead of a rainbow.
You'd still get bad chromatic dispersion from holographic lenses exposed to this light; you'd just see three images in three colours instead of a rainbow-coloured smear.
Also, you'd have to use coherent light to illuminate the scene, not just the lens. It's light reflected from the scene that you care about.
holograms don't require a single color of light. they "just" require the same wavelengths in the same places. the only way we can achieve this now is with coherent laser light. ordinary incoherent white light does not have this property.
A holographic lens, which winds up looking like a fancy diffraction grating for simple lens configurations, should work on noncoherent light, but will have very nasty chromatic dispersion (i.e. focal length is very different for different wavelengths).
I want to know about books/programs that will get ANYONE into programming. I know two adult females who are interested and able but not knowledgable.
This is interesting, because I know at least one other person who was in the same position. She visited her local library and looked for books, and found a few that covered BASIC and Pascal.
IMO, something like Pascal or Turing would be the best choice for a first language, as they are well structured, have straightforward syntax, and give access to most of the features that are actually used in real programming. Once they have the fundamentals down, the student could move to something like C/C++. Starting with C would IMO be a bad idea because the syntax is cryptic as all heck to a novice. Someone who doesn't know how to program can still look at a Pascal or Turing program and see what most of it does. Syntax aside, the three languages mentioned above are similar in structure, so there shouldn't be much of a problem moving to C/C++ after the fundamentals have been grasped.
IMO, Scheme/LISP would be a less than ideal choice. I've used Scheme, and while it is neat and represents an interesting model of programming, IMO C/C++ would be more useful if the person actually wants to do professional programming. IMO the algorithmic model of C/C++ style languages is easier for a novice to grasp than that of LISP/Scheme, also.
BASIC, from what I've seen, is slowly mutating to resemble Pascal. However, it's still easy to write spaghetti in BASIC, while you at least have to try a little harder in Pascal/Turing. I just don't see any advantage to it.
For Pascal vs. Turing, the decision is pretty arbitrary as they're nearly identical. I've written in both, and if you add/remove semicolons and make minor tweaks a Turing program will compile in Pascal or vice versa. Turing does have good multithreading support, OTOH, which Pascal didn't the last time I checked. OTOH, Turing is a lot more reluctant to let you do things like pointer aliasing and messing with assembly code, port i/o (on the x86), etc.
As far as good books are concerned, I can't name any offhand. Ye (new) Olde K&R ANSI C book is decent as a C reference but not good as a tutorial. The local library seems to be a good resource, as my friend did manage to find books that were of use to her.
I've been playing with Compaq's system configuration/pricing tool.
14 processor GS140 -> about $800k US. 4 processor 8400 5/625 -> about $400k US. 4 processor 8200 5/625 -> about $200k US.
The one irritating flaw in the tool is that it says "see dealer" for most workstation prices.
I'm told that it is more cost effective to build something like a Beowulf cluster of alpha workstations than to buy a server, as long as you are running calcaulations that can be easily split up and don't saturate the network with communications traffic.
These prices are consistent with what I've seen. If absolute performance is your friend's primary system criterion, and your friend plans to do a lot of floating-point intensive work, then the alpha system is probably the best bet. From a cost/performance POV, though, I'm still not sure that a PC cluster wouldn't be better.
AFAIK the only difference between the $5k NT workstations and the $10k Unix workstations is software and the support contract. I could be wrong about this, though. Compaq provides a handy utility that lets you work out the cost of various system configurations. Fill in their information form and they'll point you to the appropriate web pages.
An alpha will get you several times the fp95 performance of either x86 or PPC, but will cost you far too much for the time being. Compaq finally sent me price figures. Prices may vary from manufacturer to manufacturer, but not by enough, they won't.
How they managed to pull 600 MHz at 0.35 without overheating is beyond me. I'm assuming that that's with a dual-phase clock. I'm also assuming that they can do a significant amount of work in one clock cycle. Does anyone have more information on the transistor technology used for various parts of the chip (i.e. CMOS, BiCMOS, ECL), and on the 21164 instruction set with clocks-to-execute information?
Why they're fabricating at 0.28 is a mystery to me, as most fabs can run at 0.25 now.
If they can pull 750 MHz at 0.28, then the 21264 should reach 1.2-1.4 GHz on 0.18 by late 1H-00 or so.
Re. clock speed, this will always influence performance. However, I agree that making sure that memory and peripherals can keep up with the processor is important too.
I've just checked Samsung's site, and the motherboards listed have space for 2-4 megabytes of cache. The processors that they're offering are 21164s, which is not so great, but they're clocked at up to the mid-600 MHz range. These motherboards are designed to be compatible with PCI and ISA peripherals made for standard PCs.
I didn't see a price sheet on the site. You may have to write them directly in order to get pricing information (I know that that's the case with Compaq's alpha pages).
A bit is a binary digit, 0 or 1. A byte is (usually) a collection of 8 bits, representing an integer from 0..255 (unsigned) or -128..127 (signed). As it takes 8 bits to store one byte, there is a substantial difference in capacity between bits-per-second and bytes-per-second.
And as Ur_vile pointed out, some machines use bytes that are not 8 bits in length. However, you aren't likely to encounter them outside of computer research labs [note the "likely" before flaming me, please].
I've taken a look at the article, and this just appears to be a fancy way of modulating data on to the laser beam carrier. The fundamental limits remain the same as with other methods of transmission. That they see a bandwidth increase is not a surprise, because they are using an analog waveform to carry the data instead of a digital pulse train. The down side to this is greater suceptiblity to noise.
The fundamental maximum bandwidth of a fiber optic line using visible light at sane power levels is on the order of 10^14-10^15 bits per second, roughly corresponding to the frequency of oscillation of a light wave at visible wavelengths. By using analog data encoding you might be able to bump this up to 10^16 or higher, but you'd pay dearly for it in terms of power consumption (as your beam needs to be brighter if you want to have more intensity levels available). You can similarly improve noise rejection by using a brighter beam.
For those of you with time on your hands, the maximum sampling rate that you can meaningfully use is the frequency of the photons being transmitted (C / wavelength), the error in the measurement of the number of photons received is roughly the square root of the number of photons, and the energy of a photon is proportional to its frequency, and is single-digit eV for visible light.
And I seem to recall hearing about terabit fiber being demonstrated a while back.
The following approach should work, but requires venture captial.
Plan your service in detail and sign up advance customers. For a free service, this will just be accounts created before the service is up.
Take your detailed plan and customer list and make a business plan. Make sure that advertising revenue is in here.
Get venture capital. This should be do-able with the business plan and list of advance customers.
Start up the service without the banner ads. Put placeholders in where they would be.
Run the service for a month or two, keeping track of usage statistics and signing up new users. Track how the number of users grows over time.
_Now_ go out to potential advertisers. You have a service that already has many users looking at what could be their ads; this is a strong bargaining position. You know what your costs are because you've been running the service for a couple of months. You know how many advertising slots you have. You know how many hits you have. This gives you the gross advertising revenue that you need; price the advertising slots accordingly.
If your service isn't up and running, it is the advertisers who control how much they pay you for the banner ads. OTOH, if the service has a solid customer base, you can ask for whatever you want (within reason). Best of luck.
Slashdot Mirror
Check out Tom's Hardware Page for comparisons of the performance of K6-2 processors and Intel processors on popular games. The K6-2 is slower at floating point than Intel chips, and that's exactly the wrong thing to be slower at for a game machine.
Disappointing, since AMD is much better at designing chips than Intel, but still true.
The largest FPGA that I've heard of had a million gates on it. Pick-your-random-processor has 10-20 million transistors, giving it a high single-digit equivalent number of gates. Implementing anything with FPGAs will take up several times more space than using a custom chip.
This means that you will have a _big_ supercomputer.
While FPGAs are reconfigurable and hence very flexible, the implementations that they come up with for a given logic configuration aren't optimal. This, combined with the performance overhead incurred by the components that make it configurable, mean that an FPGA with a given logic pattern burned into it will be slower than an equivalent, optimized logic pattern implemented in CMOS.
This is another important point - CMOS. While the machine on your desk may use CMOS or might add BiCMOS in there for a speed boost, supercomputers and servers have significant amounts of ECL circuitry in them to speed up critical logic paths. ECL technology is based on bipolar transistors, which switch much more quickly than the MOSFETs used in CMOS but generate far more heat. Used sparingly with aggressive cooling, they can double the performance of a chip or more. This leaves CMOS chips in the dust, and by extension anything built with an FPGA.
If you're shelling out the money for a supercomputer, then you have a good idea of the classes of problem that you're going to be running on it. This lets you choose the type of processor and interconnection architecture that you use so that it matches the problems that you plan to be running. If necessary, you design a custom ASIC for even better performance (as was done with Deep Crack). A reconfigurable architecture that was magically as fast as hybrid ECL/CMOS still wouldn't get you much of a performance boost, because you're already fairly close to an optimum hardware implementation. With modern processors, this is expecially true, because the on-chip scheduling and pipelining is good enough to keep most of the chip busy if the problem even approximately matches the chip's logic capabilities.
There was much mention in the article about using processors that were tightly coupled. They'd need to be, to share logical functions with each other. However, this is extremely difficult to accomplish even with conventional processors. The communications traffic goes up with the clock speed and as the square of the number of processors (until it saturates the processors, at which point it goes up linearly). Processors have enough trouble communicating with other chips as it is; this is why new memory architectures are coming out. Asking n=lots processors to communicate tightly with each other and with memory in a reconfigurable manner is asking for a motherboard that can't be built. In practice, you'll wind up implementing either an n-cube architecture that allows fast communication but limits connectivity, an anywhere-to-anywhere mesh that has wonderful connectivity but seriously limits the amount of traffic that can be supported, or a hierarchial system using one or both of the above. The system as described just won't work.
It's hard enough to optimize well with hardware that doesn't change. Figuring out the best way to implement an algorithm using both hardware and software feels like an intrinsically hard problem. Your compiler will have to try to solve this. IMO this will result in either a compiler that requires the user to explicitly state what they want done in hardware, or else a compiler that tries to optimize but does it badly, or else a compiler that is never finished.
In summary, I think that there are a number of issues that the writer of the article was not aware of. I hope that the designers of the system took them into account, because otherwise this will be a neat-sounding project that disappears once the investors realize that there isn't going to be a product.
This might have a tolerable cost if you made the liquid nitrogen on the fly. This isn't difficult.
Right now BeOS is most certainly a single-user system, and AFAIK making it multi-user is pretty low on Be's priority list. There's no real need to for their target market, and many other things that need to be worked on in the more immediate future.
So, I'd rather that the Linux community leave perjury to Microsoft
Re. open source for development, from what I've seen Be is actively embracing third-party developers, for applications, at least. Check out the BeWare pages on their site for a list of third-party applications. The API is quite easy to write for, is reasonably clean, and isn't hidden (heck, all of the headers are in
IMO, forcing the OS itself to be open source would just remove the ability of BeOS to develop it, as they'd have trouble finding investors if the product isn't going to produce revenue.
Re. driver development, that's being worked on by both internal and external developers. Development could be faster, but it's adequate IMO.
Re. being a contender in the desktop market, I think that BeOS most certainly is. The interface is nice-looking and easy to use. There aren't any obvious drains on processing performance that I can find. The API is reasonably clean and is easy to write for. All you need is 3D accelleration, and you have the perfect platform for Joe Average User. Hardware accellerated 3D will probably be out for R5.x, IMO. You can already call a software OpenGL library as it stands.
I agree that Be is probably being wise in not calling this a competitor to Windows, but IMO it's still a very good one (though hard-core programmers will still prefer Linux).
Anything that has source available could be ported fairly easily, as the BeOS graphics API is reasonably nice and quite easy to use. There's even software OpenGL if you want it.
I doubt that Be will be doing ports itself, as they are all quite busy developing the OS, and this is a relatively low-priority item. However, they seem to actively embrace third-party software for their system (check the BeWare pages on their web site), so any game ports should be welcome.
Hardware OpenGL support would make porting 3D games extremely easy. R5 is probably a good estimate for the timeline for this, as someone already posted.
Under normal use, BeOS won't destabilize. Applications also have a very hard time taking down the entire OS, unlike Windows.
However, if you start calling drivers directly, you can wedge the system fairly easily by tying up semaphores. A fork bomb also works quite well. I'm told that memory protection leaves a bit to be desired too, though it certainly seems more stable than Windows in that regard (it survives segmentation faults).
Bear in mind that BeOS is still an OS in development. All of the "R#" releases are preludes to version 1.0. That having been said, however, I doubt that it will ever have quite as much bulletproofing as a good Unix variant, because it's intended for the single user/home user market (as opposed to servers).
I personally think that it looks neat, has a nice interface, is easy to write applications for, and is reasonably efficient. SMP was also handled quite well on the machines that I've tested it with (negligeable overhead, unlike Windows). Unix is still my environment of choice for stability, but I think that BeOS would be a wonderful replacement for Windows for the average home user, once the 3D drivers are finished and there are more 3rd-party applications available (there are still several now).
If you take the time to read the original message:
Obviously the 3d effect would be lost.
You will see that the poster was asking if a recognizable _2D_ image would be visible using 3D display with one blind eye. If you look at the screen for an LCD-shutter display without glasses, you see a blurry mess.
Closing one eye while wearing the glasses, OTOH, gives a clear display. See my other reply.
You should still see the display clearly. In order to get the 3D effect, both eyes have to be presented with clear images. Losing one image gets rid of the apparent depth, but the other image still looks fine.
I strongly suspect that most displays and platforms will have a 2D mode, as I doubt that 3D glasses will be practical in all contexts even if 3D displays do take off.
AFAIK, in SLI mode both voodoo cards are listening to the same bus traffic. One acknowledges register writes, and the other doesn't send acknowledgement signals but still reads triangle and command data. This saves considerably on bus bandwidth (you only need to send the data once), but means that you can't send different triangle data to each card in a SLI pair.
OTOH, it's been a few months since I've seen a detailed description of this, so I might be making a mistake somewhere.
You could combine red, green, and blue beams to get something that looked white, but it would be "white" in the same way that your monitor is "white". Shine it on a prism and you'll get three lines instead of a rainbow.
You'd still get bad chromatic dispersion from holographic lenses exposed to this light; you'd just see three images in three colours instead of a rainbow-coloured smear.
Also, you'd have to use coherent light to illuminate the scene, not just the lens. It's light reflected from the scene that you care about.
A holographic lens, which winds up looking like a fancy diffraction grating for simple lens configurations, should work on noncoherent light, but will have very nasty chromatic dispersion (i.e. focal length is very different for different wavelengths).
This is interesting, because I know at least one other person who was in the same position. She visited her local library and looked for books, and found a few that covered BASIC and Pascal.
IMO, something like Pascal or Turing would be the best choice for a first language, as they are well structured, have straightforward syntax, and give access to most of the features that are actually used in real programming. Once they have the fundamentals down, the student could move to something like C/C++. Starting with C would IMO be a bad idea because the syntax is cryptic as all heck to a novice. Someone who doesn't know how to program can still look at a Pascal or Turing program and see what most of it does. Syntax aside, the three languages mentioned above are similar in structure, so there shouldn't be much of a problem moving to C/C++ after the fundamentals have been grasped.
IMO, Scheme/LISP would be a less than ideal choice. I've used Scheme, and while it is neat and represents an interesting model of programming, IMO C/C++ would be more useful if the person actually wants to do professional programming. IMO the algorithmic model of C/C++ style languages is easier for a novice to grasp than that of LISP/Scheme, also.
BASIC, from what I've seen, is slowly mutating to resemble Pascal. However, it's still easy to write spaghetti in BASIC, while you at least have to try a little harder in Pascal/Turing. I just don't see any advantage to it.
For Pascal vs. Turing, the decision is pretty arbitrary as they're nearly identical. I've written in both, and if you add/remove semicolons and make minor tweaks a Turing program will compile in Pascal or vice versa. Turing does have good multithreading support, OTOH, which Pascal didn't the last time I checked. OTOH, Turing is a lot more reluctant to let you do things like pointer aliasing and messing with assembly code, port i/o (on the x86), etc.
As far as good books are concerned, I can't name any offhand. Ye (new) Olde K&R ANSI C book is decent as a C reference but not good as a tutorial. The local library seems to be a good resource, as my friend did manage to find books that were of use to her.
I've been playing with Compaq's system configuration/pricing tool.
14 processor GS140 -> about $800k US.
4 processor 8400 5/625 -> about $400k US.
4 processor 8200 5/625 -> about $200k US.
The one irritating flaw in the tool is that it says "see dealer" for most workstation prices.
I'm told that it is more cost effective to build something like a Beowulf cluster of alpha workstations than to buy a server, as long as you are running calcaulations that can be easily split up and don't saturate the network with communications traffic.
AFAIK the only difference between the $5k NT workstations and the $10k Unix workstations is software and the support contract. I could be wrong about this, though. Compaq provides a handy utility that lets you work out the cost of various system configurations. Fill in their information form and they'll point you to the appropriate web pages.
An alpha will get you several times the fp95 performance of either x86 or PPC, but will cost you far too much for the time being. Compaq finally sent me price figures. Prices may vary from manufacturer to manufacturer, but not by enough, they won't.
How they managed to pull 600 MHz at 0.35 without overheating is beyond me. I'm assuming that that's with a dual-phase clock. I'm also assuming that they can do a significant amount of work in one clock cycle. Does anyone have more information on the transistor technology used for various parts of the chip (i.e. CMOS, BiCMOS, ECL), and on the 21164 instruction set with clocks-to-execute information?
Why they're fabricating at 0.28 is a mystery to me, as most fabs can run at 0.25 now.
If they can pull 750 MHz at 0.28, then the 21264 should reach 1.2-1.4 GHz on 0.18 by late 1H-00 or so.
Re. clock speed, this will always influence performance. However, I agree that making sure that memory and peripherals can keep up with the processor is important too.
I didn't see a price sheet on the site. You may have to write them directly in order to get pricing information (I know that that's the case with Compaq's alpha pages).
And as Ur_vile pointed out, some machines use bytes that are not 8 bits in length. However, you aren't likely to encounter them outside of computer research labs [note the "likely" before flaming me, please].
The fundamental maximum bandwidth of a fiber optic line using visible light at sane power levels is on the order of 10^14-10^15 bits per second, roughly corresponding to the frequency of oscillation of a light wave at visible wavelengths. By using analog data encoding you might be able to bump this up to 10^16 or higher, but you'd pay dearly for it in terms of power consumption (as your beam needs to be brighter if you want to have more intensity levels available). You can similarly improve noise rejection by using a brighter beam.
For those of you with time on your hands, the maximum sampling rate that you can meaningfully use is the frequency of the photons being transmitted (C / wavelength), the error in the measurement of the number of photons received is roughly the square root of the number of photons, and the energy of a photon is proportional to its frequency, and is single-digit eV for visible light.
And I seem to recall hearing about terabit fiber being demonstrated a while back.
The following approach should work, but requires venture captial.
If your service isn't up and running, it is the advertisers who control how much they pay you for the banner ads. OTOH, if the service has a solid customer base, you can ask for whatever you want (within reason). Best of luck.