In a few applications, knowing the specific cache size helps. Core numeric libraries for things like matrix multiplication and factorization use blocked operations with block sizes that are dependent on cache size. Figuring out the best blocking is not straightforward, but what works best for a small cache is usually suboptimal for a larger one.
"Adding more of the same" works only for building bigger classical computers. A 32-bit register can be constructed from 32 individual isolated bits. But for a useful 32-qubit register, you must be able to maintain quantum coherence over the whole ensemble. 32 individual qubits will not suffice.
Even if it's not the case quite yet, it seems plausible that at some point enough will be known to create life. Then it appears to me that you're stuck "playing god". You have power over the existence or nonexistence of the organism, and then doing nothing is just a decision to condemn it to nonexistence. What is ethical is still open, but you will be playing god either way.
When I was in college, my roommate and I wasted many hours playing this game. I only remember two weapons though: torps and phasers. Our typical strategy involved random plinking with torps until one person accidentally ate a string. Then the stronger ship would try to close in and phaser the weaker one to death. Our main goal was to finish the other guy off with a long range phaser. This would result in a "spectacular finish", with the victor's final phaser line connected to the exploding debris from the loser. Of course, chasing after a weakened ship made you vulnerable to playing pacman with a reciprocal string of torps...
I also have a MII and switched from the Xig server to Xfree86. As of version 3.3.3.1 it seems to work very well. In earlier versions I had trouble with an annoying little streak along one side of the screen, but that's been fixed. Also I had problems with 24 bit color depths and don't know if that works, but at 32 bit depth it's fine.
I can understand the perception that there is an internet brain drain, but I don't believe that it's a reality. The perception comes from at least four factors.
What you see happening depends on where you're looking. People reading Slashdot are probably interested in computer-related fields, and they keep track of developments in these areas. Few have any serious knowledge of something like modern agriculture. In my work at Bell Labs, I see plenty of very intelligent people working in non-computer areas such as astronomy or materials science, but even this perspective is skewed towards science and technology.
What constitutes brilliant is not the same in all areas. As a technical type, I tend to admire logical thinking and the ability to reason about complex systems. But for a politician, it is probably more important to have the ability to relate to people, understand alternative viewpoints on a wide range of subjects, fashion compromises, and convince people to pull together.
Since computers are so pliable and the technology moves so fast, it is relatively easy to make sweeping changes quickly. This lends the impression that the people driving the changes are brilliant visionaries. But a great politician can't throw out the government and start from scratch. Want to develop a new automobile powered by fuel cells? You've got to contend with the huge infrastructure designed to support the internal combustion engine, from gas stations to repair shops. As programmers, we also curse the legacy systems that we must contend with. Even the smartest people find it difficult to overcome inertia.
The internet is a very young thing. When anything fundamentally new appears, there is usually a burst of rapid development. You hear about all these smart people doing exciting things. Eventually, most of the "easy" things have been done, progress slows, and you get the impression that all those people have moved on. They're still there, but it's not simple to do something really new anymore. But in a year or two, someone who's been toiling away making only incremental progress will get a great idea, and suddenly all those brilliant people will reappear from thin air.
I'll close with a little anecdotal evidence. The technically smartest people I've known personally are now: a theoretical physicist, a doctor, a musician, a film-maker, a semiconductor device physicist, a CAD researcher, and a manager at an engine manufacturer. I know one person who has founded a wildly successful internet-related company, but I never considered him very astute.
Add a spell-check button to the Post Comment page. I don't want this to be interpreted as a spelling flame, but a post full of mistakes is simply distracting. Perhaps if an automatic check were handy, people would use it.
Where feasible, this sort of "communicating but mostly autonomous" agents model can indeed isolate failures. It applies to software on single systems just as it does to the internet. My computer doesn't crash due when a bug brings down the FTP server; I just lose a little functionality. So why isn't this model used everywhere? Because the complexity of coordinating a collection of agents so that they can robustly accomplish a task is daunting. The distributed programming literature has a long and distinguished history of buggy algorithms, even for such "simple" tasks as mutual exclusion. Something nontrivial like a parallel garbage collector can be fiendishly difficult.
Developing a distributed, fault-tolerant version of any algorithm is much more difficult (and bug prone) than getting the same algorithm working on a single processor. So why bother? To tolerate failures that are viewed as likely. Since failure of a network node is a common event, it's not surprising that networks are designed to handle it. It's not simple though, it's not cheap, and it's not perfect either. Witness the occasional widespread network outages that you read about. Yet another @#!% corner case...
To sum up, you can try to control the chaos, but it requires a lot of extra structure, not a little. Exercising this control is very costly and error-prone. Unless you're trying to guard against failures that are either likely or catastrophic, you're probably better off devoting your resources to getting a "traditional" implementation as bug-free as possible.
Question: For similar levels of complexity, why do software systems typically exhibit many more bugs than (digital) hardware systems?
In my opinion, they don't.
I've heard the "hardware engineers know how to build reliable complex systems" argument numerous times, usually from hardware engineers. But the software they complain about is far more complex than the hardware by several measures.
It requires much more control state to describe the software.
The environment that that the software has to contend with is much less well-defined.
The functionality required of hardware is much less than that required of software.
For a typical digital chip, there is in fact some software which is exactly as complex: the hardware description language code for the chip, and perhaps a cycle-accurate simulator written in something like C. How many bugs are there in these pieces of software? As many as there are in the chip.
A modern CPU may have hundreds of errata, but most go unnoticed. You just don't get many level 3 interrupts while a floating point instruction is stalled waiting for the translation lookaside buffer. Besides, if the problem causes the system to crash, the user will just blame Windows anyway:-P.
The hardware engineer complains "but those are very exceptional conditions..." Exactly, and they're similar to the type of situations that tend unmask software bugs.
People are inherently bad at envisioning corner cases. The digital hardware engineers are lucky in that they at least have a well-defined finite-state abstraction to work with. You can buy commercial tools to help with test generation and state-space exploration. The corresponding tools don't exist for software.
It's true that hardware engineers have to deal with issues such as signal integrity and noise, metal migration, power supply droop, and so on. They generally do a fairly good job on these, but these are all phyiscal issues related to implementing the digital abstraction. As such, they are amenable to the standard engineering practice of giving yourself a little extra margin. If we knew how to easily provide extra margin for discrete behavior, software would be a lot more robust.
The main problem with specialized hardware is that the people building it tend to get run over by the Silicon steamroller.
"After two years of development, we're proud to announce the new HyperAccel 3000 CPU with hardware support for Snobol. It runs at 100MHz and provides a 4x speedup over general purpose processors for Snobol applications. What's that you say? Intel makes 500MHz CPUs now? #@!$"
I'm not saying that the above scenario will happen in this case. It's usually the small outfits who can't afford to keep up that get burned, and Sun isn't that small. Further, in some situations, the speed gain is so large, that even if you use previous generation fabrication, you can still win: witness the 3D graphics market. But you are competing against parts that have enormous sales volumes and all that implies. If it comes down to a chip with Java support that gives a 1.5x speed-up vs. a commodity CPU, I'd bet on the commodity CPU. It will probably be available at 1.5x higher speeds at comparable cost.
"MyGarage Software just announced a JIT compiler that is 1.5x faster than any earlier Java compilers for x86 CPUs? #$@!"
Common Lisp, like Scheme and most other modern Lisp variants, uses static scoping by default. (Though dynamic scoping is available too.) Dynamic scoping is useful in a few cases, but usually just causes problems. More important is that objects have dynamic extent. Features like function closures, continuations, etc., are what make Lisp Lisp. That and the ()'s...
This is so kewl! I can't wait to get one of these babies so that I run Quake at 10000 FPS. And an overclocked dual processor system would be even more AWS0M!!!!!! True there aren't many details in the article, but I'm sure their irreluvant anyway. An if all those clewless researchers working on pushing silicon faster or on the hundreds of alternative new technologies wood just work on this one, we'd get it in only a few years!!!
With such raducl performance, all those complicated MP (massively polynomal) complete problems will be trivial! Imagine finding factors of a Hamiltonian circuit in just seconds!!! Course one of my teachers mumbled something about hyuge speed increases not really helping on MP problems, but that's obviously B0GUZ!!
The bad thing will be that this might keep Microsux with their bloatware in business, but that's OK cuz Linux will rock even more on this puppy. Forget those GNOME vs KDE flamewars; we'll have enough juice to run both at once!
I believe he meant that in many cases, a "random" instance of an NP-complete problem will be relatively easy to solve. As an example, most instances of satisfiability tend to be very simple for any reasonable search procedure. This leads to the occasional newby claim of: "I've proved P=NP! See how fast my program is on these random formulas with 1000 variables!" Getting a hard instance, as required in cryptography applications, requires that you pick very carefully.
Cleaning up netlib would be bad. Already, too many young whippersnappers wouldn't know a FORTRAN compiler if it came up and bit them. And don't get me started about their wanton use of structs and pointers. No sir, if I had my way, all those "universities" teaching C++ and Java would be turning out FORTRAN-IV programmers. And no FORTRAN 77; that's already heading down the road to ruin.
More seriously, I think a lot of the stuff in netlib is actually pretty good. I wish more of it used reverse-call interfaces, but the numerics seem generally more solid than what you find in Numerical Recipes, and the community has definitely gotten a lot of reuse out of it. My current project has 25K lines of FORTRAN (none of which I wrote) and 3K lines of C++.
As for translation problems: extern "C" dgetrf_(...);
Still waiting for a Linux distribution which includes a nice optimized BLAS library...
Speaking as an electronic CAD research person, things like this are very useful. One of the toughest problems, especially for university types, is getting realistic designs for testing purposes. There's a big difference between algorithms that work for small benchmark circuits and those that can handle 100K+ gates, and unless you have good examples, it's easy to fool yourself.
As I read it, you're only paying for one of their surfers to look at your site ASAP. The article explicitly states that the money does not guarantee a good placement.
``Yahoo! is quick to point out that the fee doesn't guarantee placement in the directory -- that's still up to the editors. And even if the site is accepted, the money won't ensure a priority placement in the site, either.''
Slashdot Mirror
a) If you want to be perceived as a hot mover and shaker, you have to live in California
(Note: Real movers and shakers can live anywhere they want
The real movers and shakers in California are the earthquakes. Or maybe I'm just jealous since I live in New Jersey
In a few applications, knowing the specific cache size helps. Core numeric libraries for things like matrix multiplication and factorization use blocked operations with block sizes that are dependent on cache size. Figuring out the best blocking is not straightforward, but what works best for a small cache is usually suboptimal for a larger one.
"Adding more of the same" works only for building bigger classical computers. A 32-bit register can be constructed from 32 individual isolated bits. But for a useful 32-qubit register, you must be able to maintain quantum coherence over the whole ensemble. 32 individual qubits will not suffice.
Even if it's not the case quite yet, it seems plausible that at some point enough will be known to create life. Then it appears to me that you're stuck "playing god". You have power over the existence or nonexistence of the organism, and then doing nothing is just a decision to condemn it to nonexistence. What is ethical is still open, but you will be playing god either way.
You mean there are no lawyers in heaven?
A more informative link is here.
When I was in college, my roommate and I wasted many hours playing this game. I only remember two weapons though: torps and phasers. Our typical strategy involved random plinking with torps until one person accidentally ate a string. Then the stronger ship would try to close in and phaser the weaker one to death. Our main goal was to finish the other guy off with a long range phaser. This would result in a "spectacular finish", with the victor's final phaser line connected to the exploding debris from the loser. Of course, chasing after a weakened ship made you vulnerable to playing pacman with a reciprocal string of torps...
I also have a MII and switched from the Xig server to Xfree86. As of version 3.3.3.1 it seems to work very well. In earlier versions I had trouble with an annoying little streak along one side of the screen, but that's been fixed. Also I had problems with 24 bit color depths and don't know if that works, but at 32 bit depth it's fine.
This is old hat. Why, I already have a single molecule memory. It's even... Now what was I saying? Oh yeah, that slugbot is really neat!
- What you see happening depends on where you're looking. People reading Slashdot are probably interested in computer-related fields, and they keep track of developments in these areas. Few have any serious knowledge of something like modern agriculture. In my work at Bell Labs, I see plenty of very intelligent people working in non-computer areas such as astronomy or materials science, but even this perspective is skewed towards science and technology.
- What constitutes brilliant is not the same in all areas. As a technical type, I tend to admire logical thinking and the ability to reason about complex systems. But for a politician, it is probably more important to have the ability to relate to people, understand alternative viewpoints on a wide range of subjects, fashion compromises, and convince people to pull together.
- Since computers are so pliable and the technology moves so fast, it is relatively easy to make sweeping changes quickly. This lends the impression that the people driving the changes are brilliant visionaries. But a great politician can't throw out the government and start from scratch. Want to develop a new automobile powered by fuel cells? You've got to contend with the huge infrastructure designed to support the internal combustion engine, from gas stations to repair shops. As programmers, we also curse the legacy systems that we must contend with. Even the smartest people find it difficult to overcome inertia.
- The internet is a very young thing. When anything fundamentally new appears, there is usually a burst of rapid development. You hear about all these smart people doing exciting things. Eventually, most of the "easy" things have been done, progress slows, and you get the impression that all those people have moved on. They're still there, but it's not simple to do something really new anymore. But in a year or two, someone who's been toiling away making only incremental progress will get a great idea, and suddenly all those brilliant people will reappear from thin air.
I'll close with a little anecdotal evidence. The technically smartest people I've known personally are now: a theoretical physicist, a doctor, a musician, a film-maker, a semiconductor device physicist, a CAD researcher, and a manager at an engine manufacturer. I know one person who has founded a wildly successful internet-related company, but I never considered him very astute.I highly recommend the above web site.
A useful bulletin board on all aspects of refractive surgery is http://www.americaneye.com/cgi-bin/refractive.pl
Add a spell-check button to the Post Comment page. I don't want this to be interpreted as a spelling flame, but a post full of mistakes is simply distracting. Perhaps if an automatic check were handy, people would use it.
Where feasible, this sort of "communicating but mostly autonomous" agents model can indeed isolate failures. It applies to software on single systems just as it does to the internet. My computer doesn't crash due when a bug brings down the FTP server; I just lose a little functionality. So why isn't this model used everywhere? Because the complexity of coordinating a collection of agents so that they can robustly accomplish a task is daunting. The distributed programming literature has a long and distinguished history of buggy algorithms, even for such "simple" tasks as mutual exclusion. Something nontrivial like a parallel garbage collector can be fiendishly difficult.
Developing a distributed, fault-tolerant version of any algorithm is much more difficult (and bug prone) than getting the same algorithm working on a single processor. So why bother? To tolerate failures that are viewed as likely. Since failure of a network node is a common event, it's not surprising that networks are designed to handle it. It's not simple though, it's not cheap, and it's not perfect either. Witness the occasional widespread network outages that you read about. Yet another @#!% corner case...
To sum up, you can try to control the chaos, but it requires a lot of extra structure, not a little. Exercising this control is very costly and error-prone. Unless you're trying to guard against failures that are either likely or catastrophic, you're probably better off devoting your resources to getting a "traditional" implementation as bug-free as possible.
In my opinion, they don't.
I've heard the "hardware engineers know how to build reliable complex systems" argument numerous times, usually from hardware engineers. But the software they complain about is far more complex than the hardware by several measures.
For a typical digital chip, there is in fact some software which is exactly as complex: the hardware description language code for the chip, and perhaps a cycle-accurate simulator written in something like C. How many bugs are there in these pieces of software? As many as there are in the chip.
A modern CPU may have hundreds of errata, but most go unnoticed. You just don't get many level 3 interrupts while a floating point instruction is stalled waiting for the translation lookaside buffer. Besides, if the problem causes the system to crash, the user will just blame Windows anyway
The hardware engineer complains "but those are very exceptional conditions..." Exactly, and they're similar to the type of situations that tend unmask software bugs.
People are inherently bad at envisioning corner cases. The digital hardware engineers are lucky in that they at least have a well-defined finite-state abstraction to work with. You can buy commercial tools to help with test generation and state-space exploration. The corresponding tools don't exist for software.
It's true that hardware engineers have to deal with issues such as signal integrity and noise, metal migration, power supply droop, and so on. They generally do a fairly good job on these, but these are all phyiscal issues related to implementing the digital abstraction. As such, they are amenable to the standard engineering practice of giving yourself a little extra margin. If we knew how to easily provide extra margin for discrete behavior, software would be a lot more robust.
The main problem with specialized hardware is that the people building it tend to get run over by the Silicon steamroller.
"After two years of development, we're proud to announce the new HyperAccel 3000 CPU with hardware support for Snobol. It runs at 100MHz and provides a 4x speedup over general purpose processors for Snobol applications. What's that you say? Intel makes 500MHz CPUs now? #@!$"
I'm not saying that the above scenario will happen in this case. It's usually the small outfits who can't afford to keep up that get burned, and Sun isn't that small. Further, in some situations, the speed gain is so large, that even if you use previous generation fabrication, you can still win: witness the 3D graphics market. But you are competing against parts that have enormous sales volumes and all that implies. If it comes down to a chip with Java support that gives a 1.5x speed-up vs. a commodity CPU, I'd bet on the commodity CPU. It will probably be available at 1.5x higher speeds at comparable cost.
"MyGarage Software just announced a JIT compiler that is 1.5x faster than any earlier Java compilers for x86 CPUs? #$@!"
Common Lisp, like Scheme and most other modern Lisp variants, uses static scoping by default. (Though dynamic scoping is available too.) Dynamic scoping is useful in a few cases, but usually just causes problems. More important is that objects have dynamic extent. Features like function closures, continuations, etc., are what make Lisp Lisp. That and the ()'s...
Scheme is to Common Lisp as C is to C++...
This is so kewl! I can't wait to get one of these babies so that I run Quake at 10000 FPS. And an overclocked dual processor system would be even more AWS0M!!!!!! True there aren't many details in the article, but I'm sure their irreluvant anyway. An if all those clewless researchers working on pushing silicon faster or on the hundreds of alternative new technologies wood just work on this one, we'd get it in only a few years!!!
With such raducl performance, all those complicated MP (massively polynomal) complete problems will be trivial! Imagine finding factors of a Hamiltonian circuit in just seconds!!! Course one of my teachers mumbled something about hyuge speed increases not really helping on MP problems, but that's obviously B0GUZ!!
The bad thing will be that this might keep Microsux with their bloatware in business, but that's OK cuz Linux will rock even more on this puppy. Forget those GNOME vs KDE flamewars; we'll have enough juice to run both at once!
I believe he meant that in many cases, a "random" instance of an NP-complete problem will be relatively easy to solve. As an example, most instances of satisfiability tend to be very simple for any reasonable search procedure. This leads to the occasional newby claim of: "I've proved P=NP! See how fast my program is on these random formulas with 1000 variables!" Getting a hard instance, as required in cryptography applications, requires that you pick very carefully.
Cleaning up netlib would be bad. Already, too many young whippersnappers wouldn't know a FORTRAN compiler if it came up and bit them. And don't get me started about their wanton use of structs and pointers. No sir, if I had my way, all those "universities" teaching C++ and Java would be turning out FORTRAN-IV programmers. And no FORTRAN 77; that's already heading down the road to ruin.
More seriously, I think a lot of the stuff in netlib is actually pretty good. I wish more of it used reverse-call interfaces, but the numerics seem generally more solid than what you find in Numerical Recipes, and the community has definitely gotten a lot of reuse out of it. My current project has 25K lines of FORTRAN (none of which I wrote) and 3K lines of C++.
As for translation problems: extern "C" dgetrf_(...);
Still waiting for a Linux distribution which includes a nice optimized BLAS library...
Speaking as an electronic CAD research person, things like this are very useful. One of the toughest problems, especially for university types, is getting realistic designs for testing purposes. There's a big difference between algorithms that work for small benchmark circuits and those that can handle 100K+ gates, and unless you have good examples, it's easy to fool yourself.
As I read it, you're only paying for one of their surfers to look at your site ASAP. The article explicitly states that the money does not guarantee a good placement.
``Yahoo! is quick to point out that the fee doesn't guarantee placement in the directory -- that's still up to the editors. And even if the site is accepted, the money won't ensure a priority placement in the site, either.''