Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!eru!luth!sunic!dkuug!freja.diku.dk!skinfaxe.diku.dk!jensting From: jensting@skinfaxe.diku.dk (Jens Tingleff) Newsgroups: comp.lang.fortran Subject: Re: Fortran (LONG, you may think it's religious.) Message-ID: <1990Jul27.104113.21605@diku.dk> Date: 27 Jul 90 10:41:13 GMT References: <11053@chaph.usc.edu> Sender: news@diku.dk (The Netnews System) Organization: Department Of Computer Science, University Of Copenhagen Lines: 33 ajayshah@aludra.usc.edu (Ajay Shah) writes: >(LONG!) [..] (nice article) I'm no fan of FORTRAN (hehehe, I'm only here to anoy you) either. For my master thesis I wrote a program that does contrained quadratic integer programming, where the cost and contraint functions rely *heavily* on data coded as sets. Once previously, a FORTRAN program had been written for this task. On our "IBM 370 VM/rfghj{lkjhg" computer this FORTRAN program executed our standard test in a mere four CPU-minutes. My first version (written in Modula-2) executed the same computation in 3.5 minutes *on-a-8-MHz-PC* The problem was, of course, data structure, in that the original FORTRAN program used arrays of INTEGERs as set data, testing for superset-relation in a DO loop. Modula-2 used bit-maipulations, supported in a small way by the hardware in the PC (but not in a big way, my sets where 64 elements large, hence a multiword representation was used by the compiler *transparantly*). Now, no-one ever claimed that the original FORTRAN program was optimal, but the fact that such terrible performance was obtained (by someone with a lot of experience in coding this particular algorithm) with FORTRAN is a living tribute to the, ahemm, futileness of coding in a language with insufficient data structuring. Jens Jens Tingleff MSc EE, Institute of Computer Science, Copenhagen University Snail mail: DIKU Universitetsparken 1 DK2100 KBH O "It never runs around here; it just comes crashing down" apologies to Dire Straits