sm@sys.uea.ac.uk (Shaun McCullagh CMP RA) (06/02/89)
Does anyone have experience of 3L's Parallel Fortran on a PC ? We are thinking of using said compiler, to perform finite element analysis, but understand that the debugging tools are somewhat 'basic' Thanx in advance ####################################################################### Shaun McCullagh, University of East Anglia, School of Information Systems, Norwich ENGLAND NR4 7TJ Email: sm@uk.ac.uea.sys #######################################################################
nick@lfcs.ed.ac.uk (Nick Rothwell) (06/02/89)
In article <582@sys.uea.ac.uk>, sm@sys (Shaun McCullagh CMP RA) writes: >Does anyone have experience of 3L's Parallel Fortran on a PC ? > >We are thinking of using said compiler, to perform finite element >analysis, but understand that the debugging tools are somewhat 'basic' > >Thanx in advance Why not give them a call? (0506 415959.) Admittedly, that might only give the Pros, not the Cons... Disclaimer, I don't work for 'em, and I'm allergic to Fortran, but I know the guys. >Shaun McCullagh, University of East Anglia, School of Information Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Fais que ton reve soit plus long que la nuit.
csa@ADAM.BYU.EDU (Lyle Bingham) (06/02/89)
In responding to your request for debugging help with 3L Parallel FORTRAN I would suggest you could explore Parasoft's EXPRESS and NDB debugger. It is available now from various distributors. I would suggest you contact Parasoft at 714-380-9739 (Larry Lessor). If you send a private message with your address I can send literature. Larry can provide the same as well as a list of U.K. distributors. Rumor has it that 3L and everyone else is coming out with debuggers this fall. I believe 3L has shown one in your area (prototype) this last month. For more information in the U.K. call Neil Heywood at 3L 0506-415959. Best Regards, Lyle Bingham Computer System Architects, 950 N. University Avenue, Provo, UT 84604 (801) 374-2300 -- (801) 374-2306 FAX -- Network access courtesy of BYU CSA is not associated with BYU in any manner. Opinions are my own ...
stein@pixelpump.osc.edu (Rick 'Transputer' Stein) (06/03/89)
In article <8906021359.AA18991@adam.byu.edu> csa@ADAM.BYU.EDU (Lyle Bingham) writes: >In responding to your request for debugging help with 3L Parallel FORTRAN >I would suggest you could explore Parasoft's EXPRESS and NDB debugger. >It is available now from various distributors. I would suggest you >contact Parasoft at 714-380-9739 (Larry Lessor). If you send a private >message with your address I can send literature. Larry can provide the >same as well as a list of U.K. distributors. > >Rumor has it that 3L and everyone else is coming out with debuggers this >fall. I believe 3L has shown one in your area (prototype) this last month. >For more information in the U.K. call Neil Heywood at 3L 0506-415959. > >Best Regards, > >Lyle Bingham >Computer System Architects, 950 N. University Avenue, Provo, UT 84604 >(801) 374-2300 -- (801) 374-2306 FAX -- Network access courtesy of BYU >CSA is not associated with BYU in any manner. Opinions are my own ... Rumor, rumor, rumor. That's all I hear is rumors. I'm here to tell ya', that breakpoint debugging is only effective for purely synchronous (aka SIMD style) execution contexts. My opinion has it that this class of problems is somewhat narrow, but still significant. It is a function of your system requirements. However, just chuck in a little tiny bit of asynchonous execution, and then see what a breakpoint debugger does for you. Real-time multicomputers are a linear combination of both sync and async processes. Debugging the asynchronous thread is the nasty question to answer. Its kinda' equivalent to a Schaum's outline in Fourier Series: Here's the example anamalytic set, now try it on the industrial scale where there's real-world nonlinearity. How do you do it? I'm not gonna try to answer this question. Rather, I suggest a shared memory emulation of the process structure using Pi, from T.A. Cargill and AT&T. I think its ludicrous to pretend that one can preserve asynchronous process fidelity with an intrinsically sequential debugger. A debugger is tool, much like a crutch is to a cripple, for examining the logical process flow, an activity that can be conducted on a simple piece of paper. I will state that I also use symbolic debuggers, so I'm not immune to the "what the hell's going on syndrome." Yet, the transputer was built with logical concurrency in mind. That's the ticket to linear scalable software, the thing that's gonna' save everyone. What's important to recognize is that not everyone's needs can be resolved by a single solution, much like pencillin can kill only the non-resistant form of you know what. So, I suggest that the debug builders keep in mind a more global set of requirements. This would be a great help to the "other side" of engineering. The side that must face that industrial world of intrinsically asynchronous execution, like a pilot reacting to a propulsion unit failure in the middle of a dogfight. How do you handle it? ***** ***** Disclaimer: These opinions are solely those of the author and do ***** not represent, nor should they be construed as the opinions of the ***** Ohio Supercomputer Center, The Ohio State University, or its ***** affiliates. ***** -=- Richard M. Stein (aka Rick 'Transputer' Stein) Concurrent Software Specialist @ The Ohio Supercomputer Center Ghettoblaster vacuum cleaner architect and Trollius semi-guru Internet: stein@pixelpump.osc.edu