Compare 9 C / C ++ compilers according to the criteria of the language: flexibility, portability, efficiency and speed.
Although there are many new programming languages and technologies, C ++ is still the main tool of many developers, so its position will still be maintained for many years. C ++ stands out for flexibility, portability, efficiency and speed. Although the processing power of the computer has increased dramatically, software performance is still an important factor. C ++ is the language that will deliver superior performance in almost every way if used extensively. respectable.
This article compares 9 popular C ++ compilers, evaluating performance, features, and tools. Compilers (TBD) either support only Win32 environment, or support other Win32 variants. The evaluation is done on a Windows XP Pro machine (1 2GHz processor, 512MB RAM) completely not run other tasks.
Compile time
In many cases, compile time does not matter. However, it is a key element in large systems or in developing environments that often compile applications (as in the eXtreme Programming development model). Key elements in compiling / linking source code include: number of libraries, using precompiled components, code complexity, optimization requirements (for both boundaries translation and linking) and the size of the compilation modules. Scenarios considered:
C1. A large C file (1000 functions), unique (not 'include'); compiled, not optimized.
C2. A C file with a large number of include files (500); compiled, not optimized.
3. C3. A C file with the number of nested include files (100), each file included by the previous file and the main file. Evaluation of the impact of multi-level inclusion; compiler not optimized.
4. pch. A set of C ++ files (main.cpp, pch.cpp and 40 .h / .cpp files) share the same header (compiled and linked, precompiled and non-optimized).
5. whereis. A single but complex C ++ file with many include operating system libraries and templates (compilation only, size optimization).
6. MMComBsc. Large DLLs (44 C source files and 37 C ++ source files, 111 header files, 80 KB compilation size) include COM functions and classes (compilation and linking, precompiled headers; size).
Zlib. Generic and free data compression library, can run on multiple platforms.
Use Python scripts (http://www.ddj.com/ftp/2003/200310/cppcomp.zip) to create source files for scenarios 1-4. Whereis source code is available at http://stlsoft.org. / (updated binary file available at http://synesis.com.au/r_systools.html). The source files for MMComBs.dll have many things related to copyright issues so you temporarily accept the information provided here!
Examination results for scenarios 1-3 and 5 were taken with ptime (http://synesis.com.au/r_systools.html) by performing multiple times (15 times), skipping the top two results and 1 lowest result, the rest averaged to reduce deviation due to buffer or start up. Check situations 4, 6 and 7 using makefiles, ptime timing. The test results are shown in Table 1.
CodeWarrior's 'Did Not Compile' (DNC, not compiled) in C3 case results is due to TBD refusing to handle nested include up to 100 levels; The tests show a limited number of levels of 30. CodeWarrior Help Information: 'To overcome this problem, study the logical sequence behind the nested #include. There may be a way to separate multiple nested #includes into a less-than-nested #include array - this may be true but not always achievable. Watcom can not compile the whereis scenario and MMComBsc because it does not support the efficient template.
There are some significant differences in performance. Borland proved to be the best, followed closely by VC ++ 6, Digital Mars and VC ++ 7 by 3. CodeWarrior, GCC and Intel were the slowest TBDs in the group. VC ++ 7 compiles pch 43 times faster than CodeWarrior! VC ++ 7.1 is slower than VC ++ 7.0 in all tests.
Speed of code generation
Next we consider the speed of code generation, limited to the following five scenarios:
Dhrystone (http: //www.webopedia .com / TERM / D / Dhrystone.html). This test checks the computation speed of the integer. Because it uses the entire CPU (without any resource access or I / O tasks during the test), this is a good measure of the speed at which the code was compiled. The speed is measured with the Dhrystone number for 1 second (the larger the better).
Int2string . Converting integers to strings can waste your system resources. Millions of digits (0- & gt; 9.999.999) are converted to strings, and string lengths are added together. Here are two methods of conversion:
o & nbsp; & nbsp; & nbsp; Use the sprintf () function library. This speed reflects the differences in the performance of TBD libraries. (Intel uses the library of VC ++ 7.0).
o & nbsp; & nbsp; & nbsp; & nbsp; Use the template integer_to_string & lt; & gt ;. This rate directly reflects the speed of the compiled code.
StringTok . This situation creates a large set of strings to decode the token, using ';' make a separator. It separates the string from the code, then loop it sequentially to compute the total length from the code. Here we use the decomposition libraries from boost :: tokenizer & lt; & gt; (http: // boost.org) and stlsoft :: string_tokenizer & lt; & gt; (http://stlsoft.org/).
& nbsp;
RectArr . To get players to take full advantage of code generation in complex situations, use the 3D array template fixed_array_2d & lt; & gt; Of STLSoft, set the parameter value to stlsoft :: basic_simple_string & lt; char & gt; instead of std :: basic_string & lt; & gt; to focus on TBD's performance impact and reduce differences in standard libraries. This situation creates a 3D array of variable size (100x100x100) and loop through all three 'dimensions' of the array, assigning a random value to each element. There are 2 ways to do this:
o & nbsp; & nbsp; & nbsp; The first way to do a one-time count
o & nbsp; & nbsp; & nbsp; The second way is done 10 times. The allocation of 1 million elements & nbsp; is implemented gradually.
zlib . This is a featured library in many applications (http://zlib.org). It is a valuable performance test. The test program compresses the entire contents of a source file and exports it to a result file in a timed loop. Here we compile both zlib 1.1.4 source code and the test program with 9 TBD and execute it with a large file (65 MB) and a small file (149 KB).
In contrast to the Dhrystone scenario, all other scenarios are based on the WinSTL performance_counter class (see http://winstl.org/ and http: //www.windevnet. .com / documents / win0305a /). The results reflect the pure code speed, not affected by the operating system and other effects. All situations are optimized for speed (-O2, -opt speed, -o + speed, -O3, -O2, -O2, -ot). Table 2 shows the results.
In particular the Dhrystone situation was carried out running the test nine times, ignoring the highest and lowest values, remaining averaged. (The source of all situations is in http://www.ddj.com/ftp/2003/200310/cppcomp.zip
Digital Mars' DNC value is due to the fact that this TBD is not supported in the 1.30 Boost library. Boost / Digital Mars compatibility is in progress, and may be finalized as you read this article. Watcom 'DNC' values reflect the lack of support for its generic template.
:2677 Thivering colors Thels & Thick Thull Thing that Thungauer Throat Thăm Thuy Thăm Thels Thăm thể & ) Flies7 Flot encending7777 Flies Flunch7777 Flies Flunch7 or7 Flies Flies Flearvereels Flux) Flachans Flear Flies Flies Flear7 New or7.) Flies Flies7 Flux Fl. Digital Mars, VC ++ 7.0, and VC ++ 7.1 are all in the same place.
Due to not being featured in five scenarios, and given poor speed in two other situations, Watcom had to be at the bottom of the table. However, it won the Int2String (sprintf ()), so it was not bad. Borland and CodeWarrior perform well in some situations - Borland is the fastest with zlib but loses points in other situations. GCC performs poorly in all situations, except for two variants of STLSoft.
The differences between the variants of the Int2String and StringTok scenarios are not significant. Use template integer_to_string & lt; & gt; Significant speed improvements, execution time is only about 15% to 55% compared to printf (). The analysis from the string code showed a significant difference: the execution time of STLSoft code analyzer ranges from 6 to 26% compared to Boost.
Size code generated
Execution speed is not always more important than code size, as well as performance optimization does not always result in faster processing, because larger code often does not have enough buffer memory. and must require virtual memory of the operating system.
You always like the small program code. In Table 3, focus on the module size, VC ++ is the leading TBD. VC ++ 7.0 creates the smallest code, followed by VC ++ 7.1, followed by VC ++ 6.0. Intel, Digital Mars, and Watcom make & nbsp; work pretty well. Borland and CodeWarrior are not bad either. The GCC is amazing with modules that are 10 times larger than the top TBD in some situations.
Library
Standard Library. Except for Digital Mars and Watcom, all TBDs support C ++ 98 Standard Library. Digital Mars C ++ comes with the latest SGI STL and STLport (www.stlport.org), but has not updated the new header names (& lt; iostreams & gt; instead of & lt; iostreams.h & gt;) and allows internal declarations. std namespace. Both TBDs are being modified for full compatibility.
. Except for GCC and Watcom, all TBDs support ATL, but some only support version 3, not 7.
Boost . This library is supported by all TBDs, except for Digital Mars (under development), VC ++ 6 (limited support) and Watcom (not supported at all).
Managed C ++. Only VC ++ 7 supports Managed C ++. However, in the context of this article, Managed C ++ is not an important library.
. Although fairly 'old', MFC is still widely used (and still useful). It is fully supported with VC ++, Intel C ++, CodeWarrior and Digital Mars. MFC can also be used in Borland C ++ Builder, but Watcom and GCC are not supported at all.
STLSoft . Except for Watcom, all other TBDs support most of STLSoft's libraries, and Watcom also supports quite a few. STLSoft is integrated with Digital Mars from version 8.34 onwards.
Win32 / Platform SDK. All Win32 platforms support the Win32 API, although some do not support the Platform SDK-compliant version. In particular, GCC and Watcom do not support the February 2003 Platform SDK.
16 & shy; bit . Both Digital Mars and Watcom support 16-bit. Demand for this feature is not high; However, there is a need for a response tool in case of need.
. VC ++ and Intel work very well with WTL, much better than other TBDs. CodeWarrior works only a little bit, and Borland and Digital Mars need some effort.
Development tools
Most TBDs come with integrated development and debugging environment (IDDE). Choosing development tools is almost a matter of personal preference. In general, all IDDEs have the minimum features needed to create software projects and source code as well as error traps. However, some IDDEs are quite simple. IDDs such as Digital Mars or Watcom are hard to lure developers from their favorite development environment.
Conclude
Can not simply say TBD is the strongest. Most TBDs have strengths and weaknesses.
o & nbsp; TBD of Borland is the fastest, with good language support and no blame. However, it is an internal compiler error (ICE) when it is too difficult to do, which is also a 'disease' of VC ++.
Code Warrior is very powerful in terms of language, with easy-to-understand error messages. It is a good (but not very good) IDDE, pretty efficient code generation, and support for all popular libraries. This is a good candidate if you only have one option.
Digital Mars was excellent, ranked first in terms of language support, compile time, and execution speed. It occupies the 4th largest file size of the executable. However, it supports the non-standard Standard Library, occasional ICE errors, and outdated development environment. However it is free and has good support.
o The best language support is GCC, which is likely to work well with any open source TBD (possibly with commercial TBDs). However, this is also a problem that results in its inefficient characteristics. Experimental scenarios show that GCC is the slowest, slowest, and most cumbersome (as opposed to Digital Mars).
o Coding speed - this is usually the most important factor - Intel dominates the absolute. TBD for good code size but lost points on compilation time. Intel also has good language support but it does not have its own development environment but is integrated with Visual Studio (98 and .NET). Surprisingly, many programmers in the Microsoft environment (Win32 systems, Visual Studio) do not know how to exploit this.
o Visual C ++ performs better than expected. It generates the smallest code, compiles fast, has good code generation speed (but loses Intel). Finally, it also supports good language; Even VC ++ 7.1 can detect some typename errors in STLSoft libraries that CodeWarrior and GCC omitted. VC ++ has been downgraded due to poor language support (now this problem has been resolved dramatically in version 7.1, although it's a bit late), long update time (from version 6 to 7 5 years), bulky size to gigabytes, and TBD and IDDE both think that you will use Microsoft's MFC. Finally, WTL is fully supported in Visual Studio .NET and its wizards.
Watcom has poor template support, which makes it difficult to compare with other TBDs. It's good in the featured areas, although the Dhrystone speed is extremely poor. Hopefully it will continue to evolve under its 'Open Watcom' banner, and return to the light that Watcom C / C ++ had in the mid-1990s.
All C ++ professionals do not use a single TBD. No TBD can meet all requirements, using more TBD can give a more comprehensive solution. Furthermore, there is nothing better than making your source code capable of working with more than one TBD. In this respect, Borland and Visual C ++ are particularly bad. Edit the C ++ development environment by combining 3 or 4 TBD, you will see the quality of your program grow significantly.
& nbsp;
