Re: Optimizing the Speed / Design tradeoff in numeric applications
- From: CBFalconer <cbfalconer@xxxxxxxxx>
- Date: Tue, 17 May 2005 19:56:36 GMT
Randy wrote:
> Jonathan Bartlett wrote:
>
>> I'm working on a program that is fairly numerically intense.
>> Most of my work to date has been mostly business data processing,
>> so scientific processing is somewhat new to me.
>>
>> The application is a multivariate analysis technique. Anyway, I
>> got the program done, but my solutions left me with questions I
>> thought I'd ask you all regarding mathematical applications.
>>
>> The program took three points from n-dimensional space and did
>> calculations to arrive at three values, named d2, t0 and theta.
>> Each value is a function of the three points. However, many of
>> the subcalculations for each value are shared.
>>
>> So, the design side of me says that I should separate each
>> calculation into it's own function/module, so that we have:
>>
>> d2 = calc_d2(p1, p2, p3);
>> t0 = calc_t0(p1, p2, p3);
>> theta = calc_theta(p1, p2, p3);
>>
>> What I like about this method is that it truly separates
>> concerns. However, many of the subcalculations for d2, t0, and
>> theta are shared. Thus, separating the calculations in this way
>> is bad for speed, as the same pieces will have to be continually
>> recalculated.
>>
>> An alternate way would be to do:
>>
>> subcalc1 = perform_subcalc1(p1, p2, p3);
>> subcalc2 = perform_subcalc2(p1, p2, p3);
>> ...
.... snip ...
>
> I agree with Pete that whenever possible, design should trump
> speed.
>
> However, in general, I've found that a clean design that
> emphasizes simplicity is usually faster than a convoluted design
> that emphasizes speed. This is because modern compilers are
> often very good at deducing your intent from your code and
> maximizing optimizations on your behalf, especially when your
> coding style is clean and straightforward.
I think you are trusting compiler optimization too far.
My attitude would be to first separate the external world
interface. The gazinta is p1, p2, p3. The gazouta is d2, t0,
theta. At least define the gazouta as a structure in C, or as a
record in better languages.
typedef struct gazouta {
int d2; /* or whatever */
int t0;
double theta;
} gazouta;
for example. Now you can define:
gazouta transform(int p1, int p2, int p3)
{
gazouta returnvalue;
...
return returnvalue;
} /* transform */
and worry about the details later, secure in the knowledge that
they are confined to the transform function. Pascal and Ada can be
helpful here in that they can have local functions and procedures
that can reference the inputs to transform as needed. In C you
will have to pass those values about with specific parameters.
My inclination, strictly within transform, would be to define some
locals and execute
localone = makevalue(p1, p2, p3);
etc. The makevalue functions will be static, which is about as
close to a local function as you can get in C.
--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
.
- References:
- Optimizing the Speed / Design tradeoff in numeric applications
- From: Jonathan Bartlett
- Re: Optimizing the Speed / Design tradeoff in numeric applications
- From: Randy
- Optimizing the Speed / Design tradeoff in numeric applications
- Prev by Date: Re: Google Groups: Searching *ONLY* for usenet groups ????
- Next by Date: Re: AAS degrees and/or Certifications
- Previous by thread: Re: Optimizing the Speed / Design tradeoff in numeric applications
- Next by thread: Re: Optimizing the Speed / Design tradeoff in numeric applications
- Index(es):
Relevant Pages
|
