|
|
|
Тяпничная huge-сортировка
|
|||
|---|---|---|---|
|
#18+
maytonд0kХЭто я к тому что на скорость дискового ввода вывода и баланса нагрузок может влиять даже место размещения файлов на поверхрости шпинделя center - самое быстрое позиционирование inner edge и outer edge более медленное позиционирование. в center укладываются файлы с рандомным характером доступа , в edge с последовательным. Я учту это замечание на будущее. Но давай пока стартанём просто с разделов в /ext3, ext4 без привязки в расстоянию до шпинделя. Допилим чуть позже когда будет более-менее работающий код. В алгориме триплетов, каждый триплет будет создать неодинаковую нагрузку. Потоки читатели будут делить по 50% трафика а поток-писатель будет делать почти "горизонтальную полку" и оптимизировать это сейчас сложно т.к. на следующем step фазы №2 их роли меняются и тот файл который был создан писателем станет снова читаемым. И ситуация перевернётся. Как быстро двигать файлы по поверхности шпинделя так чтобы это не влияло на основной алгоитм - я пока не знаю. Движение файла по поверхности имеет смысл если это файл известной структуры с которого читается и в нем же делаются изменения. темповые файлы двигать по поверхности смысла не имеет. правила размещения простые , мелкие темповые файлы ложатся в центр , большие и результат ближе к edge. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2017, 16:34 |
|
||
|
Тяпничная huge-сортировка
|
|||
|---|---|---|---|
|
#18+
Затестил дерево триплетов на массивах 20303177 . Копирование в разы меньше других, т.е. переливание всего массива 1-2 раза. Сравнений сопоставимо с другими алгоритмами. Т.е. для биг файла самое то что надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2017, 17:49 |
|
||
|
Тяпничная huge-сортировка
|
|||
|---|---|---|---|
|
#18+
Dima TЗатестил дерево триплетов на массивах 20303177 . Копирование в разы меньше других, т.е. переливание всего массива 1-2 раза. Сравнений сопоставимо с другими алгоритмами. Т.е. для биг файла самое то что надо. На мой взгляд, дерево не самый лучший выбор. Фактически чтение происходит по одной записи из случайного файла (или части файла). Алгоритм более-менее работает только за счет блокирования и опережающего чтения ОС. Пирамида подошла бы лучше. На этапе загрузки данных в пирамиду читаем большими блоками записей. Сначала по одному блоку из каждого файла (или части файла), потом читаем очередной блок оттуда, где текущий ключ меньше. Выгружаем пирамиду до минимального текущего ключа или полностью, если файлы исчерпаны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2017, 22:19 |
|
||
|
Тяпничная huge-сортировка
|
|||
|---|---|---|---|
|
#18+
Не впадая с указателями в погоню за гигфлоппами решение на языке высокого уровня. ИМХО для сравнения приемлемое. Студентам не показывать. Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2017, 17:23 |
|
||
|
Тяпничная huge-сортировка
|
|||
|---|---|---|---|
|
#18+
mikron, спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2017, 22:28 |
|
||
|
Тяпничная huge-сортировка
|
|||
|---|---|---|---|
|
#18+
Алгоритм кстати не оптимальный. Используется две кучи/пирамиды: первая для слияния данных из многих источников и образования единого потока данных, вторая для сортировки потока данных в памяти. Заметил важную деталь: Использование второй кучи/пирамиды только вредит, т.к. увеличивает затраты на сравнения но улутшает длину сортированной последовательности только на +размер кучи за проход. Основная же "ошибка" если так можно сказать в том что слияние потоков всегда берёт наименьшее текущее значение из всех потоков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2017, 09:18 |
|
||
|
Тяпничная huge-сортировка
|
|||
|---|---|---|---|
|
#18+
Тестовый файл сортировался 50 минут с 62 временными файлами и буфером на 2^18 строк. Т.к. Строки короткие это соответсвует 16 Мб памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2017, 09:23 |
|
||
|
Тяпничная huge-сортировка
|
|||
|---|---|---|---|
|
#18+
Последние штрихи и можно сравнивать, с C++ // splitter = Split(MAX_HEAP_SIZE, Merge(sourceReq.ToArray()), target); splitter = Split(Merge(sourceReq.ToArray()), target); Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2017, 10:41 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=39421087&tid=1340453]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
579ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 214ms |
| total: | 865ms |

| 0 / 0 |
