robert@zeus.ee.uwa.oz.au (Roberto Togneri) (11/06/90)
Hi, I have been experimenting with our transputers to allow faster execution times to be achieved over our IRIS workstations. The personal IRISes are rated at 10 MIPS and use a MIPS CPU including the floating point unit. The transputers are a mix of t800d and t800c chips (and a T414 root) running at 20 Mhz and I am lead to believe that they can achieve 10 MIPS. With a 10 t800 transputer array then I expect to go at least 7 times faster than the IRISes. Well all I've been able to get is 1.5 times faster! I use the optimiser on the IRIS compiler (cc -O prog.c) and am using 3L parallel C (v2.0) for the transputers (t8c prog.c). Thinking that my program was at fault (parallel programming ain't easy) I ran two similar programs on the IRIS and a t800. And lo! The IRIS was 5 times faster. Is this expected? How fast are the t800's? How good is the compiler? What am I doing wrong? If somebody can shed some light on this I would really appreciate it. -- Dr. Roberto Togneri Dept. of EE Engineering Phone: +61-9-380-2535 The University of Western Australia Fax: +61-9-380-1065 NEDLANDS WA 6009 Email: robert@swanee.ee.uwa.oz.au
jeremy@cs.adelaide.edu.au (Jeremy Webber) (11/06/90)
In article <robert.657783594@zeus> robert@zeus.ee.uwa.oz.au (Roberto Togneri) writes:
I have been experimenting with our transputers to allow faster
execution times to be achieved over our IRIS workstations.
[stuff about the PI and t800]
What is the memory speed of your Transputer board. As the transputer does not
implement a cache system (the on-chip RAM does not count as a cache) memory
speed is likely to be critical to your execution speed.
Have you tried comparisons with Transputer tools other than 3L C? I am
interested as I am considering the purchase of a C system to replace our
current (TDS2) Occam based development environment, but performance is critical
in our application.
-jeremy
--
--
Jeremy Webber ACSnet: jeremy@chook.ua.oz
Digital Arts Film and Television, Internet: jeremy@chook.ua.oz.au
3 Milner St, Hindmarsh, SA 5007, Voicenet: +61 8 346 4534
Australia Papernet: +61 8 346 4537 (FAX)apfiffer@admin.cse.ogi.edu (Andy Pfiffer) (11/07/90)
In article <robert.657783594@zeus> robert@zeus.ee.uwa.oz.au (Roberto Togneri) writes: >ain't easy) I ran two similar programs on the IRIS and a t800. >And lo! The IRIS was 5 times faster. Is this expected? >How fast are the t800's? How good is the compiler? What am I >doing wrong? Although you don't indicate which model Iris (some have R2000+2010, others have R3000+3010 clocked at a variety of freqs.), I'm surprised that your T800 actually performed that well. My rule-of-thumb (based on experience with actual, real-life customer code) is that a 20MHz T800 with a simple external memory interface is approximately equal to a MC68020-20 + MC68881. Mitigating factors: o If you're code has a sqrt() in the inner loop, the T800 will perform well. o If you're code can operate on data that resides in on-chip RAM and your subroutine can fit in there too (ruling out large arrays), the T800 will perform well. o If you're code is written in Occam, your code will show unmeasurable performance gains over nearly any other platform. :^) o Compilers. o External memory interfaces. Smarter, page-mode DRAM memories or SRAM memories may give you a 10% to 100% boost in performance. o Any modern RISC chip. >-- >Dr. Roberto Togneri >Dept. of EE Engineering Phone: +61-9-380-2535 >The University of Western Australia Fax: +61-9-380-1065 >NEDLANDS WA 6009 Email: robert@swanee.ee.uwa.oz.au -- Andy Pfiffer (503) 645-1886 apfiffer@admin.ogi.edu Formerly w/ Cogent Research, Formerly w/ Topologix, Formerly w/ Theory Center. "To determine where to resume execution upon leaving the trap handler, examine the instruction at address fir - 4. If this instruction is not a delayed control instruction, the execution resumes at the address in fir - 4."
dlt@devnet.la.locus.com (Dan Taylor) (11/07/90)
Does the T800 still lack a barrel shifter, which would cause all shift operations to take an excessive amount of cycles? -- * Dan Taylor * The opinions expressed are my own, and in no way * * dlt@locus.com * reflect those of Locus Computing Corporation. *