2. Clusters got really popular for a few years, but have really fallen out of favor at the high end of the HPC market.
Ummm...what? Using the Top500 list as a list of large machines (not necessarily as a good ranking), I think that clusters are still very much in favor. You've got to go 25 places before finding a non-cluster (i.e the first majority shared memory (NUMA) machine). BlueGene/L and/P systems are scattered in there, but they're essentially clusters, too. They're definitely not commodity clusters, but they still have a largely distributed memory architecture just like the commodity clusters. The Crays at that level of the list are also non-commodity clusters, but they're even more like the commodity boxes than the BlueGenes.
I don't see any data in your reply. There's a heck of a lot of should and "I think" and possibly.
There's a tiny bit of assembly int OpenMPI, but nothing that has anything to do with communication, just some atomic test-and-set code. So, I'm not sure how that's relevant. LAM is basically dead (as OpenMPI is a complete rewrite by basically the same team). And I didn't say MPICH wasn't bad, I said it wasn't _that_ bad. It's come a long way from when there was no competition. Besides, for IB, MVAPICH and MVAPICH2 are the fastest implementations out there, and they're MPICH based.
Show me some floating-point intensive simulation code written in Occam that beats it's MPI C/C++/Fortran competitor, and then we'll talk about what a great model it is.
PVM also dead. Given their notional functional equivalence, it's clear that the MPI API and portability won out, so why bring it up? I don't see how PVM is any more generic or MPI any more fixed. Can you explain that, perhaps show some code?
As for the software implementations of collectives requiring loop structures, you must realize that even with multicast, most collective operations will also require some loop structures, right? Multicast allows for one-to-many communications, but that's not the full extent of what needs to happen for most collectives.
Considering that we've got SDR IB with under 2 microseconds latency for the shortest hops (and ~3 for the longest), I think you need to go update your anti-cluster argument.:) The problems with congestion in fat trees have virtually nothing to do with latency. Yes massive congestion will kill your latency numbers, but given that you don't get cascades and other failures causing congestion without fairly large bandwidth utilization, latency is the least of your worries that that point. Furthermore, the cascades you talk about also aren't common except in extremely oversubscribed networks or in the presence of malfunctioning hardware. We do our best to use properly functioning hardware and to have no more that 2:1 oversubscription (with our largest machine not being oversubscribed at all).
MPICH ain't that bad (heck, MPICH2, even just it's MPI-1 parts might be considered to be pretty good by some). MPI as standard for message-passing is fine. I'd love to hear what you think is wrong with MPI and see some examples where another portable message passing standard does consistently better. Though it's a bit like C or C++ or Perl in that there are lots of really bad ways to accomplish things in MPI and a handful of good ones. It's low-level enough that you need to know what you're doing. But if you believe anyone that tells you they have a way to make massively parallel programming easy, I've got a bridge you might be interested in.
Finally, I don't know of much in the way of a "supercomputer" that's using TCP for it's MPI traffic these days, so you can put that old saw out to pasture as well.
Higher bit-depths (like 16-bit per pixel TIFFs, HDR, etc.). PS does at least 16-bit per pixel images, and I think is starting to develop some HDR capabilities as well. Yes, there's CinePaint, but it's on an ancient Gimp tree and is really just a stopgap.
The only way to "demand a change of government" in the US is to press our Congress to impeach and convict the President. Otherwise, we have to wait until '08 until Bush is out by default. The question is then, do these corruptions rise to the level that the House and Senate will be willing to expend the political captial necessary to impeach the second President in a row (and, for removal, for the Senate to convict him). I doubt seriously that the necessary captial is there unless there's a video of the President telling Rove to monkey with the emails, and given that we'll be waiting for '08.
Is there perhaps a case (say brought by RedHat or another non-Novell Linux distributor) for tortious interference? I.e. if RedHat can show that one big deal fell through because of MS's psuedo-threat, haven't they had their business relationships interfered with in an illegitimate way?
You should look up Marcus Ranom's version of doing this or the guys that do this every year with a moving car. The latter I think even allow basically anyone to come and try their hand at it.
When you can show me a distributed memory parallel weather forecasting or climate prediction code written in Haskell, i.e. something that runs and scales well on large Linux clusters, has high interprocessor communication needs (both in terms of latency and bandwidth), and does a metric assload of floating point computations, I'll start to get interested. If you don't want to go so far as to include all the physics that go into weather and/or climate, just show me a Navier-Stokes simulator that has all those properies.
As I keep saying, this whole argument came up b/c the OP told us to drop C and Fortan, but here we are with Google using C++ to do something cool! Doesn't look like there's a need to drop C or Fortran, just a need for some smarter-than-the-average-bear programmers to make some libraries to make everyone else's life easier. Sorry, you can't have your tie. Putting functional ideas in a procedural language is good learning, but it's not a functional language showing off it's ability to handle massive parallelism like the touters claim.
Again, as another noted, there's little evidence for parallelism in these programs. I'm not saying there isn't any, it's just that we can't see it.
I (as someone who works at a supercomputing center) am still waiting for a parallel weather forcasting code or hypersonic aerothermodynamics code or the like written in one of the many functional languages touted here. I deal with such codes on a daily basis, and they're all written in Fortran, C, and C++ (in that (decreasing) order or occurrence). These are the parallel programs that are meaningful (to me). This may largely be due to historical intertia (you code like you learn and engineers, chemists, and physicists learn procedural languages), but sometimes I'd like the advocates of functional languages to put up or shut up. If it's so easy to write a massively parallel program in Haskell, I'd like a Haskell maven to write a parellel incompressible Navier-Stokes finite element code with implicit time integration on unstructured hexahedral meshes and put mine (written in C++) to shame both in terms of computational speed and efficiency and in terms of lines of code (or whatever metric of code beauty is preferred)!
There's no MapReduce compiler. The programmer writes C++. So, at best, the programmer is the functional language compiler, and he has to translate his MapReduce code into C++.
Again, no one disagrees with your idea that writing in a functional style is a good idea for parallel programming, but the OP said that we should give up on two specific languages and pick up a functional one. Clearly a program in a functional style can be written in C++ (which is a superset of C89, more or less, which is one of the two languages mentioned by the OP). The challege to the OP was to show the world a massively parallel program of significance written in a functional language, not one written directly in a procedural language but in a functioal style. You showed us the latter, we'd still like to see the former.
Yes, but if you look at the code in Appendix A, it's written in C++. Yes, it calls a the MapReduce library which is functional in style, but the user still must write their code in an essenitally procedure language. Yes, the library hides a lot from the user, but so what? They still have to write their code in C++! The OP exhorted us to "abandon C and Fortan," but you're touting a C++ class library as an example of a win for functional languages. I assume you can see why we might object!
Of course Google's programmers can write cool parallel programs with this powerful library, but it's not a functional programming library! It's a C++ library that borrows some map and reduce ideas from functional languages.
I'd rephrase the objection to the OP as: "Show me the climate simulator in Haskell. Show me the ML hypersonic flow code for computing reentry flow over the shuttle."
If you read the paper you linked to below, you'll find that Google's Mapreduce language is implemented as a C++ library. Specifically, check out Appendix A of thier paper.
The problem with your system is that it encourages your attorney to inflate his costs, as well. It might make him put on his best game, but as long as the opposition is footing the bill, what does he care if he "charges you" double what he would if not under this system? I think that in loser-pays countries, the fees charged by the winning side must meet some standards of reasonableness or not exceed some more fixed limits or, at least, the recoverable amount is capped by some limits, etc.
There is another side effect of this as well. It increases the incentives for you to win, because absolutely no one wants to pay the other side's fees. I don't know if this is a good thing or a bad thing. On the one hand it pushes lawyers to do their utmost for their clients. On the other hand, it goes against my sense that the courts should be used to find the "truth," make aggrieved parties whole, and punish scofflaws and other offenders for the benefit of the public good. Our advisarial system (which I tend to support) already makes the goal winning rather than thruth-finding. I'm not sure that I would want to increase that effect.
The other thing you should note, is that in suing a large company, many of these cases would be handled by in-house counsel who are salaried. This is different from outside counsel who bill by the hour (and include margins to cover cases that they don't win, etc.). In those cases, a loser who sued a large corp. who used their in-house lawyers would only have to pay salaries for those attorneys that participated in the litigation and actual expenses. This fact would certainly drive companies to use outside counsel for all their litigation needs, thereby making them harder to sue and driving up the costs to corporations to defend themselves in court (they can't win 'em all).
Finally, juries can be weird. Just because you win a case, it doesn't mean you should have. I'm not sure we would want to further muck up our system by further penalizing the losing side in cases that they shouldn't have lost. There are already numerous situations where statute allows for the seeking of attorneys fees (often at the judge's discretion, as in this case). Perhaps more of this sort of thing is in order.
Active yogurts have been available in the US for decades if not centuries. Activa is just the first product that I've seen to specifically mention its active cultures as a cure for certain ailments in its advertising. It's really just new marketing (and good marketing, IMO).
The thing with Ubuntu's (and many other Linus distros) admin prompts is that once you've typed your password to open it up, it doesn't need it again for X minutes (where X is distro dependent, but it defaults to 15 on my Ubuntu box). That is, it's basically a GUI for sudo. I don't know if Vista can do this, or if it has to have the password box for evertything it needs to do.
It's not "fake" so much as it's an approximation. I guarantee you the know by exactly how much they are in error (but not in what direction!). The Schroedinger Equation that is at the heart of this represents the probability (well its modulus does, at least) of something as a continuous function of space and time. These scientists make errors in that the equations that they use are discrete (in terms of mathematical degrees of freedom, strictly speaking, by discretizing space and time directly) models of the Schroedinger equation and in that the initial and boundary are not perfectly well known. That doesn't constitute "faking it" in my book. If they were faking it, they'd be making pretty pictures with no predictive value, and presuably their work makes good predictions, which, as you note, puts it in the category of "good science."
It's my understanding that R2 and Compute Cluster Edition are incompatible. Has that changed? Also, is it possible to make a statically-linked binary under Windows that uses SUA? If not, you'd have to have it everywhere.
MS-MPI is (last I heard, at least) incompatible with Windows Services for UNIX, so if your MPI code is POSIXy, you're going to have to port it over to Win32 before it will run on this new product. You don't have to rewrite the communications bits, but your I/O will have to be rewritten.
Breath/blood tests aren't "testimony," and therefore, the courts have ruled that the government can force you to comply. Giving out your encryption keys is most definitely testimony, so you can't be forced to give them up. They can get a warrant and look around on your computers, under your keyboard (for the sticky note), etc., though.
You could have had them enjoined from further distribution and sued for actual damages, and if you had registered it with the Copyright Office, you could have sued for satutory damages as well.
Slashdot Mirror
Ummm...what? Using the Top500 list as a list of large machines (not necessarily as a good ranking), I think that clusters are still very much in favor. You've got to go 25 places before finding a non-cluster (i.e the first majority shared memory (NUMA) machine). BlueGene/L and /P systems are scattered in there, but they're essentially clusters, too. They're definitely not commodity clusters, but they still have a largely distributed memory architecture just like the commodity clusters. The Crays at that level of the list are also non-commodity clusters, but they're even more like the commodity boxes than the BlueGenes.
(Damn me for forgetting to preview. There were paragraph breaks in the original, but not the HTML tags to make them show up!)
I don't see any data in your reply. There's a heck of a lot of should and "I think" and possibly. There's a tiny bit of assembly int OpenMPI, but nothing that has anything to do with communication, just some atomic test-and-set code. So, I'm not sure how that's relevant. LAM is basically dead (as OpenMPI is a complete rewrite by basically the same team). And I didn't say MPICH wasn't bad, I said it wasn't _that_ bad. It's come a long way from when there was no competition. Besides, for IB, MVAPICH and MVAPICH2 are the fastest implementations out there, and they're MPICH based. Show me some floating-point intensive simulation code written in Occam that beats it's MPI C/C++/Fortran competitor, and then we'll talk about what a great model it is. PVM also dead. Given their notional functional equivalence, it's clear that the MPI API and portability won out, so why bring it up? I don't see how PVM is any more generic or MPI any more fixed. Can you explain that, perhaps show some code? As for the software implementations of collectives requiring loop structures, you must realize that even with multicast, most collective operations will also require some loop structures, right? Multicast allows for one-to-many communications, but that's not the full extent of what needs to happen for most collectives.
Considering that we've got SDR IB with under 2 microseconds latency for the shortest hops (and ~3 for the longest), I think you need to go update your anti-cluster argument. :) The problems with congestion in fat trees have virtually nothing to do with latency. Yes massive congestion will kill your latency numbers, but given that you don't get cascades and other failures causing congestion without fairly large bandwidth utilization, latency is the least of your worries that that point. Furthermore, the cascades you talk about also aren't common except in extremely oversubscribed networks or in the presence of malfunctioning hardware. We do our best to use properly functioning hardware and to have no more that 2:1 oversubscription (with our largest machine not being oversubscribed at all).
MPICH ain't that bad (heck, MPICH2, even just it's MPI-1 parts might be considered to be pretty good by some). MPI as standard for message-passing is fine. I'd love to hear what you think is wrong with MPI and see some examples where another portable message passing standard does consistently better. Though it's a bit like C or C++ or Perl in that there are lots of really bad ways to accomplish things in MPI and a handful of good ones. It's low-level enough that you need to know what you're doing. But if you believe anyone that tells you they have a way to make massively parallel programming easy, I've got a bridge you might be interested in.
Finally, I don't know of much in the way of a "supercomputer" that's using TCP for it's MPI traffic these days, so you can put that old saw out to pasture as well.
[citation needed]
Higher bit-depths (like 16-bit per pixel TIFFs, HDR, etc.). PS does at least 16-bit per pixel images, and I think is starting to develop some HDR capabilities as well. Yes, there's CinePaint, but it's on an ancient Gimp tree and is really just a stopgap.
The only way to "demand a change of government" in the US is to press our Congress to impeach and convict the President. Otherwise, we have to wait until '08 until Bush is out by default. The question is then, do these corruptions rise to the level that the House and Senate will be willing to expend the political captial necessary to impeach the second President in a row (and, for removal, for the Senate to convict him). I doubt seriously that the necessary captial is there unless there's a video of the President telling Rove to monkey with the emails, and given that we'll be waiting for '08.
Is there perhaps a case (say brought by RedHat or another non-Novell Linux distributor) for tortious interference? I.e. if RedHat can show that one big deal fell through because of MS's psuedo-threat, haven't they had their business relationships interfered with in an illegitimate way?
You should look up Marcus Ranom's version of doing this or the guys that do this every year with a moving car. The latter I think even allow basically anyone to come and try their hand at it.
When you can show me a distributed memory parallel weather forecasting or climate prediction code written in Haskell, i.e. something that runs and scales well on large Linux clusters, has high interprocessor communication needs (both in terms of latency and bandwidth), and does a metric assload of floating point computations, I'll start to get interested. If you don't want to go so far as to include all the physics that go into weather and/or climate, just show me a Navier-Stokes simulator that has all those properies.
As I keep saying, this whole argument came up b/c the OP told us to drop C and Fortan, but here we are with Google using C++ to do something cool! Doesn't look like there's a need to drop C or Fortran, just a need for some smarter-than-the-average-bear programmers to make some libraries to make everyone else's life easier. Sorry, you can't have your tie. Putting functional ideas in a procedural language is good learning, but it's not a functional language showing off it's ability to handle massive parallelism like the touters claim.
I (as someone who works at a supercomputing center) am still waiting for a parallel weather forcasting code or hypersonic aerothermodynamics code or the like written in one of the many functional languages touted here. I deal with such codes on a daily basis, and they're all written in Fortran, C, and C++ (in that (decreasing) order or occurrence). These are the parallel programs that are meaningful (to me). This may largely be due to historical intertia (you code like you learn and engineers, chemists, and physicists learn procedural languages), but sometimes I'd like the advocates of functional languages to put up or shut up. If it's so easy to write a massively parallel program in Haskell, I'd like a Haskell maven to write a parellel incompressible Navier-Stokes finite element code with implicit time integration on unstructured hexahedral meshes and put mine (written in C++) to shame both in terms of computational speed and efficiency and in terms of lines of code (or whatever metric of code beauty is preferred)!
Again, no one disagrees with your idea that writing in a functional style is a good idea for parallel programming, but the OP said that we should give up on two specific languages and pick up a functional one. Clearly a program in a functional style can be written in C++ (which is a superset of C89, more or less, which is one of the two languages mentioned by the OP). The challege to the OP was to show the world a massively parallel program of significance written in a functional language, not one written directly in a procedural language but in a functioal style. You showed us the latter, we'd still like to see the former.
Of course Google's programmers can write cool parallel programs with this powerful library, but it's not a functional programming library! It's a C++ library that borrows some map and reduce ideas from functional languages.
I'd rephrase the objection to the OP as: "Show me the climate simulator in Haskell. Show me the ML hypersonic flow code for computing reentry flow over the shuttle."
If you read the paper you linked to below, you'll find that Google's Mapreduce language is implemented as a C++ library. Specifically, check out Appendix A of thier paper.
The problem with your system is that it encourages your attorney to inflate his costs, as well. It might make him put on his best game, but as long as the opposition is footing the bill, what does he care if he "charges you" double what he would if not under this system? I think that in loser-pays countries, the fees charged by the winning side must meet some standards of reasonableness or not exceed some more fixed limits or, at least, the recoverable amount is capped by some limits, etc.
There is another side effect of this as well. It increases the incentives for you to win, because absolutely no one wants to pay the other side's fees. I don't know if this is a good thing or a bad thing. On the one hand it pushes lawyers to do their utmost for their clients. On the other hand, it goes against my sense that the courts should be used to find the "truth," make aggrieved parties whole, and punish scofflaws and other offenders for the benefit of the public good. Our advisarial system (which I tend to support) already makes the goal winning rather than thruth-finding. I'm not sure that I would want to increase that effect.
The other thing you should note, is that in suing a large company, many of these cases would be handled by in-house counsel who are salaried. This is different from outside counsel who bill by the hour (and include margins to cover cases that they don't win, etc.). In those cases, a loser who sued a large corp. who used their in-house lawyers would only have to pay salaries for those attorneys that participated in the litigation and actual expenses. This fact would certainly drive companies to use outside counsel for all their litigation needs, thereby making them harder to sue and driving up the costs to corporations to defend themselves in court (they can't win 'em all).
Finally, juries can be weird. Just because you win a case, it doesn't mean you should have. I'm not sure we would want to further muck up our system by further penalizing the losing side in cases that they shouldn't have lost. There are already numerous situations where statute allows for the seeking of attorneys fees (often at the judge's discretion, as in this case). Perhaps more of this sort of thing is in order.
Active yogurts have been available in the US for decades if not centuries. Activa is just the first product that I've seen to specifically mention its active cultures as a cure for certain ailments in its advertising. It's really just new marketing (and good marketing, IMO).
The thing with Ubuntu's (and many other Linus distros) admin prompts is that once you've typed your password to open it up, it doesn't need it again for X minutes (where X is distro dependent, but it defaults to 15 on my Ubuntu box). That is, it's basically a GUI for sudo. I don't know if Vista can do this, or if it has to have the password box for evertything it needs to do.
They often calculate the effects of radiation from the fissile material on its surrounding container, the nearby electronics, etc.
It's not "fake" so much as it's an approximation. I guarantee you the know by exactly how much they are in error (but not in what direction!). The Schroedinger Equation that is at the heart of this represents the probability (well its modulus does, at least) of something as a continuous function of space and time. These scientists make errors in that the equations that they use are discrete (in terms of mathematical degrees of freedom, strictly speaking, by discretizing space and time directly) models of the Schroedinger equation and in that the initial and boundary are not perfectly well known. That doesn't constitute "faking it" in my book. If they were faking it, they'd be making pretty pictures with no predictive value, and presuably their work makes good predictions, which, as you note, puts it in the category of "good science."
It's my understanding that R2 and Compute Cluster Edition are incompatible. Has that changed? Also, is it possible to make a statically-linked binary under Windows that uses SUA? If not, you'd have to have it everywhere.
Actually they have an API lock-out strategy:
MS-MPI is (last I heard, at least) incompatible with Windows Services for UNIX, so if your MPI code is POSIXy, you're going to have to port it over to Win32 before it will run on this new product. You don't have to rewrite the communications bits, but your I/O will have to be rewritten.
Breath/blood tests aren't "testimony," and therefore, the courts have ruled that the government can force you to comply. Giving out your encryption keys is most definitely testimony, so you can't be forced to give them up. They can get a warrant and look around on your computers, under your keyboard (for the sticky note), etc., though.
You could have had them enjoined from further distribution and sued for actual damages, and if you had registered it with the Copyright Office, you could have sued for satutory damages as well.
Why not just a number on the date line that tells us how many (approximately) submissions you got for this article before you chose to post it?