Some things we just can't segregate, such as the name cache. Shared locks only modestly improve performance but it's still a whole lot better than what you get with an exclusive lock.
What is the challenge with the namecache, specifically? If its due to being LRU then there are approaches to mitigate the lock. A buffering approach like this Java cache batch updates to avoid lock contention. Another technique is to take a random sample to be probabilistically LRU, like Redis does.
S3 bought NumberNine, which was a pioneer in high-end 2D graphics. I bet S3 has a large enough patent portfolio to have some beneficial defensive patents.
As a nit, many algorithms that seem fundamentally linear can, in fact, be parallelized. A classic stack (last-in, first-out) seems strict since there is a single point of contention (the top of the stack). However, using an elimination technique allows entries to be transfered between the consumer and producer without updating the stack and thereby supporting concurrent exchanges. Similarly a tree is often used for maintaining sorted order (e.g. red-black) but concurrent alternatives like skip-lists provide similar characteristics. Another low-level example is an LRU cache where every access mutates the eviction order can be made concurrent by using an eventual consistency model to delay updates until required (e.g. writes). As these algorithms are worked out by experts who resolve their bugs prior, often times consumers of the libraries just need to use them with some cases needing to be aware of what can be done safely/atomically.
At an application-level, while many problems cannot be parallelized, Gustafson's Law provides an answer to Amdahl's dilemma. While the speed-up of a single user request is limited, the number of user requests increase and these can be performed in parallel (task parallelism).
So there are quite a number of opportunities even for problems that seem fundamentally linear and that customers/developers can get for free.
As an outsider, that isn't what I see. AMD has bought most of its core technology rather than designing it from scratch. The K6 was from NexGen, the bus from DEC (Socket A, HyperTransport), the Athlon was a great traditional design (P6/Alpha/PowerPC-like in ideas), the memory controller experience came from Alpha hires, their embedded chip is based on Cyrix's, etc. AMD has been quite good at taking proven ideas and implementing them for the mass market with a lot of success. The primary innovations they are given credit for is the memory controller on x86 (first done Transmetta Crusoe), HyperTransport (DEC), and multi-core (IBM Power).
Intel always seemed to be an innovative company that heavily funds R&D, but can have utter flops by not being pragmatic enough to drop a bad design. While they fail badly, the ideas are usually quite unique and I'm sure educational. The fact that they recover rather than repeatedly making bad calls (e.g. Sun) shows that they are resilliant. Having the different design teams probably helps to both recover from a flop and not corrupt creativity by allowing groups to go into different directions. As you indicate, though, there are only so many good ideas and the duplication has to be extremely frustrating.
So I'm not sure if Intel's approach is bad and they tend to be more innovative than AMD. Its costly, though, and as a consumer I've happily gone with AMD/Cyrix/etc when Intel pushes a flop chip.
Then you might like "Algorithm Design" (2008). Its a superior, imno, but has slightly less coverage with better depth. My personal favorite algorithm book is "The Art of Multiprocessor Programming".
HyperTransport is also from DEC, or Alpha Technologies Inc. to be more specific. It was called LightningTransport and developed for the EV8 microprocessor.
There are a number of differences, if I understand Python's giant lock approach correctly. They have basically adopted the threading model used in most early, single-processor operating systems (e.g. Linux, FreeBSD) where the system calls are protected by a shared lock. This works fine for single-processors, since multiple processes are implicitly serialized by task switching. However, as multiple processes run concurrently in hardware this immediately shows performance issues.
Java's synchronized keyword is a user-level mutex and not a single shared lock across the entire JVM. This means that data structures like HashMaps can use lock-splitting across buckets, or that threads executing independant code flows are not serialized across a single mutex boundary. With Java-5's support for CAS operations, more powerful locks and concurrency data structures are available. I have executed thousands of threads in a distributed master-worker fashion and, due to elegant lock semantics, have not suffered any performance issues due to synchronization. This means that Java is quite strong at both multi-core systems (where there are only a few CPUs) and distributed systems (where there are many).
I am personally a fan of an actor model (e.g. Erlang) for application developers and a lock model (e.g. C, Java) for infrastructure developers. I do not believe that the actor model works efficently enough to be used at the guts of a system, such as caches, where performance is critical. These are special areas that need a skilled hand, meaning that a lock model should be used sparingly in favor of an actor approach. This has been adopted for quite a long time, as message-based (queues) models are fairly standard in most large, distributed service-based applications.
GNU/HURD isn't Linux. It is an utter failure of an OS kernel and was always more about hype by the FSF - they really didn't put much effort into it. Perhaps because Stallman couldn't write it in ELisp.;)
Remember that Minix-3 was a fairly recent update of v2.0, which was completed in the late 80s. Minux is still a joy to work with as a programmer, but well past its time for being used as a standard OS. Its perfect for classrooms and learning kernel programming. You'd probably enjoy programming against it than Linux, for example. It was never intended, and effort was made to ensure it wasn't allowed, to be extended and used for real-world. The complexity to make it fully featured would destroy its simplicity and student projects that make it ideal for education.
PLINQ and the new C# threading APIs are quite interesting and should be fun to play with. I'm a little concerned with the focus on parallel loops, which are often abused in C++'s OpenMP because people don't understand the cost tradeoff. A simple loop isn't worth the expense, and a more complex loop may have data dependancies (e.g. a[i] = a[i]*a[i-1]) which the compiler won't flag for you. I could easily see C# developers, new to concurrent programming, greatly abusing this new construct.
I really like Java's util.concurrent, which I view as trading the focus on granularity for extremely well designed framework libraries. I have written a lot of concurrent code with it quite effectively and when needing to similating a parallel mapping function, it was perhaps only twice as long as your example. I was able to write, for example, a distributed lock free master-worker framework using the Java libraries, which I later expanded to implement Map-Reduce (for fun - took just two nights). The new Fork-Join framework for JDK6 (integrated into JDK7) is fairly impressive, though daunting in complexity.
I'm not totally convinced that locks and shared memory should be entirely hidden. There's many cases where real-world infrustructure code is written in a highly concurrent manner, and I'll have to play with Erlang a lot more before I'm ready to say that it can be dropped from that area of the stack. I've met too many Erlang enthusiasts who don't understand the slightest bit about concurrency, though in Erlang, that's also the point.
While software folks may not understand the hardware world, its quite sad that hardware folks rarely understand the software side as well. One of the most challenging jobs, which gets little attention, is software-hardware codesign. Those applications, like Cadence VLSI suite, are quite challenging as they require EE expertise to implement features while software mastery to develop the product. This results in very advanced, but also very cryptic, software stacks.
I don't think open source hardware is too interesting or valuable, but I really hope software developers will feel comfortable enough to begin reading through HDL code just like they do their favorite open source project. Verilog/VHDL are both fairly old languages, though capable of doing some absolutely amazing tasks (I was in awe the first time I compiled my VHDL chip into a VLSI layout). It would be a really great to see language gurus apply the same innovative spirit towards modernizing HDL languages as they currently do in trying out different techniques in software languages (Haskell, Erlang, etc).
They don't explain why, as a previous card holder, I should go back. I held the original card from 1999 (my first card, when leaving for college) until a few weeks ago when my replacement (non-branded version) came. The only difference I see so far is a less attractive card and that they switched from MBNA (now BoA) to US Bank for the United States. Since they failed for years to actually donate the funds contributed, the most satasfaction I got out of the card was when a waitress would complement that it was cute.
On their website, they gloss over the past and don't offer a reason why I should trust them again. I'm inclined to believe that new management will help ensure proactive measures are taken, but I'm also tempted to go reward some other charity.
Perhaps you shouldn't focus on the big-name companies, but on small/medium sized companies with strong growth. In those companies, HR is just a basic filter to get people in the door to talk to the engineers. There are still misses, but more due to a mismatch of skills/experience than incompitence. Overall, I'd say HR brings in the right candidates and we filter to those we want.
If you want a shot, you can apply at my employer (Rearden Commerce). If you'd prefer, you can email me your resume and I'll submit it directly.
BSD developers don't complain, but in fact see it as a compliment. Their philosophy is that the license promotes the distribution of good code. (And if you have ever worked as a developer, then you'd know that by and large, good code is rare)
I have seen GPL supporters whine and pretend that somehow BSD code in proprietary systems is suddenly no longer free. There was quite a bit of FUD by the FSF regarding FreeBSD, claiming that the FreeBSD Foundation could go private and leave companies locked in. This was of course when FreeBSD was seen as more mature than Linux, and we had the SVLUG making quite a number of outlandish stunts trying to get Linux publicity. So many GPL supporters are pretty well known for publically stating their beliefs are better and all others are simply wrong.
Please remember, leaching to you is a compliment to others. Some of us enjoy doing good work and simply want to be appreciated for it (aka the Beer license).
In that case, then that's a win for Intel. You never get equivilant performance clock-for-clock for a laptop and a desktop part. If you take the same generation laptop AMD chip and clock rate, you'll find C2D outperforms it.
I wouldn't go as far on that conclusion based on the 4x4. Like I said previously, the reason AMD's owns the 4+ server market is due to the system bus, not processor. Intel's 4-core processors simply don't get enough bandwidth, although I believe the first generation were not equipped with the dual Xeon system bus.
Regardless, Intel has shown that it can deliver against their technology roadmap and its quite an impressive line-up. AMD's processor developments have stumbled repeatedly, and their next generation is more of a refinement. AMD is also not a company of innovation, but licenses instead, unlike Intel. The P4/Itanium were very innovative but massive mistakes, but Intel always recovers beautifully. I think AMD can compete if they follow a "system of cores" approach, license specialized cores, and provide a more customized product for the markets. By being heavily standards-based and supporting 3rd-party core developers, AMD could do to the CPU what WebServices have done to the Internet.
I was simply providing more depth, whether it supported your argument or not.
If I remember correctly, 4x4 refered to 4-cores and 4-GPUs in SLI mode. Its supposed to target the high-end gamer, but in reality is just overkill. It was mostly a marketing stunt.
* Core2 is a wider processor, so there are more free functional units available. * SMT can vary with implementations. For instance, IBM's Power6 basically gets the SMT promise. * The P4 was designed to scale to 10+ GHz, but the designers expected too much from processing technology. As the dynamic power increases with frequency, and with power/heat becoming the bottleneck, the P4 wasn't able to achieve its promise. If it had, its HT implementation would have been fairly decent for the architecture.
* On die memory controller: Transmeta Crusoe was the first x86 compatable chip to have one. * Embedded GPU: Cyrix' MediaGX was meant to be the first consumer system-on-a-chip platform and had integrated video.
AMD's 4+ way systems only keep up because the CPUs aren't starved due to HyperTransport.
Intel has stayed on a shared bus for price-performance reasons. This method worked great for the consumer and low-end server market, but really hampered Itanium. With CSI, its clear that Intel thinks a p2p bus now makes sense for all markets.
AMD licensed the EV6 shared bus from DEC, but staying on it would have kept then busy trying to make it scale. Instead they licensed HyperTransport from Alpha Processor Inc (basically DEC), which has let them spend their energies on processor design.
AMD 4x4 is a marketing hack and utterly useless outside of their brochures.
Wow, that's so utterly wrong. You write contracts against methods, and thus express in the code explicitly the method's intent. This makes it easier to refactor because the code is clearer and the callers can't abuse it. You have an easier time refactoring this type of code because you know it is correct. And its easier to test after you've refactored because it won't hide bugs by spitting out wrong answers, but instead make them known. People who put the tiny amount required will have enough pride in their work to make their code clear, simple, and beautiful.
But if you think that argument checking is too much design effort and XP is all about slinging code, then I'm damn glad I don't work with you. I've seen to much crappy code and new frameworks written to replace old ones because the poor programming practices seeped out and corrupted more and more code. Contracts promote clean, robust code.
The fact is DbC isn't used because most programmers don't act like professionals. They program lazily, spitting out just enough to get past QA and leaving suttle bugs for the next group to deal with. They get so caught up with designing that they treat coding as the ugly step child, allowing it to get hidious. They forget that code is the design, hence bad code infects and creates a bad design. If programmers treated their profession with respect and took pride in their work, something as simple as DbC wouldn't create an almost unanimious response of rejection.
My comment argues on a slight tangent of yours, because you don't specifiy whether you agree with Gates regarding the H1-B program. The majority of complaints against root in the fact that the H1-B visa program is used to depress wages and maintain an artificial shortage by constantly expiring the working rights of experienced foriegners. If the program was done away with and competition was purely against traditional immigration, the uproar would rapidly die down. The brain drain is good for this country and would only cause concern for the worst in our profession, if that.
We are fully in agreement that immigration of qualified, exceptional people is a positive. However I've seen too many engineers that I've respected forced to leave. I've also seen discrimation towards native born Americans by those who immigrated, rose to management, and only hire foriegn staff despite cost and qualifications. I am more than happy to compete against a smart foriegner (and even happier to work beside him), but I strongly dislike what the H1-B program does to this country.
The two flaws in your argument are that (1) these individuals would not have had the opportunities to create as successful ventures in their home countries and (2) H1-B forces experienced professionals to leave the states and thus become even greater competition. They will start companies, accept outsourced jobs, or teach the next generation. These two reasons are exactly why we should foster full immigration rather than arm competing nations with skilled labor we forced back home. Instead, we accept the lowest skilled blindly (illegal) and reject the highly skilled (H1-B).
Slashdot Mirror
Some things we just can't segregate, such as the name cache. Shared locks only modestly improve performance but it's still a whole lot better than what you get with an exclusive lock.
What is the challenge with the namecache, specifically? If its due to being LRU then there are approaches to mitigate the lock. A buffering approach like this Java cache batch updates to avoid lock contention. Another technique is to take a random sample to be probabilistically LRU, like Redis does.
S3 bought NumberNine, which was a pioneer in high-end 2D graphics. I bet S3 has a large enough patent portfolio to have some beneficial defensive patents.
As a nit, many algorithms that seem fundamentally linear can, in fact, be parallelized. A classic stack (last-in, first-out) seems strict since there is a single point of contention (the top of the stack). However, using an elimination technique allows entries to be transfered between the consumer and producer without updating the stack and thereby supporting concurrent exchanges. Similarly a tree is often used for maintaining sorted order (e.g. red-black) but concurrent alternatives like skip-lists provide similar characteristics. Another low-level example is an LRU cache where every access mutates the eviction order can be made concurrent by using an eventual consistency model to delay updates until required (e.g. writes). As these algorithms are worked out by experts who resolve their bugs prior, often times consumers of the libraries just need to use them with some cases needing to be aware of what can be done safely/atomically.
At an application-level, while many problems cannot be parallelized, Gustafson's Law provides an answer to Amdahl's dilemma. While the speed-up of a single user request is limited, the number of user requests increase and these can be performed in parallel (task parallelism).
So there are quite a number of opportunities even for problems that seem fundamentally linear and that customers/developers can get for free.
As an outsider, that isn't what I see. AMD has bought most of its core technology rather than designing it from scratch. The K6 was from NexGen, the bus from DEC (Socket A, HyperTransport), the Athlon was a great traditional design (P6/Alpha/PowerPC-like in ideas), the memory controller experience came from Alpha hires, their embedded chip is based on Cyrix's, etc. AMD has been quite good at taking proven ideas and implementing them for the mass market with a lot of success. The primary innovations they are given credit for is the memory controller on x86 (first done Transmetta Crusoe), HyperTransport (DEC), and multi-core (IBM Power).
Intel always seemed to be an innovative company that heavily funds R&D, but can have utter flops by not being pragmatic enough to drop a bad design. While they fail badly, the ideas are usually quite unique and I'm sure educational. The fact that they recover rather than repeatedly making bad calls (e.g. Sun) shows that they are resilliant. Having the different design teams probably helps to both recover from a flop and not corrupt creativity by allowing groups to go into different directions. As you indicate, though, there are only so many good ideas and the duplication has to be extremely frustrating.
So I'm not sure if Intel's approach is bad and they tend to be more innovative than AMD. Its costly, though, and as a consumer I've happily gone with AMD/Cyrix/etc when Intel pushes a flop chip.
Sorry, it's "Algorithm Design Manual" by Skiena (2008).
Then you might like "Algorithm Design" (2008). Its a superior, imno, but has slightly less coverage with better depth. My personal favorite algorithm book is "The Art of Multiprocessor Programming".
HyperTransport is also from DEC, or Alpha Technologies Inc. to be more specific. It was called LightningTransport and developed for the EV8 microprocessor.
There are a number of differences, if I understand Python's giant lock approach correctly. They have basically adopted the threading model used in most early, single-processor operating systems (e.g. Linux, FreeBSD) where the system calls are protected by a shared lock. This works fine for single-processors, since multiple processes are implicitly serialized by task switching. However, as multiple processes run concurrently in hardware this immediately shows performance issues.
Java's synchronized keyword is a user-level mutex and not a single shared lock across the entire JVM. This means that data structures like HashMaps can use lock-splitting across buckets, or that threads executing independant code flows are not serialized across a single mutex boundary. With Java-5's support for CAS operations, more powerful locks and concurrency data structures are available. I have executed thousands of threads in a distributed master-worker fashion and, due to elegant lock semantics, have not suffered any performance issues due to synchronization. This means that Java is quite strong at both multi-core systems (where there are only a few CPUs) and distributed systems (where there are many).
I am personally a fan of an actor model (e.g. Erlang) for application developers and a lock model (e.g. C, Java) for infrastructure developers. I do not believe that the actor model works efficently enough to be used at the guts of a system, such as caches, where performance is critical. These are special areas that need a skilled hand, meaning that a lock model should be used sparingly in favor of an actor approach. This has been adopted for quite a long time, as message-based (queues) models are fairly standard in most large, distributed service-based applications.
GNU/HURD isn't Linux. It is an utter failure of an OS kernel and was always more about hype by the FSF - they really didn't put much effort into it. Perhaps because Stallman couldn't write it in ELisp. ;)
Remember that Minix-3 was a fairly recent update of v2.0, which was completed in the late 80s. Minux is still a joy to work with as a programmer, but well past its time for being used as a standard OS. Its perfect for classrooms and learning kernel programming. You'd probably enjoy programming against it than Linux, for example. It was never intended, and effort was made to ensure it wasn't allowed, to be extended and used for real-world. The complexity to make it fully featured would destroy its simplicity and student projects that make it ideal for education.
PLINQ and the new C# threading APIs are quite interesting and should be fun to play with. I'm a little concerned with the focus on parallel loops, which are often abused in C++'s OpenMP because people don't understand the cost tradeoff. A simple loop isn't worth the expense, and a more complex loop may have data dependancies (e.g. a[i] = a[i]*a[i-1]) which the compiler won't flag for you. I could easily see C# developers, new to concurrent programming, greatly abusing this new construct.
I really like Java's util.concurrent, which I view as trading the focus on granularity for extremely well designed framework libraries. I have written a lot of concurrent code with it quite effectively and when needing to similating a parallel mapping function, it was perhaps only twice as long as your example. I was able to write, for example, a distributed lock free master-worker framework using the Java libraries, which I later expanded to implement Map-Reduce (for fun - took just two nights). The new Fork-Join framework for JDK6 (integrated into JDK7) is fairly impressive, though daunting in complexity.
I'm not totally convinced that locks and shared memory should be entirely hidden. There's many cases where real-world infrustructure code is written in a highly concurrent manner, and I'll have to play with Erlang a lot more before I'm ready to say that it can be dropped from that area of the stack. I've met too many Erlang enthusiasts who don't understand the slightest bit about concurrency, though in Erlang, that's also the point.
While software folks may not understand the hardware world, its quite sad that hardware folks rarely understand the software side as well. One of the most challenging jobs, which gets little attention, is software-hardware codesign. Those applications, like Cadence VLSI suite, are quite challenging as they require EE expertise to implement features while software mastery to develop the product. This results in very advanced, but also very cryptic, software stacks.
I don't think open source hardware is too interesting or valuable, but I really hope software developers will feel comfortable enough to begin reading through HDL code just like they do their favorite open source project. Verilog/VHDL are both fairly old languages, though capable of doing some absolutely amazing tasks (I was in awe the first time I compiled my VHDL chip into a VLSI layout). It would be a really great to see language gurus apply the same innovative spirit towards modernizing HDL languages as they currently do in trying out different techniques in software languages (Haskell, Erlang, etc).
They don't explain why, as a previous card holder, I should go back. I held the original card from 1999 (my first card, when leaving for college) until a few weeks ago when my replacement (non-branded version) came. The only difference I see so far is a less attractive card and that they switched from MBNA (now BoA) to US Bank for the United States. Since they failed for years to actually donate the funds contributed, the most satasfaction I got out of the card was when a waitress would complement that it was cute.
On their website, they gloss over the past and don't offer a reason why I should trust them again. I'm inclined to believe that new management will help ensure proactive measures are taken, but I'm also tempted to go reward some other charity.
Perhaps you shouldn't focus on the big-name companies, but on small/medium sized companies with strong growth. In those companies, HR is just a basic filter to get people in the door to talk to the engineers. There are still misses, but more due to a mismatch of skills/experience than incompitence. Overall, I'd say HR brings in the right candidates and we filter to those we want.
If you want a shot, you can apply at my employer (Rearden Commerce). If you'd prefer, you can email me your resume and I'll submit it directly.
ben_manes at yahoo dot com
http://www.linkedin.com/in/benmanes
BSD developers don't complain, but in fact see it as a compliment. Their philosophy is that the license promotes the distribution of good code. (And if you have ever worked as a developer, then you'd know that by and large, good code is rare)
I have seen GPL supporters whine and pretend that somehow BSD code in proprietary systems is suddenly no longer free. There was quite a bit of FUD by the FSF regarding FreeBSD, claiming that the FreeBSD Foundation could go private and leave companies locked in. This was of course when FreeBSD was seen as more mature than Linux, and we had the SVLUG making quite a number of outlandish stunts trying to get Linux publicity. So many GPL supporters are pretty well known for publically stating their beliefs are better and all others are simply wrong.
Please remember, leaching to you is a compliment to others. Some of us enjoy doing good work and simply want to be appreciated for it (aka the Beer license).
In that case, then that's a win for Intel. You never get equivilant performance clock-for-clock for a laptop and a desktop part. If you take the same generation laptop AMD chip and clock rate, you'll find C2D outperforms it.
I wouldn't go as far on that conclusion based on the 4x4. Like I said previously, the reason AMD's owns the 4+ server market is due to the system bus, not processor. Intel's 4-core processors simply don't get enough bandwidth, although I believe the first generation were not equipped with the dual Xeon system bus.
Regardless, Intel has shown that it can deliver against their technology roadmap and its quite an impressive line-up. AMD's processor developments have stumbled repeatedly, and their next generation is more of a refinement. AMD is also not a company of innovation, but licenses instead, unlike Intel. The P4/Itanium were very innovative but massive mistakes, but Intel always recovers beautifully. I think AMD can compete if they follow a "system of cores" approach, license specialized cores, and provide a more customized product for the markets. By being heavily standards-based and supporting 3rd-party core developers, AMD could do to the CPU what WebServices have done to the Internet.
I was simply providing more depth, whether it supported your argument or not.
If I remember correctly, 4x4 refered to 4-cores and 4-GPUs in SLI mode. Its supposed to target the high-end gamer, but in reality is just overkill. It was mostly a marketing stunt.
* Core2 is a wider processor, so there are more free functional units available.
* SMT can vary with implementations. For instance, IBM's Power6 basically gets the SMT promise.
* The P4 was designed to scale to 10+ GHz, but the designers expected too much from processing technology. As the dynamic power increases with frequency, and with power/heat becoming the bottleneck, the P4 wasn't able to achieve its promise. If it had, its HT implementation would have been fairly decent for the architecture.
* On die memory controller: Transmeta Crusoe was the first x86 compatable chip to have one.
* Embedded GPU: Cyrix' MediaGX was meant to be the first consumer system-on-a-chip platform and had integrated video.
AMD's 4+ way systems only keep up because the CPUs aren't starved due to HyperTransport.
Intel has stayed on a shared bus for price-performance reasons. This method worked great for the consumer and low-end server market, but really hampered Itanium. With CSI, its clear that Intel thinks a p2p bus now makes sense for all markets.
AMD licensed the EV6 shared bus from DEC, but staying on it would have kept then busy trying to make it scale. Instead they licensed HyperTransport from Alpha Processor Inc (basically DEC), which has let them spend their energies on processor design.
AMD 4x4 is a marketing hack and utterly useless outside of their brochures.
Hmm. Well, I take that back now that he can finally handle the bandwidth and his blog isn't riddled with ads.
Perhaps the editors could have taken the slides from the source, rather than an opportunistic blogger who couldn't handle the bandwidth?
Tech Session
PDF slides
Wow, that's so utterly wrong. You write contracts against methods, and thus express in the code explicitly the method's intent. This makes it easier to refactor because the code is clearer and the callers can't abuse it. You have an easier time refactoring this type of code because you know it is correct. And its easier to test after you've refactored because it won't hide bugs by spitting out wrong answers, but instead make them known. People who put the tiny amount required will have enough pride in their work to make their code clear, simple, and beautiful.
But if you think that argument checking is too much design effort and XP is all about slinging code, then I'm damn glad I don't work with you. I've seen to much crappy code and new frameworks written to replace old ones because the poor programming practices seeped out and corrupted more and more code. Contracts promote clean, robust code.
The fact is DbC isn't used because most programmers don't act like professionals. They program lazily, spitting out just enough to get past QA and leaving suttle bugs for the next group to deal with. They get so caught up with designing that they treat coding as the ugly step child, allowing it to get hidious. They forget that code is the design, hence bad code infects and creates a bad design. If programmers treated their profession with respect and took pride in their work, something as simple as DbC wouldn't create an almost unanimious response of rejection.
My comment argues on a slight tangent of yours, because you don't specifiy whether you agree with Gates regarding the H1-B program. The majority of complaints against root in the fact that the H1-B visa program is used to depress wages and maintain an artificial shortage by constantly expiring the working rights of experienced foriegners. If the program was done away with and competition was purely against traditional immigration, the uproar would rapidly die down. The brain drain is good for this country and would only cause concern for the worst in our profession, if that.
We are fully in agreement that immigration of qualified, exceptional people is a positive. However I've seen too many engineers that I've respected forced to leave. I've also seen discrimation towards native born Americans by those who immigrated, rose to management, and only hire foriegn staff despite cost and qualifications. I am more than happy to compete against a smart foriegner (and even happier to work beside him), but I strongly dislike what the H1-B program does to this country.
The two flaws in your argument are that (1) these individuals would not have had the opportunities to create as successful ventures in their home countries and (2) H1-B forces experienced professionals to leave the states and thus become even greater competition. They will start companies, accept outsourced jobs, or teach the next generation. These two reasons are exactly why we should foster full immigration rather than arm competing nations with skilled labor we forced back home. Instead, we accept the lowest skilled blindly (illegal) and reject the highly skilled (H1-B).
No, Core2 has worse 64-bit performance.