Shulou(Shulou.com)06/03 Report--

This article mainly shows you the "example Analysis of programming language performance comparison", which is easy to understand and clear. I hope it can help you solve your doubts. Let the editor lead you to study and learn the article "sample Analysis of programming language performance comparison".

Since the birth of programming languages, people often argue about which language is the fastest. Whether it is serious scientific research or the hustle and bustle of late-night forums, there is no lack of disputes on this topic. This article is not going to discuss this issue, but we might as well look at it from a higher level: how to compare the performance of two very different programming languages. In order to make a meaningful comparison, we must implement a series of test programs in two programming languages, run the benchmark, and then compare the final results.

In fact, this kind of comparison is very difficult, sometimes even time-consuming and laborious. Although the problem itself may seem simple, a large number of possible errors can lead to frustrations for performance testers who know nothing about it, and sometimes it doesn't help even if they know it very well.

Equivalent implementation?

In order to fairly compare the implementation of the two languages, the quality of the programs written should reach the same level. In other words, the program must be written by someone who has roughly the same level of knowledge of both programming languages and domains. This in itself is very difficult. If different people write the implementation, they may choose different algorithms to solve the problem, so the performance comparison is no longer a problem of the programming language itself, but of the programming method chosen by each programmer.

Even if both implementations are written by the same person using the same algorithm, there are still other problems. Usually, everyone has a language that he or she is good at. As a result, they will choose their favorite language to provide faster implementation. This can lead to bias, because such a performance comparison measures not the programming language itself, but more programmers. This type of testing is suitable for looking for differences in ease of use and productivity, but not for comparing performance.

Therefore, you may need to evaluate programs that many professional programmers have already written. This is a good method, but sometimes even experienced research can go wrong. One paper attempts to compare the performance and efficiency of different programming languages in this way. Their test results show that the implementation of a program in C is 30% faster than that of C++. The test results affect the tone of the whole paper. According to this argument, assuming that the file extension .c of all C source code is changed to .cpp and recompiled, you should get roughly the same result (with a margin of error of several percentage points). So we can only come to the following conclusions (in order of probability from high to low):

1. The code of C++ version is poor.

2. There are obvious defects in the test method.

3. Compared with C, the compiler has a significant negative impact on the performance of C++.

In other words, the differences presented above do not come from the programming language itself.

The difficulty of measurement

Another big problem is how to measure the performance of a program. A common method is to run tests several times in a row, and then do the following:

1. Deal with abnormal values: remove two extremes (that is, the slowest and fastest measurements)

2. Calculate the average and / or median of the remaining data points

3. Comparing the results between different programs, the fastest program wins.

The alignment of all computers is a double-edged sword

Although statistics are very difficult, fortunately computers are simple because they are deterministic, reliable, and logical. For example, if you add a NOP instruction to a program, the result may be an extra instruction cycle with too little impact on performance to be measured. However, if you have to measure, the results may make you confused and confused. This small change sometimes increases the running time of the program by 10% (or more), but it is also possible to reduce the running time by 10%. You read it right, this kind of seemingly meaningless work can speed up the program. If this is the first time you have encountered such a problem, you may not believe it at all.

So, the question is, is it possible for CPU to redouble its efforts to make the program run faster? The answer is no. The actual instructions don't matter at all. The point is the alignment of the code. Different locations of the code in memory can affect its performance characteristics. If a loop that is often executed crosses the cache boundary, it slows down. Moving it to a place that does not cross the border will speed it up. The NOP instruction doesn't have to be in a loop; it can cause this difference as long as it moves the entire block of code up or down. Suppose you measure two programs in a very rigorous statistical way. If the performance difference between the two is less than 10%, we can't tell which program is faster unless you use measurements that eliminate the alignment effect.

People who have taken statistics courses may remember how to calculate the standard deviation. This method seems reasonable and rigorous, but it actually contains multiple systematic errors. The biggest problem involves noise in measurement.

Most basic statistical tools assume that the error is normally distributed and the average is zero. This assumption is reasonable if the temperature or speed is measured. However, this assumption is not reasonable for performance measurement of programming languages. The running time of the program includes the time actually spent solving the problem, as well as the overhead from operating system interruptions, disk access, and so on. If we assume that the noise is Gaussian noise with an average of zero, then this means that the computer has some unknown processes that can make the program run faster than when there is no noise at all. Of course this is impossible. The noise here is definitely not Gaussian noise, because it will never be negative.

In fact, the measurement closest to the platonic ideal answer is the fastest, because in this case there is the least interference from the system noise. Such measurements will be deleted by the above first step operation "handling outliers". Sometimes, adopting reasonable and ready-made measures will only make things worse.

This is about the performance measurement of the machine, not the language

As the program runs faster and faster, optimization has gone through an interesting phase of transformation. Once the performance reaches a certain level, the system no longer cares about how the compiler and CPU can speed up the program. Instead, it becomes how programmers use CPU as efficiently as possible, such as arranging data into layouts that are convenient for processors to process. This means replacing language-based primitives with hardware-based primitives. The optimization used in some circles is so strange that programmers even know which SIMD instructions their loops should be optimized into, and then they keep modifying the code until they achieve this optimization. In fact, this optimization has nothing to do with the functionality of the programming language itself.

This is the main reason why languages like C and Fortran are still at the top of many performance benchmarks, but these skills are not limited to these languages. A few years ago, I developed a very large Java application that was very thoroughly optimized. Its interior consists of an array of integers. The most frequently executed path has no classes or even Integer objects, which is basically tantamount to reshaping C within the Java language. In fact, almost any programming language can have a similar implementation. The performance difference between them mainly depends on the optimizer of each compiler. Even using the same programming language can produce very different performance results, not to mention different programming languages. Therefore, it is unreasonable to claim that a programming language has a significant performance advantage, because in the final analysis, it is an inline assembler.

The above is all the contents of the article "sample Analysis of programming language performance comparison". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.