Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
в ядрах GPU в обход шины PCI-EBandwidth памяти RAM-GPU = 100-300 GByte/sec, а PCI-E gen2 16x = 8 GBytes/sec. Вы уверены, что RAM-GPU у вас слабое звено? Или у вас данные в ядрах GPU окажутся в обход шины PCI-E? ;) Для AMD Fusion или Intel HD Graphics - копирования массивов не будет: http://social.msdn.microsoft.com/Forums/vstudio/en-US/6426345c-9110-4e58-9f18-a6320b5f75ad/amp-and-zero-copy . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2013, 22:03 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
SerValm_SlaНа cpu в одном потоке.... Exec time : 0.037000 seconds. Поздравляю! ... как известно,быстрее всего работает код, которого о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. 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. У Вас сложение на CPU по быстродействию примерно равно сложению на GPU. При этом сложение на CPU можно еще оптимизировать, например SSE прикрутить. Какой смысл в GPU и многопоточности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 05:50 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
Вот результаты с использованием gmp 5.1.2 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 06:21 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
Добрый день, m_Sla . Про n1.add(n2) - какое ж это сложение? Это не "А= В+С", а реализация оператора "+=". -> A += B - теряется одно из слагаемых - оно становится результатом. ...это как говорят в Одессе - две большие разницы. :) У меня числа складаваются и результат присваивается третьему числу: Код: 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. 133. 134. 135. 136. ================== CPU: A = add(B,C) Exec time : 0.003000 seconds. ================== Теряется ли в gmp 5.1.2 одно из слагаемых - не знаю. Однако, охотно верю. ****** То что последовательное сложение у меня сделано криворуко - согласен. Можно переписать получше. И оптимизировать его можно. Только зачем? Как Вы показали, всё оптимизировано до нас в доступных библиотеках. m_SlaКакой смысл в GPU и многопоточности? Похоже, уже на числах в 100 миллионами цифр, параллельное сложение обгоняет сложение на одном ядре. Вот: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. *Тем не менее, сделаю сложение на CPU векторами, или попробую прикрутить gmp 5.1.2(для сравнения). Всем привет и хорошего настроения. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 14:28 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
SerValGuestSerVal, а переносы между разрядами при сложении вы что вообще не учитываете? Ага, не учитываю, поскольку ещё не умею, а подсказать некому. :( Однако, сначала надо определиться, какой будет ли выигрыш в производительности. Угу, складываете вы параллельно к примеру 555....5555 и 444....4445. И у вас возник перенос в последнем разряде. Что толку от параллельного сложения циферок, если потом этот перенос надо будет последовательно по всем разрядам тащить? С умножением будет не лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 15:13 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
?Что толку от параллельного сложения циферок, если потом этот перенос надо будет последовательно по всем разрядам тащить? С умножением будет не лучше. Ш-ш-ш-ш, не спойлери. Дай ему пройти по всем граблям, иначе образовательного эффекта не будет. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 15:23 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
SerValmaytonSerVal, а какие задачи ты решаешь? Криптография? Не, сам я в криптографии не разбираюсь. Но есть ребятки, которые интересуются криптоанализом шифров Bivium и Trivum. Чел, ну насколько я знаю, крипто-библиотеки просто используют MMX/SSE наборы команд чтобы работать с длинной арифметикой. Причём у них длинная арифметика изначально, на уровне постановки ограничена в разрядности. К примеру задались регистром в 512 бит. И работают с такими регистрами. Если там умножение или сложение - то обычно по модулю. Тоесть переноса в самый старший разряд нету. Из этого и танцуют. Юзать для криптографии BigInteger - ну не знаю. Наверное это слишком уж Generic-решение. И что у тебя вообще за операции? На высоком уровне. Разложение на множители? Я к тому что есть разные подходы к оптимизации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 15:27 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
GuestУгу, складываете вы параллельно к примеру 555....5555 и 444....4445. И у вас возник перенос в последнем разряде. Что толку от параллельного сложения циферок, если потом этот перенос надо будет последовательно по всем разрядам тащить? С умножением будет не лучше. Ну, если бы перенос возникал только в последнем разряде - всё было бы просто: добавить единичку в старший разряд при сложении или остаток от деления на 10 при умножении(при базе=10) :) Однако ж, проблема давно известна, и, разумеется, решена: никто переносы последовательно не тащит. Вот тут "Введение в параллельные и распределённые алгоритмы": описано параллельное сложение больших чисел: http://www.toves.org/books/distalg/#3.3 Однако ж, реализации нетути. То что на аглицком, это ещё ладно. Похоже, там какие-то недоговорённости, не позволяющие ущучить смысл и реализовать на С++. Ну, или у меня недостаточно мозгов(что тоже не исключается). Больше никакой теории найти не могу. На русском - и подавно(всё в закромах Родины). Ежели кто знает как реализовать параллельный сумматор с переносами, прошу поделиться ссылкой(на или алгоритм или реализацию). А то чёта всё застопорилось. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 15:46 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
SerValДобрый день, m_Sla . Про n1.add(n2) - какое ж это сложение? Это не "А= В+С", а реализация оператора "+=". -> A += B - теряется одно из слагаемых - оно становится результатом. ...это как говорят в Одессе - две большие разницы. :) ...У меня почти тоже самое: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Знаю, что не оптимально, но мне переделывать лень. ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 15:48 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
SerValстрока1 : 100000000 цифр. строка2 : 100000000 цифр. Конструируем 2 числа: Exec time : 7.85 seconds. ================== CPU: A = add(B,C) Exec time : 17 seconds. У меня больше 100 мс на сложение не получается. Даже миллиард цифр в секунду укладывается. Безо всякой оптимизации. Вот тупо за 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. 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 15:54 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
Добрый день, mayton . maytonЮзать для криптографии BigInteger - ну не знаю. Наверное это слишком уж Generic-решение. И что у тебя вообще за операции? На высоком уровне. Разложение на множители? Я к тому что есть разные подходы к оптимизации. У ребят есть свой программист на зарплате. Он им сейчас на КУДЕ делает. Библиотека нужна мне. Ну, скажем для личных нужд. Никаких денех я за это не получаю, и в обозримом будущем не получу. По работе я ничего не программирую. Я, вообще, не программист. С++ для меня не более, чем удобный калькулятор. (C# тоже годится, но уж больно медленный). Ну вот захотелось мне попроверять кое-что.. у каждого свои тараканы в голове... А числа большие, даже в памяти не помещаются. Вот и пришла мне мысль, что вычисляя параллельно на 1600 процессорах результат можно получить немного быстрее, чем на одном. Началось, как писал выше, с поиска подходящей библиотеки..которой, как оказалась нетути. Точнее, у "Cray MP" она есть.. у меня нетути. *как-то Таг :) *простые числа, разложение на множители.. это тоже. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 16:16 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
Ребятки, спасибо за отклики. Я сейчас внимательно всё посмотрю и отвечу. Однако ж и меня к вам вопрос: Вы на самом деле считаете, что вычисления на 1600 процессорах медленнее, чем на одном??? Интересно, как бы вы рассуждали, будь у вас в процессоре хотя бы 1000 ядер? *ладно, ладно.. помнится во времена, когда "процессоры Интел ускоряли Интернет" нам обещали 80 ядер. Ну, хоть 80. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 16:30 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
SerValА числа большие, даже в памяти не помещаются. Вот и пришла мне мысль, что вычисляя параллельно на 1600 процессорах результат можно получить немного быстрее, чем на одном. Началось, как писал выше, с поиска подходящей библиотеки..которой, как оказалась нетути. Точнее, у "Cray MP" она есть.. у меня нетути. *как-то Таг :) *простые числа, разложение на множители.. это тоже. :) Я думаю что это забавный мозговой эксперимент. Сама по себе задача сложения многоразрядных чисел давно вдоль и поперёк изъезжена и ничего здесь поделать нельзя. Яркий пример - деление или нахождение остатка от деления. Операция принципиально несократимая. Ее можно иногда задавать таблично, иногда что-то кешировать но один хрен она - тот самый гранит который грызут все криптоаналитики. По сути она-же защищает наши засекюренные файлы от "жены" и "спецслужб". (подчеркнуть что опаснее !). А если серъезно - то факторизация гораздо интереснее чем то чем ты занят. Поинтересуйся как-нибудь. Можно зацепить краем теорвер, теорию чисел, алгебру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 16:36 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
SerValъПохоже, там какие-то недоговорённости, не позволяющие ущучить смысл и реализовать на С++ну там отсылка к разделу 3.1 (parallel prefix scan) - это самая сложная часть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 16:37 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
SerValЕжели кто знает как реализовать параллельный сумматор с переносами, прошу поделиться ссылкой(на или алгоритм или реализацию). А то чёта всё застопорилось. :( http://literaturki.net/elektronika/cifrovaya-shemotehnika1/165-parallelnye-summatory-s-parallelnym-perenosom (шутка) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 16:42 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
maytonЯ думаю что это забавный мозговой эксперимент. Скорее это очень хороший способ прокачать мозг ТСа. Возможно, в результате он дойдёт до уровня, достаточного для того, чтобы раскрыть один маленький секрет длинной арифметики: гораздо эффективнее и проще распараллеливать конечный алгоритм чем элементарные операции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2013, 16:47 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
SerValОднако ж, проблема давно известна, и, разумеется, решена: никто переносы последовательно не тащит. Вот тут "Введение в параллельные и распределённые алгоритмы": описано параллельное сложение больших чисел: http://www.toves.org/books/distalg/#3.3 Однако ж, реализации нетути. То что на аглицком, это ещё ладно. Похоже, там какие-то недоговорённости, не позволяющие ущучить смысл и реализовать на С++. Ну, или у меня недостаточно мозгов(что тоже не исключается). Больше никакой теории найти не могу. На русском - и подавно(всё в закромах Родины). Ежели кто знает как реализовать параллельный сумматор с переносами, прошу поделиться ссылкой(на или алгоритм или реализацию). А то чёта всё застопорилось. :(реализация алгоритма на С в лоб, без всякой оптимизации и без распараллеливания см. void BigInt::parallel_add(BigInt& s): Код: 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. 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2013, 08:38 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
m_Slaреализация алгоритма на С в лоб, без всякой оптимизации и без распараллеливания см. void BigInt::parallel_add(BigInt& s):Дык, там все самое сложное в распараллеливании prefix scan. А вы его циклом сделали, который не распараллеливается. А остальное то элементарно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2013, 09:28 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
?m_Slaреализация алгоритма на С в лоб, без всякой оптимизации и без распараллеливания см. void BigInt::parallel_add(BigInt& s):Дык, там все самое сложное в распараллеливании prefix scan. А вы его циклом сделали, который не распараллеливается. А остальное то элементарно.ну так надо ТСу, а не мне пусть распараллеливает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2013, 10:15 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
2 Anatoly Moskovsky : Посмотрел Ваш подарок. Аппетитный такой подарок, спасибо. *правда, в нём непонятная библиотека boost. Про буст я не знаю. m_Sla , Вы молодец, разобрались. Спасибо. Правда в Вашем коде я пока разобраться не могу. Однако ж сам дошёл до получения вектора <carry>. Получить из <prefix scan> <carries> пока не получается. :( Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Как Вы получаете из <prefix scan> <carries> - ещё непонятнее. Каким-то копированием памяти? ??? Совсем непонятно. Я пробую так: Код: 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. Векторы независимые, чтобы после того как заработает, распараллелить. Тружусь.. Всем привет и хорошего настроения. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2013, 18:02 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
SerValправда, в нём непонятная библиотека boost. Про буст я не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2013, 18:07 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
maytonА если серьёзно - то факторизация гораздо интереснее чем то чем ты занят. Поинтересуйся как-нибудь. Можно зацепить краем теорвер, теорию чисел, алгебру. Этим всё равно придётся заняться. Патамушта держать в памяти BigInt-ы (векторы с миллиардом знаков) - это ж никакой памяти не хватит. Только для примеров. Если число долго не используется, может быть есть смысл хранить его в факторизованном виде. Или как-то упакованным. А при необходимости - распаковывать. Но пока об этом рано говорить. Этим можно заняться после базовых операций(сложение, умножение..). Факторизация, в этом случае, тоже должна быть быстрой. Думаю, и тут 1600 процессоров помогут. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2013, 18:17 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
SerVal, простые числа (prime numbers) не раскладываются на можнители. В этом кстати и соль этой задачи - в поиске подобных чисел. Природа кстати такие задачи обходит и просто не решает. Просто ей не нужна чисельная точность до младшего разряда. Тот-же double или extended можно рассматривать как как biginteger но с экспоненциальной сеткой. Тоесть чем больше число - тем грубее у него абсолютная погрешность. Можно удобно посчитать соотношение поперечника вселенной к диаметру электрона и решить это в double и получить вполне вменяемый с точки зрения физики ответ. В твоих числах для решения этой задачи толку нет. Мы всё равно не можем с точностью до микрометра посчитать поперечник вселенной. Погрешности числителя и знаменателя разные. Улавливаешь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2013, 18:40 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
mayton , простые числа тоже как-то хранят. Типа 2^n+1. Мож и остальные так хранить. Ну а насчёт природы.. ээ.. Неперу про его логарифмы чего только не говорили.. Лет 300 оне без применения лежали. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2013, 19:16 |
|
||
|
C++ BigIntegers parallel library
|
|||
|---|---|---|---|
|
#18+
Ты нарисовал формулу похожую на "числа Мерсена". С некоторым отличием там минус 1 а не плюс. Отлично. Но это не все простые числа а лишь ничтожно малая их часть. Кроме того тебе никто не обещал сжатия места после факторизации. Это ты сам неверное придумал? Факторизация она ... для других дел. Я про то что физика, как наука о природе довольствуется расчётами в double. Ей не нужны копейки в младших разрядах. Так-то... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2013, 19:24 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=38394069&tid=2019035]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
68ms |
get topic data: |
8ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 179ms |

| 0 / 0 |
