Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Тут 17438916 по быстрому накидал простой генератор простых чисел. Генерит первые 100 млн. за секунду, дальше начинается тормоз. Там же узнал про решето Эратосфена и Аткина. Решил потестить. Чего бы где не писали, но у меня получилось что Эратосфен быстрее Аткина в 3 раза на первых 800 млн. (дальше Аткин не может, похоже разрядности unsigned int не хватает). Победитель, использует 62 Мб для рачета до 10^9 (запостите в википедию кто может, вектор prime выкинуть, printf() разремить): Код: 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. Решето Аткина Код: 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. 55. 56. 57. 58. Обоих с википедии взял. Допилил сколько смог. Добавил биткарту. Правда в Эратосфене она в два раза меньше, т.к. четные пропустил. В Аткине так не получилось, т.к. второй цикл (по 5-кам попадает на четные). Но и с биткартой без четных он все равно медленнее (в 2,5 раза), поэтому не стал дальше разбираться. Если кто будет ускорять Аткина - постите сюда что получилось. Мое ИМХУ в Аткине слишком много получения остатка от деления, а память нынче достаточно быстрая, поэтому Эратосфен быстрее, т.к. там только битовые операции. И потом Эратосфена проше досчитывать. Асинхронный Эратосфен. Получение следующего простого после X Код: 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. 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. Действительно ли числа простые : сравнивал результаты разных алгоритмов между собой, до 100 млн. с 17438916 , до 800 млн. с Аткиным, до 2 млрд. синхронного и асинхронного Эратосфенов, дальше они считают, но памяти в x32 не хватает чтобы результаты обоих хранить, а так асинхронный до 3 млрд. за 15 сек считает. ИМХУ можно под x64 переточить, но это уже лишнее, надо больше - есть мат.либы. Модератор: По просьбе автора ссылки изменены next_prime32.h next_prime64.h Тесты и примеры использования ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2015, 20:30 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Сразу скажу что я еще нечитал эти сорцы. Но поверхностно... не вижу в них новой идеи. Поэтомо воспроизведу свои старые мысли по сабж. Поиск и исследование простых чисел это увлекательнейшая часть математики. Если ее копнуть глубоко то ты зацепишь краем практически ВСЕ разделы математических наук. По поводу "решета". Я считаю его неэффективным на больших числах. Потому-что плотность простых чисел падает от величины. Чем больше ваше искомое prime-число тем больше "холостых вычёркиваний" в биткарте вам нужно сделать. В конце-концов поиск упирается в эффективность использования памяти. Для современной рабочей станции (адресующей 16Гб) можно адресовать примерно. 16Гб = 17,179,869,184 байт = 137,438,953,472 бит = bitcartCap Тоесть 137 млрд Количество простых чисел на этом интервале (ЕМНИП) равно n/ln(n). Посчитаем приблизительно. 137,438,953,472 / ln (137,438,953,472) ~ 5 358 986 394 Тоесть 5 млрд простых чисел в биткарте. А какова эффективность? Примерно на 26 бит приходится 1 простое число. И с ростом числа эта самая эффективность хранения будет падать. Надеюсь я не ошибся. Если что - прошу поправить. Как считать дальше? - Неизвестно. Возможно по биткарте можно построить итератор и извлекать из него биты но эффективность этого метода у меня под вопросом. Так что после генерации биткарту следовало-бы уничтожить и данные сохранить в обычный вектор. И положить в текстовый файл. Можно мечтать и расчитывать что старик Мур еще подкинет нам сюрпризы типа удвоения объёма памяти за ту-же цену. Но.... я-бы не особо на это надеялся. Primes - коварны. И как-только мы выйдем из одной трудности - тут-же вступим в другую. Хотя-бы рассмотреть неэффективность "арифметического деления по модулю" для целых чисел длинной 64, 128, 256 бит. Интересно также рассмотреть различные варианты сжатия биткарт. Использования деревьев для хранения таких "разрежённых" объемов. И прочих нестандартных структур. P.S. Жаль Базист сбежал. Он вобщем-то был неплохой оппонент и собеседник по структурам данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2015, 21:26 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
maytonне вижу в них новой идеи. Ее не было. Я же написал тестил старые. Все пишут что что Аткин быстрее Эратосфена. У меня обратное получилось. maytonДля современной рабочей станции (адресующей 16Гб) можно адресовать примерно. 16Гб = 17,179,869,184 байт = 137,438,953,472 бит = bitcartCap Тоесть 137 млрд еще на 2 умножь, четные выкинул, 1 байт = 16 чисел. maytonТак что после генерации биткарту следовало-бы уничтожить и данные сохранить в обычный вектор. И положить в текстовый файл. Мой асинхронный вариант так и делает. Кэширует результаты и досчитывает небольшой биткаротой сверх предыдущего расчета. Цели считать далеко не ставил. Эратосфеном можно посчитать простое X зная все простые до sqrt(X), т.е. с 16 Гб памяти можно рассчитать простое порядка 5*10^22. В принципе алгоритм параллелится. Изначально цель была простая: не вставлять в код статические таблицы, заменить быстрым генератором. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2015, 21:50 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Dima TЕе не было. Я же написал тестил старые. Все пишут что что Аткин быстрее Эратосфена. У меня обратное получилось. Да это странно. Интересно профилировать метод Аткина чтобы понять что можно улучшить. еще на 2 умножь, четные выкинул, 1 байт = 16 чисел. Это плюс. А если-б ты еще и "тройки" виртуально выкинул? А? Мой асинхронный вариант так и делает. Кэширует результаты и досчитывает небольшой биткаротой сверх предыдущего расчета. Цели считать далеко не ставил. Эратосфеном можно посчитать простое X зная все простые до sqrt(X), т.е. с 16 Гб памяти можно рассчитать простое порядка 5*10^22. В принципе алгоритм параллелится. Изначально цель была простая: не вставлять в код статические таблицы, заменить быстрым генератором. Кстати MOD(x,12) по Уоррену заменяется на одно умножение на магическое число и на один shift магическое число раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2015, 22:22 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Дмитрий, если не ошибаюсь очень слабо растёт. Потому сложности алгоритмов должны быть сравнимы с константой, и разница должна быть заметна на очень больших объёмах, хоты бы 10^50 элементов. Может быть я путаю конечно, но по-моему так. Мы сейчас уехжаем, потому сегодня не смогу сам написать код и проверить (( Завтра займусь :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 02:10 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
maytonПримерно на 26 бит приходится 1 простое число. Хорошая мысль, в векторе хранить невыгодно. Посчитал статистику. В диапазоне х32 в моей биткарте получается в среднем 11 бит на число. В векторе 32, т.е. биткарта в 3 раза меньше памяти расходует. Биткарта 256 Мб на все числа до 2^32. Чисел ~190 млн., т.е. массив будет 760 Мб. Я поэтому от int64 отказался. Статистика расчета 4 млрд. по 100 млн.Расчет доКол-во простыхСреднее распределениеВремя расчета мс1000000005761456182602000000005317482192803000000005173388202414000000005084001203505000000005019541203316000000004968836211907000000004928228214418000000004893248213109000000004863036213101000000000483831921381110000000048149362130120000000047922352153113000000004773628215511400000000475714022301500000000474105522661160000000047253052278117000000004711186223018000000004699403221001190000000046855062230200000000046743592220210000000046642392210722200000000465359622202300000000464481822124224000000004633507223025000000004624924222026000000004618796221642270000000046080252230280000000046000662220290000000045937532216633000000000458552622303100000000457910422203200000000457216422303300000000456502422191234000000004559367223035000000004554137222036000000004547803223137000000004542381232183380000000045366772330390000000045304312330400000000045251872320 Время неравномерно, т.к. дорасчет идет порциями +12,5% (max_prime/8*9, в изначальном варианте было +20%, поправил чтоб за разрядность х32 не вылезти) maytonКоличество простых чисел на этом интервале (ЕМНИП) равно n/ln(n) Если так, то в биткарте всегда плотность хранения будет выше чем в массиве, т.к. ln(2^N) < N maytonДа это странно. Интересно профилировать метод Аткина чтобы понять что можно улучшить. ... Кстати MOD(x,12) по Уоррену заменяется на одно умножение на магическое число и на один shift магическое число раз. Надо поискать чудоформулу, это должно заметно ускорить Аткина. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 07:49 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
SashaMercuryДмитрий, если не ошибаюсь очень слабо растёт. Потому сложности алгоритмов должны быть сравнимы с константой, и разница должна быть заметна на очень больших объёмах, хоты бы 10^50 элементов. Может быть я путаю конечно, но по-моему так. Судя по моим замерам похоже что так: 1 млрд ~5 сек, 3 млрд ~15 сек. Тут проблема в другом, для больших чисел памяти надо много под биткарты. Хотя тоже решаемо: для поиска следующего простого после любого X можно сгенерить кусок биткарты в 5 Мб (70 млн. чисел если тут не ошибаются ) и последовательно инициализировать ее всеми простыми до sqrt(X + 70 млн). В общем чем больше диапазон покрывает биткарта, тем больше чисел находится за раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 08:13 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Dima TmaytonКоличество простых чисел на этом интервале (ЕМНИП) равно n/ln(n) Если так, то в биткарте всегда плотность хранения будет выше чем в массиве, т.к. ln(2^N) < N maytonДа это странно. Интересно профилировать метод Аткина чтобы понять что можно улучшить. ... Кстати MOD(x,12) по Уоррену заменяется на одно умножение на магическое число и на один shift магическое число раз. Надо поискать чудоформулу, это должно заметно ускорить Аткина. Я не очень понял твою формулу ln(2^n) < N. Откуда она? По поводу Уоррена я немного ошибся. Старик писал про оптимизацию целочисленного деления. Вот из моих сорцов. К сожалению делители только до 10. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Но для расчёта остатков нетрудно дописать еще разность и умножение. Код: plaintext 1. По поводу Аткина. Я обращаю внимание наwikiНиже представлена реализация упрощённой версии на языке программирования C++, иллюстрирующая основную идею алгоритма — использование квадратичных форм: Что означает упрощённая ? Грубая? Без оптимизаций? Краткая? Ну и ... стоить покурить ассемблер. Недавно с Сашиком обсуждали тему получение и частного и остатка одним махом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 08:26 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
maytonЯ не очень понял твою формулу ln(2^n) < N. Откуда она? Из твоей вывел: maytonКоличество простых чисел на этом интервале (ЕМНИП) равно n/ln(n) Для обычного хранения числа размера 2^N надо N бит хранение массивом N * 2^N / ln(2^N) бит биткартой 2^N бит делим, получаем 1 биткарта = N / ln(2^N) = 1/ln(2) = 1,4427 массива т.е. плотность хранения в биткарте всегда будет выше в 1,4427. Т.к. я четные выкинул, то моя биткарта всегда будет занимать меньше места в 2,885 раза по сравнению с массивом. maytonПо поводу Уоррена я немного ошибся. Старик писал про оптимизацию целочисленного деления. Вот из моих сорцов. К сожалению делители только до 10. Направление понял. Можно попробовать подбором поискать. Может есть. Остаток от деления на 5 тоже пригодится. Тут только минус - запас разрядности надо. Если не путаю, на x32 сдвиги 32 битами ограничены. Надо на x64 тестить. maytonПо поводу Аткина. Я обращаю внимание наwikiНиже представлена реализация упрощённой версии на языке программирования C++, иллюстрирующая основную идею алгоритма — использование квадратичных форм: Что означает упрощённая ? Грубая? Без оптимизаций? Краткая? Просто корявая какая-то, расчет квадратов оптимизирован, а при считывании результатов вместо того чтобы сделать циклу шаг 2 добавили проверку кратности 3 и 5. С забавным примечанием. Я немного причесал, но не уверен что алгоритм полностью соблюден. Надо еще поискать реализации и в алгоритм посильнее вникнуть, я не понял зачем там инверсии битов. maytonНу и ... стоить покурить ассемблер. Недавно с Сашиком обсуждали тему получение и частного и остатка одним махом. Я там c вами курил, есть команда div в асме, в си div(), только компилятор MS ее в функцию обернул и в тормоз превратил. Надо глянуть во что % компилируется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 09:14 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Dima TНадо глянуть во что % компилируется. Глянул, ничего лишнего: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Значит тормоза внутри проца ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 09:55 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Dima TДля обычного хранения числа размера 2^N надо N бит хранение массивом N * 2^N / ln(2^N) бит биткартой 2^N бит делим, получаем 1 биткарта = N / ln(2^N) = 1/ln(2) = 1,4427 массива т.е. плотность хранения в биткарте всегда будет выше в 1,4427. Т.к. я четные выкинул, то моя биткарта всегда будет занимать меньше места в 2,885 раза по сравнению с массивом. Я понял почему я тебя не понял. Я разрядность int не считал. Мои увлечения primes охладели с резкой нехваткой оперативки. И я вобщем-то не планировал использовать массивы. Меня интересовали дисковые способы хранения расчитанных primes. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 10:06 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Dima TЗначит тормоза внутри проца Это краеугольный камень криптографии. Именно принципиальная невозможность оптимизировать DIV/MOD (в частности факторизацию) обеспечивает безопасность нам всем сегодня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 10:08 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
mayton, криптография оперирует простыми числами несравнимо больше 10^9, эти алгоритмы к ней отношения не имеют, так что оптимизация div для неё бесполезна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 10:20 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
maytonИ я вобщем-то не планировал использовать массивы. Меня интересовали дисковые способы хранения расчитанных primes. Выше писал как бесконечно можно генерить с минимум 5 мб оперативки: генеришь до 5 млн, пишешь в файл, делаешь решето под 5-10, считываешь посчитанные последовательно с файла до sqrt(10 млн), каждым числом проходишь по решету, получаешь все простые в интервале 5-10, результат в конец файла, и т.д. пока место на диске не кончится Написал, подумал, затестил: кусками по 5 мб в два раза быстрее считает чем в один проход. До 10^9 было 4,5 сек Код: plaintext 1. Стало 2,65 после замены на Код: plaintext 1. Заменил на +1 Мб стало 2.53 сек. Наверно потому что в L3 кэш проца целиком ложится. А когда одним большим куском считешь гоняется проц-память при каждом проходе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 10:46 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Можно назвать этот метод "Хождение по решёткам". (Решетам?) P.S. Как будете решето в множ. числе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 13:29 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Асинхронный Эратосфен Версия 2.0 Код: 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. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. Учел все вышенайденное. Скорость возросла в 2 раза по сравнению с синхронным. До 4 млрд. за 8.7 сек. Что поменялось: 1. За раз считается 1 млн. значений (64 Кб биткарты). 2. Экономнее расходуется память. Массив найденных не хранится. Только биткарта, она компактнее почти в 3 раза. Особенность: почти половина времени уходит на чтение результатов: Код: plaintext 1. после Код: plaintext 1. 2. Т.е. если надо много раз пройтись по расчитанному - лучше закэшировать в массив. В предыдущем варинте сразу писалось в массив, поэтому нельзя было съэкономить на ненужных сохранениях. Если сразу второе запустить то будет 8,7 сек., т.е. на 0,3 сек медленнее. Плата за экономию памяти. В первом случае выделяется сразу столько, сколько нужно. Проверка что до 4 млрд посчитано правильно прошла успешно Код: plaintext 1. 2. 3. 4. 5. 6. То же самое x64Не совсем x64, должно работать до 64 млрд., дальше realloc() не выделит более 4 Гб под биткарту. Сравнивал до 4 млрд. с версией х32 дальше чего нагенерит не проверял. При компиляции под x64 работает так же быстро, под x32 в 1,5 раза медленнее. Код: 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. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. По поводу Аткина: 1. Эмулятор %12 не взлетит на x32 даже если его найти. Т.к. битовые сдвиги 64-битных переменных в x32 реализованы программно. 2. Аткин медленнее в 5,6 раза этого варианта. Вывод: заход далеко за область расчета не дает посчитать более чем до 800 млн. на x32. Возможно на x64 взлетит если переделать на расчет кусками, но я эти подвиги не буду совершать, оставим поле для творчества следующим поколениям :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 20:39 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Круть. Поверхностный code-review даже ни к чему ни цепляется. Думаю что улучшать можно только в направлении теории алгоритмов или спуска на уровни Ассемблеров. Еще есть одно решето. Еще один алгоритм одного индуса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 21:34 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Ребята, что со скоростью ? Можно показать таблицу для 10^7,10^8, 10^9 для двух методов, со значениями скорости и памяти, пожалуйста ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 01:58 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Где бы запустить эти алгоритмы для 10^20 элементов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 02:39 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Кстати, почему отсев Аткина завязан на числе 60 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 07:07 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Дмитрий, так у тебя упрощенный вариант, я сначала не понял. Деление происходит на 12. В оригинальной работе , используется число 60. И как я понял, это число должно динамически менять в зависимость от мощности исследуемого множества ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 08:28 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Здесь .... эээ думаю помогут мои исторические знания. 60 - это основание древней вавилонской системы счисления. 60 уникально тем что имеет следующие делители 1,2,3,4,5,6. С шагом 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 08:34 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
SashaMercuryРебята, что со скоростью ? Можно показать таблицу для 10^7,10^8, 10^9 для двух методов, со значениями скорости и памяти, пожалуйста Я-бы предложил для начала прогнать модульный тест на корректность. Иначе мы в погоне за скоростью забудем самое главное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 09:02 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
Затестил x32 версию - ищет все до 2^32. Ошибок нет, только зацикливается после последнего. чтобы возвращала 0 по окончании, после строчки Код: plaintext 1. добавить Код: plaintext 1. 2. 3. 4. SashaMercuryРебята, что со скоростью ? Можно показать таблицу для 10^7,10^8, 10^9 для двух методов, со значениями скорости и памяти, пожалуйста Памяти надо 1 байт на каждые 16 чисел. Т.е. для расчета 10^9 надо ~62 Мб. Реально довыделяется +20% к имеющемуся, чтобы не сильно тормозило из-за realloc() Скорость померь сам. Пример замера скорости Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. У меня такой результат10^7=10000019 time 20 msec 10^8=100000007 time 110 msec 10^9=1000000007 time 1101 msec all to 10^9=1000000007 time 2143 msec Для чистоты эксперимента последнего замера, чтобы исключить перевыделение памяти, задай в next_prime() сразу выделение максимума Код: plaintext 1. вместо if(bm_size_new > 0xB000000) ... SashaMercuryГде бы запустить эти алгоритмы для 10^20 элементов Если считать все до 10^20, то надо под хранение результата ~10^19 байт или 10^7 терабайт, думаю мало у кого столько есть. Задача отпадает. Можно попробовать посчитать какой-нибудь диапазон, например 10^20...10^20 + 70 млн., для этого надо посчитать все до 10^10 (625 Мб памяти под хранение). Инициализировать ими решето только для этого диапазона и снять результат. Только тут засада, 64 битная переменная до 1,8*10^19. Можешь порешать задачу: поиск максимально большого простого x64. Думаю за минуту должно посчитаться. Дальше все резко усложняется из-за ограничения разрядности целых переменных. maytonЕще есть одно решето. Еще один алгоритм одного индуса. Решето Сундарама Оно (как и Аткин) заточено на поиск всех от 1 до N. mayton, просьба, добавь в первый пост ссылку на окончательный вариант В конец: UPD Асинхронный Эратосфен. Версия 2.0 17451792 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 09:23 |
|
||
|
Генератор простых чисел (до 10^9 за 5 сек)
|
|||
|---|---|---|---|
|
#18+
maytonЯ-бы предложил для начала прогнать модульный тест на корректность. Иначе мы в погоне за скоростью забудем самое главное. Это было с самого начала. Делал проверки: Dima T Действительно ли числа простые : сравнивал результаты разных алгоритмов между собой, до 100 млн. с 17438916 , до 800 млн. с Аткиным, до 2 млрд. синхронного и асинхронного Эратосфенов. Проверка от 4 млрд. до 2^32 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Так все можно, только ждать устанешь, эти 250 млн. проверялись с полчаса По хорошему еще бы на пропуски проверить после 800 млн. До 800 совпало с Аткиным, а после алгоритмы одинаковые. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 09:36 |
|
||
|
|

start [/forum/topic.php?fid=57&fpage=22&tid=2017971]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
40ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
| others: | 16ms |
| total: | 167ms |

| 0 / 0 |
