Greetings.
I'm one of the developers from Open MPI. We currently include ROMIO (just like everyone else), but we did two important things:
We properly wrapped it such that I/O requests are of type MPI_Request, not MPIO_Request. Hence, you can actually progress IO requests, generalized requests, and point-to-point requests in a single MPI_WAITALL (or MPI_TESTALL, or any of the other variants)
Our MPI-2 IO support is based on a component framework -- so replacing ROMIO is not only easy, it's encouraged! We had always intended ROMIO to be a stopgap soltuon until we could implement "something better" (as yet to be defined). We would love to have someone with expertise in this area to a) help define what a "better" component interface should be (our ROMIO interface is a simple one-to-one function mapping), and b) write one or more components to implement this in a generic and/or proprietary way.
That's a long way of saying: "E-mail me and let's talk.":-)
Actually, when you activate your Telocity Gateway, you have to agree to the terms of service -- there's a click-through screen before you actually sign up for the service, etc., etc.
How many times do you actually sign for anything these days? When was the last time you bought something on the internet? You just gave them your credit card number, right?
Also, re-read my original post:
I've been a Telocity customer for a few years now... I *distinctly* remember the clause about paying for the modem if you don't return it.
That clause has always been there. It only makes sense: they're loaning you the modem -- you never paid for it. The user is never given any illusion of ownership of the modem. Heck, that's one of the reasons why I chose Telocity -- so I didn't have to pay extra for a modem. What do I need a DSL modem for after I've terminated the service?
If you say you couldn't find it on their web site, then you must not have been looking hard; I found it in under 30 seconds.
I've been a Telocity customer for a few years now, and I've been mostly pleased with their service. I *distinctly* remember the clause about paying for the modem if you don't return it. Read your contracts more clearly. There have been a few blips now and then, but all in all:
- they support linux (I got a RedHat engineer on the phone from tech support when I had problems DHCPing to my Telocity Gateway)
- they allow NAT (doesn't cost extra)
- they allow you to run servers (sshd, etc.)
- in some places (like Louisville, KY), you get a fixed IP
I think that you are missing the point here. The point is not to remove the telnet and ftp clients, the point is to remove the telnet and ftp servers.
Sure -- you need telnet for checking that you installed sendmail correctly, that your WWW server functions properly, etc., etc. And there are more anonymous FTP servers than you can shake a stick at (what would I do if I couldn't reach ftp.gnu.org?).
I think the intent is for.edu sites to remove these services to eliminate two common ways for sending cleartext passwords across the net where they can easily be sniffed. And this is only a start. How many.edu sites use unencrypted POP and IMAP servers? Mine does, regardless of how much we yell and scream that this is a Bad Idea. Hence, I run my own SSL/IMAP server.:-(
You'd be surprised how many students use telnet to check mail and ftp to move their files between systems, simply because they don't know any better (or don't care). I can't tell you how many times I've heard, "Oh, no one would care about my account...". <sigh>
Education is [part of] the real answer, definitely, but in the mean time, a little enforcement isn't a bad idea. I'm not saying that this is a total answer -- far from it. Education, proper multi-layered network security designs, and adequate monitoring go a long way to make a network "secure" (as much as it can be, anyway).
I would have to agree -- it's all about optimization. In addition to good code, you must have a good optimizing compiler (regardless of your language).
And the fact of the matter is, the author of the article neglected to mention that gcc's optimizer is well known to be horrible.
Conventional programming wisdom is that "the compiler's optimizer can do far more than you could ever do in your source code". This is an indisputable fact, since the compiler optimizes not only the high-level language (e.g., C), it also optimizes at the assembly level, even taking into account specific assembly instructions for the architecture that you are running on.
Don't get me wrong -- gcc is a fine compiler. But anyone who knows anything about high performance computing knows and acknowledges that gcc is not used for performance-oriented code. One reason for this is because one of gcc's main goals is to be portable. As an author of portable unix software, I can appreciate how demanding this task is. Making software portable is extremely time-consuming and resource-demanding. Making software high performace is doubly so, particularly across multiple platforms and operating systems. It is extremely difficult to get both high portability and high performance, particularly for something as large and complex (and system-depedant) as a compiler.
gcc has (rightly, IMHO) chosen to emphasize portability and give reasonable optimization (vs. extraordinary optimization).
More conventional wisdom -- this time from the "Beowulf" side of the fence -- get your hardware cheap (i.e., x86), pay for good RAM and hard disks, but don't pay for any software except for a commercial compiler. There are several vendors who produce very high quality C compilers for x86/Linux, and there's even at least one freeware effort that has produced a pentium-optimized version of gcc (Mandrake Linux uses this compiler, for example). The difference in real-world performance between code produced by gcc and code produced by a good optimizing compiler can be measured in orders of magnitude.
So while the rest of his article seemed to be reasonable (although admittedly short and incomplete), I believe that the results are extremely skewed by using gcc as the "base-C" and "max-C" cases. I would like to see the tests re-done with a better compiler.
Final note: why does it matter how long it takes you to come up with a good set of optimization flags for a C/C++ compiler? By definition, optizations are highly configuration-specific (e.g., OS, architecture, etc.). The fact of the matter is that they can provide substatintial performance improvements. Java, despite the uniformity of VM behavior across platforms, might very well benefit from the same thing (it may only be a matter of time before such specific optimization flags are introduced, anyway).
Slashdot Mirror
- We properly wrapped it such that I/O requests are of type MPI_Request, not MPIO_Request. Hence, you can actually progress IO requests, generalized requests, and point-to-point requests in a single MPI_WAITALL (or MPI_TESTALL, or any of the other variants)
- Our MPI-2 IO support is based on a component framework -- so replacing ROMIO is not only easy, it's encouraged! We had always intended ROMIO to be a stopgap soltuon until we could implement "something better" (as yet to be defined). We would love to have someone with expertise in this area to a) help define what a "better" component interface should be (our ROMIO interface is a simple one-to-one function mapping), and b) write one or more components to implement this in a generic and/or proprietary way.
That's a long way of saying: "E-mail me and let's talk."This story seems to have jumped the gun a few hours; the 1.0 tarballs don't seem to be available yet.
However, you can download the latest Subversion sources from its Bitkeeper repository... no, wait...
I've been a Telocity customer for a few years now... I *distinctly* remember the clause about paying for the modem if you don't return it.
The clause has always been there. Why would a company give you a DSL modem for free and then let you keep it? The fact is that the modem is a loaner.
How many times do you actually sign for anything these days? When was the last time you bought something on the internet? You just gave them your credit card number, right?
Also, re-read my original post:
I've been a Telocity customer for a few years now... I *distinctly* remember the clause about paying for the modem if you don't return it.
That clause has always been there. It only makes sense: they're loaning you the modem -- you never paid for it. The user is never given any illusion of ownership of the modem. Heck, that's one of the reasons why I chose Telocity -- so I didn't have to pay extra for a modem. What do I need a DSL modem for after I've terminated the service?
For those of you who haven't bothered to check, sending the Telocity gateway back when the service is over is right in their service agreement:
http://www.directvdsl.com/products/agreement.asp
If you say you couldn't find it on their web site, then you must not have been looking hard; I found it in under 30 seconds.
I've been a Telocity customer for a few years now, and I've been mostly pleased with their service. I *distinctly* remember the clause about paying for the modem if you don't return it. Read your contracts more clearly. There have been a few blips now and then, but all in all:
- they support linux (I got a RedHat engineer on the phone from tech support when I had problems DHCPing to my Telocity Gateway)
- they allow NAT (doesn't cost extra)
- they allow you to run servers (sshd, etc.)
- in some places (like Louisville, KY), you get a fixed IP
How can you argue with that?
Does this make... a Crayowulf?
Sure -- you need telnet for checking that you installed sendmail correctly, that your WWW server functions properly, etc., etc. And there are more anonymous FTP servers than you can shake a stick at (what would I do if I couldn't reach ftp.gnu.org?).
I think the intent is for .edu sites to remove these services to eliminate two common ways for sending cleartext passwords across the net where they can easily be sniffed. And this is only a start. How many .edu sites use unencrypted POP and IMAP servers? Mine does, regardless of how much we yell and scream that this is a Bad Idea. Hence, I run my own SSL/IMAP server. :-(
You'd be surprised how many students use telnet to check mail and ftp to move their files between systems, simply because they don't know any better (or don't care). I can't tell you how many times I've heard, "Oh, no one would care about my account...". <sigh>
Education is [part of] the real answer, definitely, but in the mean time, a little enforcement isn't a bad idea. I'm not saying that this is a total answer -- far from it. Education, proper multi-layered network security designs, and adequate monitoring go a long way to make a network "secure" (as much as it can be, anyway).
And the fact of the matter is, the author of the article neglected to mention that gcc's optimizer is well known to be horrible.
Conventional programming wisdom is that "the compiler's optimizer can do far more than you could ever do in your source code". This is an indisputable fact, since the compiler optimizes not only the high-level language (e.g., C), it also optimizes at the assembly level, even taking into account specific assembly instructions for the architecture that you are running on.
Don't get me wrong -- gcc is a fine compiler. But anyone who knows anything about high performance computing knows and acknowledges that gcc is not used for performance-oriented code. One reason for this is because one of gcc's main goals is to be portable. As an author of portable unix software, I can appreciate how demanding this task is. Making software portable is extremely time-consuming and resource-demanding. Making software high performace is doubly so, particularly across multiple platforms and operating systems. It is extremely difficult to get both high portability and high performance, particularly for something as large and complex (and system-depedant) as a compiler.
gcc has (rightly, IMHO) chosen to emphasize portability and give reasonable optimization (vs. extraordinary optimization).
More conventional wisdom -- this time from the "Beowulf" side of the fence -- get your hardware cheap (i.e., x86), pay for good RAM and hard disks, but don't pay for any software except for a commercial compiler. There are several vendors who produce very high quality C compilers for x86/Linux, and there's even at least one freeware effort that has produced a pentium-optimized version of gcc (Mandrake Linux uses this compiler, for example). The difference in real-world performance between code produced by gcc and code produced by a good optimizing compiler can be measured in orders of magnitude.
So while the rest of his article seemed to be reasonable (although admittedly short and incomplete), I believe that the results are extremely skewed by using gcc as the "base-C" and "max-C" cases. I would like to see the tests re-done with a better compiler.
Final note: why does it matter how long it takes you to come up with a good set of optimization flags for a C/C++ compiler? By definition, optizations are highly configuration-specific (e.g., OS, architecture, etc.). The fact of the matter is that they can provide substatintial performance improvements. Java, despite the uniformity of VM behavior across platforms, might very well benefit from the same thing (it may only be a matter of time before such specific optimization flags are introduced, anyway).