草庐IT

c - 在单独的编译单元中调用函数是否有更多开销?

我知道由于双跳转,在DSO中调用函数会产生更多开销。与在同一编译单元中调用一个函数相比(假设在这两种情况下都没有内联),在单独的编译单元中调用函数是否有更多的开销? 最佳答案 一般来说,它们将是相同的,不包括内联或其他全局优化机会。但根据架构的不同,可能存在细微差别。比如在Linux/Unix中,问题不在于不同CU的函数之间,而在于你调用的函数是否有外部链接:voidfoo(){}voidbar(){foo();}或者:staticvoidfoo(){}voidbar(){foo();}如果此代码被编译成共享对象(但不是可执行文件!

linux - 在 Linux 内核中支持浮点运算的开销

众所周知,基于Linux/BSD的内核不支持浮点(FP)算法。在内核中处理FP寄存器的开销是多少? 最佳答案 通常的回答是,如果内核不使用float,则不必在进入内核时保存浮点寄存器或在退出时恢复它们。这将所有系统调用的成本削减数百个周期。我不知道是否有人尝试将这种节省与内核可以不加选择地使用这些寄存器时可能获得的性能改进进行比较。请注意,如果您小心谨慎,您可以在内核中使用它们,并且这是在可以获得巨大速度优势的环境中完成的,例如使用SSE指令加速memcpy等。(在Linux源代码中查找对kernel_fpu_begin的调用。)

c - 在不修改内核的情况下拦截系统调用的最小开销方式

我知道拦截系统调用的方法如下。使用ptrace,但这似乎有很高的开销。据我所知,像strace这样的工具也在内部使用ptrace。使用内核模块来更改系统调用表,但据我所知,这种方法在后来的linux内核中不再可行。使用LD_PRELOAD。但是,如果您直接进行系统调用而没有为该系统调用使用一些包装库函数,这将不起作用。所以你看上面提到的所有方法都有缺陷。所以我的问题是在不修改内核且开销最小的情况下拦截系统调用的方法是什么。 最佳答案 如果不能修改内核,就必须修改应用程序。您需要以某种方式拦截int/syscall/sysenter指

c++ - Linux内存管理开销

我试图解释我在Linux中的应用程序所占用的内存。我做了一个基本测试,发现如果我们新建一些内存,它至少为单个新内存分配32个字节。这是我的代码。#include#includeusingnamespacestd;intmain(intargc,constchar**argv){intiBlockSize=atoi(argv[1]);intiBlockCount=atoi(argv[2]);for(inti=0;i当我执行./a.out8100时,它给出了以下结果。............0xf6db100xf6db300xf6db500xf6db700xf6db900xf6dbb00x

linux - NUMA 内存页面迁移开销

我必须找出在Linux下与NUMA内存页面迁移相关的开销。您能告诉我可以使用哪些工具吗?如果可能的话,你能举个例子吗。 最佳答案 如果您想了解您的系统是否正在执行过多的远程节点内存访问并且您正在使用英特尔CPU,Intel'sPMU有一个名为vtbwrun的实用程序来报告QPI/uncore事件。如果您想查看执行页面迁移需要多长时间,您可以测量调用numa_move_pages的持续时间(由numactl包提供)。这是anexample:/**Testprogramtotestthemovingofaprocessespages.*

linux - dlopen 与链接开销

假设我有一个库-foo.so。在构建我的二进制文件(需要这个库)时,我可以(1)链接foo.so,或者(2)在程序源代码中,dlopen这个库,然后调用这个库提供的函数当我从库中调用函数时,(1)和(2)之间是否存在任何性能差异?请注意,我知道会有不同的初始化特征(例如dlopen的成本、首次使用符号的开销等),但在稳定状态下,两种替代方案是同样快还是更快?谢谢。 最佳答案 如果库是使用gcc-Wall-fPIC-O2编译并使用gcc链接的共享对象(即一些lib*.so文件)-shared那么它是一个ELFPositionIndep

c - 共享对象开销

我们有一个非常模块化的应用程序,其中包含大量共享对象(.so)。有些人认为在内存/闪存有限的低端平台上,最好将所有内容静态链接到一个大的可执行文件中,因为共享对象会产生开销。你对此有何看法?最好的问候,保罗 最佳答案 共享库的成本大致是(每个库):至少4k的私有(private)脏内存。至少12k的虚拟地址空间。多个文件系统访问系统调用、mmap和mprotect系统调用,以及至少一个加载时页面错误。是时候解析库代码中的符号引用了。加上与位置无关的代码成本:丢失一个通用寄存器(这在x86(32位)上可能会很大,但在其他架构上几乎无关

c - 空堆竞技场的开销

我的工具是Linux、gcc和pthreads。当我的程序从多个线程调用new/delete时,并且存在对堆的争用时,将创建“arena”(引用以下链接http://www.bozemanpass.com/info/linux/malloc/Linux_Heap_Contention.html)。我的程序运行24x7,并且arenas仍然偶尔在2周后创建。我认为最终可能会有和线程一样多的竞技场。ps(1)显示了惊人的内存消耗,但我怀疑实际上只有一小部分被映射了。空场的“开销”是多少?(与所有分配都局限于传统堆相比,每个竞技场使用了多少内存?)有没有办法强制提前创建n个arenas?有没

c - AF_UNIX 套接字开销?

我看到一对AF_UNIX套接字由调用创建的一些奇怪的事情,例如:socketpair(AF_UNIX,SOCK_STREAM,0,sfd);其中sfd是文件描述符的int[2]数组。首先,默认缓冲区大小似乎恰好是122K(124928字节),而不是/proc/sys/net中的任何内容(例如设置为128K的wmem_default)。有谁知道这种奇怪的缓冲区大小的原因吗?其次,通过套接字(8字节)写入小消息时。我只能在写入block之前写入其中的423个,也就是8*423=3384字节,又是一个奇怪的大小。这些消息就像每条消息占用295多个字节一样。这种开销的来源是什么?在RHEL6(

linux - 上下文切换的开销是多少?

最初我认为上下文切换的开销是刷新TLB。但是我刚刚在维基百科上看到:http://en.wikipedia.org/wiki/Translation_lookaside_bufferIn2008,bothIntel(Nehalem)[18]andAMD(SVM)[19]haveintroducedtagsaspartoftheTLBentryanddedicatedhardwarethatchecksthetagduringlookup.Eventhoughthesearenotfullyexploited,itisenvisionedthatinthefuture,thesetags