CRDSS_Task1_05-14_GeneralPerformanceIssues

Home Browse Search

conduct analyses. For example, if generating a baseline data set for the water rights planning model using a DMI requires "too much time", then perhaps the baseline files could automatically be created and stored in a common location. Individual users could then access that data directly rather than having to each recreate the data from the database. If the user is running a model on a remote machine, such as at the Briefing Room, and the DMI data transfer is slow, then issues related to network speed will be studied. Perhaps it will be necessary to dump the flat files onto the server machine and then transfer all of the files to the remote machine. General Code Optimization Because most of the analytical code to be used in the CRDSS will consist of existing code (e.g., CRSM and the selected water rights planning model), it is unlikely that a great deal of effort will be spent improving the performance of the existing code. It often takes a great deal of time to decipher someone else's code (depending on the documentation), and changing the code will distance the code from its original form (and consequently decrease the likelihood that the code could be updated if the author releases a new version). An exception to this is that MODSIM code performance could be improved because the author of the code is part of the CRDSS team. Code related to GUI components will most likely perform well because GUI components are interactive and do not involve a great deal of "number-crunching." Additionally, much of the GUI code will exist as system libraries such as the Motif libraries, and cannot be recompiled. The consumptive use model will use GIS technology to perform analyses. However, both ARC/INFO and GRASS are existing code that will not be rewritten. New (or recompiled) code that is part of CRDSS applications can be compiled using the optimize compiler options (e.g., "-O1, -O2, -O3") to take advantage of general optimization technology. This generally involves elimination of unused variables, inlining of code (replacing a function call with the code for that call), and unrolling loops (using separate assignment commands for short loops rather than incurring overhead for executing the loop). RTi has used optimizing compilers before and has sometimes found bugs with such compilers. Consequently, it is important that all code be verified after it is optimized. prof Standard UNIX tools such as can be used to profile executables. This involves compiling the code with the profile option ("-p"), executing the code to generate profile information, and then running the profile command to review the results. Such a procedure will indicate which routines use the majority of processing resources. These routines can then be targeted for recoding to make the code more efficient. Code can also be optimized simply by following good programming techniques. For example, ensure that memory is accessed efficiently by using loop indexes that are in the appropriate order for the language being used. C stores arrays by rows and FORTRAN stores arrays by column. Model Performance Model performance should be evaluated by treating models as stand-alone programs. Model performance is related mainly to input/output operations (e.g., reading/writing files) and solution algorithm speed. Current experience with MODSIM on a SUN workstation indicates that approximately two hours are required to solve a system roughly equivalent to the Gunnison River basin. It is currently unknown how well the SGI machines will perform when running models. RTi 3 A275 05.10.94 1.05-14 Malers, Brazil