I misspoke, but no matter. Worker processes are even worse than worker threads, again for blindingly obvious reasons. What purpose did you hope to serve by picking that nit?
I don't see a direct relation between your experience and performance of an ST application.
Then you must be blind. How could I write dozens of servers and gain some understanding of the factors affecting their performance? How could an understanding of those factors not be applicable to evaluating ST's design choices? What you're attempting is not only ad hominem but lame ad hominem.
what's wrong with simplicity? If running a process per CPU provides SMP scalability why do we need anything else?
Running a process or thread per CPU is no trick at all. You can do it with a traditional multi-process design, you can do it with a state-machine design, you can do it with a staged design. The first real trick is to have the infrastructure rather than the programmer ensure that you are in fact running one process per CPU...which the ST docs explicitly state it doesn't do for you. The second trick is to remove from the programmer some of the synchronization and concurrency burden associated with handling parallelism the old-fashioned way...which ST also does not do.
There's nothing wrong with simplicity at all, but ST apparently doesn't do anything to simplify life for programmers who want to run on SMP hardware and get something out of it. It's just another threading package, hardly different from any other in any significant way. There are much more advanced frameworks available, which have been proven to scale well on SMPs and which do help simplify programmers' lives. I've already named some of them, and I suggest you learn about them before you continue making ridiculous assertions about how great ST is.
How do you know performance will suck in the worker case?
Because I have written servers for a variety of applications over the last decade-plus, and in every case doing disk I/O through worker threads was a major lose. Yes, I have done benchmarks. There's even one set that's on my already-cited website; I believe it's under the "tech_design" category in the archives, but the reasons why that approach sucks are so blindingly obvious that I can't be bothered verifying the category.
using this library should be inherently better for performance than starting a thread per connection
Yet again, you are trying to refute a claim about X by making a claim about Y. There are many things that suck; mentioning new ones doesn't make the old ones better.
I'm going to try to stay on topic here, and not bash state threads unnecessarily. The question before us is this: do state threads take full advantage of SMP, without degenerating into something indistinguishable from the traditional multi-process model? Do you have any evidence yet to support that claim?
MPI software runs on *BSD. Even MOSIX was originally built for FreeBSD.
Are those the only forms of clustering? What about high-availability clustering? Linux is way ahead of *BSD in that area.
"Garbage...spewing...idiot". You're a pretty abusive guy, you know that? You're providing a lot of heat but little light, and I suggest that you forego the abusive posturing until you can back it up with something.
Stop being an ass, Dan. The person to whom your responding mentioned having written a webserver, and even provided a link. I'll wager that s/he has done more profiling than you have, and you're the one engaging in idle speculation.
which explains unless you have worker processes for the disk I/O, in their threads library implementation, the process and all its threads will be blocked by it (the I/O).
Yes, if you use only a single process scalability will suck. Unfortunately, performance will also suck if you use helper processes to do your disk I/O and context-switch yourself to death. You're attempting to refute a claim about X by making a claim about Y, and that sort of doesn't work.
Two CPUs? The library will start two processes, and a number of threads. Four CPUs? Start four processes, etc.
...and then you'll be responsible for synchronization and concurrency between them. The docs are quite explicit about that. The library even provides its own set of primitives. In other words: welcome back to the multithreaded paradigm, only now all the same old mutex/condition/TLS calls have different names. Excuse me if I don't seem impressed.
The apache MPM module they wrote (Apache Accelerating Projec) scales better than Apache's own pthread-based modules. Several times better. Read their pages.
Read them yourself. There are many claims, but the only relevant semi-quantitative one I could find is this, from http://aap.sourceforge.net/stm.html:
Informal performance measurements reveal that the STM is faster than any other standard MPM on all the systems it currently supports. In particular on a dual Pentium III Linux 2.4 system the STM is 25% faster than the dexter MPM, which uses a similar MPMT architecture with pthreads.
25% isn't all that much, and could be an implementation artifact or measurement error/bias (given the informal and unspecified nature of the measurements). It certainly doesn't make a very strong case that state threads perform particularly well, and it makes no case at all in support of your SMP-scalability claim. AAP as a whole claims a performance improvement of up to 900% over Apache 1.3, but
Apache 2.0 is not Apache 1.3
the vast majority of the improvement is from the QSC, not the STM
There are a lot of people out there making a lot of claims about performance of this or that. Don't believe everything you read in a paper written by someone trying to make a name for themselves - including me. Reason for yourself about what effects each design decision will have on parallelism, context switches, cache warmth, etc. etc. etc. Even better, find or generate quantitative measurements showing the performance charactertistics on real workloads of interest to you (not just toys constructed to show the package's best side and hide its warts). Try to write actual code for a framework and see if the pain is justified even if their performance/scalability claims are true. Don't rely on the open-source equivalent of advertising copy to make your arguments for you.
I don't believe you. Neither the FAQ nor the intro does more than pay lip-service to the issue. The programmer's notes explicitly suggest using pipes or similar IPC between processes, which indicates a lack of support for closer (more efficient) coupling. There's also an egregiously incorrect statement that "disk I/O (unlike network I/O) always takes a finite and predictable amount of time" and then suggests using helper processes to handle disk I/O; to me, this indicates that the authors don't even understand the performance issues surrounding disk I/O, context switches, etc.
In short, I see nothing in the docs that even holds out any hope of the "scales on SMP" claim being true. Do you have any actual evidence that the claim is true, or that state threads in general provide any real benefit compared to the plethora of other network-application frameworks (e.g. Sandstorm, Twisted) that already exist?
That is correct. I apologize if I gave the impression that state-machine approaches can not scale; what I meant was that as often implemented they do not and thus should not be considered inherently superior to threaded approaches. A lot of work is necessary to make a scalable application either way.
There's also an important point that should not be missed; while a pure state-machine model can be used to create a scalable implementation of complex functionality (such as a web server), that doesn't mean such a model is the best choice. Most real applications at some point seem to grow at least one periodic "cleanup" tasks - usually several. Such tasks are conceptually, "naturally" parallel with respect to main-line request processing. Trying to implement their looping and concurrency behaviors within a pure state-machine model is beyond inconvenient or painful; I've seen it trigger the complete collapse of more than one project as the program's complexity surpassed the programmers' ability to manage it effectively. There are also adapters that must be written where non-blocking interfaces are not available, often at significant performance cost, and many other issues. In short, some code deserves to be written in a linear fashion. Maybe it's not much, but it's enough to make a mockery of the purists' idealism. I'm sure the folks at Zeus have cursed the state-machine model many times, and almost equally sure that they've violated it in ways they don't talk about in their white papers. IMO a system that's designed to support the most appropriate model for each sub-component is more useful than one that tries (and almost inevitably fails) to follow a single model throughout.
It's nice to know there are others out there who know state machines are the One True Way
Oh, but they're not. Yes, I know you were joking, but it's also a serious matter and a mistake many people make. I love state machines, I'm notorious among my past and present coworkers for using them, but they're not the only way to break out of the naive multithreaded model. In fact, naive state-machine implementations are often even worse than naive multithreaded implementations since they're all too often utterly incapable of using more than one CPU.
The best-known alternative to the two representatives of this false programming-paradigm dichotomy is probably Matt Welsh's SEDA. I've also written extensively on the subject: here's an archive of past articles and my server-design guide that sums it all up. The basic idea, which goes back much further than either my work or Matt's, is to break processing into stages. Interactions between stages are asynchronous event- or message-based, while what occurs within a stage can be either state-oriented or thread-oriented according to programmer preference, availability of non-blocking I/O interfaces, etc. The programmer thus has a great deal of control over how a task-appropriate balance between the relative advantages and drawbacks of the two "standard" models is achieved.
Ideally you have exactly as many threads as CPUs
An excellent point. In fact, this is the area where Matt's thinking and mine diverge, and thus deserves special attention. SEDA tends a little toward the bounded-thread-pool model of having more threads than processors (though not infinite) and I believe that's a mistake. My own model more sharply limits the number of threads that are used. Though there might transiently be more active threads than processors under certain conditions, this is not a persistent condition; it's simply more costly to eliminate those rare transient cases than to allow them. Another difference is that SEDA attempts to reduce context switches and stage transitions by "batching" (passing multiple requests through a stage in a single pass) whereas I tend more towards "run until completion" (passing a single request through multiple stages). While the two approaches are probably equivalent in most ways, I believe the latter has a cache-warmth advantage; there's usually more data shared between the processing of a single request through multiple stages than between multiple requests in one stage.
I guess we're getting a little off-topic, though. Maybe we should find an alternate venue to discuss this if people are interested.
This could have been handled in Apache proper, by adding a call conversion mechanism (present a blocking interface that, underneath, converts the blocking call into a non-blocking primitive plus a context switch).
At significant cost in performance, of course, and if performance is the goal then nobody wins.
It's also funny to see you present as a solved problem something that's actually a very active area of research and pretty much still in its infancy. If you ask ten people who've been working on peer reputation how it works, you'll probably get five saying "it doesn't...yet" and the other five giving you five (or more) different algorithms. You're probably correct that there's a solution in there somewhere, but please don't make people think all the interesting stuff in that area has already been done.
One of the assumption that's being made both in the story and in many of the comments is that the CMS runs on a dedicated machine over which you have total control. This assumption covers database formats and filesystem layouts that are unfriendly to multiple installations, plus custom Apache configs (even an Apache dependency is noxious IMO) to "just install mod_obscure_widget" pseudo-advice.
The problem is that the assumption is just not true for many people, who run their sites on servers owned, configured and administered by a hosting provider. Any CMS that can be installed in such an environment automatically becomes about five times more useful than one that requires total control of a dedicated machine. That's the review/comparison that would really be useful to most of us.
And what about Outlook Express, the joke of an e-mail client that comes with IE? Wasn't that single program responsible for most of the e-mail worms that have plagued Windows machines on the Internet in the last three years?
Nope. Outlook Express has certainly been vulnerable to an embarrassing number of exploits, but it's a distant #2 to Outlook itself. Despite the similar names (that's a rant for another day) they're completely different programs.
I really wish they had asked how people find time to develop open-source software. We couldn't expect completely honest answers, of course, but it's always interesting to see how many people not only do open-source work when they're supposed to be doing something else (e.g. paid work or study) but even admit that they do so. A similar question would be about what effects the expenditure of time on open-source projects has had on other aspects of people's lives - e.g. flunked out of school, got fired, lost a girlfriend, etc.
I know that many do open-source work entirely on their own time (or get paid to do it) and manage to find a balance between that and other aspects of their lives. I don't mean to imply otherwise. I just think that any sociological study of open-source developers should pay at least some attention to this "darker side" in addition to the by-now-overdone philosophical and work-habit questions.
Re:Ignorance is beaming
on
Haiku vs Spam
·
· Score: 5, Funny
Get it straight, scab-boy. The *spammers* are from China. Not the poetry.
Yeah, I know it's fun to bash Microsoft and hint that your OSOS (Open Source Operating System) of choice would do better, but the drivers in question here are not Microsoft drivers. They're vendor-supplied drivers which would probably use 90% common code and have 99% of the same problems on any OS.
If michael's "every action implies an ulterior motive" theory were correct, we'd have to wonder what his ulterior motive is. Does michael perhaps have some vested interest in promoting open source, like for example drawing a paycheck from a company that is associated with open source? Yes, of course he does. Sellout! Astroturf! The sky is falling!
Get real. O'Reilly is taking a principled stand, knowing that it will alienate many of his friends. I respect him for that. By contrast, I have no respect for michael's ad hominem attacks.
Not only was the idea developed on his own time, it was developed before his employment there began. That's the part that's so noxious about this. Basically they're claiming rights to an idea that had nothing to do with them or their business, just because someone happened to work for them somewhere along the way, and that's nothing but the rawest kind of opportunism. How, one must ask, does that fit into the supposed theory behind intellectual-property law, which is to foster innovation and creativity for the public good?
Re:evaluation function in Deep Blue hardware
on
Men vs. Machines
·
· Score: 2
Then I stand corrected. Nonetheless, I think even that still falls into the category of "making the brute-force approach go faster". The type of evaluation function involved, no matter how "sophisticated" it is in a certain context, is not truly sophisticated in the same manner as something that actually performs planning or learning functions. It's basically a calculator for a complex mathematical function, and is still driven more by the intelligence of the person who assigned weights to all of the positional factors than by any actual sophistication as an AI researcher would use the term.
Re:Someone posts a chess computer story...
on
Men vs. Machines
·
· Score: 2
If the computer's preparation were comparable in duration and resources to the human's preparation, that would be fine. My point, though, is that in the particular case of Deeper Blue vs. Kasparov that was not the case. The computer had much more time to prepare for Kasparov than vice versa (he was kinda busy winning tournaments and such). Similarly, DB had many more of Kasparov's games to study than vice versa. It's not a problem that DB was allowed to prepare; it's a problem that Kasparov effectively was not.
Re:Someone posts a chess computer story...
on
Men vs. Machines
·
· Score: 5, Insightful
you instantly get a bunch of posts about how it's "not that impressive because the computer is trained to beat just that player".
Well, here's a heads up. That is exactly how human players prepare for matches against each other. They sit down and play through their opponents previous matches
...and that is precisely the opportunity that was denied Kasparov. Deeper Blue and its handlers -especially Joel Benjamin - had years to dissect Kasparov's games, but Kasparov had no access to DB's oeuvre. That's not a level playing field.
Another aspect you've overlooked is that human preparation to play a particular opponent is usually on the order of weeks or months, and does not significantly sacrifice the preparer's ability to play other opponents. Even in the middle of preparing to play Kramnik or Anand, Kasparov could go to a tournament and beat just about anyone else. By contrast, DB was in preparation for years and the result was so finely tuned toward playing Kasparov that DB would have fared very poorly in any top-level tournament involving anyone other than Kasparov. That kind of inflexibility is not a hallmark of a intelligence, artificial of otherwise. What it indicates is that the basic methods were so old and so well understood that people have been able to spend years just tuning the implementation.
Making a computer beat the world champion is a respectable feat. However, it's not even the highest goal in computer chess. Making a computer that could beat a series of opponents, without fundamental changes equivalent to a brain transplant between matches, would be more impressive. Making a computer that could win a 16-player round robin tournament against a whole field of top grandmasters - something Kasparov still does regularly, to this day - would be more impressive still. Making a computer that could play speed chess better than Anand or Hawkeye would be another worthwhile challenge in a different direction. Then there's Go, and then a bunch of other challenges, and then there's the real world. Spending years to create a program that can beat one player in one chess match under less-than-fair conditions is really a pretty low goal.
Re:Someone posts a chess computer story...
on
Men vs. Machines
·
· Score: 4, Insightful
Because they have teams of programmers and serious hardware.
Deep(er) Blue used some special-purpose hardware, but Deep Fritz and Deep Junior don't. Multiprocessors are a commodity nowadays.
More hardware than is needed for a brute-force approach, actually, so what's all the extra hardware doing?
Deep(er) Blue's custom ASICs were basically there to make the brute-force approach go faster. They didn't implement some sort of expert system or neural net, they had little to do with sophisticated position evaluation, they were mostly just there to speed up the nuts-and-bolts operations of walking extremely large decision trees.
The scorn you heap upon this post's grandparent seems just a trifle misplaced, since you yourself seem to know little about the programs being discussed. They're a combination of chess-specific knowledge and fast implementations of fairly ancient algorithms, so they're pretty formidable opponents, but in terms of AI research they've progressed little beyond an early-to-mid-80s level. Nobody that I know who actually works in AI would say any different, either.
Learn what he taught. Avoid GOTO. Learn about structured programming and CSP. Strive for elegance and simplicity in your programs. I can think of no better testament to his work than to show that we really were listening.
23 languages on 14 platforms? That's odd. As recently as 6 July 2001 Mr. Paget was posting a position-wanted ad on SecurityFocus, describing his language/platform knowledge as follows:
I am fluent (if a little rusty) in many programming languages (C, C++, Delphi, VB, VBScript, various assemblers), and I am keen to broaden my skills, specificially [sic] to include Unix and x86 assembler...my Unix knowledge is far from brilliant
One can only wonder which 23 languages and 14 platforms he knows, if several of the most important ones are notable by their absence or explicit disclaimer. Of course, he never tires of telling us he's a fast learner. Maybe he has filled in some of those gaping holes in his basic computer knowledge in the last year and a bit.
Slashdot Mirror
I misspoke, but no matter. Worker processes are even worse than worker threads, again for blindingly obvious reasons. What purpose did you hope to serve by picking that nit?
Then you must be blind. How could I write dozens of servers and gain some understanding of the factors affecting their performance? How could an understanding of those factors not be applicable to evaluating ST's design choices? What you're attempting is not only ad hominem but lame ad hominem.
Running a process or thread per CPU is no trick at all. You can do it with a traditional multi-process design, you can do it with a state-machine design, you can do it with a staged design. The first real trick is to have the infrastructure rather than the programmer ensure that you are in fact running one process per CPU...which the ST docs explicitly state it doesn't do for you. The second trick is to remove from the programmer some of the synchronization and concurrency burden associated with handling parallelism the old-fashioned way...which ST also does not do.
There's nothing wrong with simplicity at all, but ST apparently doesn't do anything to simplify life for programmers who want to run on SMP hardware and get something out of it. It's just another threading package, hardly different from any other in any significant way. There are much more advanced frameworks available, which have been proven to scale well on SMPs and which do help simplify programmers' lives. I've already named some of them, and I suggest you learn about them before you continue making ridiculous assertions about how great ST is.
Because I have written servers for a variety of applications over the last decade-plus, and in every case doing disk I/O through worker threads was a major lose. Yes, I have done benchmarks. There's even one set that's on my already-cited website; I believe it's under the "tech_design" category in the archives, but the reasons why that approach sucks are so blindingly obvious that I can't be bothered verifying the category.
Yet again, you are trying to refute a claim about X by making a claim about Y. There are many things that suck; mentioning new ones doesn't make the old ones better.
I'm going to try to stay on topic here, and not bash state threads unnecessarily. The question before us is this: do state threads take full advantage of SMP, without degenerating into something indistinguishable from the traditional multi-process model? Do you have any evidence yet to support that claim?
Are those the only forms of clustering? What about high-availability clustering? Linux is way ahead of *BSD in that area.
"Garbage...spewing...idiot". You're a pretty abusive guy, you know that? You're providing a lot of heat but little light, and I suggest that you forego the abusive posturing until you can back it up with something.
Stop being an ass, Dan. The person to whom your responding mentioned having written a webserver, and even provided a link. I'll wager that s/he has done more profiling than you have, and you're the one engaging in idle speculation.
Yes, if you use only a single process scalability will suck. Unfortunately, performance will also suck if you use helper processes to do your disk I/O and context-switch yourself to death. You're attempting to refute a claim about X by making a claim about Y, and that sort of doesn't work.
...and then you'll be responsible for synchronization and concurrency between them. The docs are quite explicit about that. The library even provides its own set of primitives. In other words: welcome back to the multithreaded paradigm, only now all the same old mutex/condition/TLS calls have different names. Excuse me if I don't seem impressed.
Read them yourself. There are many claims, but the only relevant semi-quantitative one I could find is this, from http://aap.sourceforge.net/stm.html:
25% isn't all that much, and could be an implementation artifact or measurement error/bias (given the informal and unspecified nature of the measurements). It certainly doesn't make a very strong case that state threads perform particularly well, and it makes no case at all in support of your SMP-scalability claim. AAP as a whole claims a performance improvement of up to 900% over Apache 1.3, but
There are a lot of people out there making a lot of claims about performance of this or that. Don't believe everything you read in a paper written by someone trying to make a name for themselves - including me. Reason for yourself about what effects each design decision will have on parallelism, context switches, cache warmth, etc. etc. etc. Even better, find or generate quantitative measurements showing the performance charactertistics on real workloads of interest to you (not just toys constructed to show the package's best side and hide its warts). Try to write actual code for a framework and see if the pain is justified even if their performance/scalability claims are true. Don't rely on the open-source equivalent of advertising copy to make your arguments for you.
I don't believe you. Neither the FAQ nor the intro does more than pay lip-service to the issue. The programmer's notes explicitly suggest using pipes or similar IPC between processes, which indicates a lack of support for closer (more efficient) coupling. There's also an egregiously incorrect statement that "disk I/O (unlike network I/O) always takes a finite and predictable amount of time" and then suggests using helper processes to handle disk I/O; to me, this indicates that the authors don't even understand the performance issues surrounding disk I/O, context switches, etc.
In short, I see nothing in the docs that even holds out any hope of the "scales on SMP" claim being true. Do you have any actual evidence that the claim is true, or that state threads in general provide any real benefit compared to the plethora of other network-application frameworks (e.g. Sandstorm, Twisted) that already exist?
That is correct. I apologize if I gave the impression that state-machine approaches can not scale; what I meant was that as often implemented they do not and thus should not be considered inherently superior to threaded approaches. A lot of work is necessary to make a scalable application either way.
There's also an important point that should not be missed; while a pure state-machine model can be used to create a scalable implementation of complex functionality (such as a web server), that doesn't mean such a model is the best choice. Most real applications at some point seem to grow at least one periodic "cleanup" tasks - usually several. Such tasks are conceptually, "naturally" parallel with respect to main-line request processing. Trying to implement their looping and concurrency behaviors within a pure state-machine model is beyond inconvenient or painful; I've seen it trigger the complete collapse of more than one project as the program's complexity surpassed the programmers' ability to manage it effectively. There are also adapters that must be written where non-blocking interfaces are not available, often at significant performance cost, and many other issues. In short, some code deserves to be written in a linear fashion. Maybe it's not much, but it's enough to make a mockery of the purists' idealism. I'm sure the folks at Zeus have cursed the state-machine model many times, and almost equally sure that they've violated it in ways they don't talk about in their white papers. IMO a system that's designed to support the most appropriate model for each sub-component is more useful than one that tries (and almost inevitably fails) to follow a single model throughout.
Oh, but they're not. Yes, I know you were joking, but it's also a serious matter and a mistake many people make. I love state machines, I'm notorious among my past and present coworkers for using them, but they're not the only way to break out of the naive multithreaded model. In fact, naive state-machine implementations are often even worse than naive multithreaded implementations since they're all too often utterly incapable of using more than one CPU.
The best-known alternative to the two representatives of this false programming-paradigm dichotomy is probably Matt Welsh's SEDA. I've also written extensively on the subject: here's an archive of past articles and my server-design guide that sums it all up. The basic idea, which goes back much further than either my work or Matt's, is to break processing into stages. Interactions between stages are asynchronous event- or message-based, while what occurs within a stage can be either state-oriented or thread-oriented according to programmer preference, availability of non-blocking I/O interfaces, etc. The programmer thus has a great deal of control over how a task-appropriate balance between the relative advantages and drawbacks of the two "standard" models is achieved.
An excellent point. In fact, this is the area where Matt's thinking and mine diverge, and thus deserves special attention. SEDA tends a little toward the bounded-thread-pool model of having more threads than processors (though not infinite) and I believe that's a mistake. My own model more sharply limits the number of threads that are used. Though there might transiently be more active threads than processors under certain conditions, this is not a persistent condition; it's simply more costly to eliminate those rare transient cases than to allow them. Another difference is that SEDA attempts to reduce context switches and stage transitions by "batching" (passing multiple requests through a stage in a single pass) whereas I tend more towards "run until completion" (passing a single request through multiple stages). While the two approaches are probably equivalent in most ways, I believe the latter has a cache-warmth advantage; there's usually more data shared between the processing of a single request through multiple stages than between multiple requests in one stage.
I guess we're getting a little off-topic, though. Maybe we should find an alternate venue to discuss this if people are interested.
At significant cost in performance, of course, and if performance is the goal then nobody wins.
It's also funny to see you present as a solved problem something that's actually a very active area of research and pretty much still in its infancy. If you ask ten people who've been working on peer reputation how it works, you'll probably get five saying "it doesn't...yet" and the other five giving you five (or more) different algorithms. You're probably correct that there's a solution in there somewhere, but please don't make people think all the interesting stuff in that area has already been done.
In other words, watch out for that elephant. ;-)
That's exactly what the paper's authors said, pointing out that the decrease in convenience is in itself a real danger, and they were right.
One of the assumption that's being made both in the story and in many of the comments is that the CMS runs on a dedicated machine over which you have total control. This assumption covers database formats and filesystem layouts that are unfriendly to multiple installations, plus custom Apache configs (even an Apache dependency is noxious IMO) to "just install mod_obscure_widget" pseudo-advice.
The problem is that the assumption is just not true for many people, who run their sites on servers owned, configured and administered by a hosting provider. Any CMS that can be installed in such an environment automatically becomes about five times more useful than one that requires total control of a dedicated machine. That's the review/comparison that would really be useful to most of us.
Nope. Outlook Express has certainly been vulnerable to an embarrassing number of exploits, but it's a distant #2 to Outlook itself. Despite the similar names (that's a rant for another day) they're completely different programs.
I really wish they had asked how people find time to develop open-source software. We couldn't expect completely honest answers, of course, but it's always interesting to see how many people not only do open-source work when they're supposed to be doing something else (e.g. paid work or study) but even admit that they do so. A similar question would be about what effects the expenditure of time on open-source projects has had on other aspects of people's lives - e.g. flunked out of school, got fired, lost a girlfriend, etc.
I know that many do open-source work entirely on their own time (or get paid to do it) and manage to find a balance between that and other aspects of their lives. I don't mean to imply otherwise. I just think that any sociological study of open-source developers should pay at least some attention to this "darker side" in addition to the by-now-overdone philosophical and work-habit questions.
Get it straight, scab-boy.
The *spammers* are from China.
Not the poetry.
Yeah, I know it's fun to bash Microsoft and hint that your OSOS (Open Source Operating System) of choice would do better, but the drivers in question here are not Microsoft drivers. They're vendor-supplied drivers which would probably use 90% common code and have 99% of the same problems on any OS.
If michael's "every action implies an ulterior motive" theory were correct, we'd have to wonder what his ulterior motive is. Does michael perhaps have some vested interest in promoting open source, like for example drawing a paycheck from a company that is associated with open source? Yes, of course he does. Sellout! Astroturf! The sky is falling!
Get real. O'Reilly is taking a principled stand, knowing that it will alienate many of his friends. I respect him for that. By contrast, I have no respect for michael's ad hominem attacks.
What would happen if it turned out that he'd actually stolen the idea from someone else? Think for a moment about what that does to Alcatel's claim.
Not only was the idea developed on his own time, it was developed before his employment there began. That's the part that's so noxious about this. Basically they're claiming rights to an idea that had nothing to do with them or their business, just because someone happened to work for them somewhere along the way, and that's nothing but the rawest kind of opportunism. How, one must ask, does that fit into the supposed theory behind intellectual-property law, which is to foster innovation and creativity for the public good?
Then I stand corrected. Nonetheless, I think even that still falls into the category of "making the brute-force approach go faster". The type of evaluation function involved, no matter how "sophisticated" it is in a certain context, is not truly sophisticated in the same manner as something that actually performs planning or learning functions. It's basically a calculator for a complex mathematical function, and is still driven more by the intelligence of the person who assigned weights to all of the positional factors than by any actual sophistication as an AI researcher would use the term.
If the computer's preparation were comparable in duration and resources to the human's preparation, that would be fine. My point, though, is that in the particular case of Deeper Blue vs. Kasparov that was not the case. The computer had much more time to prepare for Kasparov than vice versa (he was kinda busy winning tournaments and such). Similarly, DB had many more of Kasparov's games to study than vice versa. It's not a problem that DB was allowed to prepare; it's a problem that Kasparov effectively was not.
...and that is precisely the opportunity that was denied Kasparov. Deeper Blue and its handlers -especially Joel Benjamin - had years to dissect Kasparov's games, but Kasparov had no access to DB's oeuvre. That's not a level playing field.
Another aspect you've overlooked is that human preparation to play a particular opponent is usually on the order of weeks or months, and does not significantly sacrifice the preparer's ability to play other opponents. Even in the middle of preparing to play Kramnik or Anand, Kasparov could go to a tournament and beat just about anyone else. By contrast, DB was in preparation for years and the result was so finely tuned toward playing Kasparov that DB would have fared very poorly in any top-level tournament involving anyone other than Kasparov. That kind of inflexibility is not a hallmark of a intelligence, artificial of otherwise. What it indicates is that the basic methods were so old and so well understood that people have been able to spend years just tuning the implementation.
Making a computer beat the world champion is a respectable feat. However, it's not even the highest goal in computer chess. Making a computer that could beat a series of opponents, without fundamental changes equivalent to a brain transplant between matches, would be more impressive. Making a computer that could win a 16-player round robin tournament against a whole field of top grandmasters - something Kasparov still does regularly, to this day - would be more impressive still. Making a computer that could play speed chess better than Anand or Hawkeye would be another worthwhile challenge in a different direction. Then there's Go, and then a bunch of other challenges, and then there's the real world. Spending years to create a program that can beat one player in one chess match under less-than-fair conditions is really a pretty low goal.
Deep(er) Blue used some special-purpose hardware, but Deep Fritz and Deep Junior don't. Multiprocessors are a commodity nowadays.
Deep(er) Blue's custom ASICs were basically there to make the brute-force approach go faster. They didn't implement some sort of expert system or neural net, they had little to do with sophisticated position evaluation, they were mostly just there to speed up the nuts-and-bolts operations of walking extremely large decision trees.
The scorn you heap upon this post's grandparent seems just a trifle misplaced, since you yourself seem to know little about the programs being discussed. They're a combination of chess-specific knowledge and fast implementations of fairly ancient algorithms, so they're pretty formidable opponents, but in terms of AI research they've progressed little beyond an early-to-mid-80s level. Nobody that I know who actually works in AI would say any different, either.
Learn what he taught. Avoid GOTO. Learn about structured programming and CSP. Strive for elegance and simplicity in your programs. I can think of no better testament to his work than to show that we really were listening.
23 languages on 14 platforms? That's odd. As recently as 6 July 2001 Mr. Paget was posting a position-wanted ad on SecurityFocus, describing his language/platform knowledge as follows:
One can only wonder which 23 languages and 14 platforms he knows, if several of the most important ones are notable by their absence or explicit disclaimer. Of course, he never tires of telling us he's a fast learner. Maybe he has filled in some of those gaping holes in his basic computer knowledge in the last year and a bit.