[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Performance
- To: HMADORF@ESO.ORG, INFO-MCL@CAMBRIDGE.APPLE.COM
- Subject: Re: Performance
- From: UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,GB,IDV)
- Date: 28 Sep 92 21:54 GMT
Hans-Martin,
>Any clue how to improve the performance?
Yes, and it is easy - code it in assembler on the fastest machine that you can
get your hands on. Ideally, something like Transputer assembler (or possibly
occam) on a huge array of Transputers, with carefully designed parallelism.
Whilst you are doing that, I will probably have written three or four complete
applications in MCL and/or MacApp. *That* is where the speed is, in the
development.
I write a lot of number-intensive code for various applications. It is my
experience that I probably only spend 2-5% of my development time coding
numerical work, whilst I spend at least 30% of my time writing all the rest of
the stuff (particularly user interface, file handling, etc.), and the great
majority of my time debugging. MCL's wonderful incremental compilation,
built-in GUI classes, and all its other power features, mean that the actual
time spent doing non-numeric coding and debugging is *very* much less.
Now, that means that if you are writing an application that will be designed
and written once and run for many thousands of hours afterwards - with no
maintenance - than MCL is a bad choice for numerical work. I am sure that you
can tune your code a bit, but CL carries a lot of overhead, and you should
really resort to the use of foreign (C) functions and other dirty tricks, or
even better just write the whole lot in assembler as I suggested above.
However, I have not yet come across any useful application which has that sort
of lifetime - everything that I know of has prolonged development periods,
several different versions, etc., and probably spends almost as much time in
development as in use (I do a lot of vertical market software!). In that case,
MCL is an excellent choice, as the performance decrement is more than
compensated for by the huge reduction in development and maintenance.
That is your choice, but I know which way *I* am heading...
Howard.