C代码是否喜欢Go GC的防碎片策略？[关闭]

作者: 春风助手
发布时间: 2024-04-18 06:29:06 (1天前)

2 条回复

1#
回复此人
只怕再见是故人 | 2020-08-04 15-30

恐怕您在这里可能会在多个层面上造成混乱。首先，从一开始就在生产级的Go代码中调用C 通常是不可行的：它很慢；像进行系统调用一样慢 —在大多数情况下，它实际上可以作为系统调用工作：一个需要从Go堆栈切换到C堆栈，并且要使 OS线程恰巧正在执行Go代码，从而使cgo调用成为即使C端发生阻塞，也会锁定到该线程。这并不是说您必须避免呼唤C，但这意味着您需要先考虑一下并加以衡量。可能是建立了一组工作流程，以便将需要进行C调用的任务散布到其中。其次，您的记忆问题可能毫无根据。让我解释。在通常用于运行Go程序的现代系统（我的意思是类似的东西）上，虚拟内存的碎片化应该不是问题amd64。这是相当多的，因为分配的虚拟内存不强制操作系统实际分配物理内存页-只有当虚拟内存被后者恰好使用（即，在一个地址发生在点到分配的虚拟内存区访问）。因此，无论您是否想要，您都确实遇到了物理内存碎片问题，并且正在使用多层地址转换表（和TLB缓存）在OS和CPU级别对它进行整理。第三，您似乎陷入了一个普遍的陷阱，即猜测事物在负载下的性能如何，而不是编写高度简化的模型程序并检查其在估计的生产负载下的行为。也就是说，您认为分配C内存会出现问题，然后幻想整个事情将无法正常工作。考虑到用C和C ++编写的大量生产代码并在核心负载下工作，我会说您的担心是没有根据的。最后，C和C ++程序员很久以前就尝试了通往高性能内存管理的途径。一种典型的解决方案是对在典型负载下表现出最大分配/取消分配变动的对象使用自定义池分配器。通过这种方法，在C端分配的内存在程序的生命周期中通常是稳定的。 TL; DR 编写一个模型程序，在其上施加估计的负载，然后查看其行为。然后分析内存的问题（如果有），然后开始攻击它们。

编辑

登录后才能参与评论