C/C++
linxxx3
CUDA,Phi,Multi-core Parallel programming
展开
-
C++中vertor的用法
<br />C++内置的数组支持容器的机制,但是它不支持容器抽象的语义。要解决此问题我们自己实现这样的类。在标准C++中,用容器向量(vector)实现。容器向量也是一个类模板。<br />标准库vector类型使用需要的头文件:#include <vector>。vector 是一个类模板。不是一种数据类型,vector<int>是一种数据类型。Vector的存储空间是连续的,list不是连续存储的。<br />一、 定义和初始化<br />vector< typeName > v转载 2010-06-25 16:27:00 · 1573 阅读 · 0 评论 -
Intel Transactional Synchronization Extension (TSX) 事务性同步扩展
这是一份Intel IDF2013上的讲座笔记。TSX是新一代Haswell架构上,通过硬件支持的事务性内存(Transactional Memory)解决方案。1. 动机一句话概括Intel的事务性同步扩展(Transactional Synchronization Extension, TSX)的动机:粗粒度锁保证的事务性操作,在高并发下性能下降,作为细粒度锁方案的一种替代,原创 2013-04-11 14:34:46 · 1413 阅读 · 0 评论 -
C程序中简单获取机器的CPU物理核数和主频(Redhat Linux系统)
获取这两个参数,主要的目的是计算机器的理论浮点峰值。言归正传,问题有两个部分,一个是如何获取这两个值,另一个是怎么传递到C程序中。1. 获取(以下内容在非Redhat 系统上需要变通以下,不能用是正常的)先看一个cpuinfo的例子:$cat /proc/cpuinfoprocessor : 0vendor_id :GenuineIntelcpu family原创 2013-03-26 18:56:37 · 849 阅读 · 0 评论 -
GotoBLAS2编译,与openmp兼容性的解决方案
编译配置在makefile.rule里,在较新的机器上,首先要设置target和位宽,比如:TARGET=NEHALEMBINARY=64然后,multi-threaded版本与openmp使用有潜在冲突:1. 首先,必须禁用gotoblas2的cpu affinity选项,即设置 NO_AFFINIY = 1 否则,编译出的libgoto2,能原创 2013-02-01 10:54:01 · 611 阅读 · 0 评论 -
关于函数的calling convention(调用规范)
最近做C和汇编的混合编译时,掉进的一个坑,记一笔。对于混合编程,最需要注意的地方是平台层面的ABI (application binary interface) 和语言层面的calling convention。这次的坑:caller是C语言函数,callee用汇编写的。C函数里的实参用的int型,汇编函数输入需要long型。在64位平台的汇编,要求INTEGER类型的参数原创 2013-02-20 19:27:08 · 605 阅读 · 0 评论 -
GNU和Intel的debugger在使用方便性上的比较
GNU的调试器就是大名鼎鼎的gdb,Intel对应的产品是idbc,大体上命令和使用方法都是一样的,但是使用的方便性上,也就是调试时呈现的方式稍有不同。实际gdb也可以调试icc编译的程序,但是会丢失一些信息,使断点等的定位不准,多线程的调试不能进入并行区等,不推荐。idbc最让人不爽的一点,是使用list (l)命令显示源码,会从当前行的前几行开始,这样连续使用list 的话,打原创 2012-12-19 17:42:38 · 713 阅读 · 0 评论 -
一个简单的大坑,C语言整型常数的声明与乘法溢出
栽到一个简单的坑里了,怪自己基础不牢,网上查了下,中文的结果貌似没有写这个的,所以发出来。下面的代码,变量 i 的值是多少呢:#define P (64*1024)long long i = P * P;答案是 i 溢出了,暂时我看到结果 i = 0(当然这很有可能结果属于未定义)。解决的关键是,对于运算可能出现超出int范围的常数,一律声明为long,比如#define P原创 2012-10-25 15:37:17 · 3296 阅读 · 1 评论 -
非规格化浮点数(nan, inf, subnormal等)的判别和运算
大规模数学运算中有时会碰到结果为NaN的情况,由于NaN参与任何比较得到false(这点与inf不同!),将破坏正常的程序逻辑,又因为NaN同任何数做数学运算得到NaN,具有传递性,使得定位非常困难。NaN产生的最可能的原因是 0*inf ,大多数路径是这样的:1/subnormal = inf 或 1/0 = inf --> 0 * inf = nan下面的代码重原创 2012-10-12 19:32:36 · 1729 阅读 · 0 评论 -
用Intel编译器做C和fortran混合编译的trick,关于for_main.o
上次写了GNU的一套编译器做C和fortran的混合编译问题,这次因为机器编译环境的问题,用了intel的编译器(icc/ifort/icc编译的mpi),使用C语言的主程序调用fortran的函数,同样的方法会遇到链接的问题:multiple definition of `main':/opt/intel/……/lib/intel64/for_main.c: first defi原创 2012-03-07 17:01:51 · 1127 阅读 · 0 评论 -
gcc的大坑,inline函数
为什么说inline函数是gcc的一个大坑呢?因为对inline的处理,它做了C99标准之外的东西,虽然更方便了,但是埋下了兼容性的隐患。我偶然想用icc编译以前的代码发现链接不能通过,引用一个inline函数提示未定义。网上有篇日志讲的很详细:GCC中的inline关键字 (原创 2011-07-12 23:00:48 · 775 阅读 · 0 评论 -
函数后const声明的含义
<br /> 类成员函数中const的使用 <br /> <br />一般放在函数体后,形如:void fun() const; <br />如果一个成员函数的不会修改数据成员,那么最好将其声明为const,因为const成员函数中不允许对数据成员进行修改,如果修改,编译器将报错,这大大提高了程序的健壮性。<br /> <br />原文可以参考:const在函数前与函数后的区别——http://apps.hi.baidu.com/share/detail/743转载 2011-04-02 11:06:00 · 445 阅读 · 0 评论 -
linux使用openmp及math库的小问题
<br />有些小问题在初次使用的时候很烦,知道了就很容易。下面的麻烦事我自己碰到的,分享一下,大牛见笑。<br /> <br />gcc和g++本身包含openmp的支持,但是使用上有一点区别:gcc或者icc只需要添加-fopenmp编译即可使用,但是g++需要包含<omp.h>头文件以使用某些C风格的函数,比如omp_get_num_procs。<br /> <br />我使用的redhat enterprise 6 系统的math动态库 libm.so在默认链接路径下,但是如果使用-static静态原创 2011-03-16 19:02:00 · 1462 阅读 · 0 评论 -
结构体数据对齐
driver API中需要对function传递参数,本来这个是device端的对齐问题。但是当我想用结构体来传递参数时,想让结构体的对齐方式与device要求的一致,这时是主机端代码的问题了。如果认为device端数据都必须按照8byte对齐(其实不对齐也可以,不知道这个说法怎么来的),怎么做呢?查了一下,用 #pragma pack ([n])可以,或者:typedef struct kernel_args { int dummy; CUdeviceptr d_res;原创 2010-10-11 09:52:00 · 284 阅读 · 0 评论 -
赋值带限定符时的规则
<br />带限定符const ,static 的赋值<br /> <br />1. 对于普通类型赋值: 规则很简单<br />2. 对于指针类型赋值: "="两边都是指针时,左边的指针必须具有右边指针的全部限定符(可以更多)。<br /> <br />有一点就是在程序里对常量和内建变量取地址操作 & 会得到 const 修饰的指针!!<br /> <br />更加详细的说明mark一下,希望页面不会失效:<br />http://www.cnblogs.com/chio/archive/2008/09/1原创 2010-09-27 09:44:00 · 255 阅读 · 0 评论 -
非规则浮点数(subnormal)引起浮点运算变慢
1. 非规则浮点数(subnormal) 根据IEEE754(http://zh.wikipedia.org/wiki/IEEE_754),浮点数由符号位、指数、尾数组成,对8字节的double 类型数据,指数位有11位,可以表示2的阶数范围 -1022~+1023,对应的指数部分的值是1~2046(加上1023的偏移)。 double类型的尾数位有52位,原创 2013-04-16 18:40:46 · 2057 阅读 · 0 评论