Re: Re: Optimizing a compiler?

Re: Re: Optimizing a compiler?

[gerardo juarez-mondragon]

Using a profiler would certainly be a good idea,
since it is not obvious exactly where you will be
spending most of your CPU time. 

There is also a package called LINPACK or a
similar name. It is a standard set or numerical
routines in Fortran and C versions. It can be
freely downloaded as far as I remember (a couple
of years ago). The documentation was sold and
among the materials there was a manual for
creating high performance applications from Sun
or HP. It could be worth a look.

Another point would be to actually use some of
the routines I mention if possible, because they
are highly optimized and they are quite difficult
to surpass with handrolled code.
A final thought is that, if your execution times
are usually as you describe, your problem might
be eligible for parallel computing. Does your
algorithm/problem allow this approach? Linux has
 parallel computing capabilities -there are
several implementations.

Gerardo

Searching for the best free email?  Try MetaCrawler Mail, from the #1 metasearch service on the Web, http://www.metacrawler.com

Re: Re: Optimizing a compiler?

[Paul Furness]

I haven't tried a profiler yet but I agree from looking into it that
that is definitely a Good Idea. The code is indeed based around the
lapack libs, which are fairly fast.

As to the parallel processing: the problem is that the actual individual
bits of code can't be paralleled because each calculation depends on the
results of the last.

We are paralleling as much as possible by running multiple experiment
runs at the same time - we have 6 CPUs across 3 boxes, and since over
95% of the program involves numerical calculation with no I/O, SMP
machines are proving to be very, very nearly as efficient as 2 single
machines.

I'm investigating PVM to see if I can improve the automation of this
stuff - at the moment, I have to manually run each script on the next
available CPU, and sometimes they finish in the middle of the night so
there is a long gap between runs. Other parallel ideas might also work -
gridding the office workstations, for example. But that will only work
when the run time is less than about 10 hours on a single CPU. That
could be some time away.

P.




On Tue, 2002-10-22 at 19:08, gerardo juarez-mondragon wrote:
> 
> Using a profiler would certainly be a good idea,
> since it is not obvious exactly where you will be
> spending most of your CPU time. 
> 
> There is also a package called LINPACK or a
> similar name. It is a standard set or numerical
> routines in Fortran and C versions. It can be
> freely downloaded as far as I remember (a couple
> of years ago). The documentation was sold and
> among the materials there was a manual for
> creating high performance applications from Sun
> or HP. It could be worth a look.
> 
> Another point would be to actually use some of
> the routines I mention if possible, because they
> are highly optimized and they are quite difficult
> to surpass with handrolled code.
> A final thought is that, if your execution times
> are usually as you describe, your problem might
> be eligible for parallel computing. Does your
> algorithm/problem allow this approach? Linux has
>  parallel computing capabilities -there are
> several implementations.
> 
> Gerardo
> 
> Searching for the best free email?  Try MetaCrawler Mail, from the #1 metasearch service on the Web, http://www.metacrawler.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
-- 
Paul Furness

Systems Manager

2+2=5 for extremely large values of 2.