That's because we don't attack the root causes of the abuse, nor do we draw a line of distinction about which of us are more genetically or adaptively susceptible to them.
Prisons aren't the answer. Rehab helps. Good jobs help.
You can't make meth and blow safe. Legalizing them condemns to death and abyss, many people that need protection.
But you don't speak about the abyss of drug addiction, the income-sapping expense, the parents of kids that forget parenting while doing drugs, the accidents on the freeway, the madness of things like meth addiction and its incredible debilitating affects on the body.
Or how the drug cartels live in lawlessness just below the border in muderous droves.
Correlation != causation. There are data that suggest that a moist climate can bring about autism, or at least many came from most climates. My brother has autism sprectral disorder. Yes, we lived in a climate with 44+ inches of rain a year. So? I think a number of my family members going back generations had touches of Aspbergers. Is it in the genes? Can autism changes to the brain be triggered somehow, or by something?
Do we know if the MMR vaccine has quality control problems? That maybe there's more to the MMR than what it's supposed to prevent? Do we know any of this stuff?
No. We do not. It's sadly anecdotal except that we know more about ASD than ever before, in terms of post-diagnosis treatment. But because it's a spectral disorder, there are many conditions and variants to consider.
I had the measles. Both kinds. Didn't die. Mumps? Yes. No after-effects. But a classmate of mine had the mumps and nearly died; lost vision and hearing, and subsequently had lots of cardio issues to deal with from a damaged heart. Rubella? Haven't heard of a case in years. But I gave MMRs to both my children. They turned out ok. What might happen if I had a different batch? Dunno. Currently, the science behind all of this is very immature.
I vote for MMRs and additional research on all of the issues, especially drug dose QA and QC.
I believe that Shanghai and the i7 multicores were built more with hypervisors, rather than clusters, in mind. Tho I'm loathe to cite Sun's cluster model and have even more difficulty with some of their processor architectures, I see their multicores as going down a more astute track.
There are other cache semaphoring techniques and instruction pipeline optimization possibilities, but it's the compiler that gets it right-- or not. I wish aloud for a compiler analyzer that can take various constructs (like as was done in the old 'Lifeboat' days) and examine objects for optimizations and executions--> and importantly, states.
Cell CPUs also intrigue me a lot.... but the thread between us is now long. Dinner knows no wait states where I live.
Multiple memory controllers are ok, if they satisfy the problem of eliminating bottle necks.
Memristors and better FSB technology could help, see above.
Multiplexed memory is intriguing, as are memory bus architectures that eliminate bottlenecks or achieve more rapid cache coherency and less state dependency in multi-core constructions.
Gamers? Given the current nature of games, multi-player games suffer the most from I/O bandwidth problems. In terms of rendering, so as to aid player decision making process, it would seem that pseudoephedrine is really important. Just kidding.
Data mining or large table processing/joins/rendering is a somewhat linear process, and while supercomputing components helps, there are lots of optimizations yet to be squeezed in db activity. It's a whole other subject, fraught with fanbois and architectural whizzes/bigots.
From an interdisciplinary perspective, I still hold that given current dimensionality, crossbar arrays with high speed interconnects are the most productive and reliable without changing lots of thinking.
You've made a good description of the variants in traditional state-dependent (Von Neumann) problem solving, although various parallelisms are the crux of the problem, and that's where multi-cores tend to bottleneck. Cross-bar relationships certainly beat the bottlenecks that are inherent to current multi-core designs. Everything is subject to the slave of the clock.
Once dimensionality is conquered, supercomputing becomes even more interesting, IMHO. I like how GPUs can be slaved to each other, even though instruction and cache coherency problems aren't solved to any degree of fun yet.
Multi-threading, however, is really more of an applied concept, and begins to achieve multi-dimensionality in ways that make my clocks clang. I wait longingly for CPU designers to step outside of the box even farther, then destroy the box as we know it. But that's rather abstract; until then, I spend a good part of my time cutting through vendor propaganda crap in search of optimizations and the reality of CPU/GxPU/DSP offerings, only to then be thwarted by the next announcement.
Certainly sales efforts are justified. But it's what the machine does, rather than its esoteric facade, that makes a difference. CEOs like Lambo looks. Nerds understand that it's how much you can actually productively crunch that makes the difference. Gimme crunch, as the aesthetics are somewhat meaningless. These are computers.
The problem with multicores relates to the fact that the cores are processors, but the relationship to other cores and to memory aren't fully 'cross-bar'. Sun did a multi-CPU architecture that's truly crossbar (meaning that there are no dirty cache problems and semaphor latencies) among the processors, but the machine was more of a technical achievement than a decent workhorse to use in day to day stuff.
Still, cores are cores. More cores aren't better necessarily until you fix what they describe. And it doesn't matter what they look like at all. Like any other system, it's what's under the hood that count. Esoteric-looking shells are there for marketing purposes and cost-justification.
Unless a code set is monolithic, it has to interact with other components. Maintenance and audit mandates basic documentation. Those that eschew it aren't really programmers, because that's part of the job. Instead, they're really good artists, creative people, and not industrial professionals that understand they're part of a larger process. Part of the lone wolf contingent of coders and hackers will always refuse to be a part of the discipline required to work and play well with others. It's been this way since I started using computers 42 years ago. It hasn't changed. Corporate excellence? No, 'plays well with others'. Doing that requires submission to the processes needed by others and being both courageous and disciplined enough to do so.
Playing the machine can be done in many ways. Some of them are safe and sane, others edgy, and clearly, some stupid. You have to demonstrate the difference and be willing to submit to scrutinize your code. Otherwise, in a way, you're like how Microsoft used to be-- ranging from the sloppiest rush jobs ever written to fabulous code with no method to judge the underlying difference until the object blew to pieces. Fie.
There's some truth to your logic. Productivity is key. Using components and techniques that enable productivity are good steps. Solving problems at the possible sacrifice of audit, scrutiny, and even safety aren't good ideas, however. I don't believe in slowing people down for bureaucracy sake. And I believe that some coders are basally more productive. Identifying them is good, but the basics of standards, QA checks, review, and audit are still necessary, and perhaps even mandated by law.
We all want the best for the moneys spent. But incredible coders that pass quality audits are still necessary; I've seen any number that don't, but sure look good on the surface.
Excellence can be determined in various ways, often through documentation, the great allergen of programmers. If you can't explain it, it isn't really done.
The benchmarks can also be defined as well. They need to be met. Make the bars well known, and what must be done to meet them.
There are great references for auditors, too. Feeling a little pain, are you? Had to throw in the grammar nazi reference?
No, these are not diametrically opposed views. You have to step outside the box to understand its dimensions, or lack thereof.
We've seen a Window-izing of Linux for a long time that amount to parallel development efforts undertaken under the aegis of different values and development animals, but they both still walk like a duck.
Fortunately, the need for ducks is high. But we have to see beyond what's currently here. The basic principals go back to Unix and PARC SmallTalk and iPCs/RPCs, and variations on that theme. Hardware gets cheaper, and coders get sloppier. This cycle's been going on for four decades now. I yearn for something that breaks the model, gives state machine computing a run for its money, and really challenges how we think.
A cute FA in some ways, but bereft of content. Wish there was something to see here, like comparisons regarding integrity, access costs, evolution from JFS and Andrews journaled FS, etc. No real meat (with apologies to the vegetarians out there). Just a lightweight historical analysis with some glib suggestions of current adaptations.
No, there is a profound ideological disagreement that needs to be vetted. There's an RMS viewpoint, the purist of 'free', the various GPLs, and the concept of what open source should mean and how it gets used. There's another, looser definition, and the motives of many, many coders and users.
It's not wise to trivialize the differences, as they represent motivations and a bucketload of resulting efforts.
We all want to catch the rocket. There's no doubt that like after the various terrorist incidents, there'll be management that are unprepared to stanch loses and will go belly up.
I didn't say that the stock markets are recovering, either, It'll be wild and wooly for a while. Then it will get better. In the US, where I'm from, retailers that were in trouble before are still in trouble. Fundamentals say that if you don't meet market demands with value, and you throttle back cash flows, you're toast in this economy. Actually that's every economy-- but this one needs lubrication and some fuel.
There is a smidgen of truth in some lies. But the whole of his/her post bears the mark of doom and gloom that isn't there. Yes, there'll be 'interesting times' in the 'Chinese Curse" sense. But we lived through them before, when Geo Bush The Elder left office, in 1996, 2000, 2001, and now. We'll get through it. The sky-is-falling mentality is obnoxious and needed addressing. Best of luck with fixing up your income to match what will become more and more inflation. Prices are unlikely to go down; I just went to the market were my favorite crackers have doubled in price since July. Perhaps they were loss-leaders then, but I doubt it.
Didn't read the parent list, did you?
Of course not.
That's because we don't attack the root causes of the abuse, nor do we draw a line of distinction about which of us are more genetically or adaptively susceptible to them.
Prisons aren't the answer. Rehab helps. Good jobs help.
You can't make meth and blow safe. Legalizing them condemns to death and abyss, many people that need protection.
To some extent, yes.
And sugar.
And Diet Coke.
And Krispy Kreme donuts.
You have to draw the line somewhere; I'm not sure it's correctly drawn right now.
I'll agree that there's a profit motive.
But you don't speak about the abyss of drug addiction, the income-sapping expense, the parents of kids that forget parenting while doing drugs, the accidents on the freeway, the madness of things like meth addiction and its incredible debilitating affects on the body.
Or how the drug cartels live in lawlessness just below the border in muderous droves.
Correlation != causation. There are data that suggest that a moist climate can bring about autism, or at least many came from most climates. My brother has autism sprectral disorder. Yes, we lived in a climate with 44+ inches of rain a year. So? I think a number of my family members going back generations had touches of Aspbergers. Is it in the genes? Can autism changes to the brain be triggered somehow, or by something?
Do we know if the MMR vaccine has quality control problems? That maybe there's more to the MMR than what it's supposed to prevent? Do we know any of this stuff?
No. We do not. It's sadly anecdotal except that we know more about ASD than ever before, in terms of post-diagnosis treatment. But because it's a spectral disorder, there are many conditions and variants to consider.
I had the measles. Both kinds. Didn't die. Mumps? Yes. No after-effects. But a classmate of mine had the mumps and nearly died; lost vision and hearing, and subsequently had lots of cardio issues to deal with from a damaged heart. Rubella? Haven't heard of a case in years. But I gave MMRs to both my children. They turned out ok. What might happen if I had a different batch? Dunno. Currently, the science behind all of this is very immature.
I vote for MMRs and additional research on all of the issues, especially drug dose QA and QC.
I believe that Shanghai and the i7 multicores were built more with hypervisors, rather than clusters, in mind. Tho I'm loathe to cite Sun's cluster model and have even more difficulty with some of their processor architectures, I see their multicores as going down a more astute track.
There are other cache semaphoring techniques and instruction pipeline optimization possibilities, but it's the compiler that gets it right-- or not. I wish aloud for a compiler analyzer that can take various constructs (like as was done in the old 'Lifeboat' days) and examine objects for optimizations and executions--> and importantly, states.
Cell CPUs also intrigue me a lot.... but the thread between us is now long. Dinner knows no wait states where I live.
I'm with you until the last paragraph. It's the reason why crossbar relationships overcome the dirty inter-core state machine.
Nonetheless, you argue well for NUMA-- except that the HPC seems to still have cache thrash. An exchange for another day, perhaps.
Multiple memory controllers are ok, if they satisfy the problem of eliminating bottle necks.
Memristors and better FSB technology could help, see above.
Multiplexed memory is intriguing, as are memory bus architectures that eliminate bottlenecks or achieve more rapid cache coherency and less state dependency in multi-core constructions.
Gamers? Given the current nature of games, multi-player games suffer the most from I/O bandwidth problems. In terms of rendering, so as to aid player decision making process, it would seem that pseudoephedrine is really important. Just kidding.
Data mining or large table processing/joins/rendering is a somewhat linear process, and while supercomputing components helps, there are lots of optimizations yet to be squeezed in db activity. It's a whole other subject, fraught with fanbois and architectural whizzes/bigots.
From an interdisciplinary perspective, I still hold that given current dimensionality, crossbar arrays with high speed interconnects are the most productive and reliable without changing lots of thinking.
You've made a good description of the variants in traditional state-dependent (Von Neumann) problem solving, although various parallelisms are the crux of the problem, and that's where multi-cores tend to bottleneck. Cross-bar relationships certainly beat the bottlenecks that are inherent to current multi-core designs. Everything is subject to the slave of the clock.
Once dimensionality is conquered, supercomputing becomes even more interesting, IMHO. I like how GPUs can be slaved to each other, even though instruction and cache coherency problems aren't solved to any degree of fun yet.
Multi-threading, however, is really more of an applied concept, and begins to achieve multi-dimensionality in ways that make my clocks clang. I wait longingly for CPU designers to step outside of the box even farther, then destroy the box as we know it. But that's rather abstract; until then, I spend a good part of my time cutting through vendor propaganda crap in search of optimizations and the reality of CPU/GxPU/DSP offerings, only to then be thwarted by the next announcement.
'Cause it's crunching on their hardware, not yours. Easy in, easy out. Stay if you want. Don't feed the Microsoft Monster. That's why, chiefly.
Certainly sales efforts are justified. But it's what the machine does, rather than its esoteric facade, that makes a difference. CEOs like Lambo looks. Nerds understand that it's how much you can actually productively crunch that makes the difference. Gimme crunch, as the aesthetics are somewhat meaningless. These are computers.
Look are deceptive.
The problem with multicores relates to the fact that the cores are processors, but the relationship to other cores and to memory aren't fully 'cross-bar'. Sun did a multi-CPU architecture that's truly crossbar (meaning that there are no dirty cache problems and semaphor latencies) among the processors, but the machine was more of a technical achievement than a decent workhorse to use in day to day stuff.
Still, cores are cores. More cores aren't better necessarily until you fix what they describe. And it doesn't matter what they look like at all. Like any other system, it's what's under the hood that count. Esoteric-looking shells are there for marketing purposes and cost-justification.
That mentality is just what virus writers are looking for.
We would disagree.
Unless a code set is monolithic, it has to interact with other components. Maintenance and audit mandates basic documentation. Those that eschew it aren't really programmers, because that's part of the job. Instead, they're really good artists, creative people, and not industrial professionals that understand they're part of a larger process. Part of the lone wolf contingent of coders and hackers will always refuse to be a part of the discipline required to work and play well with others. It's been this way since I started using computers 42 years ago. It hasn't changed. Corporate excellence? No, 'plays well with others'. Doing that requires submission to the processes needed by others and being both courageous and disciplined enough to do so.
Playing the machine can be done in many ways. Some of them are safe and sane, others edgy, and clearly, some stupid. You have to demonstrate the difference and be willing to submit to scrutinize your code. Otherwise, in a way, you're like how Microsoft used to be-- ranging from the sloppiest rush jobs ever written to fabulous code with no method to judge the underlying difference until the object blew to pieces. Fie.
There's some truth to your logic. Productivity is key. Using components and techniques that enable productivity are good steps. Solving problems at the possible sacrifice of audit, scrutiny, and even safety aren't good ideas, however. I don't believe in slowing people down for bureaucracy sake. And I believe that some coders are basally more productive. Identifying them is good, but the basics of standards, QA checks, review, and audit are still necessary, and perhaps even mandated by law.
We all want the best for the moneys spent. But incredible coders that pass quality audits are still necessary; I've seen any number that don't, but sure look good on the surface.
Fools trade quantity for quality. Productivity without regimen isn't cost-effective in the end run.
To wit:
Excellence can be determined in various ways, often through documentation, the great allergen of programmers. If you can't explain it, it isn't really done.
The benchmarks can also be defined as well. They need to be met. Make the bars well known, and what must be done to meet them.
There are great references for auditors, too. Feeling a little pain, are you? Had to throw in the grammar nazi reference?
Sorry dude.
She's a real person. There's a little too much mythos and drama sometimes about that fact, but yeah, she's real.
On the other hand, so are you, despite your AC status.
No, these are not diametrically opposed views. You have to step outside the box to understand its dimensions, or lack thereof.
We've seen a Window-izing of Linux for a long time that amount to parallel development efforts undertaken under the aegis of different values and development animals, but they both still walk like a duck.
Fortunately, the need for ducks is high. But we have to see beyond what's currently here. The basic principals go back to Unix and PARC SmallTalk and iPCs/RPCs, and variations on that theme. Hardware gets cheaper, and coders get sloppier. This cycle's been going on for four decades now. I yearn for something that breaks the model, gives state machine computing a run for its money, and really challenges how we think.
Cite your source, then cite where US corporations pay more than other countries (Germany, Japan, France) do in aggregate annual dollars.
Mod parent up. Even Karl Rove can do better than that.
A cute FA in some ways, but bereft of content. Wish there was something to see here, like comparisons regarding integrity, access costs, evolution from JFS and Andrews journaled FS, etc. No real meat (with apologies to the vegetarians out there). Just a lightweight historical analysis with some glib suggestions of current adaptations.
No, there is a profound ideological disagreement that needs to be vetted. There's an RMS viewpoint, the purist of 'free', the various GPLs, and the concept of what open source should mean and how it gets used. There's another, looser definition, and the motives of many, many coders and users.
It's not wise to trivialize the differences, as they represent motivations and a bucketload of resulting efforts.
We all want to catch the rocket. There's no doubt that like after the various terrorist incidents, there'll be management that are unprepared to stanch loses and will go belly up.
I didn't say that the stock markets are recovering, either, It'll be wild and wooly for a while. Then it will get better. In the US, where I'm from, retailers that were in trouble before are still in trouble. Fundamentals say that if you don't meet market demands with value, and you throttle back cash flows, you're toast in this economy. Actually that's every economy-- but this one needs lubrication and some fuel.
There is a smidgen of truth in some lies. But the whole of his/her post bears the mark of doom and gloom that isn't there. Yes, there'll be 'interesting times' in the 'Chinese Curse" sense. But we lived through them before, when Geo Bush The Elder left office, in 1996, 2000, 2001, and now. We'll get through it. The sky-is-falling mentality is obnoxious and needed addressing. Best of luck with fixing up your income to match what will become more and more inflation. Prices are unlikely to go down; I just went to the market were my favorite crackers have doubled in price since July. Perhaps they were loss-leaders then, but I doubt it.