|
Linq.AsParallel()
|
|||
---|---|---|---|
#18+
Есть такой простой код Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
почему сумма по обычному массиву всегда в несколько раз медленней? Судя по тому, что пишут тут Массив должен быть быстрей ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2013, 19:49 |
|
Linq.AsParallel()
|
|||
---|---|---|---|
#18+
relief, авторпочему сумма по обычному массиву всегда в несколько раз медленней? а патаму что не правильно замеряете попробуйте вот такой код Код: 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.
ARRAY 36 queue 18 ARRAY 1 queue 12 ARRAY 1 queue 9 а вот если поменять последовательность вызова ( массива и последовательности) то картина вообще станет разгромной ARRAY 2 queue 51 ARRAY 1 queue 9 ARRAY 1 queue 10 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2013, 20:35 |
|
Linq.AsParallel()
|
|||
---|---|---|---|
#18+
beg-in-er, чуть покопавшись с кодом получим Код: 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.
а вот и результаты. по ним видно , что Queue PLINQ наглухо проигрывает даже Queue LINQ. а уж обычному ARRAY так вообще на порядок. что в общем и ожидаемо время в миллисекундах X64 ARRAY PLINQ 29 ARRAY LINQ 86 ARRAY PURE 23 Queue PLINQ 254 Queue LINQ 210 X86 ARRAY PLINQ 23 ARRAY LINQ 47 ARRAY PURE 15 Queue PLINQ 152 Queue LINQ 114 ну и как всегда, платформа x86 разделала под орех x64. что то же вполне ожидаемо. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 01:44 |
|
Linq.AsParallel()
|
|||
---|---|---|---|
#18+
beg-in-er, а почему играет очередность вызовов? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 10:50 |
|
Linq.AsParallel()
|
|||
---|---|---|---|
#18+
relief, вообщето последовательность вызовов не имеет значение. но при т.к. скомпилированный проект это код JIT , то разница во времени объясняется как раз этим. когда происходит повторный вызов метода , то код уже скомпилирован в байткод и это уже чистое время. от этого "недостатка" можно избавится использовав утилиту ngen ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 11:41 |
|
Linq.AsParallel()
|
|||
---|---|---|---|
#18+
beg-in-errelief, вообщето последовательность вызовов не имеет значение. но при т.к. скомпилированный проект это код JIT , то разница во времени объясняется как раз этим. хочу остановиться на вот этом вашем сравнении авторARRAY 36 queue 18 ARRAY 1 queue 12 ARRAY 1 queue 9 почему первый раз Array тратит намного больше чем queue? насколько я понимаю jit компилирует функцию целиком при первом обращении, т.е. array должен работать также быстрей в 2 и 3 попытках. Если нет - пояссните детали такой разницы ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 12:17 |
|
Linq.AsParallel()
|
|||
---|---|---|---|
#18+
relief, я чесно говоря не знаю , почему так проиходит. на знаю тонкостей реализации JIT->байт кода. но судя по поведению, либо счётчик глючит, либо среда пытается исполнить без байткода, но когда натыкается на дорогой вызов - компилит...но счётчик уже запущен. наверно как так ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 12:31 |
|
Linq.AsParallel()
|
|||
---|---|---|---|
#18+
я не понимаю что вы хотели показать? Вот мой пример на коленке. Взял более "тяжелые" операции, чтобы затраты на потоки были не так видны. Результат есть: Код: c# 1. 2. 3. 4.
код: Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 21:51 |
|
Linq.AsParallel()
|
|||
---|---|---|---|
#18+
netivan, а ничего не хочу сказать. цифири сами говорят за себя а вот с List да , там дела стоят именно так. Да PLINQ будет быстрее. ну добивать , так добивать. чистый массив туда зафигачим ARRAY PLINQ 35 ARRAY LINQ 82 ARRAY PURE 20 Queue PLINQ 192 Queue LINQ 184 Queue PURE 74 LIST PLINQ 31 LIST LINQ 112 LIST PURE 41 I32 PLINQ 28 I32 LINQ 40 I32 foreach 4 I32 for 9 Код: 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.
ПС. многое зависит от проца. у меня какой то щас на ноуте мутный проц AMDx64 . ноут , который был на 30% дешевле , но Core i3, работает в 2 раза быстрее. ПС2. в толк не могу взять , почему на х86 оператор foreach в 2 раза быстрее оператора for. foreach 4 миллисекунды , супротив 9 для for. при том , что на х64 разницы нет никакой . парадоксЪ. я то думал , что быстрее for трудно сделать. ан нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 22:22 |
|
Linq.AsParallel()
|
|||
---|---|---|---|
#18+
beg-in-er, но само по себе , что разница в обработке для простого массива интов в разы быстрее чем сложных типов очень показательна. меня это наводит только на одну мысль , что все эти PLINQ какой-то паллиатив. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 22:26 |
|
Linq.AsParallel()
|
|||
---|---|---|---|
#18+
beg-in-erв толк не могу взять , почему на х86 оператор foreach в 2 раза быстрее оператора for. foreach 4 миллисекунды , супротив 9 для for. Слишком велика погрешность на IO и т.п., не заморачивайся. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2013, 22:40 |
|
|
start [/forum/topic.php?fid=20&msg=38248302&tid=1404734]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
68ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 170ms |
0 / 0 |