DSB Scientific Consulting R&D Services computed molecular vibration Fire to Ceiling computed molecular vibration

Writing Fast Programs

DSB Scientific Consulting Home PageDSB Scientific Company InfoContact DSB Scientific

Services
Computational Chemistry ServicesComputer Programming ServicesCurrent Physical Chemistry Research ProjectsAnalytical Chemistry Consulting Services

Products
HPC SystemsSoftware ProductsBooks

Resources
Chemistry and Related LinksEssaysFree Physical Science Publications
Writing Fast Programs: A Practical Guide for Scientists and Engineers
John Riley
Published by Cambridge International Science Publishing
ISBN: 1-904602-40-1

1.1 Motivation for Writing High Performance Code

When thinking of computers as scientific problem solving tools, we typically envision two distinctly different images. The first is the large mainframe “supercomputer” housed in some environmentally controlled special room and maintained by a full-time staff of dedicated systems experts. These systems, in the scientific context, are typically accessed via remote site terminals and are used by many practicing scientists to run existing codes. That is, there is relatively little day-to-day code development by the scientist, and the codes are run “as-is” to produce some computational result. Very often, these codes are used to mathematically model a physical system, such as the programs used for Computational Fluid Dynamics (CFD), Quantum Chemistry ab initio calculations, Statistical Mechanics models of reasonably large systems and searches on extremely large datasets.

In contrast, the desktop computer (alternately referred to as microcomputer or PC) is typically imagined to play more of a data acquisition and data analysis role. Further, these desktop computers may well be used as “smart terminals” for the mainframes mentioned above, and can employ software that acts as either input or output processors for the mainframe. In this type of configuration, the mainframe is used only for the most demanding part of a calculation, while the desktop computer is utilized for such tasks as pre-computing input values and graphing (and other visualization). One very important difference is the percentage of time the research scientist may spend developing software tools on the desktop. In a research environment, desktop software is continually developed to address this or that problem, and often such development is done on the fly with little planning and overall code organization.

However, recent advances in both PC hardware and software technologies have dramatically changed the role of desktop machines in scientific research. Increases in processor clock speeds, memory spaces, memory bandwidth, compiler technology as well as Component Object Model (COM) interfaces and Plug N Play peripheral devices have allowed the PC to be an even more easily integrated and useful scientific research tool. These advances, combined with lowering prices, contribute to PC’s being used to solve hard core computational problems once believed solely accessible to large, parallel architectures. Indeed, the clustering of PC’s into parallel architectures (such as the so-called Beowulf style cluster) is a growing field of microcomputer application and research.

So, in regard to small, affordable microcomputers, the question that consistently comes to mind is “What really can be done with a PC”? Ab Initio chemistry codes, Monte Carlo Statistics codes and 3-D fluid dynamics codes are a few examples of open source and commercially available packages running on PC’s. With additional advances, the PC will undoubtedly continue to grow as a numerical modeling tool; as microcomputers expand their usefulness, so too the demands made upon them will continue to increase.

In addition, the purest may simply ask “just how fast can I get my task to run on this particular computer?” In this realm, speed improvements of 1% or even smaller can be considered milestones. Some “speedfreaks” even revel in hours of programming to accomplish a less than 1% gain. While this approach may seem of limited practical importance, even small computational gains can accumulate in large, iterative procedures.

In short, the two questions outlined in the preceding two paragraphs provide the motivation for this book. With this motivation, the question “Just how do we generate faster code so that our computers can help solve larger, more complicated problems” will be addressed. As illustrated in the next section, many scientists writing computer code to solve practical problems are figuratively shooting themselves in the foot performance-wise, and are not taking advantage of the full potential of their computational machines.

To whet the appetite a little further, code examples will be presented in this book are demonstrated to run 1000’s times faster (or more) than “first try” coding of the algorithm. As an example, imagine something as simple as reducing a data curve fitting algorithm requiring five minutes to an execution time of less than 10 seconds.

Return to the Writing Fast Programs Summary Page

Powered by Apache
DSB Scientific Consulting . New Bern, NC . 803-413-4768 TEL
© DSB Scientific Consulting 2005-2014