|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Dima T а "за границей диапазона" это контроль ошибок, его надо оставить. Это должен быть assert() включаемый только в дебаг сборках. Потому что в это отладочный код. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2021, 21:39 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky Dima T а "за границей диапазона" это контроль ошибок, его надо оставить. Это должен быть assert() включаемый только в дебаг сборках. Потому что в это отладочный код. Может и так, но эти 7% мало что меняют. Тут важно оценить сложность алгоритма, ясно что не O(1). Например если потребуется 5 лет, то будет пофиг 5 лет или 5 лет и 4 месяца. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2021, 22:10 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Dima T, под gcc выдает варнинг Код: sql 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2021, 23:48 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky mayton Что нам интересно рассматривать: 1. Большие величиные N. Например от 100. А в чем сложность больших N? Разве что переполнение стека при рекурсивной реализации. Но там вообще глубина стека равна K (размер сочетаний), а не N. А К у нас вряд ли будет достаточно большим чтобы переполнить стек. В данном конкретном алгоритме переполнение стека нам не грозит. Слишком малые у нас запросы. А на больших - мы дождемся финала когда остынет солнце. Что интересовало? Некие общие подходы к комбинаторным алгоритмам. Генераторы последовательностей. Ленивые списки. Хвостовая рекурсия в продолжение моего одноименного топика. (Всегда-ли возможно?) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 00:03 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Пока быстрее работает рекурсивный алгоритм Анатолия. На генерации 6 из 45 занимает меньше 1 секунды против 9 секунд итеративного метода Димы. В коде Анатолия я только счетчик перенес из принта в основную функцию потому-что при отключени вывода на печать - выключается и подсчет найденных сочетаний. Код: plaintext 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 00:56 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Александр. Я про твой код не забыл. Просто пока не хватает терпенья оформить все формальности для того чтоб собрать туловище алгоритма. make.sh Код: sql 1. 2. 3. 4. 5.
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
perm-k-n.lpr - это последний сорс который ты публиковал. Уж извини если я иногда - нетерпеливый. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 01:04 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Тюнинганул алгоритм, заменил проверку на assert(), но стало медленнее (( 1.96 сек вместо 1.67 тут 22268468 исходник Код: plaintext 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.
mayton Пока быстрее работает рекурсивный алгоритм Анатолия. На генерации 6 из 45 занимает меньше 1 секунды против 9 секунд итеративного метода Димы. Затестил алгоритм Анатолия без вывода - 1.63 сек. Странно конечно что рекурсия быстрее, но не в разы. Проверь, может с разными ключами компилировал. PS Оказалось эта проверка отъедает 0.12 сек, можно закаментить, без нее 1.84 сек. Код: plaintext 1.
PPS Турбобуст хитрая штука, затестил вчерашний код, считает 2.1 сек, тестю в виртуалке, а хост сейчас нагружен, задача однопоточная, долгоиграющая, но похоже не дает на других ядрах частоту повысить. Перемеряю вечером, когда хост в спокойном состоянии. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 09:09 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Для ускорения можно попробовать использовать одну общую структуру для всех данных и оптимизировать изменение последнего элемента массива. Но смысла в этом не особенно много, т.к. обычно содержательная обработка сочетания заметно медленнее генерации. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 10:49 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
В идеале у нас получается что вся полезная информация по рекурсии лежит в стеке. Это два целых числа. И сам current вектор - глобальный и модифицируется на каждом рекуррентном вызове. Я думаю что мы достигли хорошей величины перформанса и дальше - узким местом будет просто передача найденных сочетаний в consumer или в то приложение которое будет его юзать. Здесь я хотел-бы это сделать на streams/actors/ или каких-то асинхронных технологиях через кольцевой буфер. Тоесть чтобы генерация сочетаний шла отдельным потоком а уже их извлечение отдельно. Работа с STDOUT - это конечно ужас-ужас но пускай пока она будет как основной вариант межпроцессного протокола. И в данной задаче (которая удачно ложится на списки ФП) я еще для себя хотел реализовать ее на Haskell/Lisp если будет время. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 12:00 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
mayton В идеале у нас получается что вся полезная информация по рекурсии лежит в стеке. Это два целых числа. На самом деле там одно число только нужно. Второе всегда равно уровню вложенности, который легко вычисляется. Я допускаю что и второе можно вычислить, и тогда можно вообще без стека обойтись. Но мне некогда думать )) Вот еще вчера наклепал нерекурсивный алгоритм с явным стеком. Скорость чуть хуже рекурсивного со стеком на основе std::deque и чуть лучше с boost::static_vector (но жесткий лимит на глубину стека). Код: sql 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 12:26 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Anatoly Moskovsky, нет-нет. Не надо разматывать рекурсию в автомат со стеком. Для асинхронного актора о котором я думаю это вообще не нужно. А для внешнего вида исходника - это только ухудшает чтение. Пускай рекурсивный вариант будет основным. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 12:35 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
mayton, Нерекурсивный легче оптимизировать. Сами же писали что скорость одна из задач. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 12:42 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Вот кстати, было пару минут, вообще убрал стек из нерекурсивного алгоритма. На скорость не повлияло :) Код: sql 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 13:16 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Давай затестим на больших числах. Кроме того нерекурсивный - гибче. Если какое-то условие надо вставить то рекурсивный остается красив и компактен а итерационный превращается в нагромождение необъяснимой логики. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 13:41 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Затестил алгоритм Анатолия без вывода - 1.63 сек. Странно конечно что рекурсия быстрее, но не в разы. Проверь, может с разными ключами компилировал. PS Оказалось эта проверка отъедает 0.12 сек, можно закаментить, без нее 1.84 сек. ОК спасибо. Проверю вечером на своём AMD. Щас сижу на ограниченном десктопе где неудобно собирать и бенчмаркать. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 13:43 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
mayton Пока быстрее работает рекурсивный алгоритм Анатолия. На генерации 6 из 45 занимает меньше 1 секунды против 9 секунд итеративного метода Димы. Я потестил 6 из 45 считает 18 мс. Что-то у тебя не то с замером или компилятором. Вот самый быстрый код. С(6,100) за 1.2 сек. Только для каждого k надо будет отдельно код написать Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Можно использовать для получения идеального времени расчета. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 13:45 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Dima T Код: plaintext 1.
Не может этого быть. Маска + сравнение... Скорее всего тормозит printf даже при печати в /dev/null ведь ему надо сделать десятичное форматирование cnt и еще ряд каких-то блокировок и фиксаций в разделяемый объект стандартного вывода. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 13:49 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Dima T Только для каждого k надо будет отдельно код написать Ахахах! ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 13:50 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Dima T mayton Пока быстрее работает рекурсивный алгоритм Анатолия. На генерации 6 из 45 занимает меньше 1 секунды против 9 секунд итеративного метода Димы. Я потестил 6 из 45 считает 18 мс. Что-то у тебя не то с замером или компилятором. Я все собираю на GCC без параметров. Вечером - предоставлю больше сведений. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 13:52 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
mayton Dima T Код: plaintext 1.
Не может этого быть. Маска + сравнение... Скорее всего тормозит printf даже при печати в /dev/null ведь ему надо сделать десятичное форматирование cnt и еще ряд каких-то блокировок и фиксаций в разделяемый объект стандартного вывода. Для C(6, 100) эта строчка выполняется 1.2 миллиарда раз. Т.е. (cnt & 0x3FFFFFF) == 0 выполняется со скоростью примерно 10 миллиардов раз в секунду. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 13:53 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
mayton Dima T Только для каждого k надо будет отдельно код написать Ахахах! Шаблонам же можно кучу однотипных функций компилировать, а мы чем хуже. Можно генератор кода написать Данный код подходит как минимум для определения максимально возможной скорости, быстрее точно ни у кого не будет. mayton Я все собираю на GCC без параметров. Вечером - предоставлю больше сведений. добавь ключи -O3 -DNDEBUG ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 13:58 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Dima T mayton пропущено... Не может этого быть. Маска + сравнение... Скорее всего тормозит printf даже при печати в /dev/null ведь ему надо сделать десятичное форматирование cnt и еще ряд каких-то блокировок и фиксаций в разделяемый объект стандартного вывода. Для C(6, 100) эта строчка выполняется 1.2 миллиарда раз. Т.е. (cnt & 0x3FFFFFF) == 0 выполняется со скоростью примерно 10 миллиардов раз в секунду. Ну смотри... этот код на самом деле не должен срабатывать точно-точно каждые 2 мильярда итераций. Это-ж для статистики? Тоесть я могу сюда поставить любую константу кратную числу вложенных итераций от верхних циклов. Тогда эту проверку можно вообще убрать а printf просто вынести на 4-5 уровней циклов выше. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 14:05 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
Dima T mayton пропущено... Ахахах! Шаблонам же можно кучу однотипных функций компилировать, а мы чем хуже. Можно генератор кода написать Кодогенерация для С++ в рантайме? .... Хм... эту тему надо вообще толкнуть отдельным топиком. Насколько я помню тут ключевой вопрос - безопасность. В рантайме ты должен сгенерить неподписанную никем *.dll -ку и динамически вызвать ее из главной процедуры. Антивирус сойдет с ума. Это то что легко делается в языках типа JScript/Python/Node/Lisp через eval и то что почти неизведанно как Антарктида в С++. Откомментируйте кто в теме. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 14:09 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
mayton Dima T пропущено... Для C(6, 100) эта строчка выполняется 1.2 миллиарда раз. Т.е. (cnt & 0x3FFFFFF) == 0 выполняется со скоростью примерно 10 миллиардов раз в секунду. Ну смотри... этот код на самом деле не должен срабатывать точно-точно каждые 2 мильярда итераций. Это-ж для статистики? Тоесть я могу сюда поставить любую константу кратную числу вложенных итераций от верхних циклов. Тогда эту проверку можно вообще убрать а printf просто вынести на 4-5 уровней циклов выше. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Не, так нельзя. Если ты закаментишь красное, то оптимизатор выкинет все циклы после твоего printf(). Я сначала без этой строчки написал, время работы 50 мс выдало. Пусть будет, 1% времени на него расходуется. Как выше писали: все-равно в реале вместо cnt++ внутри будет какое-то сохранение комбинации, а это на порядки дольше времени займет. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 14:15 |
|
Генерация сочетаний из N по K
|
|||
---|---|---|---|
#18+
mayton Насколько я помню тут ключевой вопрос - безопасность. В рантайме ты должен сгенерить неподписанную никем *.dll -ку и динамически вызвать ее из главной процедуры. Антивирус сойдет с ума. Думаю именно тут будет затык. Может еще админ права поотбирать. Вообще я немного в другую сторону думал. Если известны часто используемые значения N, то для них прописать, а остальным универсальную запускать. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Взять ту же задачу милторга, я так понимаю у него вектора были фиксированного размера, т.е. известного на момент компиляции. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2021, 14:33 |
|
|
start [/forum/topic.php?fid=16&msg=40038648&tid=1339689]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
others: | 249ms |
total: | 418ms |
0 / 0 |