拆分堆叠unneccesary在AMD64 [英] Split stacks unneccesary on amd64
问题描述
似乎有一个意见，在那里，用的是拆分堆叠运行模式是不必要的64位架构。我说，好像是的，因为我还没有看到有人居然说，只有跳舞吧：
There seems to be an opinion out there that using a "split stack" runtime model is unnecessary on 64-bit architectures. I say seems to be, because I haven't seen anyone actually say that, only dance around it:
一个典型的多线程程序的内存使用量可以减少 显著，因为每个线程不需要最坏情况堆 尺寸。变得可以运行百万线程（全NPTL 在一个32位地址空间的线程或协同例程）。 - 伊恩·兰斯·泰勒
The memory usage of a typical multi-threaded program can decrease significantly, as each thread does not require a worst-case stack size. It becomes possible to run millions of threads (either full NPTL threads or co-routines) in a 32-bit address space. -- Ian Lance Taylor
......这意味着一个64位的地址空间已经可以应付自如。
...implying that a 64-bit address space can already handle it.
和
...分割堆的恒定的开销和窄用例 （产卵在32位架构的I / O密集型任务巨大的数字） 是不能接受的...... - bstrie
... the constant overhead of split stacks and the narrow use case (spawning enormous numbers of I/O-bound tasks on 32-bit architectures) isn't acceptable... -- bstrie
两个问题：难道这就是他们在说什么？其次，如果是的话，为什么他们unneccesary在64位体系结构？
Two questions: Is this what they are saying? Second, if so, why are they unneccesary on 64-bit architectures?
推荐答案
是的，这是他们在说什么。
Yes, that's what they are saying.
拆分堆栈是（目前）没有必要在64位架构，因为64位的虚拟地址空间是如此之大，它可以包含数以百万计的堆栈地址范围，每个大到一个完整的32位地址空间，如果需要的话。
Split stacks are (currently) unnecessary on 64bit architectures because the 64bit virtual address space is so large it can contain millions of stack address ranges, each as large as an entire 32bit address space, if needed.
在使用中的平面内存模式时下，翻译从虚拟地址到物理性存储器位置与支撑做的硬件MMU 。在 AMD64 事实证明，这是更好（意思是，整体速度更快）保留的64位虚拟地址的大块空间要创建，而仅在第一页（4KB）映射到实际的RAM每一个新的堆栈。通过这种方式，堆栈将能够成长并根据需要缩小，在连续的虚拟地址（这意味着减少code在每个函数序言，一个大的优化），而操作系统的重新配置MMU将虚拟地址的每一页映射到内存的实际可用页面，只要堆栈增大或缩小高于/低于一些配置的阈值。
In the Flat memory model in use nowadays, the translation from virtual addresses to phisical memory locations is done with the support of the hardware MMU. On amd64 it turns out it's better (meaning, overall faster) to reserve big chunks of the 64bit virtual address space to each new stack you are creating, while only mapping the first page (4kB) to actual RAM. This way, the stack will be able to grow and shrink as needed, over contiguous virtual addresses (meaning less code in each function prologue, a big optimization) while the OS re-configures the MMU to map each page of virtual addresses to an actual free page of RAM, whenever the stack grows or shrinks above/below some configurable thresholds.
通过巧妙地选择阈值（例如，见
By choosing the thresholds smartly (see for example the theory of dynamic arrays) you can achieve O(1) complexity on the average stack operation, while retaining the benefits of millions of stacks that can grow as much as you need and only consume the memory they use.
PS：现在的围棋实施远远落后于任何这一点： - ）
PS: the current Go implementation is far behind any of this :-)
这篇关于拆分堆叠unneccesary在AMD64的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
