Your comments are interesting, and I'm not trying to stop you - but I'd like to play the devil's advocate and poke a few holes in some of the statements you've made.
Maybe they should select somebody in their company to be a project maintainer and pay developers a bounty by-the-line for code that gets accepted. Basically divide the $20,000 or whatever by lines of code submitted.
Ouch. This sounds very Dibertian, as it will lead to
code
that
looks
like
this
from developers, and
codethatlookslikethis
from the maintainer after integration.
I heartily agree with the principle, but so far I know of no mechanistic way of figuring out how "productive" a given programmer is by automatically examining their code. Current industry makes an approximation by paying programmers for their time at a rate dependent on what their boss feels reflects the quality of their work, but this doesn't work very well for paying contributors to Open Source projects, who aren't a part of the company and so can't be timed or evaluated as easily.
Not that the conventional system is perfect, of course.
But this influence could easily be mitigated if another company started doing the same thing. Problems could turn up when 2 companies want to influence the same project, but I think that they could both hire programmers, and the 2 teams would have to cooperate in order to prevent a code fork.
That only holds true if the companies are altruistic enough to hold the quality of their software over the revenue and/or ego boost gained by having the project follow their own model. Realistically, if a serious dispute came up, I think that each company would fork the code and hope for the best. Remember, business by and large isn't altruistic. There are isolated exceptions, but IMO these will remain exceptions rather than the rule.
Think of a nerve as an analog device of near infinite resolution but with a sampling frequency of roughly 1 MHz. The nerve also has a quasi-averaging mechanism built in wherein the nerve can respond quite quickly to stimuli but exhibits a time-based decay (self-erasing memory) when the stimuli is removed.
[..]
Simply put, a nerve needs a LOT of bandwidth to function correctly.
Most models of the behaviour of biological neural networks that I've seen treat neurons as entities that give out pulse trains corresponding to an activity level and are stimulated by pulse trains that they receive from other neurons, weighted by coefficients applied by the synapses the signals pass through. These models exhibit behaviour of great complexity, and simulations of abstracted versions of these models have been adapted to many computational tasks. Why do we assume that additional complexity above this a part of the brain's information processing, as opposed to just noise or the biological equivalent of hardware-introduced artifacts? AFAIK, the jury is still out as to exactly how much computational work the brain is doing in order to host our minds?
A neuron's precise response to stimulus may depend on the precise timing and amplitude of incoming signals, but is this a feature or a bug?
The brain's memory capacity is far more than 2 megabytes. In a very simplified model, each synapse performs a multiplication of the signal going through it by a constant. If you assume that this constant has at least eight bits of precision, this gives you one byte of storage per synapse. The numbers I've heard for the number of synapses in the brain tend to vary, but there are at least on the order of a trillion of them and possibly several orders of magnitude more.
Shannon's information theory does _not_ apply to quantum systems, however. I don't know to what extent quantum effects are used in the nervous system.
Greatly, if you listen to Roger Penrose. Negligeably, if you listen to most other people. Quantum effects will inject noise into the brain's neural network, which in the long run makes it a bit more flexible by perturbing it out of metastable states when it's trying to learn something, but that doesn't affect bandwidth.
No, you did not read the article. the danger is that the cooling system will fail because of a lack of backup power.
So, drop the control rods in and shut down the reactor.
This assumes that the magnets holding the control rods up still have power, even though the cooling system doesn't.
If by some magic you can't drop the control rods, most reactors have a safety feature that lets you dump out the liquid that acts as a moderator. No more slow neutrons; the reactor stops dead.
If mischeivous Martians weld the control rods in place and similarly render all other safety mechanisms inoperative, preventing shutdown, then long before meltdown occurred your coolant pipes will burst. As the coolant is also the moderator, your reactor will stop dead. This makes one hell of a mess, but isn't catastrophic.
Meltdowns can only easily occur in reactors that use a moderator that can keep on moderating even when at the melting point of the fuel bundles. In Chernobyl, for instance, graphite rods were used to moderate the reactor. Graphite sublimates at about 4000 degrees C, and so remained in the reactor, slowing down neutrons, until the molten glop that was the reactor core spread out enough to no longer be able to sustain the reaction. Modern nuclear power plants use heavy water, ordinary water, or molten sodium as moderators. These have low boiling points (even sodium, IIRC).
Ever since the possibilty of meltdowns became known, the designers of nuclear power plants have made damned sure that the reactors will shut down, either by user action or by failure of moderator containment, long before meltdown can occur.
Will Linux or NT automatically take advantage of the extra CPU? Or is it an application issue?
"Yes".
The OS, if it's been compiled to support SMP, should detect multiple processors automatically and spread out threads accordingly. Applications will only benefit from this if they were written to use multiple threads.
Really beats me why K6's can't go dual (at least everybody say so) when there were, say, dual 486's.
The problems are locking and memory coherence.
When you have a single processor accessing memory, everything is just fine. The processor can cache what it wants, and what is in its cache will always be valid. It can load a value from memory, modify it, and write it back, and be confident that nothing has modified it in the interim. In general, life is good, though if it uses superscaling it'll have to implement some locking logic internally for memory operations that are supposed to be atomic.
When you have multiple processors, things get significantly uglier. First, let's consider the case where you have multiple processors accessing uncached memory.
Processor A and processor B are counting events. Each increments the same counter. This is done by reading the value from memory, incrementing it, and then writing it to memory again. A problem occurs when both try to do this at the same time. Processor A reads the value. Processor B reads the value. Both increment it, and then both write it again. At the end of all of this, the value has only been incremented by one, because both processors had read the original value of the variable.
The solution to this is locking. We declare that we want the incrementing operations performed atomically; that is, we want the incrementing operation to behave as if it is done in one step, instead of several steps interleaved with other instructions. When processor A wants to increment the counter, it locks the memory region in which the counter resides, performs the steps required for incrementing it, and then unlocks it again. During this time, processor B is unable to acquire a lock for that region of memory and so ends up waiting until processor A has finished incrementing. The counting works properly, but the memory control system needs to be a bit more complex.
Now, we have the problem of cacheing. When processor A wants to lock a region of memory, not only does it have to lock the region of main memory, but the cache of processor B needs to be updated if it stored a copy of that region of memory. This kind of cache updating requires even more complicated memory control logic.
The K6 series of processors doesn't include this. As a result, it has a simpler memory control and cacheing system, making it cheaper to produce, but it can't support SMP unless you disable cacheing on the chip and stick memory management logic on the motherboard. This extra logic is expensive, and if you have any sense, you'll stick a cache next to the chip on the motherboard, which is expensive also, and slower than an on-chip cache would be.
So, for AMD SMP, wait for the K7.
The Celeron doesn't have this either. For Celeron SMP, you either have to include this logic on the motherboard or on the 370-to-slot-1 adapter, or else run into very bizzare flakiness when two processors disagree about what should be in memory at a given location.
I've used both fairly extensively. BeOS has a nice interface, is reasonably stable, and has a fairly clean API. However, it's still fairly easy to wedge a BeOS system if you muck around with anything complicated, and security and memory protection leave much to be desired, for the time being. Linux and other Unix variants tend to have uglier interfaces and more complex APIs, but are very stable, reasonably secure, and can be tortured to within an inch of their lives without falling over (though you can still wedge them if you try hard enough). A BeOS box is a wonderful user machine. A *nix box is a wonderful server.
I don't know anyone who has tried Linux SMP, but those who have tried NT SMP have found it non optimal.
I've heard similar stories. I was told that adding a second processor under NT gave about a 33% performance increase, due to bad design (IIRC all interrupts were handled by one processor, among other things, but I don't have hard details on that).
BeOS scales beautifully to dual processors. As far as I can tell on the test machine here, there is little or no overhead for multithreaded _applications_. I'm not sure about the kernel, but it was designed explicitly with multithreading and SMP in mind.
I'm told that earlier versions of Linux could support SMP, but only one processor could be in the kernel at a time. I'm told that 2.2.x is much better in this regard, with finer locking granularity allowing proper distribution of kernel load between processors.
If there isn't much OS overhead in general/if the primary load is the application (i.e. you're running something like a multithreaded ray-tracer or physical simulation), then in principle SMP should give substantial performance gains on any platform. In the real world, I don't know, but it probably still is application-dependent.
The ray tracer would probably run into memory bandwidth problems, come to think of it. That might be its performance bottleneck even on a single-processor system.
You can still be paid to write the software. You're not paid for a copy of the software, just the service of writing it.
Let me rephrase my question, as apparently I didn't state it clearly enough - Why would a company pay me to write software if they gained no revenue from it?
If it's an application that the company needs internally that's worth paying the entire development cost for, then it will get written. However, that's a pretty steep cost, and if that's the only case in which applications software is produced, a lot of programmers are going to be out of work...
and GPS (which is dumb cause if the worst imaginable happens, GPS isnt gonna work!)
Um, the GPS satellites are way in the heck up in orbit, and don't give a flying leap what date computer systems down here think it is, because they have their own clocks on board (a GPS satellite's *job* is to transmit timing pulses, and that's it). Your GPS will still work, as long as you have batteries for it and nobody fires a box of nails up at the satellite.
This is a big problem. If there is a loss of power for more then 3 days, there WILL be meltdowns.
Hah.
Power goes out in a typical US power plant. The elctromagnets holding the control rods over the reactor shut off. The reactor stops dead, and can't be restarted until the rods are pulled out again.
You _can_ turn the reactors _off_ if there's a problem. How do you think that they do maintainence on them?
But, honestly. Why the hell would you need the year to determine a nuclear launch function? They might have the year in the event-logging software, just for reference, but they don't need a year for anything else.
The article didn't mention date rollover in nuclear weapon control systems specifically. Instead, it talked about their response to a wave of catastrophic computer crashes sweeping across the planet. This pretty much spelled out for me the knowledge level of the article's writers' on the subject.
They also mentioned nuclear power plants, stating that they would spontaneously melt down when this wave of devastation hit. Leaving aside the fact that it is extremely hard to make modern nuclear power plants melt down when you are actively trying to do so, the control systems that panic when anything like this happens aren't date-sensitive.
This article would probably make a neat movie, but IMO that's about it.
[Re. hiring programmers to work on a large project that needs to be completed reasonably quickly:]
"And in order to pay them, you are going to have to sell your product."
You have to sell _a_ product. Software will effectively not be the product; sell something else.
Such as?
You can't force people to pay for support contracts. Further, if the source for the software is distributed, they'll get better tech support on newsgroups than most companies are likely to produce.
Software that's developed to serve specific hardware is useful if you're a hardware vendor, but this doesn't help you if you're writing a third-party application.
For applications programming, the software _is_ the product. If that's free, there's nothing left to sell, which means it might as well not be written in the first place from the company's point of view.
7) Just because all software is free does not mean that no software needs to be written. You can still be paid to write programs.
By whom? The resulting software must be given away, not sold, so there will be very little in the way of revenue to pay you with.
Free software has many good points, and is especially useful for small projects (that can be handled by one person in their spare time), or for large projects that don't require much coordination and that don't have a deadline (there are many very useful examples of these). If, OTOH, you need a large amount of organized development done within a moderately short length of time, you're going to need to hire full-time programmers. And in order to pay them, you are going to have to sell your product.
There are a number of logic faults within your post. Here are the ones that I am most concerned about:
The playstatoin is about 10 times faster then a 5,000 visual sgi workstation and only a little bit faster then a indy workstation.
Put these boxes beside each other and run them. To my knowledge, no real, production grade Playstation 2 exists. You can do wonderful things with demo hardware (I seem to recall a few Intel shennanigans in that regard...). This is vapour.
Its true that a $150 kids consule can outperform a $5,000 workstation. GO blame intel for those rediculously over engineered motherborads and [..]
Perhaps you weren't aware of this, but Intel does not make real workstations.
Real workstations are made by companies like Sun, Compaq, HP, and SGI, and are based on Sparc, Alpha, PA-RISC, and MIPS processors, respectively. Intel processors are garbage in workstation-land, and PPC processors aren't much better, I'm afraid. Likewise, real workstations and servers use well-designed motherboards and well-designed bus protocols. Never, ever confuse souped up desktop "workstations" with the real thing.
Now, go to www.spec.org and to the web sites of the manufacturers mentioned, and get specs on some real systems, please.
Oh, and FYI a real workstation costs about $50,000, not $5000.
adaptec for making scsi really expensive video card manufactors for over engineering their cards to make them 10 times as much and 5 times slower then what they could be.
The video cards that are put in PCs are about the same quality as the PCs themselves. For an example of a real video card, go to http://www.3dlabs.com and look at the high-end Oxygen boards.
I couldn't agree with Larry Elison more when he calls pc's mini mainframes.
Architecturally, they are very different. Functionally, they have very different strengths. The best thing to call a PC would be a poor man's workstation, and even that's stretching it. Please research for yourself what "mainframes", "servers", and "workstations" are before blindly believing what your favourite noteworthies tell you.
THink about how fast a mainframe can do graphics and compare that to todays pc's. hmmm they have something in common. Also isdn and scsi are all mainframe based technologies that suck. scsi is actually slower then eidi with non server single user loads. ITs true.
I believe that this demonstrates a complete lack of knowledge about what a graphics workstation is. Please look up the terms described above, and try again.
Would Firewire or any of the other interfaces be fast enough to handle realtime gaming graphics being streamed to the PSX 2 for display, rather than to a PCI or AGP card?
The short answer to this is "no". Old-fashioned PCI-33 maxes out at 132 MBytes/sec. AGP increases this considerably, but it is still fairly easy to find cases where card performance is limited by the system bus. I have yet to hear of a network connector or external bus that is commonly available that does this (gigabit ethernet and the like are expensive). This means that any scheme that used a Playstation 2 as a rendering box would have serious limits imposed by whatever you're using to connect with it.
That having been said, you get free geometry processing in the Playstation 2, which means that it could very well outperform conventional cards that don't have geometry processing, even when used as a peripheral. OTOH, geometry processing will be on graphics cards Real Soon Now (tm), so the actual usefulness of this is open to question.
Since the PSX-2 supposedly outperforms an SGI InfiniteReality (specced at up to 13 Million poly/second with quad-R10000s)
The key word here is "supposedly". The real numbers, from rumours, are considerably lower than what their marketing department is claiming.
and has it's own geometry engine, the PSX-2 would likely make an inexpensive and hugely capable dedicated graphics engine for a PC.
Possibly. A system with multiple conventional graphics cards may be more efficient at this when the Playstation 2 actually comes out. We'll see.
The advantages of using 2 or more of these boxes in parallel also naturally spring to mind...
Communications with the boxes will be even more of a problem with this than with one box. You will rapidly reach diminishing returns with this, except in very specific cases.
But, really, how much does one of these 50 million polys/sec chips actually cost *today*?
From what I've heard, a 50 million poly/sec chip doesn't exist. Try about an order of magnitude lower than that. That's just the rumour mill, though; we'll see what the specs actually are when it ships.
Graphics cards based on a similar chip would be interesting, at the very least, agreed.
Why would that not be practical? Not being belligerent, just curious.
I strongly suspect that it would be more expensive, as it would need extra logic to interface it with the PCI bus and the PC as a whole. It would also be harder for the console makers to make money by charging royalties for media, as piracy would be much easier. Also, you would need a moderately expensive PC to put it in, and would need to either use a video pass-through cable or tie up more bus bandwidth with video output data. You'd also either need a separate controller port on the card, making for additional cabling.
I agree that none of the above is earth-shattering, but I see no advantage to putting the console on a card and several minor disadvantages. You could get better output resolution just by putting a monitor output on a conventional console (though this means either buying another monitor or fiddling with cables when you want to play games).
The above assumes that you have a PC, also. I don't know exactly how large a chunk of the gaming market doesn't use a computer, but I suspect that it is pretty sizeable. Just about everyone has a TV.
pixels, not polys. a TV is what, ~640x480? so, htats like 307,200 pixels a 'frame', but TV's use fields, so its more like 153,600 a field, at 60 fields a second is 9,216,000 pixels a second for your average TV show. Remember, that 24 bill is most likely just doing pix's.
I strongly suspect that a fill rate that insane is for flat-shaded untextured polygons, or at best for single-textured polygons. Divide by four for a quad-textured multitextured polygon, or by somewhere between 2 and 8 for a single-textured polygon with trilinear filtering, depending on the conditions and how clever the hardware is.
There's also the question of overdraw. Triangles overlap each other; this is why z-buffering exists. In the worst case, where your polygons are drawn from back to front, you wind up drawing n times as many pixels as are actually displayed, where n is the number of overlapping triangles. Overdraw factor varies widely, as it depends on how much effort the game programmer put into culling algorithms. However, it can be anywhere from about 2 to about 10.
So, at 640x240x60 (or 640x480x30 interlaced), you need to draw about 9.2 million pixels per second. If your overdraw factor is about 3 on average, this means you need a fill rate of about 28 million pixels per second. If you're using dual-textured trilinearly filtered textures with a moderately efficient texturing algorithm, you need a fill rate equivalent to about 220 million non-filtered single-texture pixels per second.
What this says to me in practice is that the Playstation 2 isn't going to be fill-rate limited if it's running on a standard television set. For higher resolutions and less marketing-inflated spec numbers, fill rate may become significant.
Now here's a question. Could all the capabilities of the PSX be brought over to a computer by putting that hardware on a PCI card? Maybe with a software interface to the computer?
In principle, yes. This is in fact done for development boards IIRC. However, in practice, this won't be much more useful or cost-effective than just buying a separate console.
The problem is that a PC's I/O and memory subsystems are relatively lousy. A console (or a real workstation, for that matter) has a highly optimized, very fast, and very wide set of busses connection the various components of the system in a configuration designed to serve the needs of the purpose for which the system is being used (for a console, graphics processing). If you dropped a console's graphics processors on a PCI card and let the CPU handle all other tasks, the system would crawl, because the PC's bus doesn't have the bandwidth to control the hardware effectively. You could stick most of the console components on the card and give it an internal bus with appropriate specs, but then you just have a full console sitting in your PCI slot. There isn't much point.
This is useful for development boards, because it lets you transfer new builds of games to the console and run the console in debug mode, but IMO a gamer would be better off just with the production version of the console and a TV. I'm sure that somebody will figure out how to run home-brewed or pirated games on it in short order, especially with firewire and other ports available for data transfer (boot to a special CD and run the game off of a hard drive).
Vaporware is always cheaper and always kicks ass of commercially available hardware."
Uh, I guess you missed the 5 or so mpgs they released? Doesn't look like vaporware to me.
Take a good look at the screen shots and MPEGs. They look nice, yes. They are worth buying a Playstation 2 for? Quite possibly. They need 50^H^H70^H^H20 million polygons per second to render? Not really. Believe marketing specs at your peril. The numbers that I've been hearing floating out of the developer community are quite a bit lower.
and a system that can do in realtime what takes SGIs hours to render
Put a playstation 2 next to an SGI box and prove this, if you want me to believe it.
An SGI box of equivalent cost, maybe...
The numbers coming out of Sony's marketing division are very overinflated. The screen shots prove otherwise, you say? Take a good look at them and figure out how many polygons you'd need in order to generate something that looks like that. Many, but not *that* many, by between one and two orders of magnitude (even at a decent frame rate).
Slashdot Mirror
Maybe they should select somebody in their company to be a project maintainer and pay developers a bounty by-the-line for code that gets accepted. Basically divide the $20,000 or whatever by lines of code submitted.
Ouch. This sounds very Dibertian, as it will lead to
code
that
looks
like
this
from developers, and
codethatlookslikethis
from the maintainer after integration.
I heartily agree with the principle, but so far I know of no mechanistic way of figuring out how "productive" a given programmer is by automatically examining their code. Current industry makes an approximation by paying programmers for their time at a rate dependent on what their boss feels reflects the quality of their work, but this doesn't work very well for paying contributors to Open Source projects, who aren't a part of the company and so can't be timed or evaluated as easily.
Not that the conventional system is perfect, of course.
But this influence could easily be mitigated if another company started doing the same thing. Problems could turn up when 2 companies want to influence the same project, but I think that they could both hire programmers, and the 2 teams would have to cooperate in order to prevent a code fork.
That only holds true if the companies are altruistic enough to hold the quality of their software over the revenue and/or ego boost gained by having the project follow their own model. Realistically, if a serious dispute came up, I think that each company would fork the code and hope for the best. Remember, business by and large isn't altruistic. There are isolated exceptions, but IMO these will remain exceptions rather than the rule.
[..]
Simply put, a nerve needs a LOT of bandwidth to function correctly.
Most models of the behaviour of biological neural networks that I've seen treat neurons as entities that give out pulse trains corresponding to an activity level and are stimulated by pulse trains that they receive from other neurons, weighted by coefficients applied by the synapses the signals pass through. These models exhibit behaviour of great complexity, and simulations of abstracted versions of these models have been adapted to many computational tasks. Why do we assume that additional complexity above this a part of the brain's information processing, as opposed to just noise or the biological equivalent of hardware-introduced artifacts? AFAIK, the jury is still out as to exactly how much computational work the brain is doing in order to host our minds?
A neuron's precise response to stimulus may depend on the precise timing and amplitude of incoming signals, but is this a feature or a bug?
The brain's memory capacity is far more than 2 megabytes. In a very simplified model, each synapse performs a multiplication of the signal going through it by a constant. If you assume that this constant has at least eight bits of precision, this gives you one byte of storage per synapse. The numbers I've heard for the number of synapses in the brain tend to vary, but there are at least on the order of a trillion of them and possibly several orders of magnitude more.
Greatly, if you listen to Roger Penrose. Negligeably, if you listen to most other people. Quantum effects will inject noise into the brain's neural network, which in the long run makes it a bit more flexible by perturbing it out of metastable states when it's trying to learn something, but that doesn't affect bandwidth.
So, drop the control rods in and shut down the reactor.
This assumes that the magnets holding the control rods up still have power, even though the cooling system doesn't.
If by some magic you can't drop the control rods, most reactors have a safety feature that lets you dump out the liquid that acts as a moderator. No more slow neutrons; the reactor stops dead.
If mischeivous Martians weld the control rods in place and similarly render all other safety mechanisms inoperative, preventing shutdown, then long before meltdown occurred your coolant pipes will burst. As the coolant is also the moderator, your reactor will stop dead. This makes one hell of a mess, but isn't catastrophic.
Meltdowns can only easily occur in reactors that use a moderator that can keep on moderating even when at the melting point of the fuel bundles. In Chernobyl, for instance, graphite rods were used to moderate the reactor. Graphite sublimates at about 4000 degrees C, and so remained in the reactor, slowing down neutrons, until the molten glop that was the reactor core spread out enough to no longer be able to sustain the reaction. Modern nuclear power plants use heavy water, ordinary water, or molten sodium as moderators. These have low boiling points (even sodium, IIRC).
Ever since the possibilty of meltdowns became known, the designers of nuclear power plants have made damned sure that the reactors will shut down, either by user action or by failure of moderator containment, long before meltdown can occur.
"Yes".
The OS, if it's been compiled to support SMP, should detect multiple processors automatically and spread out threads accordingly. Applications will only benefit from this if they were written to use multiple threads.
The problems are locking and memory coherence.
When you have a single processor accessing memory, everything is just fine. The processor can cache what it wants, and what is in its cache will always be valid. It can load a value from memory, modify it, and write it back, and be confident that nothing has modified it in the interim. In general, life is good, though if it uses superscaling it'll have to implement some locking logic internally for memory operations that are supposed to be atomic.
When you have multiple processors, things get significantly uglier. First, let's consider the case where you have multiple processors accessing uncached memory.
Processor A and processor B are counting events. Each increments the same counter. This is done by reading the value from memory, incrementing it, and then writing it to memory again. A problem occurs when both try to do this at the same time. Processor A reads the value. Processor B reads the value. Both increment it, and then both write it again. At the end of all of this, the value has only been incremented by one, because both processors had read the original value of the variable.
The solution to this is locking. We declare that we want the incrementing operations performed atomically; that is, we want the incrementing operation to behave as if it is done in one step, instead of several steps interleaved with other instructions. When processor A wants to increment the counter, it locks the memory region in which the counter resides, performs the steps required for incrementing it, and then unlocks it again. During this time, processor B is unable to acquire a lock for that region of memory and so ends up waiting until processor A has finished incrementing. The counting works properly, but the memory control system needs to be a bit more complex.
Now, we have the problem of cacheing. When processor A wants to lock a region of memory, not only does it have to lock the region of main memory, but the cache of processor B needs to be updated if it stored a copy of that region of memory. This kind of cache updating requires even more complicated memory control logic.
The K6 series of processors doesn't include this. As a result, it has a simpler memory control and cacheing system, making it cheaper to produce, but it can't support SMP unless you disable cacheing on the chip and stick memory management logic on the motherboard. This extra logic is expensive, and if you have any sense, you'll stick a cache next to the chip on the motherboard, which is expensive also, and slower than an on-chip cache would be.
So, for AMD SMP, wait for the K7.
The Celeron doesn't have this either. For Celeron SMP, you either have to include this logic on the motherboard or on the 370-to-slot-1 adapter, or else run into very bizzare flakiness when two processors disagree about what should be in memory at a given location.
I've used both fairly extensively. BeOS has a nice interface, is reasonably stable, and has a fairly clean API. However, it's still fairly easy to wedge a BeOS system if you muck around with anything complicated, and security and memory protection leave much to be desired, for the time being. Linux and other Unix variants tend to have uglier interfaces and more complex APIs, but are very stable, reasonably secure, and can be tortured to within an inch of their lives without falling over (though you can still wedge them if you try hard enough). A BeOS box is a wonderful user machine. A *nix box is a wonderful server.
Just my 2 cents worth (1.3 cents US).
optimal.
I've heard similar stories. I was told that adding a second processor under NT gave about a 33% performance increase, due to bad design (IIRC all interrupts were handled by one processor, among other things, but I don't have hard details on that).
BeOS scales beautifully to dual processors. As far as I can tell on the test machine here, there is little or no overhead for multithreaded _applications_. I'm not sure about the kernel, but it was designed explicitly with multithreading and SMP in mind.
I'm told that earlier versions of Linux could support SMP, but only one processor could be in the kernel at a time. I'm told that 2.2.x is much better in this regard, with finer locking granularity allowing proper distribution of kernel load between processors.
If there isn't much OS overhead in general/if the primary load is the application (i.e. you're running something like a multithreaded ray-tracer or physical simulation), then in principle SMP should give substantial performance gains on any platform. In the real world, I don't know, but it probably still is application-dependent.
The ray tracer would probably run into memory bandwidth problems, come to think of it. That might be its performance bottleneck even on a single-processor system.
Done. It's the same game, though my version is obviously a port of the original (it ran in monochrome CGA on an x86).
Let me rephrase my question, as apparently I didn't state it clearly enough - Why would a company pay me to write software if they gained no revenue from it?
If it's an application that the company needs internally that's worth paying the entire development cost for, then it will get written. However, that's a pretty steep cost, and if that's the only case in which applications software is produced, a lot of programmers are going to be out of work...
Um, the GPS satellites are way in the heck up in orbit, and don't give a flying leap what date computer systems down here think it is, because they have their own clocks on board (a GPS satellite's *job* is to transmit timing pulses, and that's it). Your GPS will still work, as long as you have batteries for it and nobody fires a box of nails up at the satellite.
Hah.
Power goes out in a typical US power plant. The elctromagnets holding the control rods over the reactor shut off. The reactor stops dead, and can't be restarted until the rods are pulled out again.
You _can_ turn the reactors _off_ if there's a problem. How do you think that they do maintainence on them?
The article didn't mention date rollover in nuclear weapon control systems specifically. Instead, it talked about their response to a wave of catastrophic computer crashes sweeping across the planet. This pretty much spelled out for me the knowledge level of the article's writers' on the subject.
They also mentioned nuclear power plants, stating that they would spontaneously melt down when this wave of devastation hit. Leaving aside the fact that it is extremely hard to make modern nuclear power plants melt down when you are actively trying to do so, the control systems that panic when anything like this happens aren't date-sensitive.
This article would probably make a neat movie, but IMO that's about it.
"And in order to pay them, you are going to have to sell your product."
You have to sell _a_ product. Software will effectively not be the product; sell something else.
Such as?
You can't force people to pay for support contracts. Further, if the source for the software is distributed, they'll get better tech support on newsgroups than most companies are likely to produce.
Software that's developed to serve specific hardware is useful if you're a hardware vendor, but this doesn't help you if you're writing a third-party application.
For applications programming, the software _is_ the product. If that's free, there's nothing left to sell, which means it might as well not be written in the first place from the company's point of view.
By whom? The resulting software must be given away, not sold, so there will be very little in the way of revenue to pay you with.
Free software has many good points, and is especially useful for small projects (that can be handled by one person in their spare time), or for large projects that don't require much coordination and that don't have a deadline (there are many very useful examples of these). If, OTOH, you need a large amount of organized development done within a moderately short length of time, you're going to need to hire full-time programmers. And in order to pay them, you are going to have to sell your product.
The playstatoin is about 10 times faster then a 5,000 visual sgi workstation and only a little bit faster then a indy workstation.
Put these boxes beside each other and run them. To my knowledge, no real, production grade Playstation 2 exists. You can do wonderful things with demo hardware (I seem to recall a few Intel shennanigans in that regard...). This is vapour.
Its true that a $150 kids consule can outperform a $5,000 workstation. GO blame intel for those rediculously over engineered motherborads and [..]
Perhaps you weren't aware of this, but Intel does not make real workstations.
Real workstations are made by companies like Sun, Compaq, HP, and SGI, and are based on Sparc, Alpha, PA-RISC, and MIPS processors, respectively. Intel processors are garbage in workstation-land, and PPC processors aren't much better, I'm afraid. Likewise, real workstations and servers use well-designed motherboards and well-designed bus protocols. Never, ever confuse souped up desktop "workstations" with the real thing.
Now, go to www.spec.org and to the web sites of the manufacturers mentioned, and get specs on some real systems, please.
Oh, and FYI a real workstation costs about $50,000, not $5000.
adaptec for making scsi really expensive video card manufactors for over engineering their cards to make them 10 times as much and 5 times slower then what they could be.
The video cards that are put in PCs are about the same quality as the PCs themselves. For an example of a real video card, go to http://www.3dlabs.com and look at the high-end Oxygen boards.
I couldn't agree with Larry Elison more when he calls pc's mini mainframes.
Architecturally, they are very different. Functionally, they have very different strengths. The best thing to call a PC would be a poor man's workstation, and even that's stretching it. Please research for yourself what "mainframes", "servers", and "workstations" are before blindly believing what your favourite noteworthies tell you.
THink about how fast a mainframe can do graphics and compare that to todays pc's. hmmm they have something in common. Also isdn and scsi are all mainframe based technologies that suck. scsi is actually slower then eidi with non server single user loads. ITs true.
I believe that this demonstrates a complete lack of knowledge about what a graphics workstation is. Please look up the terms described above, and try again.
The short answer to this is "no". Old-fashioned PCI-33 maxes out at 132 MBytes/sec. AGP increases this considerably, but it is still fairly easy to find cases where card performance is limited by the system bus. I have yet to hear of a network connector or external bus that is commonly available that does this (gigabit ethernet and the like are expensive). This means that any scheme that used a Playstation 2 as a rendering box would have serious limits imposed by whatever you're using to connect with it.
That having been said, you get free geometry processing in the Playstation 2, which means that it could very well outperform conventional cards that don't have geometry processing, even when used as a peripheral. OTOH, geometry processing will be on graphics cards Real Soon Now (tm), so the actual usefulness of this is open to question.
Since the PSX-2 supposedly outperforms an SGI InfiniteReality (specced at up to 13 Million poly/second with quad-R10000s)
The key word here is "supposedly". The real numbers, from rumours, are considerably lower than what their marketing department is claiming.
and has it's own geometry engine, the PSX-2 would likely make an inexpensive and hugely capable dedicated graphics engine for a PC.
Possibly. A system with multiple conventional graphics cards may be more efficient at this when the Playstation 2 actually comes out. We'll see.
The advantages of using 2 or more of these boxes in parallel also naturally spring to mind...
Communications with the boxes will be even more of a problem with this than with one box. You will rapidly reach diminishing returns with this, except in very specific cases.
But, really, how much does one of these 50 million polys/sec chips actually cost *today*?
From what I've heard, a 50 million poly/sec chip doesn't exist. Try about an order of magnitude lower than that. That's just the rumour mill, though; we'll see what the specs actually are when it ships.
Graphics cards based on a similar chip would be interesting, at the very least, agreed.
I strongly suspect that it would be more expensive, as it would need extra logic to interface it with the PCI bus and the PC as a whole. It would also be harder for the console makers to make money by charging royalties for media, as piracy would be much easier. Also, you would need a moderately expensive PC to put it in, and would need to either use a video pass-through cable or tie up more bus bandwidth with video output data. You'd also either need a separate controller port on the card, making for additional cabling.
I agree that none of the above is earth-shattering, but I see no advantage to putting the console on a card and several minor disadvantages. You could get better output resolution just by putting a monitor output on a conventional console (though this means either buying another monitor or fiddling with cables when you want to play games).
The above assumes that you have a PC, also. I don't know exactly how large a chunk of the gaming market doesn't use a computer, but I suspect that it is pretty sizeable. Just about everyone has a TV.
I strongly suspect that a fill rate that insane is for flat-shaded untextured polygons, or at best for single-textured polygons. Divide by four for a quad-textured multitextured polygon, or by somewhere between 2 and 8 for a single-textured polygon with trilinear filtering, depending on the conditions and how clever the hardware is.
There's also the question of overdraw. Triangles overlap each other; this is why z-buffering exists. In the worst case, where your polygons are drawn from back to front, you wind up drawing n times as many pixels as are actually displayed, where n is the number of overlapping triangles. Overdraw factor varies widely, as it depends on how much effort the game programmer put into culling algorithms. However, it can be anywhere from about 2 to about 10.
So, at 640x240x60 (or 640x480x30 interlaced), you need to draw about 9.2 million pixels per second. If your overdraw factor is about 3 on average, this means you need a fill rate of about 28 million pixels per second. If you're using dual-textured trilinearly filtered textures with a moderately efficient texturing algorithm, you need a fill rate equivalent to about 220 million non-filtered single-texture pixels per second.
What this says to me in practice is that the Playstation 2 isn't going to be fill-rate limited if it's running on a standard television set. For higher resolutions and less marketing-inflated spec numbers, fill rate may become significant.
In principle, yes. This is in fact done for development boards IIRC. However, in practice, this won't be much more useful or cost-effective than just buying a separate console.
The problem is that a PC's I/O and memory subsystems are relatively lousy. A console (or a real workstation, for that matter) has a highly optimized, very fast, and very wide set of busses connection the various components of the system in a configuration designed to serve the needs of the purpose for which the system is being used (for a console, graphics processing). If you dropped a console's graphics processors on a PCI card and let the CPU handle all other tasks, the system would crawl, because the PC's bus doesn't have the bandwidth to control the hardware effectively. You could stick most of the console components on the card and give it an internal bus with appropriate specs, but then you just have a full console sitting in your PCI slot. There isn't much point.
This is useful for development boards, because it lets you transfer new builds of games to the console and run the console in debug mode, but IMO a gamer would be better off just with the production version of the console and a TV. I'm sure that somebody will figure out how to run home-brewed or pirated games on it in short order, especially with firewire and other ports available for data transfer (boot to a special CD and run the game off of a hard drive).
Uh, I guess you missed the 5 or so mpgs they released? Doesn't look like vaporware to me.
Take a good look at the screen shots and MPEGs. They look nice, yes. They are worth buying a Playstation 2 for? Quite possibly. They need 50^H^H70^H^H20 million polygons per second to render? Not really. Believe marketing specs at your peril. The numbers that I've been hearing floating out of the developer community are quite a bit lower.
We must be talking about different "Spacewar" programs, then.
What program are you referring to?
Put a playstation 2 next to an SGI box and prove this, if you want me to believe it.
An SGI box of equivalent cost, maybe...
The numbers coming out of Sony's marketing division are very overinflated. The screen shots prove otherwise, you say? Take a good look at them and figure out how many polygons you'd need in order to generate something that looks like that. Many, but not *that* many, by between one and two orders of magnitude (even at a decent frame rate).
Turn on anti-aliasing. That is the only thing that a television display gets for free that a monitor doesn't.
Or take off your glasses to get the same effect for free