Comments 11
Торт.
Конечно пишите! Такие вопросы на Хабре не обсуждаются… ) Если есть чем поделиться, то полезные знания/опыт должны быть в свободном доступе. Это ли не путь к развитию человечества? :)
Вот не понимаю, школьники/гуманитарии жмут «нет» в опросе или профессора физико-математических наук? Вам от новой статьи плохо станет или вы настолько круты, что с пеленок знаете все тонкости рассматриваемой темы? Просто пройдите мимо и почувствуйте свою причастность и полезность в немешании другим…
Ничего не понял, но теперь будет стимул копнуть в эту сторону, спасибо.
Да, в проектировании классов и архитектурных подходах в C# вам не мешало бы прокачать скил (Console.Write внутри методов классов — извините меня). И не стоит так расхваливать TPL, что прям всё так стало оптимально и быстро. Конечно, библиотека замечательная, но, насколько я знаю, не так просто определить места, где тот же Parallel.ForEach() действительно даст рост производительности. И по-хорошему нужно сделать тесты. Вообще много чего по-хорошему нужно писать, а стиль статьи смахивает на стиль написания дипломных работ — мы взяли библиотеку такую-то, написали метод такой-то, тут вот у нас TPL использован…
Однако сама тема весьма интересна, и за работу скорее лайк, чем минус.
Однако сама тема весьма интересна, и за работу скорее лайк, чем минус.
К сожалению, не было времени долго над архитектурой думать. Так бы вместо статических хэлперов со статическими переменными реализовал бы синглтоны. Вместо тупого стринг.формата в консоль сделал бы нормальный логгер. Юнит-тесты тоже вещь хорошая, но в данном случае максимум пригодятся тестовые сценарии — прогон симуляции с тестовыми параметрами. Нормальное юнит-тестирование с более чем 50% покрытием мне в данный момент кажется излишним. Все упирается в ресурсы.
Я расхваливаю эту библиотеку за удобство. Эффективность же ее использования определяется общими соображениями многопоточности (замыкания, расшаренные ресурсы, блокировки и т.д.). При этом выполнение Task в пулле потоков избавляет от необходимости контролировать количество запускаемых одновременно тасков.
И не стоит так расхваливать TPL, что прям всё так стало оптимально и быстро.
Я расхваливаю эту библиотеку за удобство. Эффективность же ее использования определяется общими соображениями многопоточности (замыкания, расшаренные ресурсы, блокировки и т.д.). При этом выполнение Task в пулле потоков избавляет от необходимости контролировать количество запускаемых одновременно тасков.
Имею ввиду сравнительные тесты на время выполнения параллельной и непараллельной версий (с применением TPL / без применения TPL). Правда для этого нужно непараллельную версию написать. Ведь есть же такие понятия, как переключение контекстов, ожидание снятия блокировки, вызов делегата (ресурсоемкая операция, хотя видел у вас в коде Partitioner).
Промазал, это ответ на коммент выше.
Промазал, это ответ на коммент выше.
Насколько мне известно, есть способ задавать количество тредов в пулле. Кроме того я сравнивал скорость работы этой программы на i3 и Core 2 Duo. У последнего выше частота, но ядер/потоков меньше. Так на i3 значительно быстрее. Там чуть ли не 6-8 фильтров в параллели обсчитывается. На Core 2 Duo по 2-3 где-то. Это примерная, качественная оценка сделанная по динамике вывода отладочной инфы, которая при параллельной работе появляется группами однотипных блоков.
Можно и бенч забубенить нехитрый.
Можно и бенч забубенить нехитрый.
Очень круто, понятно и главное — вовремя. Спасибо.
Sign up to leave a comment.
Генератор Федеративного Фильтра Калмана с использованием Генетических Алгоритмов