blocks|key|3134416|text|在处理中断或高性能数据读取时，您可能需要对齐高速缓存线边界，每个高速缓存线通常为64字节，并且在处理进程间套接字时必须使用它们。对于进程间套接字，有一些控制变量不能分布在多个缓存线或DDR字中，否则它将导致L1、L2等或缓存或DDR充当低通滤波器，并过滤掉中断数据！这太糟糕了！这意味着当你的算法很好的时候，你会得到奇怪的错误，它有可能让你发疯！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3134417|DDR+RAM几乎总是要读入128位字(DDR+RAM字)，即16字节，因此环形缓冲区变量不应分布在多个DDR+RAM字中。有些系统确实使用64位DDR+RAM字，从技术上讲，您可以在16位CPU上获得32位DDR+RAM字，但在这种情况下会使用SDRAM。|3134418|当在高性能算法中读取数据时，人们可能只对最小化所使用的高速缓存线的数量感兴趣。在我的例子中，我开发了世界上最快的整数到字符串算法(比以前最快的算法快40%25)，我正在优化Grisu算法，这是世界上最快的浮点算法。为了打印浮点数，你必须打印整数，所以为了优化Grisu，我已经实现了一个优化，我已经实现了高速缓存线对齐的Grisu的查找表(LUT)到恰好15个缓存线，这是相当奇怪的，它实际上是这样对齐的。这将从.bss部分(即静态内存)获取but，并将它们放到堆栈(或堆，但堆栈更合适)上。我还没有对此进行基准测试，但可以提出来，我学到了很多关于这方面的知识，最快的加载值的方法是从i-cache而不是d-cache加载它们。不同之处在于，i-cache是只读的，并且具有更大的缓存线，因为它是只读的(2KB是一位教授曾经引用给我的)。因此，您实际上是要将性能从数组索引中分离出来，而不是像这样加载变量：|3134419|int+faster_way+=+12345678;|code-block|syntax|javascript|3134420|与较慢的方式相反：|3134421|int+variables[2]+=+{+12345678,+123456789};
int+slower_way+=+variables[0];|3134422|不同之处在于，int+variable+=+12345678将通过从函数开始时偏移到i-cache中的变量来从i-cache行加载，而slower_way+=+int[0]将使用慢得多的数组索引从较小的d-cache行加载。正如我刚刚发现的，这个特殊的巧妙之处实际上减慢了我和其他许多人的整数到字符串算法。我之所以这么说，是因为你可能认为你是在通过缓存对齐只读数据来进行优化。|offset|length|style|CODE|3134423|通常在C%2B%2B中，您将使用std::align函数。我建议不要使用这个函数，因为it+is+not+guaranteed+to+work+optimally。这是对齐到缓存线的最快方法，说实话，我是作者，这是一个无耻的插头：|3134424|Kabuki+Toolkit内存对齐算法|3134425|namespace+_+{
/*+Aligns+the+given+pointer+to+a+power+of+two+boundaries+with+a+premade+mask.
@return+An+aligned+pointer+of+typename+T.
@brief+Algorithm+is+a+2's+compliment+trick+that+works+by+masking+off
the+desired+number+of+bits+in+2's+compliment+and+adding+them+to+the
pointer.
@param+pointer+The+pointer+to+align.
@param+mask+The+mask+for+the+Least+Significant+bits+to+align.+*/
template+<typename+T+=+char>
inline+T*+AlignUp(void*+pointer,+intptr_t+mask)+{
++intptr_t+value+=+reinterpret_cast<intptr_t>(pointer);
++value+%2B=+(-value+)+&+mask;
++return+reinterpret_cast<T*>(value);
}
}+//<+namespace+_

//+Example+calls+using+the+faster+mask+technique.

enum+{+kSize+=+256+};
char+buffer[kSize+%2B+64];

char*+aligned_to_64_byte_cache_line+=+AlignUp<>+(buffer,+63);

char16_t*+aligned_to_64_byte_cache_line2+=+AlignUp<char16_t>+(buffer,+63);|3134426|下面是更快的std::align替换：|3134427|inline+void*+align_kabuki(size_t+align,+size_t+size,+void*&+ptr,
++++++++++++++++++++++++++size_t&+space)+noexcept+{
++//+Begin+Kabuki+Toolkit+Implementation
++intptr_t+int_ptr+=+reinterpret_cast<intptr_t>(ptr),
+++++++++++offset+=+(-int_ptr)+&+(align+-+1);
++if+((space+-=+offset)+<+size)+{
++++space+%2B=+offset;
++++return+nullptr;
++}
++return+reinterpret_cast<void*>(int_ptr+%2B+offset);
++//+End+Kabuki+Toolkit+Implementation
}|3134428|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/kabuki-starship/kabuki-toolkit/wiki/Fastest-Method-to-Align-Pointers^0|0|0|0|0|0|0|7|N|1V|J|0|C|A|13|12|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1D|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1E|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1F|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1G|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|1H|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|1I|8|@$Q|1J|R|1K|S|T]|$Q|1L|R|1M|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1N|8|@$Q|1O|R|1P|S|T]]|9|@$Q|1Q|R|1R|1|1S]]|A|$]]|$1|W|3|X|5|6|7|1T|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|H|7|1U|8|@]|9|@]|A|$I|J]]|$1|10|3|11|5|6|7|1V|8|@]|9|@]|A|$]]|$1|12|3|13|5|H|7|1W|8|@]|9|@]|A|$I|J]]|$1|14|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]]]

You may need to align to a cache line boundary, which is typically 64 bytes per cache line, when you are working with interrupts or high-performance data reads, and they are mandatory to use when working with interprocess sockets. With Interprocess sockets, there are control variables that cannot be spread out across multiple cache lines or DDR RAM words else it will cause the L1, L2, etc or caches or DDR RAM to function as a low-pass filter and filter out your interrupt data! THAT IS BAD!!! That means you get bizarre errors when your algorithm is good and it has the potential to make you go insane!

The DDR RAM is almost always going to read in 128-bit words (DDR RAM Words), which is 16 bytes, so the ring buffer variables shall not be spread out across multiple DDR RAM words. some systems do use 64-bit DDR RAM words and technically you could get a 32-bit DDR RAM word on a 16-bit CPU but one would use SDRAM in the situation.

One may also just be interested in minimizing the number of cache lines in use when reading data in a high-performance algorithm. In my case, I developed the world's fastest integer-to-string algorithm (40% faster than prior fastest algorithm) and I'm working on optimizing the Grisu algorithm, which is the world's fastest floating-point algorithm. In order to print the floating-point number you must print the integer, so in order optimize the Grisu one optimization I have implemented is I have cache-line-aligned the Lookup Tables (LUT) for Grisu into exactly 15 cache lines, which is rather odd that it actually aligned like that. This takes the LUTs from the .bss section (i.e. static memory) and places them onto the stack (or heap but the Stack is more appropriate). I have not benchmarked this but it's good to bring up, and I learned a lot about this, is the fastest way to load values is to load them from the i-cache and not the d-cache. The difference is that the i-cache is read-only and has much larger cache lines because it's read-only (2KB was what a professor quoted me once.). So you're actually going to degrigate your performance from array indexing as opposed to loading a variable like this:

<pre><code>int faster_way = 12345678;
</code></pre>

as opposed to the slower way:

<pre><code>int variables[2] = { 12345678, 123456789};
int slower_way = variables[0];
</code></pre>

The difference is that the <code>int variable = 12345678</code> will get loaded from the i-cache lines by offsetting to the variable in the i-cache from the start of the function, while <code>slower_way = int[0]</code> will get loaded from the smaller d-cache lines using much slower array indexing. This particular subtly as I just discovered is actually slowing down my and many others integer-to-string algorithm. I say this because you may thing you're optimizing by cache-aligning read-only data when you're not.

Typically in C++, you will use the <code>std::align</code> function. I would advise not using this function because <a href="https://github.com/kabuki-starship/kabuki-toolkit/wiki/Fastest-Method-to-Align-Pointers" rel="noreferrer">it is not guaranteed to work optimally</a>. Here is the fastest way to align to a cache line, which to be up front I am the author and this is a shamless plug:

<h1>Kabuki Toolkit Memory Alignment Algorithm</h1>

<pre><code>namespace _ {
/* Aligns the given pointer to a power of two boundaries with a premade mask.
@return An aligned pointer of typename T.
@brief Algorithm is a 2's compliment trick that works by masking off
the desired number of bits in 2's compliment and adding them to the
pointer.
@param pointer The pointer to align.
@param mask The mask for the Least Significant bits to align. */
template &lt;typename T = char&gt;
inline T* AlignUp(void* pointer, intptr_t mask) {
 intptr_t value = reinterpret_cast&lt;intptr_t&gt;(pointer);
 value += (-value ) &amp; mask;
 return reinterpret_cast&lt;T*&gt;(value);
}
} //&lt; namespace _

// Example calls using the faster mask technique.

enum { kSize = 256 };
char buffer[kSize + 64];

char* aligned_to_64_byte_cache_line = AlignUp&lt;&gt; (buffer, 63);

char16_t* aligned_to_64_byte_cache_line2 = AlignUp&lt;char16_t&gt; (buffer, 63);
</code></pre>

and here is the faster std::align replacement:

<pre><code>inline void* align_kabuki(size_t align, size_t size, void*&amp; ptr,
 size_t&amp; space) noexcept {
 // Begin Kabuki Toolkit Implementation
 intptr_t int_ptr = reinterpret_cast&lt;intptr_t&gt;(ptr),
 offset = (-int_ptr) &amp; (align - 1);
 if ((space -= offset) &lt; size) {
 space += offset;
 return nullptr;
 }
 return reinterpret_cast&lt;void*&gt;(int_ptr + offset);
 // End Kabuki Toolkit Implementation
}
</code></pre>

In Dmitry Vyukov's excellent bounded mpmc queue written in C++
See: <a href="http://www.1024cores.net/home/lock-free-algorithms/queues/bounded-mpmc-queue">http://www.1024cores.net/home/lock-free-algorithms/queues/bounded-mpmc-queue</a>

He adds some padding variables. I presume this is to make it align to a cache line for performance. 

I have some questions.

<ol>
<li>Why is it done in this way? </li>
<li>Is it a portable method that will
always work </li>
<li>In what cases would it be best to use <code>__attribute__
((aligned (64)))</code> instead. </li>
<li>why would padding before a buffer pointer help with performance? isn't just the pointer loaded into the cache so it's really only the size of a pointer?

<pre><code>static size_t const cacheline_size = 64;
typedef char cacheline_pad_t [cacheline_size];

cacheline_pad_t pad0_;
cell_t* const buffer_;
size_t const buffer_mask_;
cacheline_pad_t pad1_;
std::atomic&lt;size_t&gt; enqueue_pos_;
cacheline_pad_t pad2_;
std::atomic&lt;size_t&gt; dequeue_pos_;
cacheline_pad_t pad3_;
</code></pre></li>
</ol>

Would this concept work under gcc for c code?

How and when to align to cache line size?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在Dmitry Vyukov用C++编写的优秀的有界mpmc队列中，请参阅：他添加了一些填充变量。我假设这是为了使它与缓存线对齐以提高性能。我有几个问题要问。为什么要这样做？是一种可移植的方法，在中总是有效的，在什么情况下最好改用__attribute__ ((aligned (64)))。为什么在缓冲区指针前填充有助...

如何以及何时对齐高速缓存线大小？-腾讯云开发者社区-腾讯云

问如何以及何时对齐高速缓存线大小？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何以及何时对齐高速缓存线大小？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何以及何时对齐高速缓存线大小？
EN