是否弃用了内联函数和#define函数？ [英] Is the use of inline and #define functions deprecated?

问题描述

我经常在高速编码中看到使用#define和内联函数来加速程序。

我进行了一些速度测试，结果是在windows中工作没有用。

#define仅对我有用，但我在旧的1GHz电脑上测试过。



以下是结果：

Quote：

Windows7 Intel 3.5Ghz

发布模式：

#define = 1.009纳秒/操作

函数= 0.997纳秒/操作

内联函数= 1.031纳秒/操作



调试模式：

#define = 3.467纳秒/操作

函数= 11.09纳秒/操作

内联函数= 11.81纳秒/操作



LINUX AMD 1Ghz：

#define = 10.06纳秒/操作

功能= 14.28纳秒/操作

内联乐趣ction = 13.20纳秒/操作

我尝试过：



它是用Linux编译的：gcc -std = c ++ 11 -lstdc ++ -o prue define_timing.cpp



我试过以下代码：

 #include< iostream> 
 #include< chrono>使用namespace std 
 
; 
 
 #define INLIMIT2（x，xmin，xmax）（（x）<（xmin）？（xmin）:(（x）<（xmax）？（x）:(（xmax） ）））
 double inlimit2（double x，double xmin，double xmax）
 {
 if（x< xmin）
 return xmin; 
 else if（x> = xmax）
返回xmax; 
返回x; 
} 
 
 
 inline double inlimit3（double x，double xmin，double xmax）
 {
 if（x< xmin）
 return xmin; 
 else if（x> = xmax）
返回xmax; 
返回x; 
} 
 
 int main（）
 {
 const int top = 1000000000; 
 double * x = new double [top]; 
 int i; 
 for（i = 0; i< top; i ++）x [i] = 1.01 * i; 
 time_t ini，fin; 
 double x2 = 0.0; 
 
 cout<< 使用#define进行测试：<< ENDL; x2 = 0.0; 
 ini = clock（）; 
 for（i = 0; i< top; i ++）x2 + = INLIMIT2（x [i]，10.0,100.0）; 
 fin = clock（）; 
 cout<< 时间/操作=<< 1e9 / top *（1.0 * fin-ini）/ CLOCKS_PER_SEC<< nanoseconds / operation<< ENDL; 
 cout<< Result =<< x2<< ENDL; 
 
 cout<< 使用函数测试：<< ENDL; x2 = 0.0; 
 ini = clock（）; 
 for（i = 0; i< top; i ++）x2 + = inlimit2（x [i]，10.0,100.0）; 
 fin = clock（）; 
 cout<< 时间/操作=<< 1e9 / top *（1.0 * fin-ini）/ CLOCKS_PER_SEC<< nanoseconds / operation<< ENDL; 
 cout<< Result =<< x2<< ENDL; 
 
 cout<< 使用内联函数测试：<< ENDL; x2 = 0.0; 
 ini = clock（）; 
 for（i = 0; i< top; i ++）x2 + = inlimit3（x [i]，10.0,100.0）; 
 fin = clock（）; 
 cout<< 时间/操作=<< 1e9 / top *（1.0 * fin-ini）/ CLOCKS_PER_SEC<< nanoseconds / operation<< ENDL; 
 cout<< Result =<< x2<< ENDL; 
 
删除x; 
 cout<< === END ===<< ENDL;的getchar（）; 
返回1; 
} 

解决方案

现代编译器将内联关键字视为建议。他们可以使用该关键字创建一个内联或不内联的函数，也可以创建没有该关键字作为内联的函数。



如果你真的想知道编译器在做什么您必须使用MS编译器检查程序集输出（GCC选项 -S 和 / FA 选项）。 />


它还取决于通常在调试版本中禁用的编译器优化。因此，由于使用调试构建插入的附加代码（如数组绑定检查），使用调试版本进行性能测量并将结果与​​发布版本中的结果进行比较通常没有意义。



使用宏时，您将拥有内联代码。因此，您可以使用宏而不是函数来强制内联。



但请注意宏的缺点（容易产生不必要的副作用，没有类型检查，代码可读性更差）。



当不使用宏时，您仍然可以通过优化速度而不是大小来确保编译器生成更多内联代码（MS编译器： / O2 ; GCC：不要使用 -Os ;使用 -O2 或 -O3 ）。



GCC在没有指定优化时不会创建内联函数，只有极少数（如果有的话） -O 和 -O1 。由于您尚未指定任何优化选项，因此您的Linux版本未使用内联函数（时差可能是由于不确定性）。我建议在使用 -O2 或 -O3 构建后重复测量。

< blockquote>这取决于编译器的优化，我想。

作为一般建议，尽可能使用最干净的代码，只有在需要加速时才应用手工制作优化（并且可能达到） ）。

I see usually in high speed coding the use of #define and inline functions in order to speed up the programs.
I made some speed tests and as result that efforts are unuseful in windows.
The #define is useful only for me in linux but I tested in an old 1GHz computer.

Here are the results:

Quote:

Windows7 Intel 3.5Ghz
Release mode:
#define = 1.009 nanoseconds/operation
function = 0.997 nanoseconds/operation
inline function = 1.031 nanoseconds/operation

Debug mode:
#define = 3.467 nanoseconds/operation
function = 11.09 nanoseconds/operation
inline function = 11.81 nanoseconds/operation

LINUX AMD 1Ghz:
#define = 10.06 nanoseconds/operation
function = 14.28 nanoseconds/operation
inline function = 13.20 nanoseconds/operation

What I have tried:

It was compiled in linux using: gcc -std=c++11 -lstdc++ -o prue define_timing.cpp

I tried following code:

#include <iostream>
#include <chrono>

using namespace std;

#define INLIMIT2(x,xmin,xmax) ( (x)<(xmin) ? (xmin) : ((x)<(xmax) ? (x) : ((xmax)))) 
double inlimit2(double x, double xmin, double xmax)
{
	if (x < xmin)
		return xmin;
	else if (x >= xmax)
		return xmax;
	return x;
}


inline double inlimit3(double x, double xmin, double xmax)
{
	if (x < xmin)
		return xmin;
	else if (x >= xmax)
		return xmax;
	return x;
}

int main()
{
	const int top=1000000000;
	double *x=new double[top];
	int i;
	for (i = 0; i < top; i++) x[i] = 1.01*i;
	time_t ini, fin;
	double x2 = 0.0;

	cout << "Test using #define:" << endl; x2 = 0.0;
	ini = clock();
	for (i = 0; i < top; i++) x2 += INLIMIT2(x[i], 10.0, 100.0);
	fin = clock();
	cout << "Time/op=" << 1e9 / top*(1.0*fin - ini) / CLOCKS_PER_SEC << " nanoseconds/operation" << endl;
	cout << "Result=" << x2 << endl;

	cout << "Test using function:" << endl; x2 = 0.0;
	ini = clock();
	for (i = 0; i < top; i++) x2 += inlimit2(x[i], 10.0, 100.0);
	fin = clock();
	cout << "Time/op=" << 1e9 / top*(1.0*fin - ini) / CLOCKS_PER_SEC << " nanoseconds/operation" << endl;
	cout << "Result=" << x2 << endl;

	cout << "Test using inline function:" << endl; x2 = 0.0;
	ini = clock();
	for (i = 0; i < top; i++) x2 += inlimit3(x[i], 10.0, 100.0);
	fin = clock();
	cout << "Time/op=" << 1e9 / top*(1.0*fin - ini) / CLOCKS_PER_SEC << " nanoseconds/operation" << endl;
	cout << "Result=" << x2 << endl;

	delete x;
	cout << "=== END ===" << endl; getchar();
	return 1;
}

解决方案

Modern compilers treat the inline keyword as a suggestion. They may create a function with that keyword as inline or not and may also create functions without that keyword as inline.

If you really want to know what the compiler is doing you have to inspect the assembly output (GCC option -S and /FA option with the MS compiler).

It also depends on the compiler optimisations which are usually disabled with debug builds. Therefore, and due to additional code that is inserted with debug build like array bound checks, it makes usually no sense to do performance measurings with debug builds and compare the results with those from a release build.

When using macros, you will have inline code. So you might use macros instead of functions to force inlining.

But be aware of the drawbacks of macros (prone for unwanted side effects, no type checking, worse code readability).

When not using macros you can still ensure that the compiler generates more inline code by optimising for speed instead of size (MS compiler: /O2; GCC: do not not use -Os; use -O2 or -O3).

The GCC will not create inline functions when no optimisation is specified and only very few (if any) with -O and -O1. Because you have not specified any optimisation option, your Linux build has not used inline functions (the time difference may be due to uncertainty). I suggest to repeat your measurements after building with -O2 or -O3.

It depends on compiler optimizations, I suppose.
As a general advice, use the cleanest code you can and apply 'hand-crafted' optimization only whenever a speed-up is required (and possibly reached).

这篇关于是否弃用了内联函数和#define函数？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！