hblim@sp1.csrd.uiuc.edu (Hock-Beng Lim) (05/20/91)
I would like to know if STRAND 88 is public-domain, and if so, where can I obtain it. Thanks in advance for any info ! HB -- --------------------------------------------------------------------- Hock-Beng Lim Center for Supercomputing R&D hblim@csrd.uiuc.edu Univ. of Illinois at Urbana-Champaign -- NIL SINE LABORE --
will@uunet.UU.NET (William Pickles) (05/21/91)
hblim@sp1.csrd.uiuc.edu (Hock-Beng Lim) writes: >I would like to know if STRAND 88 is public-domain, and if so, where can I >obtain it. Thanks in advance for any info ! 'fraid not we got a bankmanager and kiddies to feed Best Wishes though William Pickles Strand Software -- =========================== MODERATOR ============================== Steve Stevenson {steve,fpst}@hubcap.clemson.edu Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
warren@eecs.cs.pdx.edu (Warren Harrison) (05/23/91)
In article <1991May20.025248.26252@csrd.uiuc.edu> hblim@sp1.csrd.uiuc.edu (Hock-Beng Lim) writes: >I would like to know if STRAND 88 is public-domain, and if so, where can I >obtain it. Thanks in advance for any info ! > Strand isn't public domain. It is available in the U.S. from their U.S. distributor: 18235 Monte Verdi Blvd. Aloha 97007 503-642-0151 We've been using Strand extensively here at PSU, and I've found it to be a great language for teaching parallel programming. They seem to support a number of platforms: Sequent, Intel iPSC, Sun Workstations, etc. (but no MS-DOS version yet :-) Strand is neat in that it simulates parallelism even if you don't have multiple processors (or enough processors) by creating "virtual cpus". We regularly develop Strand applications on a 2 CPU Sequent (because it's local) and then run the application on a Sequent with (many) more CPUs at our research institute, without having to make any changes to the source. This way my students can develop their applications without annoying people who are trying to use the research platform, but still can see and measure speedup on a final set of runs. We've also found that the overhead added by Strand isn't all that bad, so applications written in Strand don't run much slower than ones written in FORTRAN. The downside is that Strand requires you to carry around a run-time package, so you can't make stand alone executables to distribute to people. I have no financial connection with Strand, I'm just a satisfied user. ========================================================================== Warren Harrison warren@cs.pdx.edu Center for Software Quality Research 503/725-3108 Portland State University/CMPS -- =========================== MODERATOR ============================== Steve Stevenson {steve,fpst}@hubcap.clemson.edu Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
hawley@uunet.UU.NET (David John Hawley) (05/24/91)
In article <1991May23.180217.9427@hubcap.clemson.edu> eecs!warren@uunet.UU.NET (Warren Harrison) writes: >We've also found that the overhead added by Strand isn't all that bad, >so applications written in Strand don't run much slower than ones written >in FORTRAN. The downside is that Strand requires you to carry around a Hmmm. I know that Prolog compiler technology has advanced a great deal recently (yes, I know that Strand is not Prolog!), but I still would expect Strand to run maybe an order of magnitude slower than FORTRAN or its ilk. I know that Argonne National Labs was using hybrid Strand-FORTRAN programming to overcome Strand's overhead, and I've heard it rumoured that they are developing a parallel language which is moving further in the FORTRAN direction. All this to say "Can you explain why or demonstrate how (i.e. benchmarks) Strand isn't much slower than FORTRAN?" David Hawley -- Location: 4th-lab, ICOT, 1-4-28 Mita, Minato-ku Tokyo 108 JAPAN. EMail: hawley@icot.or.jp, hawley@icot.jp@relay.cs.net, uucp:{enea,inria,kddlab,mit-eddie,ukc}!icot!hawley -- =========================== MODERATOR ============================== Steve Stevenson {steve,fpst}@hubcap.clemson.edu Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
will@uunet.UU.NET (William Pickles) (05/28/91)
kddlab!icot31.icot.or.jp!hawley@uunet.UU.NET (David John Hawley) writes: >In article <1991May23.180217.9427@hubcap.clemson.edu> eecs!warren@uunet.UU.NET (Warren Harrison) writes: >>We've also found that the overhead added by Strand isn't all that bad, >>so applications written in Strand don't run much slower than ones written >>in FORTRAN. >All this to say "Can you explain why or demonstrate how (i.e. benchmarks) >Strand isn't much slower than FORTRAN?" I dont think Warren Harrison was saying that Strand in itself was not much slower than Fortran. The benchmarks shown by Argonne indicated that where Strand was used to construct the optimal parallelizing harness for an application the *slowdown* due to Strand was not noticeable when the application itself was achieving pretty much linear *speedup* on multiple processors. Where an application only spends 1-5% of wall clock time in the Strand layer you dont notice the performance hit of that layer. William Pickles STRAND Software Blatant Commercial hit follows ( hit space bar if you are sensitive) Strand is being continuously improved. Native code compilation is a project under current development. New compilation strategies are being finetuned for release. The product is now available on networks of Unix V rel 3,4 workstations subject only to compilation and your funds. -- =========================== MODERATOR ============================== Steve Stevenson {steve,fpst}@hubcap.clemson.edu Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell