Slashdot Mirror

← Back to Domains

Domain: open-mpi.org

Stories and comments across the archive that link to open-mpi.org.

Comments · 8

  1. What's the Goal? by TreeInMyCube · · Score: 2 · on Ask Slashdot: Building a Cheap Computing Cluster?

    Functioning computer systems are rarely useless; the E8000 systems the OP has will run software just like they did a few years ago when they were purchased. The most important question is: what do you want this cluster to do? If you want the experience of building it, including solving the HW issues of racking and stacking, and the software issues of cluster management software, job scheduling and resource management, then don't throw the equipment away. There are many opportunities for making decisions that require problem-solving and resourcefulness. Plenty of FOSS solutions, even while using only the built-in network connections for an interconnect. If you have some HPC or scientific cluster-aware software in mind that you want to run, tailor your software configuration to run that. The folks who built Beowulf clusters in the early 2000s had a goal in mind; often, that goal was to provide an environment to develop their own MPI software to simulate some phenomena they were interested in. Are you a programmer, or want to learn parallel programming? Are you offering your cluster to folks who are learning parallel programming? http://www.open-mpi.org/ has good information, and FOSS implementations for Linux distributions. There are also Windows clustering solutions, if that's what your user base requires; not free, obviously. So, what do you want this cluster to do?

  2. Re:I still don't like IPv6 by Cajal · · Score: 1 · on Comcast To Bring IPv6 To Residential US In 2010

    Sure IPv6 has it all. But I doubt any ISP will do business any differently with IPv6 than otherwise. In fact, they'll just salivate that any caps will be reached a bit quicker because of the increased IPv6 header size. Mobile operators are probably salivating as well - 5 cents per kilobyte (not kiB), which includes the OTA headers, plus increased IPv6 header size

    Could we please stop it with the baseless assertions that the extra 20 bytes in an IPv6 header will cause so many problems? There is no evidence at all to support this claim. The best example of now IPv6 header size is a non-issue is a paper about adding IPv6 support to OpenMPI. The developers investigated potential performance impacts of running MPI over IPv6 in a cluster. They found a whopping 1.4% drop in throughput and no increase in latency (section 4.1). If IPv6 shows such little hit in a such a sensitive environment, I'm very confident that it will work fine in broadband and cellular access networks.

    Further, if you were really so concerned with bandwidth, you'd stop using HTML, since it's a remarkably inefficient encoding system.

  3. Re:Pricing Rational? by MrMr · · Score: 1 · on Average User Only Runs 2 Apps, So Microsoft Will Charge For More

    I'm sure it's not as easy as it sounds...
    It's trivially simple using mpi for instance.
    Or you could just run a few dozen wine session each with a single windows app from your linux desktop.

  4. Re:You hit the nail right on the head by Pausanias · · Score: 2, Informative · on IBM's Chief Architect Says Software is at Dead End
    Er, C is in "limited use?" How about all of GNU software, the linux kernel, and all of GNOME, which are written in C (not C++ or anything else), and even large parts of Apple's OS X Darwin kernel?

    Regarding multicore CPUs, there already plenty of parallelization packages linkable directly into C (e.g. the various MPI implementations). All you have to do is structure your for loops to make use of it. Once you do that, you can run each iteration of the loop on a separate core via MPI or something similar, thus fantastically improving your code execution time and making full use of all your cores.

    Heck, with your OS's built-in threading calls, you can do this even without MPI, as long as you can make your for loops thread-safe. Interestingly, OS X does this all the time---in Activity Monitor you can see the number of threads your processes have spawned. The kernel usually has the most, and iTunes, iMovies, etc usually have a few as well. Expect this number to go up when cpus with dozens of cores come out. And, of course, linux has the same functionality, though I've seen fewer linux apps that actually make significant use of multiple threads. They'll come soon, as long as the GNOME, etc. authors

    Well, programming languages come and go...of course, some of the "classics" are still in limited use (cobol, Pascal, C) but for the most part programming languages go the way of the dodo eventually.

    I would imagine that if these new multi-multi core procs are released into the wild in mass numbers, new programming languages will be developed that will enable things to be done more efficiently and easier....or perhaps a hybrid language: One half of the language is for writing processes for individual cores, while the other half acts as a "hub"....or even better, say you have 16 cores, and then one "central" core that acts like a post office...it doesn't actually create any of the mail, it just makes sure it gets delivered to the correct place.

    There is no way that the hardware would advance without the programming ability to back it up
  5. MPI & MOSIX by Anonymous Coward · · Score: 0 · on Ultra-Stable Software Design in C++?

    if "Basically, it allows users to crunch a god-awful amount of data over several computing nodes" is one of your requirements I would look at http://www.open-mpi.org/ and http://openmosix.sourceforge.net/. These two projects will provide you the library to create multi-node applications( MPI ) and a load balancer for your cluster( MOSIX ).

  6. MPICH2? What interests me... by jd · · Score: 3, Informative · on Open Source Code Finds Way into Microsoft Release
    ...is WHY they would choose the version of MPI that is regarded as a great reference edition but not that good for serious work. MPICH2 does not support shared libraries under Microsoft's C compiler or under Windows (MPICH2's docs) or external data representations. Their version of ROMIO also hangs when using MPI threads.


    (Also, MPICH sucks when used with multiple devices - you have to compile it with the device(s) you're using, and can only configure it for one device type at a time. So if you're planning on using a mix of Infiniband, Globus and Ethernet, forget it. It won't work.)


    Probably the best MPI library out there is Open MPI, which supports the MPI2 standard, supports MPI threads and progress threads, is much more optimizable for different platforms and was developed by groups ranging from Los Alamos Laboratories (yes, the nuke place) and the LAM/MPI development team.


    Ok, you have a choice between two implementations. One is slow, has a poor release cycle and has been forked numerous times (MPICH, MPICH2, MP-MPICH, Globus MPICH, GAMMA MPICH and MVICH are all forks off the same code-base). The other is partially written in assembler, is developed by a broad consortium of MPI experts and is unlikely to fork as the maintainers are really good about integrating new code. Which would you pick?


    I am also concerned about Microsoft's history of "Embrace and Extend' - are they planning on breaking the MPI-2 specifications for their own purposes? I can't see any value in them doing so, but I don't see any value in 'Embrace and Extend' anyway.

  7. This one's easy. by jd · · Score: 4, Informative · on Looking for Portable MPI I/O Implementation?
    First, you want to use Open MPI (the latest and greatest MPI implementation) or MPICH (which is not so good, but is solid and widely used, so will be easier to work with for portable I/O packages).


    Now, we move onto the portable I/O. The vast majority of scientific software (which is, in turn, the bulk of MPI-based software) uses the Heirarchical Data Format. There are two versions worthy of mention - HDF5 and Parallel HDF. Both support MPI in operations. Compile HDF5 with MPI support, and you have something that will support platform-independent atomic and compound data types.


    Of all the options, HDF5 (from the NCSA) is the most widely used. I would say that the majority of scientific and distributed software out there that uses platform-independent typing uses HDF. So does the grid computing system Globus. The other platform-independent complex data typing libraries, CDF (from NASA) and NetCDF (from UniData), are rarely used. Indeed, the next generation of NetCDF - version 4 - will be built on top of HDF5. There's a link to the development site and the source code on Freshmeat.


    Less-widely used, but still very significant, is the Transparent Parallel I/O Environment. I am not 100% sure if this supports MPI, it's been a while since I've used it and I never put in the dependencies on Freshmeat for it.


    Depending on what is being done, PETSc may also be worth checking out. This supports MPI-based differential equations.


    Globus can use MPI for communication and then handle the I/O directly. This means you only have to write your interface for one API, not one API per type of operation. Main problem is that Globus has a fairly large footprint, so you might not want to do that unless the project is large enough to warrant that kind of sophistication.

  8. If last resort try human-readable text by Krellan · · Score: 3, Informative · on Looking for Portable MPI I/O Implementation?

    I take it you've aleady read section 7.5 in MPIv2. If you haven't, now's the time!

    Unfortunately, I know of no other MPI I/O implementations, other than ROMIO, that can simply be plugged into an existing MPI stack. You might want to ask around at the new project OpenMPI, a new-from-the-ground-up MPI implementation that is currently in development. I'd be curious to learn the level of MPI I/O support that they claim!

    Assuming you are stuck with a MPI stack that only supports the "native" representation, the problem you face becomes one of data representation in general. As you know, there's bajillions of different ways of storing floating-point numbers, and if you write them to disk, the files will be only valid for exactly that CPU.

    As a last resort, a brute-force solution is to write the numbers as human-readable text, and then parse them in again accoringly. It's a waste of file space, but there's no ambiguity in the datatype representation, and it is very tolerant of floating point differences between machines.

    -1.2345234523452345
    2.345634563456365e+13
    -3.2121212121e-24
    And so on.

    This shouldn't be much of a hotspot in your code, since ideally it would only be done at start, stop, and checkpoint time. Also, if you need paralellism, and don't care about wasted file space or future precision improvements, you could use a fixed-length string for each number (with much padding), thus allowing you to read your numbers random-access instead of sequential.

    Hope this helps!

    Josh