1. volatile на производительность повлияет отрицательно, но у вас там в принципе баг, этот цикл может работать неправильно.
2. Вы измеряете время выполнения кода с Thread.sleep внутри. Который в принципе может вести себя непредсказуемо.
Посмотрел реализации EncodeParallel/DecodeParallel:
1. Параллельный код так в целом писать не стоит, но придираться не буду.
2. Такая реализация дает очень высокий contention, то есть ваши потоки скорее всего большую часть времени висят на блокировках.
Я бы:
1. Переписал бы код без блокировок, для этого алгоритма это легко.
2. Посмотрел бы как устроен ThreadPool в Unity. И погонял бы под профайлером. Я ничего не знаю о Unity, но почти уверен, что дело в разнице реализаций.
И к тебе тоже, так как ты привел пример с прямоугольниками. Я на самом деле немножко неправильно задал вопрос.
Я к тому, что реальный разработчик вас послушает-послушает, покачает головой и пойдет рисовать треугольники. И интересовать его в общем-то будут в худшем случае два вида треугольников:
1. Те, который хотя бы одной точкой попали на видимую часть окна приложения.
2. Те, которые ни одной точкой в окно не попали.
И вот этот вот разрез ну никак не будет связан с «объемом понятия», который есть множество всех возможных треугольников по определению. Зато будет включать некую связь с понятием «окно» и его размерами.
И где-то уже потом появится абстракция «прямоугольник», который будет состоять из двух треугольников со специфическими инвариантами.
Таким образом, вопрос должен звучать так — каким образом вышеописанные онтология и подход помогут мне построить реальное приложение? И что «абстрактнее» — прямоугольник или треугольники из которых он состоит? Или «окно»? (мне вот кажется что это вообще три разных иерархии).
А теперь еще представим, что рядом появилась дополнительная функциональность — подсчет площадей прямоугольников. Мне надо знать, что при отрисовке прямоугольники состоят из треугольников? Вроде нет. Получается, это уже совсем другие прямоугольники?
Прошу участников указать предметные области, которые плохо охватываются данным подходом.
Непонятно что должно получиться в результате «охвата». И как этот результат потом использовать для решения каких-либо предметных задач.
Справедливости ради, у меня такое же ощущение от практически всех знатоков EA, Захмана, TOGAF и прочих *AF. Идеи вроде и здравые/интересные в основе, но…
«Нужно принимать по одной таблетке из каждой бутылки ежедневно в течении месяца, чтобы приобрести иммунитет к вирусу.»
«Таблетку выбросить нельзя, поскольку их количество ограничено.»
Задача про вирусную инфекцию:
1. Отложим пока три таблетки и пересчитаем сколько осталось в бутылках. В одной из бутылок будет на одну таблетку больше. Заберем эту лишную таблетку и положим к трем высыпавшимся. Таким образом в куче высыпавшихся таблеток будет по две таблетки из каждой бутылки.
2. Разломим каждую таблетку пополам. «Левые» половины сложим в одну кучу. «Правые» в другую.
Таким образом, в каждой куче будет по две половинки таблетки из каждой бутылки. Или по одной целой таблетке из каждой бутылки.
3. Сегодня съедим левую кучку, завтра съедим правую.
Как я писал выше — я хочу СВОЙ аллокатор. Например, чтобы гарантировать что созданные объекты легли в одну страницу памяти. Или обеспечить хорошую data locality без танцев с массивами и структурами.
В целом, меня смущает managed-платформа, из которой везде торчат кишки (иногда самым неожиданным способом) в виде volatile, unsafe, fixed, структур и даже memory padding'а, но к которой я при этом не могу прикрутить хотя бы свой аллокатор и сборщик мусора.
И, да, я видел больше одного проекта на дотнете где это важно и при этом использование дотнета оправдано. И видел задачи, где fine grained il-код может что-то решить.
Технический специалист быстро даст заднюю передачу и признается, что всё это философия, она нужна чтобы начать разговор, однако всё это неважно. И вы продолжите общение.
Справедливости ради, банальный random вполне себе детерминирован и возвращает одну и ту же последовательность чисел при одном и том же seed.
Реальной недетерминированности в коде на самом деле практически нет, разве что какие-либо race condition, которых вообще не должно быть (а тестирование конкуррентного кода — это, собственно, не совсем юнит-тестирование).
2. Вы измеряете время выполнения кода с Thread.sleep внутри. Который в принципе может вести себя непредсказуемо.
Посмотрел реализации EncodeParallel/DecodeParallel:
1. Параллельный код так в целом писать не стоит, но придираться не буду.
2. Такая реализация дает очень высокий contention, то есть ваши потоки скорее всего большую часть времени висят на блокировках.
Я бы:
1. Переписал бы код без блокировок, для этого алгоритма это легко.
2. Посмотрел бы как устроен ThreadPool в Unity. И погонял бы под профайлером. Я ничего не знаю о Unity, но почти уверен, что дело в разнице реализаций.
Дальше не смотрел, но этого достаточно чтобы сильно засомневаться в адекватности как минимум бенчмарка.
Почитайте зачем нужен как минимум volatile.
Получается, что ваша шкала абстрактности зависит от конкретной задачи и даже контекста в рамках задачи. О какой общей базе тогда можно говорить?
Я к тому, что реальный разработчик вас послушает-послушает, покачает головой и пойдет рисовать треугольники. И интересовать его в общем-то будут в худшем случае два вида треугольников:
1. Те, который хотя бы одной точкой попали на видимую часть окна приложения.
2. Те, которые ни одной точкой в окно не попали.
И вот этот вот разрез ну никак не будет связан с «объемом понятия», который есть множество всех возможных треугольников по определению. Зато будет включать некую связь с понятием «окно» и его размерами.
И где-то уже потом появится абстракция «прямоугольник», который будет состоять из двух треугольников со специфическими инвариантами.
Таким образом, вопрос должен звучать так — каким образом вышеописанные онтология и подход помогут мне построить реальное приложение? И что «абстрактнее» — прямоугольник или треугольники из которых он состоит? Или «окно»? (мне вот кажется что это вообще три разных иерархии).
А теперь еще представим, что рядом появилась дополнительная функциональность — подсчет площадей прямоугольников. Мне надо знать, что при отрисовке прямоугольники состоят из треугольников? Вроде нет. Получается, это уже совсем другие прямоугольники?
Зачем это вообще нужно знать?
Непонятно что должно получиться в результате «охвата». И как этот результат потом использовать для решения каких-либо предметных задач.
Справедливости ради, у меня такое же ощущение от практически всех знатоков EA, Захмана, TOGAF и прочих *AF. Идеи вроде и здравые/интересные в основе, но…
«Таблетку выбросить нельзя, поскольку их количество ограничено.»
Их там не более 31.
1. Отложим пока три таблетки и пересчитаем сколько осталось в бутылках. В одной из бутылок будет на одну таблетку больше. Заберем эту лишную таблетку и положим к трем высыпавшимся. Таким образом в куче высыпавшихся таблеток будет по две таблетки из каждой бутылки.
2. Разломим каждую таблетку пополам. «Левые» половины сложим в одну кучу. «Правые» в другую.
Таким образом, в каждой куче будет по две половинки таблетки из каждой бутылки. Или по одной целой таблетке из каждой бутылки.
3. Сегодня съедим левую кучку, завтра съедим правую.
Как я писал выше — я хочу СВОЙ аллокатор. Например, чтобы гарантировать что созданные объекты легли в одну страницу памяти. Или обеспечить хорошую data locality без танцев с массивами и структурами.
И, да, я видел больше одного проекта на дотнете где это важно и при этом использование дотнета оправдано. И видел задачи, где fine grained il-код может что-то решить.
А если в контексте задачи Master_Dante?
А можно пример решения производительность которого не умрет на маршаллинге?
Пожалуй, дальше можно не читать.
Справедливости ради, банальный random вполне себе детерминирован и возвращает одну и ту же последовательность чисел при одном и том же seed.
Реальной недетерминированности в коде на самом деле практически нет, разве что какие-либо race condition, которых вообще не должно быть (а тестирование конкуррентного кода — это, собственно, не совсем юнит-тестирование).