- 主题:size_t和int比较时哪种写法效率更高？
会有人往 vector/linked_list 里面写超过 2^32 数量的元素？
【 在 z16166 (Netguy) 的大作中提到: 】
: 除了是unsigned，size_t移植性更好，不是固定bit数目的，最大值取决于机型/编译模式。
: 把STL size()返回的size_t转为int什么的，不是好习惯，因为size_t在x64模式下编译可能是64-bit的。
: 正常应该把n定义为size_t类型，避免转换。有极端性能要求的场合另行考虑。
: ...................
--
FROM 112.47.122.*
道理我懂啊。我只是想问，有谁见过一次性处理 4gb 内存和 4g 元素列表的代码没？是什么场景。
【 在 z16166 (Netguy) 的大作中提到: 】
: strlen、memcpy之类的，都是size_t
--
FROM 112.47.122.*
没有分块吗？一次性处理 4gb 连续内存的数据？
【 在 ancksunamun (安卡苏娜) 的大作中提到: 】
: 我就经常遇到，影像系统的模拟。我干活的workstation都是256G内存。
--
FROM 112.47.122.*
spark 程序也不是一个任务处理 4gb，得拆分开才有效率。内存大很正常，但一次处理一块大内存的场景可能比较少。
【 在 Bernstein (Berns) 的大作中提到: 】
: 数据处理里面，一次处理16GB以上的数据也有可能，我原来公司的服务器基本上都是128GB内存的；比较变态的spark服务器，有些公司会弄到300GB以上的内存
: 包含4G个元素的列表倒是很少见，主要是效率太低，包含4G个元素的vector是很有可能的
--
FROM 59.60.57.*