From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Furness Subject: Re: Re: Optimizing a compiler? Date: 23 Oct 2002 10:40:16 +0100 Sender: linux-admin-owner@vger.kernel.org Message-ID: <1035366016.6443.22.camel@zebra.vil.ite.mee.com> References: <54A529125D499C14EA4F0BE971333552@gjuarezmondragon.metacrawler.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54A529125D499C14EA4F0BE971333552@gjuarezmondragon.metacrawler.com> List-Id: Content-Type: text/plain; charset="us-ascii" To: linux-admin@vger.kernel.org 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.