Granted, my terminology was a little wrong. Let me try again.
Algebra is required for complex manipulation of symbolic expressions.
Most programming is not complex manipulation of symbolic expressions. Rather, much programming, especially beginning programming, is simple algorithmic design more akin to solving elementary word problems than to solving algebraic expressions.
Consider a bubble sort. It's easy enough that it's been reinvented thousands of times the world over, and the the only math required is an understanding of relational operators. That's hardly the realm of algebra when you're simply laying out evaluation rather than doing complex analysis.
Why? I taught myself BASIC at 7 with an Apple IIgs' built in interpreter- I was a good 5 years from my first Algebra I class at that point.
Algebra is relevant for the manipulation of expressions with variables, but is completely unnecessary for the *evaluation* of expressions with variables, which is what programming really is. Higher math is generally required for complex algorithm creation, but for introductory programming assignments it's really unnecessary.
He was specifically talking about LANL and LLNL rather than ORNL.. that was the entire point.
Granted, yes, his description of disallowing classified non-classified connectivity as "ludicrous" is a little off-base, although writing things down by hand really is stupid- there are plenty of procedures in place for putting data on transportable media and then arranging to declassify that media once it has been verified so that it can be used elsewhere.
That doesn't change his fundamental points, though, that there are larger computing clusters that are locked up in classified nuclear simulation that could (and perhaps should) be used for more general science.
The problem with this is that there are actually two solutions.
You're arguing that security vulnerabilities should just (potentially, potentially not) cause crashes in the hope that this gets them fixed faster. However, you should be aware that not all such bugs actually cause immediate crashes- some just corrupt state. You're also arguing, effectively, for leaving the vulnerability there until it is fixed.
The other option is to sandbox things so that it doesn't matter if there's a vulnerability- if the process is correctly sandboxed, unless there's an OS bug that would allow privilege escalation, nothing can be exploited.
You're basically saying "let's try to make these problems more obvious so they get fixed faster". A properly written process model is saying "let's acknowledge that such bugs may always exist, and prevent them from harming anything at a higher level".
You cannot so isolate threads without effectively making them separate processes. If the threads *can* write into other memory, then there is the danger that broken code *will* do so. What code you write doesn't matter in the least- get a dangling pointer and you'll be writing to something random, which may very well be some other thread's memory space. If the OS doesn't enforce the isolation, you effectively have no isolation.
No code is perfect. The process model is an acknowledgement of that fact. When it comes to plugins, the code is third-party- adobe, etc. Do you really want the stability of the browser as a whole to depend on third-party code?
You acknowledge the security vulnerability possibility, but you seem to be missing that the process model is an example of the sort of sandboxing that is precisely appropriate for limiting the impact of those vulnerabilities. Given sufficient OS-level control, in fact, you could run plugins in subprocesses specifically barred from touching any other portion of the system- that's precisely the sort of the risk-mitigation that we want browsers to be moving toward.
I certainly agree that the process model as currently implemented continues to have some efficiency issues, and the incompleteness of its implementation wrt chrome reusing process and the like impairs or removes some of its benefits. But I'm not sure how it can be held that the segregation and robustness benefits are actually downsides, as you seem to be saying- if Flash crashes or hangs due to a broken flash app, I'd really rather not lose the email I'm writing in another tab.
Ahh... that's the entire point. Multiprocess models are generally an acknowledgement of the fact that there are problems, and a way to mitigate their effect.
If you're running 3rd-party code inside your memory space in a thread (read: plugins) there is nothing you can do to prevent that code from trashing your process. The only solution is to isolate the resources they have access to by sticking them into a separate process.
In addition, it is *very* easy for bugs to make cause errors in shared data structures that end up corrupting the memory space for all threads. This is also true if you're using shared memory across processes, for that matter- if one process using the shared memory goes down, the entire shared memory must be considered suspect and trashed unless you've got some protected way of verifying/correcting it.
IPC over pipes or the like, with strict and correct validation of the messages passed there, is really the only way to correctly sandbox separate processes that want to work together yet be immune from non-local faults. Even then, if the processes have any sort of dependencies (children on a manager process, for instance) there may not be anything you can do to avoid a global failure if the dependency's target fails.
Yes, but the amount of market share held by each browser will generally not be divided evenly- there will always be a clear market leader, then a succession of browsers with increasingly small shares.
If you think about it, the "market" for linux distributions is similar. Which is leading changes reasonably often, but at any given time there's generally a couple very strong distributions and then a very long tail of niche ones.
I don't have any issue with anyone applying it to Obama as well. He was a relative unknown, and that certainly has bearing on how one can look at him. Personally, I think he's had opportunity since then to make up for that- and I think that even a casual investigation of his credentials turns up a reasonable array of experience- but if you don't agree with me on that point, I'm okay with that too.
Regardless of who you're talking about, reputation (or lack thereof) has some importance. Ignoring that is simply ignoring a source of information. Sure, it has to be tempered by other information sources- but it shouldn't be completely ignored. Whoever your candidate of choice is.
Oh, the joys of people who don't read and think about entire posts before responding.
First, anyone investigating operating systems *would* have heard of Linus already, so the point is already moot.
Even assuming that they hadn't, however, even trivial research would turn up a large amount of information about him- which is directly related to my second point (the rapid acquisition of knowledge about someone suddenly thrust onto such a stage).
So, overall- your point has absolutely nothing to do with what I'm actually saying.
I didn't say that being relatively unheard of was necessarily bad. It does indicate things about the person, however, and denying that (regardless of who you're talking about) is simply silly.
You also completely failed to respond to my point that someone's background is researched rather rapidly once they come under the political spotlight. Consider it open source in action in politics- with so many eyes, everything's bound to come out.
So, yes, I am in fact being rational. You'll also note that I didn't actually make any comments either way about any political candidate in my post. Nor have I in this one. I'm merely pointing out that rapid decisions are not necessarily invalid, and that ignoring the fact that someone is a relative unknown is throwing away *potentially* useful information about them. I never said it was bad- please quote me if you think I did.
Ahh.. not having heard of someone before an election is, in fact, reason to make some assumptions about the individual's qualifications. In addition, once someone comes onto the political stage, a reasonable background information packet is assembled quite rapidly- so the fact that someone hasn't been heard of prior to the current political environment is hardly enough, by itself, to preclude people from forming rapid (and often accurate) opinions about the individual.
But that doesn't help your quest to label people as "group-think"-ers and idiots. Sorry. Is my rationality interfering with your political agenda?
Autovectorization does a pretty good job of boosting performance, though it's not all actually vectorizable (too many cases and branches). It is pretty much all numeric- a mixture of integer and floating point.
Dedicated hardware is definitely not workable; the algorithms are in pretty much constant flux - it's a research application, so a lot of what's going on is testing new algorithms, or tweaking existing ones.
Memory management is extremely minimal, by design (malloc and free aren't cheap). A chunk of data is read from the DB, a block of memory is allocated for results to be written into, and then various algorithms look at various parts of the big chunk and produce output; the DB is only hit for new data about once every hour per process (the whole thing is massively parallelizable on an extremely coarse-grained level, so we usually have well over a dozen independent processes running to split up the work- throwing more hardware at the problem is definitely something that's slowly happening, but that doesn't change the need for optimal code to reduce the amount of hardware that needs to be used).
Assembly language is possible, of course, but the portions of the algorithms that don't change all that often and are therefore good candidates for assembly language tuning are also the portions that we get very good results from with just the compiler; the effort to move them to assembly language wouldn't get us sufficient benefit to be worth it. Oh- we're using LLVM as our compiler, which gave us a pretty decent speed boost.
We're constantly profiling the app, tweaking algorithms for performance. New algorithms are surely written to *work* first and to be optimized second- but given that we know it's going to need that optimization, there's really no point to starting the write in anything other than c++.
There's a core dataset. A piece of that dataset is loaded, and then a set of about 30 individual algorithms are run on that dataset; they in turn produce additional data.
Once those algorithms are done, another set of algorithms runs on pieces of the data that the first set produced, and produces new data
Once *those* are done, another tier of the same happens, producing final results.
The only code that cannot be considered "tight loop" is the outer framework code that sets up the data structures and then calls the various algorithmic bits, and the code that interacts with the database. That together isn't more than a couple thousand lines of code.
The project basically entails calling a set of algorithms repeatedly on many, many, many different sets of data, and then aggregating and analyzing the results.
Rewriting in another language, and then managing a multi-language application, is itself nontrivial.
Consider, for instance, a research application I'm currently working on. 95% of the code is extremely performance critical- every "run" takes 2 to 4 weeks of computer time. Dealing with multi-language complexities just to write the other 5% in something other than C++ would be stupid. Most changes between runs are either adding additional algorithms that run in a performance-critical fashion, or tweaking existing portions- the framework changes rarely, if ever.
The "premature optimization is the root of all evil" comment has a very specific limitation- it corresponds to low-level optimization. There's a lot of performance considerations that happen at the design and algorithmic level, and when you're initially contemplating the design for a project it is often obvious from the outset which pieces are going to be performance critical. Writing them in something other than a performance conscious language is just wasting your time.
I did because Comcast is the only service provider in my area, and OpenDNS actually provides better DNS reliability than Comcast's DNS servers. The switch was actually driven by a Comcast DNS outage.
Uh, no, not really. Especially when driven by specific profiling. I've gotten some pretty serious gains in tight loops on modern hardware with intelligent unrolling. If you've got stuff organized properly to stream out of memory and into the processor, you can get rid of pipeline stalls and significantly improve throughput for certain classes of loops.
Are you serious? XML is great for certain applications, but the one thing it *isn't* is fast. It's very believable that something like this could be an order of magnitude faster.
I'll take the benefits of Google supporting open source over "GSoC is evil" paranoia.
If Google suddenly decides to stop hosting these, or touches them in some fashion, it's going to get discovered and fixed in well under 24 hours. Google hosting a file like this means that there are going to be a *lot* of eyes on the file.
Google is, as it currently stands, far from "dangerous to the health of the web". Outside of using their webmail fairly heavily, I could avoid using google quite easily- as could any other web user. Many websites are more dependent on them due to Google being their source of income, but the fact that Google has effectively created a niche for small websites to live in can hardly be viewed as a negative.
Re-read it again without the bias that complexity begets quality.
Sure, you can compare it with the books you mentioned and find a more complex structure in each of them. Complexity does not automatically imply quality, however, and while those three books are certainly historic works, that does nothing to indicate anything about Ender's Game.
Calling it "trash" as a result merely indicates a literary snob and doesn't do anything to invalidate its quality.
Particle systems are about as perfectly a parallel problem as it's possible to get- and not only that, the calculations are generally very straightforward with few (if any) general CPU control structures (branches, loops, etc).
As a result, the massively parallel hardware on a GPU that exists to render many triangles/pixels/shader programs/etc at once can be exploited to calculate updates for many particles at once. The CPU is at an inherent disadvantage because it is only leveraging a small subset of it's full capabilities.
The CPU is very good at *lots* of different tasks. The GPU is phenomenally good at a very specific set of tasks. Physics just happens to fit within that set.
Much of the point of a laptop is so that you can take it to places that aren't necessarily properly designed work environments.
Yes, in perfect lighting conditions, glossy screens are wonderful. If you have a laptop that you take around to places that actually exist in the real world, though- without those perfect lighting conditions- then they're suddenly not so wonderful and I'll take my matte screen over them any day.
This is true to some extent, but raster will never completely go away- there are situations where raster is completely appropriate.
For instance, modern GUIs often use the 3d hardware to handle window transforms, blending and placement. These are fundamentally polygonal objects for which triangle transformation and rasterization is a perfectly appropriate tool and ray tracing would be silly.
The current polygon model will never vanish completely, even if high-end graphics eventually go to ray tracing instead.
I don't (and wasn't trying to) deny that PC gaming can be a bit more expensive than console gaming; the advantage is that you can do other things with the device. The point is that the extreme price differential mentioned, or silly "requirements" to participate, are nothing but FUD.
You can take a standard PC, $1000, and spend $200-$300 tops giving it a good video card- and have a very competent gaming platform for several years. Yes, the upgrade cycle is faster than a console generation- but then, old consoles start looking very dated in comparison by the end of their cycle, whereas the computer can stay quite competent. I've got a $200 graphics card, still AGP, and a first generation athalon64 processor in the windows computer I game on- and it works just fine.
There are definitely advantages to consoles, including (as you note) the removal of Windows and compatibility related hassles. But this extreme price difference is simply BS if you take what you would spend on a console and spend that much *more* on a PC than you otherwise might, you'll have a very competent gaming platform.
As someone still quite enjoying PC gaming, I've got to take issue with "now requires a $1200 piece of graphics technology just to participate". You can play modern games on some very inexpensive hardware just fine. Yes, you *can* spend $1200 on graphics alone, easily, but the vast majority of us, I think, realize the futility of it.
Tech like quad-SLI is there for people with more money than sense, or at least more money than they know what to do with- and at that point, fine, if they want to spend that money and basically support the graphics companies' development costs, let them. The rest of us can continue as we have, working with normally-priced hardware that does everything we need it to. No, we can't play the latest games at 200 FPS on a 30" monitor with everything turned on- but then again, most of us don't even *have* 30" monitors, so... who cares?
Slashdot Mirror
Granted, my terminology was a little wrong. Let me try again.
Algebra is required for complex manipulation of symbolic expressions.
Most programming is not complex manipulation of symbolic expressions. Rather, much programming, especially beginning programming, is simple algorithmic design more akin to solving elementary word problems than to solving algebraic expressions.
Consider a bubble sort. It's easy enough that it's been reinvented thousands of times the world over, and the the only math required is an understanding of relational operators. That's hardly the realm of algebra when you're simply laying out evaluation rather than doing complex analysis.
Why? I taught myself BASIC at 7 with an Apple IIgs' built in interpreter- I was a good 5 years from my first Algebra I class at that point.
Algebra is relevant for the manipulation of expressions with variables, but is completely unnecessary for the *evaluation* of expressions with variables, which is what programming really is. Higher math is generally required for complex algorithm creation, but for introductory programming assignments it's really unnecessary.
You, sir, can't read.
He was specifically talking about LANL and LLNL rather than ORNL.. that was the entire point.
Granted, yes, his description of disallowing classified non-classified connectivity as "ludicrous" is a little off-base, although writing things down by hand really is stupid- there are plenty of procedures in place for putting data on transportable media and then arranging to declassify that media once it has been verified so that it can be used elsewhere.
That doesn't change his fundamental points, though, that there are larger computing clusters that are locked up in classified nuclear simulation that could (and perhaps should) be used for more general science.
The problem with this is that there are actually two solutions.
You're arguing that security vulnerabilities should just (potentially, potentially not) cause crashes in the hope that this gets them fixed faster. However, you should be aware that not all such bugs actually cause immediate crashes- some just corrupt state. You're also arguing, effectively, for leaving the vulnerability there until it is fixed.
The other option is to sandbox things so that it doesn't matter if there's a vulnerability- if the process is correctly sandboxed, unless there's an OS bug that would allow privilege escalation, nothing can be exploited.
You're basically saying "let's try to make these problems more obvious so they get fixed faster". A properly written process model is saying "let's acknowledge that such bugs may always exist, and prevent them from harming anything at a higher level".
You cannot so isolate threads without effectively making them separate processes. If the threads *can* write into other memory, then there is the danger that broken code *will* do so. What code you write doesn't matter in the least- get a dangling pointer and you'll be writing to something random, which may very well be some other thread's memory space. If the OS doesn't enforce the isolation, you effectively have no isolation.
No code is perfect. The process model is an acknowledgement of that fact. When it comes to plugins, the code is third-party- adobe, etc. Do you really want the stability of the browser as a whole to depend on third-party code?
You acknowledge the security vulnerability possibility, but you seem to be missing that the process model is an example of the sort of sandboxing that is precisely appropriate for limiting the impact of those vulnerabilities. Given sufficient OS-level control, in fact, you could run plugins in subprocesses specifically barred from touching any other portion of the system- that's precisely the sort of the risk-mitigation that we want browsers to be moving toward.
I certainly agree that the process model as currently implemented continues to have some efficiency issues, and the incompleteness of its implementation wrt chrome reusing process and the like impairs or removes some of its benefits. But I'm not sure how it can be held that the segregation and robustness benefits are actually downsides, as you seem to be saying- if Flash crashes or hangs due to a broken flash app, I'd really rather not lose the email I'm writing in another tab.
Ahh... that's the entire point. Multiprocess models are generally an acknowledgement of the fact that there are problems, and a way to mitigate their effect.
If you're running 3rd-party code inside your memory space in a thread (read: plugins) there is nothing you can do to prevent that code from trashing your process. The only solution is to isolate the resources they have access to by sticking them into a separate process.
In addition, it is *very* easy for bugs to make cause errors in shared data structures that end up corrupting the memory space for all threads. This is also true if you're using shared memory across processes, for that matter- if one process using the shared memory goes down, the entire shared memory must be considered suspect and trashed unless you've got some protected way of verifying/correcting it.
IPC over pipes or the like, with strict and correct validation of the messages passed there, is really the only way to correctly sandbox separate processes that want to work together yet be immune from non-local faults. Even then, if the processes have any sort of dependencies (children on a manager process, for instance) there may not be anything you can do to avoid a global failure if the dependency's target fails.
Yes, but the amount of market share held by each browser will generally not be divided evenly- there will always be a clear market leader, then a succession of browsers with increasingly small shares.
If you think about it, the "market" for linux distributions is similar. Which is leading changes reasonably often, but at any given time there's generally a couple very strong distributions and then a very long tail of niche ones.
I don't have any issue with anyone applying it to Obama as well. He was a relative unknown, and that certainly has bearing on how one can look at him. Personally, I think he's had opportunity since then to make up for that- and I think that even a casual investigation of his credentials turns up a reasonable array of experience- but if you don't agree with me on that point, I'm okay with that too.
Regardless of who you're talking about, reputation (or lack thereof) has some importance. Ignoring that is simply ignoring a source of information. Sure, it has to be tempered by other information sources- but it shouldn't be completely ignored. Whoever your candidate of choice is.
/sigh
Oh, the joys of people who don't read and think about entire posts before responding.
First, anyone investigating operating systems *would* have heard of Linus already, so the point is already moot.
Even assuming that they hadn't, however, even trivial research would turn up a large amount of information about him- which is directly related to my second point (the rapid acquisition of knowledge about someone suddenly thrust onto such a stage).
So, overall- your point has absolutely nothing to do with what I'm actually saying.
I didn't say that being relatively unheard of was necessarily bad. It does indicate things about the person, however, and denying that (regardless of who you're talking about) is simply silly.
You also completely failed to respond to my point that someone's background is researched rather rapidly once they come under the political spotlight. Consider it open source in action in politics- with so many eyes, everything's bound to come out.
So, yes, I am in fact being rational. You'll also note that I didn't actually make any comments either way about any political candidate in my post. Nor have I in this one. I'm merely pointing out that rapid decisions are not necessarily invalid, and that ignoring the fact that someone is a relative unknown is throwing away *potentially* useful information about them. I never said it was bad- please quote me if you think I did.
Ahh.. not having heard of someone before an election is, in fact, reason to make some assumptions about the individual's qualifications. In addition, once someone comes onto the political stage, a reasonable background information packet is assembled quite rapidly- so the fact that someone hasn't been heard of prior to the current political environment is hardly enough, by itself, to preclude people from forming rapid (and often accurate) opinions about the individual.
But that doesn't help your quest to label people as "group-think"-ers and idiots. Sorry. Is my rationality interfering with your political agenda?
Autovectorization does a pretty good job of boosting performance, though it's not all actually vectorizable (too many cases and branches). It is pretty much all numeric- a mixture of integer and floating point.
Dedicated hardware is definitely not workable; the algorithms are in pretty much constant flux - it's a research application, so a lot of what's going on is testing new algorithms, or tweaking existing ones.
Memory management is extremely minimal, by design (malloc and free aren't cheap). A chunk of data is read from the DB, a block of memory is allocated for results to be written into, and then various algorithms look at various parts of the big chunk and produce output; the DB is only hit for new data about once every hour per process (the whole thing is massively parallelizable on an extremely coarse-grained level, so we usually have well over a dozen independent processes running to split up the work- throwing more hardware at the problem is definitely something that's slowly happening, but that doesn't change the need for optimal code to reduce the amount of hardware that needs to be used).
Assembly language is possible, of course, but the portions of the algorithms that don't change all that often and are therefore good candidates for assembly language tuning are also the portions that we get very good results from with just the compiler; the effort to move them to assembly language wouldn't get us sufficient benefit to be worth it. Oh- we're using LLVM as our compiler, which gave us a pretty decent speed boost.
We're constantly profiling the app, tweaking algorithms for performance. New algorithms are surely written to *work* first and to be optimized second- but given that we know it's going to need that optimization, there's really no point to starting the write in anything other than c++.
Yes, actually.
Structure is something like this:
There's a core dataset. A piece of that dataset is loaded, and then a set of about 30 individual algorithms are run on that dataset; they in turn produce additional data.
Once those algorithms are done, another set of algorithms runs on pieces of the data that the first set produced, and produces new data
Once *those* are done, another tier of the same happens, producing final results.
The only code that cannot be considered "tight loop" is the outer framework code that sets up the data structures and then calls the various algorithmic bits, and the code that interacts with the database. That together isn't more than a couple thousand lines of code.
The project basically entails calling a set of algorithms repeatedly on many, many, many different sets of data, and then aggregating and analyzing the results.
Rewriting in another language, and then managing a multi-language application, is itself nontrivial.
Consider, for instance, a research application I'm currently working on. 95% of the code is extremely performance critical- every "run" takes 2 to 4 weeks of computer time. Dealing with multi-language complexities just to write the other 5% in something other than C++ would be stupid. Most changes between runs are either adding additional algorithms that run in a performance-critical fashion, or tweaking existing portions- the framework changes rarely, if ever.
The "premature optimization is the root of all evil" comment has a very specific limitation- it corresponds to low-level optimization. There's a lot of performance considerations that happen at the design and algorithmic level, and when you're initially contemplating the design for a project it is often obvious from the outset which pieces are going to be performance critical. Writing them in something other than a performance conscious language is just wasting your time.
I did because Comcast is the only service provider in my area, and OpenDNS actually provides better DNS reliability than Comcast's DNS servers. The switch was actually driven by a Comcast DNS outage.
Uh, no, not really. Especially when driven by specific profiling. I've gotten some pretty serious gains in tight loops on modern hardware with intelligent unrolling. If you've got stuff organized properly to stream out of memory and into the processor, you can get rid of pipeline stalls and significantly improve throughput for certain classes of loops.
Are you serious? XML is great for certain applications, but the one thing it *isn't* is fast. It's very believable that something like this could be an order of magnitude faster.
I'll take the benefits of Google supporting open source over "GSoC is evil" paranoia.
If Google suddenly decides to stop hosting these, or touches them in some fashion, it's going to get discovered and fixed in well under 24 hours. Google hosting a file like this means that there are going to be a *lot* of eyes on the file.
Google is, as it currently stands, far from "dangerous to the health of the web". Outside of using their webmail fairly heavily, I could avoid using google quite easily- as could any other web user. Many websites are more dependent on them due to Google being their source of income, but the fact that Google has effectively created a niche for small websites to live in can hardly be viewed as a negative.
Re-read it again without the bias that complexity begets quality.
Sure, you can compare it with the books you mentioned and find a more complex structure in each of them. Complexity does not automatically imply quality, however, and while those three books are certainly historic works, that does nothing to indicate anything about Ender's Game.
Calling it "trash" as a result merely indicates a literary snob and doesn't do anything to invalidate its quality.
Particle systems are about as perfectly a parallel problem as it's possible to get- and not only that, the calculations are generally very straightforward with few (if any) general CPU control structures (branches, loops, etc).
As a result, the massively parallel hardware on a GPU that exists to render many triangles/pixels/shader programs/etc at once can be exploited to calculate updates for many particles at once. The CPU is at an inherent disadvantage because it is only leveraging a small subset of it's full capabilities.
The CPU is very good at *lots* of different tasks. The GPU is phenomenally good at a very specific set of tasks. Physics just happens to fit within that set.
Much of the point of a laptop is so that you can take it to places that aren't necessarily properly designed work environments.
Yes, in perfect lighting conditions, glossy screens are wonderful. If you have a laptop that you take around to places that actually exist in the real world, though- without those perfect lighting conditions- then they're suddenly not so wonderful and I'll take my matte screen over them any day.
This is true to some extent, but raster will never completely go away- there are situations where raster is completely appropriate.
For instance, modern GUIs often use the 3d hardware to handle window transforms, blending and placement. These are fundamentally polygonal objects for which triangle transformation and rasterization is a perfectly appropriate tool and ray tracing would be silly.
The current polygon model will never vanish completely, even if high-end graphics eventually go to ray tracing instead.
And if you'd read the post it was a response to, you'd see that it was a perfectly germane response to a comment about SATA.
Way to miss the point.
I don't (and wasn't trying to) deny that PC gaming can be a bit more expensive than console gaming; the advantage is that you can do other things with the device. The point is that the extreme price differential mentioned, or silly "requirements" to participate, are nothing but FUD.
You can take a standard PC, $1000, and spend $200-$300 tops giving it a good video card- and have a very competent gaming platform for several years. Yes, the upgrade cycle is faster than a console generation- but then, old consoles start looking very dated in comparison by the end of their cycle, whereas the computer can stay quite competent. I've got a $200 graphics card, still AGP, and a first generation athalon64 processor in the windows computer I game on- and it works just fine.
There are definitely advantages to consoles, including (as you note) the removal of Windows and compatibility related hassles. But this extreme price difference is simply BS if you take what you would spend on a console and spend that much *more* on a PC than you otherwise might, you'll have a very competent gaming platform.
As someone still quite enjoying PC gaming, I've got to take issue with "now requires a $1200 piece of graphics technology just to participate". You can play modern games on some very inexpensive hardware just fine. Yes, you *can* spend $1200 on graphics alone, easily, but the vast majority of us, I think, realize the futility of it.
Tech like quad-SLI is there for people with more money than sense, or at least more money than they know what to do with- and at that point, fine, if they want to spend that money and basically support the graphics companies' development costs, let them. The rest of us can continue as we have, working with normally-priced hardware that does everything we need it to. No, we can't play the latest games at 200 FPS on a 30" monitor with everything turned on- but then again, most of us don't even *have* 30" monitors, so... who cares?