Development of resource-intensive applications in Visual C++


Published on

The article will familiarize application developers with tasks given them by the mass introduction of 64-bit multi-core processors symbolizing revolutionary increase of computing power available for an average user. It will also touch upon the problems of effective use of hardware resources for solving everyday applied tasks within the limits of Windows x64 operating system

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Development of resource-intensive applications in Visual C++

  1. 1. Development of resource-intensiveapplications in Visual C++Authors: Andrey Karpov, Evgeniy RyzhkovDate: 10.02.2008AbstractThe article will familiarize application developers with tasks given them by the mass introduction of 64-bit multi-core processors symbolizing revolutionary increase of computing power available for anaverage user. It will also touch upon the problems of effective use of hardware resources for solvingeveryday applied tasks within the limits of Windows x64 operating systemInformation for readersBy default in this article we mean Windows as the operating system. By 64-bit systems we mean thex86-64 (AMD64) architecture. By the development environment - Visual Studio 2005/2008. You maydownload a demo sample which will be touched upon in the article using this link: computing and large RAM size are now available not only for large firmware complexes meantfor large-scale scientific computing, but are also used for solving everyday tasks related to work, study,entertainment and computer games.The possibility of paralleling and large RAM size, on the one hand, make the development of resource-intensive applications easier, but on the other hand, requires more qualification and knowledge in thearea of parallel programming from a programmer. Unfortunately, a lot of developers are far frompossessing such qualification and knowledge. And this is not because they are bad developers butbecause they simply havent come across such tasks. This is not surprising since creation of parallelsystems of information processing has been performed mostly in scientific institutions while solvingtasks of modeling and forecasting until recently. Parallel computer complexes with large memory sizewere used also for solving applied tasks by enterprises, banks etc, but they have been rather expensiveand very few developers were able to get acquainted with the peculiarities of developing software forsuch systems.The authors of the article managed to take part in the development of resource-intensive softwareproducts related to visualization and modeling of physical processes and to learn the peculiarities ofdevelopment, testing and debugging of such systems by themselves. By resource-intensive software wemean program code which efficiently uses abilities of multiprocessor systems and large amount ofmemory (2GB and more). Thats why wed like to bring some knowledge to developers who may find ituseful while creating modern parallel 64-bit systems in the nearest future.Problems related to parallel programming have been studied in detail long ago and described in manybooks, articles and study courses. Thats why this article will pay more attention to the sphere of
  2. 2. organizational and practical issues of developing high-performance applications and to the use of 64-bittechnologies.While talking about 64-bit systems well consider that they use LLP64 data model (see table 1). This datamodel is used in 64-bit versions of the Windows operating system. But information given here may bealso useful for those who work with systems using a data model different from LLP64. Table 1. Data models and their use in different operating systems.1. Be brave to use parallelism and 64-bit technologyConsidering the conservatism in the sphere of developing large program systems, we would like, though,to advise you to use the abilities provided by multicore 64-bit processors. It may become a large
  3. 3. competitive advantage over similar systems and also become a good reason for news in advertisingcampaigns.It is senseless to delay 64-bit technology and parallelism usage since it is inevitable. You may ignore all-round passion for a new programming language or optimizing a program for MMX technology. But youcannot avoid increase of the amount of processed data and slowing down of clock frequency rise. Letstouch upon this statement in detail.Parallelism is becoming the basis of productivity rise and this is related to the slowing down of thetempo of modern microprocessors clock frequency rise. While the number of transistors on a dice isincreasing, a sharp fall of clock frequency rise speed was outlined after 2005 (see figure 1). There is anarticle on this topic which is rather interesting: "The Free Lunch Is Over. A Fundamental Turn TowardConcurrency in Software" [1].
  4. 4. Figure 1. Rise of clock frequency and the number of transistors on a dice.During last 30 years productivity has been determined by clock frequency, optimization of commandexecution and cache enlarging. In the next years it will be determined by the number of cores.Development of parallel programming will become the main direction of programming technologiesdevelopment.Parallel programming will allow not only to solve the problem of slowing down of clock frequency risebut also to come to creation of scalable software which will fully use the increase of number ofcomputational nodes in the processor. That is, software will gain productivity not only through theincrease of the microprocessors clock frequency, but through the rise of number of cores as well. Suchsystems are the future of software. And one who will master the new technologies quicker will be ableto shift the software market for ones own benefit.Although the use of 64-bit technologies doesnt look so impressive in comparison to parallelism,however, it provides a lot of new abilities too. Firstly, it is free 5-15% productivity rise. Secondly, largeaddress space solves the problem of RAM fragmentation while working with large data sizes. The searchfor solution of this task has caused a lot of troubles for many developers whose programs crash becauseof memory shortage after several hours of work. Thirdly, this is an opportunity to easily work with dataarrays of several GB. Sometimes it results in amazing rise of productivity, because HDD is not accessed.
  5. 5. If all said above doesnt convince you of advantages of 64-bit systems look closer what your colleaguesor yourself are working at. Does somebody optimize code, raising the functions productivity in 10%,although this 10% can be got by simple recompilation of a program for the 64-bit architecture? Doessomebody create his own class for working with arrays, loaded from files because there is no enoughspace for these arrays in memory? Do you develop your own manager of memory allocation in order notto fragment memory? If you say "Yes" to at least one of the question, you should stop and think for awhile. Perhaps, you fight in vain. And perhaps, it would be more profitable to spend your time onporting your application on a 64-bit system where all these questions will disappear at once. Still, sooneror later you will have to spend your time on this.Lets sum up all said above. It can be a waste of time trying to gain last profits from the 32-bitarchitecture. Save your time. Think about using parallelism and 64-bit address space to increaseproductivity. Give a new informational occasion and take the lead over your rivals while developing themarket of high-performance applications.2. Provide yourself with a good hardwareSo, you decided to use parallelism and 64-bit technologies in your program development. Perfect. So,lets touch upon some organizational questions first.Inspite of you have to face the development of complex programs processing large amounts of data, stillthe company management often doesnt understand the necessity of providing the developers with themost high-performance computers. Although your applications may be intended for high-performanceworkstations, you are likely to test and debug them on your own machine. Of course all programmersneed high-performance computers even if their programs dont process many GB of data. All have tocompile them, launch heavy auxiliary tools and so on. But only a developer of resource-intensivesoftware reveals all the troubles caused by the lack of RAM or slow speed of the disk subsystem.Show this part of the article to your manager. Now well try to explain why it is profitable to investmoney into your tools - computers.This may sound trivial but a fast processor and a fast disk subsystem may speed up the process ofapplications compilation greatly! It seems to you that there is no difference between two minutes andone minute of compilation of some part of the code, doesnt it? The difference is enormous! Minutesturn out into hours, days, months. Ask your programmers to count how much time they spend awaitingthe code compilation. Divide this time at least by 1.5 and then you can calculate how quickly theinvestment into the new machinery will be repaid. I assure you that you will be amused.Keep in mind one more effect which will help you to save work time. If some action takes 5 minutes onewill wait. If it is 10 minutes one will go to make coffee, read forums or play ping-pong, what will takemore than 10 minutes! And not because he is an idler or wants coffee very much - he will be just bored.Dont let the action be interrupted: push the button - get the result. Make those processes consume 5minutes instead of 10.Once again I want you to note that the aim is not to occupy a programmer with a useful task in hisleisure-time but to speed up all the processes in general. Setting up a second computer (dual-processorsystem) so that the the programmer will switch to other tasks while waiting is wrong at all. Aprogrammers labor is not that of a street cleaner, who can clear a bench from snow during a breakbetween breaking ice. A programmers labor needs concentration on the task and keeping in mind a lot
  6. 6. of its elements. Dont try to make a programmer switch to another task (this try will be useless), try tomake it so that he could continue to solve the task hes working at as soon as possible. According to the"Stresses of multitask work: how to fight them" article [2] a person needs 25 minutes to go deeply intosome other task or return to an interrupted one. If you dont provide continuity of the process, half ofthe time will be wasted on this very switching over. It doesnt matter what it is - playing ping-pong orsearching for an error in another program.Dont spare money to buy some more gigabytes of memory. This purchase will be repaid after severalsteps of debugging a program allocating large memory size. Be aware that lack of RAM causes swappingand can slow down the process of debugging from minutes to hours.Dont spare money to provide the machine with RAID subsystem. Not to be a theorist, here is anexample from our own experience (table 2).Configuration (pay attention to RAID) Time of building of an average project using large number of exterior libraries.AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, 2 GB 95 minutesof RAM,2 x 250Gb HDD SATA - RAID 0AMD Athlon(tm) 64 X2 Dual Core Processor 4000+, 4 GB 140 minutesof RAM,500 Gb HDD SATA (No RAID)Table 2. An example of how RAID affects the speed of an applications building.Dear managers! Trust me that saving on hardware is compensated by delays of programmers work.Such companies as Microsoft provide the developers with latest models of hardware not because ofgenerosity and wastefulness. They do count their money and their example shouldnt be ignored.At this point the part of the article concerning managers is over, and we would like to address creatorsof program solutions again. Do demand for the equipment you consider to be necessary for you. Dontbe shy, since your manager is likely is not understanding that it is profitable for everybody. You shouldenlighten him. Moreover, in case the plan isnt fulfilled it is you who will seem to be guilty. It is easier toget new machinery than try to explain what are you wasting your time for. Imagine how can your excuseconcerning why you have been correcting only one error all the day long sound: "Its a very large project.I launched the debugger, had to wait very long. And I have only one GB of memory. I cant work atanything else simultaneously. Windows began to swap. Found an error, corrected it, but I have to launchand check it again...". Perhaps, your manager wont say anything but will consider you just an idler.Dont allow this.Your major task while developing a resource-intensive application is not designing a new system andeven not the study of theory, this task is to demand to buy all the necessary hardware and software intime. Only after that you may begin to develop resource-intensive program solutions efficiently. It isimpossible to write and check parallel programs without multicore processors. And it is impossible towrite a system for processing large data sizes without necessary RAM size.Before we switch to the next topic, we would like to share some ideas, which will help you to make yourwork process more comfortable.You may try to solve the problem of slow building of a project by using special tools of parallel buildingof a system similar, for example, to IncrediBuild by Xoreax Software ( Ofcourse, there are other similar systems which may be found in the Web.
  7. 7. The problem of testing applications with large data arrays (launch of a tests set) for which usualmachines are not productive enough, may be solved by using several special high-performancemachines via remote access. An example of remote access tool is Remote Desktop or X-Win. Usuallysimultaneous test launches are performed only by a few developers. And for a group of 5-7 developers 2dedicated high-performance machines are quite enough. It wont be the most convenient solution but itwill be rather saving in comparison to providing every developer with such workstations.3. Use a logging system instead of a debuggerThe next obstacle on your way while developing systems for processing large data sizes is that you arelikely to reconsider your methodology of work with the debugger or even refuse to use it at all.Some specialists offer to refuse the debugging methodology because of some ideological reasons. Themain argument is that the use of the debugger is the use of the cut and try method. A person noticingthe incorrect behavior of the algorithm at some step of its execution brings corrections into it withoutexamining why this error occurred and without thinking about the way he corrects it. If he didnt guessthe right way of correction he will notice it during the next execution of the code and bring newcorrections. It will result in lower quality of the code. And the author of this code is not always sure thathe understands how it works. Opponents of debugging method offer to replace it with more strictdiscipline of algorithm development, with the use of functions as small as possible so that their workingprinciples are clear. Besides, they offer to pay more attention to unit testing and to use logging systemsfor analysis of the programs correct work.There are some rational arguments in the described criticism of debugging systems but, as in manycases, one should weigh everything and not run to extremes. The use of the debugger is oftenconvenient and may save much efforts and time.3.1. Causes why debugger is not so attractiveBad applicability of the debugger for systems processing large data sizes is unfortunately related not toideological but practical difficulties. Wed like to familiarize the readers with these difficulties to savetheir time on fighting with the debugging tool when it is of little use, and prompt them to search foralternative solutions.Lets study some reasons why alternative means should be used instead of a traditional debugger (forexample, the one integrated into Visual C++ environment).1) Slow program execution.Execution of a program under a debugger processing millions and billions of elements may becomepractically impossible because of great time costs. Firstly, it is necessary to use debugging code variantwith optimization turned off and that already slows down the speed of algorithms work. Secondly, inthe debug version of the program more memory is allocated in order to check bounds of memoryblocks, memory fill during allocation/deallocation etc. This slows down the work even more.One can truly notice that a program may be debugged not necessarily at large working data sizes andtesting tasks are anough. Unfortunately, this is not so. An unpleasant surprise is that while developing64-bit systems you cannot be sure that the algorithms work correctly when testing them at smallamounts of data instead of working amounts of many GB.
  8. 8. Here is another simple example demonstrating the problem of necessary testing at large amounts ofdata.#include <vector>#include <boost/filesystem/operations.hpp>#include <fstream>#include <iostream>int main(int argc, char* argv[]){ std::ifstream file;[1], std::ifstream::binary); if (!file) return 1; boost::filesystem::path fullPath(argv[1], boost::filesystem::native); boost::uintmax_t fileSize = boost::filesystem::file_size(fullPath); std::vector<unsigned char> buffer; for (int i = 0; i != fileSize; ++i) { unsigned char c; file >> c; if (c >= A && c <= Z) buffer.push_back(c); } std::cout << "Array size=" << buffer.size() << std::endl; return 0;}This program reads the file and saves all the capital English letters in the array. If all the symbols in theoutput file are capital English letters we wont be able to put more than 2*1024*1024*1024 symbolsinto the array on a 32-bit system, and consequently to process the file of more than 2 GB. Lets imagine
  9. 9. that this program has been used correctly on a 32-bit system, taking this limitation into consideration,and no errors occurred.On a 64-bit system wed like to process files of larger size as there is no limitation of the arrays size.Unfortunately, the program is written incorrectly from the point of view of LLP64 data model (see table1) used in the 64-bit version of Windows. The loop contains int type variable whose size is still 32 bits. Ifthe files size is 6 GB, condition "i != fileSize" will never be fulfilled and an infinite loop will occur.This code is intended to show how difficult it is to use the debugger while searching for errors whichoccur only at a large memory size. When you get an infinite loop while processing the file on the 64-bitsystem you may take a file containing 50 bytes and watch how the functions work under the debugger.But an error wont occur at such data size and it is impossible to watch the processing of 6 billionelements under the debugger.Of course, you should understand that this is only an example and that it can be debugged easily andthe cause of the infinite loop may be found. Unfortunately, this often becomes practically impossible incomplex systems because of the slow speed of the processing of large amount of data.To learn more about such unpleasant examples see articles "Forgotten problems of 64-bit programdevelopment" [3] and "20 issues of porting C++ code on the 64-bit platform" [4].2) Multi-threading.The method of several instruction flows executed simultaneously for speeding up the processing of largeamount of data has been used for a long time and rather successfully in cluster systems and high-performance servers. But only with the appearance of multicore processors on market, the possibility ofparallel data processing is widely used in applications. And the urgency of the parallel systemdevelopment will only increase in future.Unfortunately, it is not easy to explain what is difficult in debugging of parallel programs. Only on facingthe task of searching and correcting errors in parallel systems one may feel and understand theuselessness of such a tool as a debugger. But in general, all the problems may be reduced to theimpossibility to reproduce many errors and to the way the debugging process affects the workflow ofparallel algorithms.To learn more about the problems of debugging parallel systems you may read the following articles:"Program debugging technology for machines with mass parallelism" [5], "Multi-threaded DebuggingTechniques" [6], "Detecting Potential Deadlocks" [7].Using specialized methods and tools solves the difficulties described. You may handle 64-bit code byusing static analyzers, which work with the input program code and do not require its launch. Anexample is the Viva64 static code analyzer [8].To debug parallel systems you should pay attention to such tools as TotalView Debugger (TVD) [9].TotalView is the debugger for the C, C++ and Fortran languages, which works on Unix-compatibleoperating system and Mac OS X. It allows controlling execution threads, shows data of one or all thethreads, can synchronize the threads through breakpoints. It also supports parallel programs using MPIand OpenMP.Another interesting application for multithreaded analysis is Intel® Threading Analysis Tools [10].
  10. 10. 3.2. Using a logging systemAll the tools both mentioned and remaining undiscussed are surely useful and may be of great helpwhile developing high-performance applications. But one shouldnt forget about such time-provedmethodology as logging systems. Debugging via logging method hasnt become less urgent for severaldecades and still remains a good tool which well speak about in detail. The only change concerninglogging systems is growing requirements applied to them. Lets try to list the properties a modernlogging system should have for high-performance systems: • The code providing logging of data in the debug version must be absent in the release version of a software product. Firstly, this is related to the increase of performance and decrease of the software products size. Secondly, it doesnt allow using debugging information for cracking the application and other illegal actions. • The logging systems interfaces should be compact so that they do not overload the main program code. • Data writing should be as fast as possible in order to bring minimal changes into time characteristics of parallel algorithms. • The output log should be understandable and analyzable. There should be a possibility to divide information gained from different threads and also to vary its specification level.A logging system which meets these requirements allows solving the task of debugging parallelalgorithms and also to debug algorithms processing large data arrays.We wont give a particular example of a logging systems code in this article. It is hard to make such asystem universal as it depends on the development environment very much, as well as the projectsspecificity, the developers wishes and so on. Instead, well touch upon some technical solutions whichwill help you to create a convenient and effective logging system if you need it.The simplest way to perform logging is to use the function similar to printf as shown in the example: int x = 5, y = 10; ... printf("Coordinate = (%d, %d)n", x, y);Its natural disadvantage is that the information will be shown both in the debugging mode and in theoutput product. Thats why we have to change the code as follows:#ifdef DEBUG_MODE #define WriteLog printf#else #define WriteLog(a)#endif WriteLog("Coordinate = (%d, %d)n", x, y);
  11. 11. This is better. And pay attention that we use our own macro DEBUG_MODE instead of a standard macro_DEBUG to choose how the function WriteLog will be implemented. This allows including debuginformation into release versions that is important when debugging at large amount of data.Unfortunately, when compiling the non-debugging version in Visual C++ environment we get a warningmessage: "warning C4002: too many actual parameters for macro WriteLog". We may turn thismessage off, but it is a bad style. We can rewrite the code as follows:#ifdef DEBUG_MODE #define WriteLog(a) printf a#else #define WriteLog(a)#endif WriteLog(("Coordinate = (%d, %d)n", x, y));This code is not smart because we have to use double parentheses and this is often forgotten. Thatswhy lets bring some improvements:#ifdef DEBUG_MODE #define WriteLog printf#else inline int StubElepsisFunctionForLog(...) { return 0; } static class StubClassForLog { public: inline void operator =(size_t) {} private: inline StubClassForLog &operator =(const StubClassForLog &) { return *this; } } StubForLogObject; #define WriteLog StubForLogObject = sizeof StubElepsisFunctionForLog#endif WriteLog("Coordinate = (%d, %d)n", x, y);This code looks complicated but it allows to write single brackets. When the DEBUG_MODE flag isturned off this code doesnt matter at all and you can safely use it in critical code fragments.
  12. 12. The next modification is to add parameters to the logging function. Let us add the specification level andinformation type. The specification level may be defined as a parameter, for example:enum E_LogVerbose { Main, Full};#ifdef DEBUG_MODE void WriteLog(E_LogVerbose, const char *strFormat, ...) { ... }#else ...#endifWriteLog (Full, "Coordinate = (%d, %d)n", x, y);This is convenient because you can decide whether to filter unimportant messages or not after theprograms shutdown using a special utility. The disadvantage of this method is that all the information isshown - both important and unimportant, and this may affect the productivity badly. Thats why youmay create several functions of the WriteLogMain, WriteLogFull type and so on, whose implementationwill depend on the mode of the programs building.We mentioned that the writing of the debugging information must not affect the speed of thealgorithms execution too much. We can reach this by creating a system for gathering messages, whichare written in the thread executed simultaneously. The outline of this mechanism is shown on figure 2.
  13. 13. Figure 2. Logging system with the lazy write algorithm.
  14. 14. As you can see from the figure the next data portion is written into an intermediate array with strings offixed length. The fixed size of the array and its strings allows excluding expensive memory allocationoperations. This doesnt reduce the possibilities of this system at all. You can just select the stringslength and the arrays size with spare. For example, 5000 strings of 4000 symbols will be enough fordebugging nearly any system. And memory size of 20 MB which is necessary for that is not critical formodern systems, I think youll agree with me. But if the arrays overflow occurs anyway, its easy toprovide a mechanism for anticipatory writing of the information into a file.The described mechanism provides practically instant execution of the WriteLog function. If there areoffloaded processors cores in the system the writing into the file will be practically transparent for themain program code.The advantage of the described system is that it can function without changes while debugging theparallel program, when several threads are being written into the log simultaneously. You need just toadd a process identifier so that you can know later from what threads the messages were received (seefigure 3).
  15. 15. Figure 3. Logging system for multithread applications debugging.The last improvement wed like to suggest is showing the level of nesting of messages at the moment offunctions call or the beginning of a logical block. This can be easily organized by using a special classthat writes an identifier of a blocks beginning into the log in the constructor, and an identifier of theblocks end in the destructor. Lets try showing this on an example.Program code:
  16. 16. class NewLevel {public: NewLevel() { WriteLog("__BEGIN_LEVEL__n"); } ~NewLevel() { WriteLog("__END_LEVEL__n"); }};#define NEW_LEVEL NewLevel tempLevelObject;void MyFoo() { WriteLog("Begin MyFoo()n"); NEW_LEVEL; int x = 5, y = 10; printf("Coordinate = (%d, %d)n", x, y); WriteLog("Begin Loop:n"); for (unsigned i = 0; i != 3; ++i) { NEW_LEVEL; WriteLog("i=%un", i); }}Logs content:Begin MyFoo()__BEGIN_LEVEL__Coordinate = (5, 10)Begin Loop:__BEGIN_LEVEL__i=0__END_LEVEL____BEGIN_LEVEL__i=1__END_LEVEL____BEGIN_LEVEL__
  17. 17. i=2__END_LEVEL__Coordinate = (5, 10)__END_LEVEL__Log after transformation:Begin MyFoo() Coordinate = (5, 10) Begin Loop: i=0 i=1 i=2 Coordinate = (5, 10)I think thats all for this topic. Wed like to mention at last that the article "Logging In C++" [11] may beof use for you too. We wish you successful debugging.4. Using correct data types from the 64-bit technologies viewpointUsing base data types corresponding to the hardware platform in C/C++ languages is an important pointof creating quality and high-performance program solutions. With the appearance of 64-bit systems newdata models have been used - LLP64, LP64, ILP64 (see table 1) and this changes the rules andrecommendations concerning the use of base data types. Such types are int, unsigned, long, unsignedlong, ptrdiff_t, size_t and pointers. Unfortunately, there are practically no popular literature and articleswhich touch upon the problems of choosing types. And those sources which do, for example "SoftwareOptimization Guide for AMD64 Processors" [12], are seldom read by application developers.The urgency of correct choice of base types for processing data is determined by two important causes:the correctness of the code execution and its efficiency.Due to the historical development the base and the most often used integer type in C and C++ languagesis int or unsigned int. It is accepted to consider the int type the most optimal as its size coincides withthe length of the processors computer word.The computer word is a group of RAM bits taken by the processor at one call (or processed by it as asingle group) and usually contains 16, 32 or 64 bits.The tradition to make the int type size equal to the computer word has been seldom broken untilrecently. On 16-bit processors int consisted of 16 bits. On 32-bit processors it is 32 bits. Of course, thereexisted other correlations between int-size and the computer words size but they were used seldomand are not of interest for us now.
  18. 18. We are interested in that fact that with the appearance of 64-bit processors the size of int typeremained 32-bits in most systems. Int type has 32-bit size in the LLP64 and LP64 data models, which areused in 64-bit Windows operating system and most Unix systems (Linux, Solaris, SGI Irix, HP UX 11).It is a bad decision to leave the int type size equal to 32 bits due to many reasons, but it is really areasonable way to choose the lesser of two evils. First of all, it is related to the problems of providingbackward compatibility. To learn more about the reasons of this choice you may read the "Why did theWin64 team choose the LLP64 model?" blog [13] and the "64-Bit Programming Models: Why LP64?"article [14].For developers of 64-bit applications all said above is the reason to follow two new recommendations inthe process of software development.Recommendation 1. Use the ptrdiff_t and size_t types for loop counters and pointers arithmetic insteadof the int and unsigned types.Recommendation 2. Use the ptrdiff_t and size_t types for indexing in arrays instead of the int andunsigned types.In other words you should use 64-bit data types in a 64-bit system whenever possible. Therefore youshouldnt use constructions like:for (int i = 0; i != n; i++) array[i] = 0.0;Yes, this is a canonical code example. Yes, it is included in many programs. Yes, with this learning the Cand C++ languages begins. But it is recommended not to use it anymore. Use either an iterator or theptdriff_t and size_t data types as it is shown in the improved example:for (size_t i = 0; i != n; i++) array[i] = 0.0;Developers of Unix applications may notice that the practice of using long type for counters andindexing arrays has appeared long ago. Long type is 64-bit in 64-bit Unix systems and it looks smarterthan ptdriff_t or size_t. Yes, its true but we should keep in mind two important points.1) long types size remained 32-bit in 64-bit Windows operating system (see table 1). Therefore it cannotbe used instead of the ptrdiff_t and size_t types.2) Using the long and unsigned long types causes a lot of troubles for developers of cross-platformapplications for Windows and Linux systems. Long type has different sizes in these systems and onlycomplicates the situation. Its better to stick to types, which have the same size in 32-bit and 64-bitWindows and Linux systems.Now lets explain why we are so insistent asking you to use the ptrdiff_t/size_t type instead of the usualint/unsigned type on an example.Well begin with an example illustrating the typical error of using unsigned type for loop counter in 64-bit code. We have already described a similar example before but lets see it once again as this error iswidespread:
  19. 19. size_t Count = BigValue;for (unsigned Index = 0; Index != Count; ++Index){ ... }This code is typical and its variants can be met in many programs. It is executed correctly in 32-bitsystems where the value of Count variable cannot exceed SIZE_MAX (which is equal to UINT_MAX in a32-bit system). In a 64-bit system the range of possible values for Count may be extended and in thiscase when Count > UINT_MAX, an eternal loop occurs. The proper correction of this code is to use thesize_t type instead of unsigned.The next example shows incorrect using of the int type for indexing large arrays:double *BigArray;int Index = 0;while (...) BigArray[Index++] = 3.14f;This code doesnt seem suspicious to an application developer accustomed to the practice of usingvariables of the int or unsigned types as arrays indexes. Unfortunately, this code wont work in a 64-bitsystem if the size of the processed BigArray array becomes more than four billion items. In this case anoverflow of Index variable will occur and the result of the programs work will be incorrect (not theentire array will be filled). Again, the correction of the code is to use the ptrdiff_t or size_t types forindexes.As the last example wed like to demonstrate the potential danger of mixed usage of 32-bit and 64-bittypes, which you should avoid whenever possible. Unfortunately, few developers think about theconsequences of inaccurate mixed arithmetic and the next example is absolutely unexpected for many(the results are received using Microsoft Visual C++ 2005 at 64-bit compilation mode):int x = 100000;int y = 100000;int z = 100000;intptr_t size = 1; // Result:intptr_t v1 = x * y * z; // -1530494976intptr_t v2 = intptr_t(x) * y * z; // 1000000000000000intptr_t v3 = x * y * intptr_t(z); // 141006540800000intptr_t v4 = size * x * y * z; // 1000000000000000intptr_t v5 = x * y * z * size; // -1530494976intptr_t v6 = size * (x * y * z); // -1530494976intptr_t v7 = size * (x * y) * z; // 141006540800000
  20. 20. intptr_t v8 = ((size * x) * y) * z; // 1000000000000000intptr_t v9 = size * (x * (y * z)); // -1530494976We want you to pay attention that expression of "intptr_t v2 = intptr_t(x) * y * z;" type doesntguarantee the correct result at all. It guarantees only that expression "intptr_t(x) * y * z" will haveintptr_t type. The article "20 issues of porting C++ code on the 64-bit platform" [4] will help you to learnmore about this problem.Now lets look at the example demonstrating the advantages of using the ptrdiff_t and size_t types fromthe viewpoint of productivity. For demonstration well take a simple algorithm of the minimal length of apath in the labyrinth calculation. You may see the whole code of the program here: this article we place only the text of the FindMinPath32 and FindMinPath64 functions. Both thesefunctions calculate the length of the minimal path between two points in a labyrinth. The rest of thecode is not of interest for us now.typedef char FieldCell;#define FREE_CELL 1#define BARRIER_CELL 2#define TRAVERSED_PATH_CELL 3unsigned FindMinPath32(FieldCell (*field)[ArrayHeight_32],unsigned x, unsigned y, unsigned bestPathLen,unsigned currentPathLen) { ++currentPathLen; if (currentPathLen >= bestPathLen) return UINT_MAX; if (x == FinishX_32 && y == FinishY_32) return currentPathLen; FieldCell oldState = field[x][y]; field[x][y] = TRAVERSED_PATH_CELL; unsigned len = UINT_MAX; if (x > 0 && field[x - 1][y] == FREE_CELL) { unsigned reslen = FindMinPath32(field, x - 1, y, bestPathLen, currentPathLen); len = min(reslen, len); }
  21. 21. if (x < ArrayWidth_32 - 1 && field[x + 1][y] == FREE_CELL) { unsigned reslen = FindMinPath32(field, x + 1, y, bestPathLen, currentPathLen); len = min(reslen, len); } if (y > 0 && field[x][y - 1] == FREE_CELL) { unsigned reslen = FindMinPath32(field, x, y - 1, bestPathLen, currentPathLen); len = min(reslen, len); } if (y < ArrayHeight_32 - 1 && field[x][y + 1] == FREE_CELL) { unsigned reslen = FindMinPath32(field, x, y + 1, bestPathLen, currentPathLen); len = min(reslen, len); } field[x][y] = oldState; if (len >= bestPathLen) return UINT_MAX; return len;}size_t FindMinPath64(FieldCell (*field)[ArrayHeight_64],size_t x, size_t y, size_t bestPathLen, size_tcurrentPathLen) { ++currentPathLen; if (currentPathLen >= bestPathLen) return SIZE_MAX; if (x == FinishX_64 && y == FinishY_64) return currentPathLen; FieldCell oldState = field[x][y];
  22. 22. field[x][y] = TRAVERSED_PATH_CELL; size_t len = SIZE_MAX; if (x > 0 && field[x - 1][y] == FREE_CELL) { size_t reslen = FindMinPath64(field, x - 1, y, bestPathLen, currentPathLen); len = min(reslen, len); } if (x < ArrayWidth_64 - 1 && field[x + 1][y] == FREE_CELL) { size_t reslen = FindMinPath64(field, x + 1, y, bestPathLen, currentPathLen); len = min(reslen, len); } if (y > 0 && field[x][y - 1] == FREE_CELL) { size_t reslen = FindMinPath64(field, x, y - 1, bestPathLen, currentPathLen); len = min(reslen, len); } if (y < ArrayHeight_64 - 1 && field[x][y + 1] == FREE_CELL) { size_t reslen = FindMinPath64(field, x, y + 1, bestPathLen, currentPathLen); len = min(reslen, len); } field[x][y] = oldState; if (len >= bestPathLen) return SIZE_MAX; return len;}The FindMinPath32 function is written in classic 32-bit style using unsigned types. FindMinPath64function differs from it only in that all the unsigned types in it are replaced by the size_t type. There are
  23. 23. no other differences! I think youll agree that this is an easy modification of the program. And now letscompare the execution speeds of these two functions (see table 2). Mode and function. Functions execution time1 32-bit compilation mode. Function FindMinPath32 12 32-bit compilation mode. Function FindMinPath64 1.0023 64-bit compilation mode. Function FindMinPath32 0.934 64-bit compilation mode. Function FindMinPath64 0.85Table 2. Execution time of the FindMinPath32 and FindMinPath64 functions.Table 2 shows the time relative to the FindMinPath32 functions execution speed in a 32-bit system. Thisis made for more clearness.In the first line the work time of FindMinPath32 function in a 32-bit system is 1. It is because we take itswork time for a unit of measure.In the second line we see that FindMinPath64 functions work time in a 32-bit system is 1 too. This is notsurprising because unsigned type coincides with size_t type in a 32-bit system and there is no differencebetween FindMinPath32 and FindMinPath64 functions. Some deviation (1.002) means only a little timecalculation error.In the third line we see 7% productivity increase. This is an expected result of the code recompilation fora 64-bit system.The fourth line is the most interesting. Productivity increase is 15% here. This means that the simple useof the size_t type instead of unsigned allows the compiler to construct more efficient code working 8%faster!It is a simple and clear example of how the use of data not equal to the computer words size decreasesthe algorithms productivity. Simple replacement of the int and unsigned types with ptrdiff_t and size_tmay give a great productivity increase. First of all this concerns usage of these data types for indexingarrays, pointer arithmetic and organization of loops.We hope that having read all said above you will think if you should continue to write:for (int i = 0; i !=n; i++) array[i] = 0.0;Developers of Windows applications may take into consideration the Viva64 static code analyzer [8] toautomate the errors search in 64-bit code. Firstly, its usage will help to find most errors. Secondly, whiledeveloping programs under its control you will use 32-bit variables more seldom, avoid mixed arithmeticwith 32-bit and 64-bit data types that will at once increase productivity of your code. Developers of Unixapplication should take a look at the Gimpel Software PC-Lint [15] and Parasoft C++test [16] staticanalyzers. They can diagnose some 64-bit errors in the code with LP64 data model, which is used in mostUnix-systems.To learn more about the problems of developing quality and efficient 64-bit code you may read thefollowing articles: "Problems of testing 64-bit applications" [17], "24 Considerations for Moving YourApplication to a 64-bit Platform" [18], "Porting and Optimizing Multimedia Codecs for AMD64architecture on Microsoft Windows" [19], "Porting and Optimizing Applications on 64-bit Windows forAMD64 Architecture" [20].
  24. 24. 5. Additional ways of increasing productivity of program systemsIn the last part of this article wed like to touch upon some more technologies, which may be useful foryou while developing resource-intensive program solutions.5.1. Intrinsic functionsIntrinsic functions are special system-dependent functions, which execute actions impossible to beexecuted on the level of C/C++ code or which execute these actions much more efficiently. As thematter of fact they allow you to avoid using inline assembler because it is often impossible orundesirable.Programs may use intrinsic functions for creating faster code due to the absence of overhead costs onthe call of a usual function. In this case, of course, the codes size will be a bit larger. The list of functionswhich may be replaced with their intrinsic versions is given in the MSDN Library. For example, thesefunctions are memcpy, strcmp, etc.There is a special option, "/Oi" in Microsoft Visual C++ compiler. This option allows you to replace callsof some functions with intrinsic analogs automatically.Besides automatic replacement of functions with their intrinsic analogs we can explicitly use intrinsicfunctions in code. This feature may be used due to the following reasons: • Inline assembler code is not supported by Visual C++ compiler in 64-bit mode, while intrinsic code is. • Intrinsic functions are simpler to use as they dont require the knowledge of registers and other similar low-level constructions. • Intrinsic functions are updated by compilers, while assembler code has to be updated manually. • Built-it optimizer doesnt work with assembler code, thats why you have to use external assembler modules, while intrinsic code doesnt need this. • Intrinsic code is easier to port than assembler code. • Using intrinsic functions in automatic mode (with the help of the compilers key) you can get some increase of productivity, and "manual" mode will give you even more. Thats why the usage of intrinsic functions is reasonable. • To learn more about intrinsic functions you may see the Visual C++ teams blog [21].5.2. Data packing and alignmentNowadays data alignment doesnt affect the code productivity so greatly as it did 10 years ago. Butsometimes you can get a little profit in this sphere too, saving some memory and productivity.Lets take a look at an example:struct foo_original {int a; void *b; int c; };This structure occupies 12 bytes in 32-bit mode but in 64-bit mode it takes 24 bytes. In order to makethis structure take prescribed 16 bytes in 64-bit mode you should change the order of fields:struct foo_new { void *b; int a; int c; };In some cases it is useful to help the compiler explicitly by defining the alignment manually in order toincrease productivity. For example, SSE data should be aligned at the border of 16 bytes. You can do thisin the following way:
  25. 25. // 16-byte aligned data__declspec(align(16)) double init_val [3.14, 3.14];// SSE2 movapd instruction_m128d vector_var = __mm_load_pd(init_val);The "Porting and Optimizing Multimedia Codecs for AMD64 architecture on Microsoft Windows" [19]and "Porting and Optimizing Applications on 64-bit Windows for AMD64 Architecture" [20] sourcescontain detailed review of these problems.5.3. Files mapped into memoryWith the appearance of 64-bit systems the technology of mapping files into memory became moreattractive because the data access window increased its size. It may be a very good addition for someapplications. Dont forget about it.Memory mapping of files is becoming less useful with 32-bit architectures, especially with theintroduction of relatively cheap recordable DVD technology. A 4 Gb file is no longer uncommon, andsuch large files cannot be memory mapped easily on 32-bit architectures. Only a region of the file can bemapped into memory and such regions will have to be mapped into and out of memory in order toaccess such a file via memory mapping. On 64-bit versions of Windows you have much larger addressspace, so you may map the entire file at once.5.4. The __restrict keywordOne of the most serious problems for a compiler is aliasing. When a program source code containsmemory read/write operations it is often impossible to find out whether more than one identifier refersto a certain memory space, i.e. whether more than one identifier can be a "synonym" for one and thesame memory space. Thats why the compiler should be very careful inside a loop in which memory isboth read and written while storing data in registers and not in memory. This insufficient usage ofregisters may influence the performance greatly.The __restrict keyword is used to make it easier for the compiler to make a decision. It "tells" thecompiler to use registers widely.The __restrict keyword makes the compiler not to consider the marked pointers to be aliased, i.e.referring to the same memory area. In this case the compiler can provide more efficient optimization.Lets take a look at the following example:int * __restrict a;int *b, *c;for (int i = 0; i < 100; i++){ *a += *b++ - *c++ ; // no aliases exist}In this code the compiler can safely keep the sum in the register related to variable "a" avoiding writinginto memory. MSDN Library is a good source of information about the __restrict keyword.
  26. 26. 5.5. SSE instructionsApplications executed on 64-bit processors (regardless of the mode) will work more efficiently if the SSEinstructions are used in them instead of MMX/3DNow. This behavior is related to the capacity ofprocessed data. SSE/SSE2 instructions operate with 128-bit data, while MMX/3DNow work only with 64-bit data. Thats why it is better to rewrite the code which uses MMX/3DNow so that it will use SSEinstructions.We wont dwell upon SSE-constructions in this article. The readers who may be interested in this topiccan read the documentation written by processor architecture developers.5.6. Some specific rules of language constructions usage64-bit architecture gives new opportunities for optimizing a programming language on the level ofseparate operators. These are the methods (which have become traditional already) of "rewriting"pieces of a program to make the compiler optimize them better. Of course, we cannot recommendthese methods for mass usage but it may be useful to learn about them.On the first place of the entire list of these optimizations is manual unrolling of loops. The idea of thismethod is shown in the example:double a[100], sum, sum1, sum2, sum3, sum4;sum = sum1 = sum2 = sum3 = sum4 = 0.0;for (int i = 0; i < 100; I += 4){sum1 += a[i];sum2 += a[i+1];sum3 += a[i+2];sum4 += a[i+3];}sum = sum1 + sum2 + sum3 + sum4;In many cases the compiler can unroll the loop to this form (see the description of the /fp:fast key forVisual C++) but not always.Another syntax optimization is the use of array notation instead of pointer one.A lot of such methods are described in the "Software Optimization Guide for AMD64 Processors" article[12].ConclusionThough youll have to face many difficulties while creating program systems using hardware abilities ofmodern computers efficiently, it is worthwhile. Parallel 64-bit systems provide new possibilities fordeveloping real, scalable solutions. They allow to expand the abilities of modern data processing
  27. 27. software tools, such as games, CAD-systems or pattern recognition. We wish you good luck in creatingnew technologies!References 1. Herb Sutter. The Free Lunch Is Over. A Fundamental Turn Toward Concurrency in Software. 2. Stresses of multitask work: how to fight them. 3. Andrey Karpov. Forgotten problems of developing 64-bit programs. 4. 5. Andrey Karpov, Evgeniy Ryzhkov. 20 issues of porting C++ code on the 64-bit platform. 6. V.V. Samofalov, A.V.Konovalon. Program debugging technology for machines with mass parallelism//"Issues of atomic science and technology" Series "Mathematical modeling of physical processes". 1996. Issue 4. pp. 52-56. 7. Shameem Akhter and Jason Roberts. Multi-threaded Debugging Techniques // Dr. Dobbs Journal, April 23, 2007, 8. Tomer Abramson. Detecting Potential Deadlocks // Dr. Dobbs Journal, January 01, 2006, 9. Viva64 Tool Overview. 10. The TotalView Debugger (TVD). 11. Intel Threading Analysis Tools. 12. Petru Marginean. Logging In C++ // Dr. Dobbs Journal, September 05, 2007, 13. Software Optimization Guide for AMD64 Processors. 14. Blog "The Old New Thing": "Why did the Win64 team choose the LLP64 model?". 15. "64-Bit Programming Models: Why LP64?" 16. Gimpel Software PC-Lint. 17. Parasoft C++test. 18. Andrey Karpov. Problems of testing 64-bit applications. 19. 20. John Paul Mueller. 24 Considerations for Moving Your Application to a 64-bit Platform. 21. Harsha Jaquasia. Porting and Optimizing Multimedia Codecs for AMD64 architecture on Microsoft Windows. 22. Mike Wall. Porting and Optimizing Applications on 64-bit Windows for AMD64 Architecture. 23. Dylan Birtolo. Visual C++ Team Blog: New Intrinsic Support in Visual Studio 2008.