使用快速磁盘存储（SSD）进行优化的算法？

作者: 甲基蓝
发布时间: 2024-12-21 03:48:00 (1月前)
转自：

6 条回复

0#
回复此人
=_= | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 随机读取的SSD速度要快得多，顺序读取的速度要快得多，写入速度要慢得多（随机或不随机）。 </p> <P> 所以基于磁盘的哈希表是正确的 <EM> 不 </EM> 对SSD有用，因为它现在需要很长时间来更新它，但搜索磁盘变得（与普通硬盘相比）非常便宜。 </p> </DIV>

编辑
1#
回复此人
浮华丶 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 事实上，你能想到的任何算法都需要大量的随机磁盘I / O（随机是关键词，这有助于向鸟类抛出局部性原理，从而消除了许多缓存的有用性）。 </p> <P> 我可以看到某些数据库系统从中获益。 MySQL，例如使用MyISAM存储引擎（其中数据记录基本上是美化的CSV）。但是，我认为非常大的哈希表对于好的例子来说是最好的选择。 </p> </DIV>

编辑
2#
回复此人
啦啦啦拉肚子 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> SSD随机访问的速度要快得多。顺序访问磁盘它们只是主流旋转驱动器的两倍。如上所述，许多SSD在许多情况下的性能较差，导致它们表现更差 <a href="http://blogs.msdn.com/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx" rel="nofollow noreferrer"> 这里 </A> 。 </p> <P> 虽然SSD确实大大改变了针头，但它们仍然比CPU操作和物理内存慢得多。对于4GB哈希表示例，您可以通过SSD维持250+ MB / s的速度来访问随机哈希表桶。对于旋转驱动器，您很幸运能够打破单位数MB / s。如果你可以将这个4 GB的哈希表保存在内存中，你可以每秒读取一亿GB的速度 - 比一个非常迅速的SSD快得多。 </p> <P> 参考文章列出了MS在Windows上运行时对Windows 7所做的一些更改，这些更改可以让您了解可以考虑进行的更改类型。首先，禁用用于从磁盘预取数据的SuperFetch - 它旨在解决磁盘缓慢的随机访问时间，这些时间可以通过SSD减轻。碎片整理被禁用，因为分散在磁盘上的文件不会影响SSD的性能。 </p> </DIV>

编辑
3#
回复此人
阿政ღ | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 不要自欺欺人。 SSD仍然比系统内存慢得多。任何选择在硬盘上使用系统内存的算法仍然会快得多，其他条件相同。 </p> </DIV>

编辑
4#
回复此人
℘ 宋唐 ℒº ѵ ℯ楚厦 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 您的哈希表示例确实是受益的关键数据库结构。可以直接探测SSD，而不必将整个4GB或更多文件加载到内存中以探测值。固态硬盘仍然比RAM要慢一个数量级，但是在磁盘上有一个50GB的哈希表是合理的，但除非你为大铁支付大笔钱，否则不在RAM中。 </p> <P> 一个例子是象棋位置数据库。我有超过50GB的散列位置。有一些复杂的代码试图在散列中将相关位置分组到彼此附近，因此我可以一次在10MB的表中进行分页，并希望将其中的一些用于多个类似的位置查询。为了提高效率，需要大量的代码和复杂性。 </p> <P> 替换为SSD，我能够放弃集群的所有复杂性，只使用非常愚蠢的随机哈希。我也提高了性能，因为我只从磁盘中获取所需的数据，而不是大的10MB块。延迟确实更大，但净加速是显着的...而超级干净的代码（20行，而不是800+）可能更好。 </p> </DIV>

编辑

登录后才能参与评论