Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Alexey Maslov Код: plaintext 1. 2. 3. 4. 5. С другой стороны, возможно, выборка простых чисел <1 000 000 слишком мала... Код: plaintext 1. 2. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Вечером с http://iron.intersys.com/wrc/Distribution.csp скачаю cache-2008.2.0.526-win.exe и тогда завтра попробую на ней погонять примеры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2008, 09:38 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
MaWr, можно вопрос: что нужно сделать, чтоб получить сюда http://iron.intersys.com/wrc/Distribution.csp доступ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2008, 10:38 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
ceshkaMaWr, можно вопрос: что нужно сделать, чтоб получить сюда http://iron.intersys.com/wrc/Distribution.csp доступ? Это лучше узнать у представителей InterSystems :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2008, 10:50 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
А вот решето Аткина на конфигурации тоже хорошо распараллеливается: Код: 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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. А если убрать Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2008, 11:48 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
упс... Читать так: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2008, 11:51 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Намудрил я с Аткином - параллельный режим работал неверно. Вот правильный вариант: Код: 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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2008, 18:20 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Ув. коллеги! Вот и мне есть что сказать...:) Ведь у нас в М такие замечательные циклы! Силу этого цикла Код: plaintext 1. Код: plaintext 1. 2. 3. Увлеченный вашим примером, я также протестировал однозадачный вариант первоначальной задачи. Поскольку в GT.M Job запускает системные процессы, а не задания М, в выигрыше оказался многозадачный вариант (сегодня он протекал на 5% быстрее, чем многозадачный). Также хочу сообщить, что в этой связи время исполнения несколько "пляшет", но тенденция остаётся. Персонально to Alexey Maslov хочу сообщить размер базы данных : 93949К - вдвое больше Caсhe. Так получилось, что первоначально я запускал другую подобную задачу, которая просто заполняла базу данных рядами(проверял многопоточность), а потом ту, которую просил попробовать в Caсhe. Чувствуя, что её размер должен быть меньше, я написал это в скобках, а на момент написания поста не имел возможности повторно перезапустить задачу с новой базой данных (не было 36 мин:). Надеюсь, что не причинил этим особых неудобств... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2008, 23:34 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Ув. коллеги! Вот и мне есть что сказать...:) Ведь у нас в М такие замечательные циклы! Силу этого цикла Код: plaintext 1. Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2008, 00:35 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
al-veliev Код: plaintext 1. 2. 3. Все-таки, наверное, вот так: Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2008, 09:49 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Протестировал все приведенные выше алгоритмы на Код: plaintext 1. CPU: Intel Core2Duo 2,33 ГГц 2 ГБ ОЗУ кэш бд выставлен вручную 1536 МБ Журналирование базы USER отключено, база предварительно расширена до 3 ГБ В агоритмах цикл Код: plaintext Код: plaintext 1. 2. Результаты: 1. Алгоритм с делением на простые числа: Limit=1000000, JobCount=1, Time=3.461106 Limit=1000000, JobCount=2, Time=2.207736 Limit=10000000, JobCount=1, Time=67.622076 Limit=10000000, JobCount=2, Time=36.391247 Limit=20000000, JobCount=1, Time=169.475283 Limit=20000000, JobCount=2, Time=89.043663 2. Моя реализация решета Эратосфена с изменениями Алексея Маслова: Limit=1000000, JobCount=1, Time=1.080419 Limit=1000000, JobCount=2, Time=1.267313 Limit=10000000, JobCount=1, Time=12.459379 Limit=10000000, JobCount=2, Time=12.814223 Limit=20000000, JobCount=1, Time=26.047151 Limit=20000000, JobCount=2, Time=25.736279 3. Алгоритм от al-veliev без каких-либо переделок (но без вывода на экран) Limit=1000000, Time=697.431159 4. Алгоритм от al-veliev с изменениями Алексея Маслова: Limit=1000000, JobCount=1, Time=1.853483 Limit=1000000, JobCount=2, Time=1.97762 Limit=10000000, JobCount=1, Time=24.433566 Limit=10000000, JobCount=2, Time=25.123423 Limit=20000000, JobCount=1, Time=52.238333 Limit=20000000, JobCount=2, Time=52.51064 5. Решето Аткина: Limit=1000000, JobCount=1, Time=1.111294 Limit=1000000, JobCount=2, Time=1.222627 Limit=10000000, JobCount=1, Time=14.68235 Limit=10000000, JobCount=2, Time=12.085616 Limit=20000000, JobCount=1, Time=30.78442 Limit=20000000, JobCount=2, Time=24.814908 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2008, 10:36 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
al-velievПоскольку в GT.M Job запускает системные процессы, а не задания М, в выигрыше оказался многозадачный вариант (сегодня он протекал на 5% быстрее, чем многозадачный).В Cache аналогично: Job запускает системные процессы. "Задания М" остались в далеком прошлом (MSM, DTM). Выигрыш 5% может быть в пределах погрешности. У меня получался даже больший выигрыш (см. начало дискуссии), который впоследствии не подтвердился. Думаю, это в природе Linux: скорость записи на диск не вполне предсказуема, т.к. на нее влияет много факторов, поэтому полностью согласен с MaWr'ом: чтобы уменьшить случайные флуктуации, имеет смысл тестировать на бОльших интервалах. Предложение (к MaWr'у): если не трудно, выложите здесь последний вариант исходников, чтобы была уверенность, что все мы запускаем одно и то же. Мне кажется, интересно было бы протестировать их и в GT.M, но пока у меня нет такой возможности. Столь значительный проигрыш в скорости в GT.M (пусть и на относительно слабом ноуте) по сравнению с Cache, который получил Ал. Велиев, продолжает казаться мне странным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2008, 11:55 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Alexey MaslovСтоль значительный проигрыш в скорости в GT.M (пусть и на относительно слабом ноуте) по сравнению с Cache, который получил Ал. Велиев, продолжает казаться мне странным.Имелся в виду проигрыш однозадачного варианта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2008, 12:03 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Alexey MaslovПредложение (к MaWr'у): если не трудно, выложите здесь последний вариант исходников, чтобы была уверенность, что все мы запускаем одно и то же. Код: 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. 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2008, 13:00 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
MaWr, спасибо, запланирую запуск на вечер (чтоб поменьше побочных эффектов :). Результатами поделюсь завтра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2008, 13:47 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
А к чему все-таки пришли, скорость удовлетворительная или нет? Или это были "шахматные этюды"? "Быстрее, выше, сильнее"-лозунг на стадионе. "МАМПС-это сила, а сила есть-ума не надо"-высказывание одного МАМПСиста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2008, 15:56 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Спасибо за информацию о способе запуска в Cache. Вы совершенно правы, говоря о значительном влиянии ОС на скорость протекания задачи. У меня также сложилось устойчивое впечатление, что у меня слишком тихий HDD . В процессе наблюдал "зависания" из-за процессов чтения-записи на диск в разные моменты времени. Также могу сказать с уверенностью, что чем б о льший максимум запущенных процессов, тем хуже результат. Для полноты сравнения с GT.M - можно его запустить без инсталляции . В Linux необходимы только 3 файла: mumps, libgtmshr.so и shell-скрипт для его запуска (около 2 Мбайт). Я Вам смогу этот набор выслать по e-mail в архиве - сейчас под рукой нет. Также я несколько улучшил алгоритм и завтра выложу усредненные результаты и свой код. Алгоритм с решетом Аткина пока перевариваю... Новая для меня функция $i - в GT.M её нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2008, 20:23 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Наметился явный лидер среди алгоритмов для нахождения ряда простых чисел для cache Оптимизировав еще решето Эратосфена таким образом: Код: 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. Получил следующее: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2008, 10:08 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Результаты из предыдущего поста были получены на 5.0.20 На 2008.2 результаты следующие: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2008, 10:16 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
al-veliev, да, там и $LB() нету, очень, очень жаль, но, может появится... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2008, 10:17 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Вот результаты вечернего прогона. Гонял только самые быстрые варианты (Аткина и Эратосфена от Мавра), по десять раз с каждым набором параметров. Сегодня ночью погоняю новый вариант "решета Мавра" (от Зратосфена там уже почти ничего, кроме идеи решета, не осталось :). Код: 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. Меня давно интересуют параллельные вычисления. Были случаи удачного применения их в работе. Но об общих закономерностях говорить пока рано (даже применительно к Cache - как к наиболее знакомому мне серверу БД/приложений). Все решает, в конечном счете, эксперимент. Предварительные соображения есть, но пока на уровне предположений. Например, в решете Эратосфена частые Kill 'ы в активно читаемый глобал приводят к его "перетряске", устареванию блоков в кэше, и кол-во ядер уже не спасает: процессы банально ждут, пока закончится цикл работы WRTDMN - а он (демон записи) в Cache один. Но почему-то (почему?) не менее частые команды set ^l(n)='$g(^l(n)) в решете Аткина оказываются меньшим злом.al-velievЯ Вам смогу этот набор выслать по e-mail в архиве - сейчас под рукой нетСпасибо, скачать GT.M для меня не проблема - проблема, чтобы руки дошли :). К тому же Вы немного не в курсе: $increment() в GT.M появился достаточно давно - посмотрите на SourceForge. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2008, 11:22 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Эратосфена забыл вставить. Вот: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2008, 11:26 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Alexey Maslov, Ой не последний вариант случайно выложил... Вот последний: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2008, 13:26 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Принял к сведению :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2008, 13:33 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
AlexKBИли это были "шахматные этюды"? У меня чисто практический интерес. Хочу в связи с этим рассказать историю. Захожу как-то к товарищу, а он чёрный как туча около своего компьютера. Оказывается, что в базе данных сайта, который он разрабатывал, хранились протоколы сессий - того требовал характер обработки данных. Очистка мусора была "зацеплена" на админку. Так вышло, что на неё долго никто не заходил, и накопилось очень много таких "хвостов". В результате они начали "топить" обработку. Мой товарищ оказался в сложной ситуации - броузер выделяет на ответ 300 миллисекунд, сервер загружается одним запросом по полной, защита сервера срабатывает по подозрению в fork bomb (метод взлома, основанный на бесконечном вызове процессом самого себя или съедания памяти подобным образом. После перезагрузки системы неопытным администратором остаётся ловить пользовательские пароли) и обрезает ему квоту до минимума. Броузер, не дождавшись ответа, разрывает соединение, и ответ получить не удаётся. Ему пришлось потратить весь вечер и всю ночь, чтобы очищать по малюсенькому кусочку базу данных. Если бы у него в руках на тот момент был подобный механизм, он потратил бы час-два, и сайт не бездействовал бы весь вечер и всю ночь. Во избежание необоснованных обвинений в некомпетентности, расхлябанности и т. д. сайт, имена и фамилии не называю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2008, 20:10 |
|
||
|
Что же главное в Cache?
|
|||
|---|---|---|---|
|
#18+
Хочу продолжить тему с fork bomb применительно к нашей с Вами теме. Пришел вчера домой. Подумал. Отключил антивирус и сетевую поддержку. Скорость и стабильность прохода задач резко выросли. В среднем прогон задачи шел около 3-х минут (Рост более чем в 2 раза). Если не считать одного случая с явным вмешательством ОС в процессы вычислений, то отклонения не превышали 10 сек., количество процессов колебалось в пределах 40-60. Но, говоря о нестабильности результатов в Linux, Вы абсолютно правы - сегодня днём цифры были немного больше. К концу следующей недели-середине месяца я запущу GT.M под Windows в режиме эмуляции, чтобы исключить этот фактор. Спасибо за информацию об $i , а то начал уже огород городить с пользовательской функцией. Говоря об её отсутствии, я ориентировался на документацию. Похоже, она слегка устарела. Кстати, увидев H 0.1 я порадовался за то, что в Cache сделали более точный механизм задержек. Преисполненный радужных надежд, я направился в онлайн-документацию по Cache, надеясь увидеть такой же прогресс в командах Read, Open и Use, но был разочарован. Как Вы выходите из ситуации, когда нужно более точно реагировать при использовании этих комманд(скажем, с точностью до миллисекунд)? Алгоритм Аткина меня порадовал более аккуратной работой с диском - таково первое впечатление. Хорошо Вам провести выходные! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2008, 20:36 |
|
||
|
|

start [/forum/topic.php?fid=39&msg=35627068&tid=1557930]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
83ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
87ms |
get tp. blocked users: |
2ms |
| others: | 263ms |
| total: | 490ms |

| 0 / 0 |
