Комментарии 12
Я смотрю, что работа с пикслеми проводится во float-ах. Не знаю как в Go, но вот в C++ перевод такого же кода на целые числа дал бы существенный прирост производительности.
А мне вот какой вопрос не понятен. Разве не логично применять average не к оригинальным картинкам из директории, а в начале уменьшить их до размера плиток, а затем уже считать средний цвет. Мне кажется в этом случае картинки более качественно подбираться будут.
Для этого пришлось бы создавать несколько новых директорий, сохранять там результат изменений, хранить усреднённые цвета в разных отображениях. Или просто с префиксом генерировать уменьшенные картинки в ту же директорию, тогда всё бы помещалось в уже созданное отображение, но непомерно увеличивало бы его.
Это всё ещё раздуло бы эту статью, а в ней и так около 20 страниц текста.
Задача статьи — показать как с помощью Го ускорить приложение, добавив немножко горутин.
Это всё ещё раздуло бы эту статью, а в ней и так около 20 страниц текста.
Задача статьи — показать как с помощью Го ускорить приложение, добавив немножко горутин.
Статья полезная, мне понравилась, но кто мешал автору перед вычислением average сделать уменьшенную копию изображения в памяти без всякого сохранения. Ну да, у нас размер плиток может разный быть, тогда взять какое-нибудь максимальное значение, скажем в пикселей 50. Хотя, если картинки в директории уже маленькие, то вопрос отпадает.
Картинки изначально размером 150х150 пикселей. Приложение ресайзит в 8 размеров от 10 до 100 пикселей.
Но в целом да, ничего не мешало. Улучшить саму генерацию мозаики точно можно.
Но в целом да, ничего не мешало. Улучшить саму генерацию мозаики точно можно.
Я не понял, почему в программах на одном ядре есть такая разница в производительности? Алгоритм же линеен и по сути только зависит от производительности процессора, а операций типа I/O на которых включается конкурентность особо и нет.
Не понимаю почему вас минусуют, замечание вполне уместное.
Мне тоже не ясна причина производительности с использованием go-рутин на 1 ядре. Ведь количество шагов, инструкций процессора будет одинаковым, без разницы в каком порядке будут выполнены go-подпрограммы и на какое количество псевдо-потоков разделится программный код.
В чем именно оптимизация пока непонятна, однако складывается ощущение, что автор недостаточно понимает смысл concurrency:
Мне тоже не ясна причина производительности с использованием go-рутин на 1 ядре. Ведь количество шагов, инструкций процессора будет одинаковым, без разницы в каком порядке будут выполнены go-подпрограммы и на какое количество псевдо-потоков разделится программный код.
В чем именно оптимизация пока непонятна, однако складывается ощущение, что автор недостаточно понимает смысл concurrency:
для того чтобы обрабатывать их одновременно.
Оптимизация по скорости может быть потому, что алгоритм утилизировал не все ресурсы процессора до того как его разбили на четыре части.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Веб приложение для генерации фотомозаики с легковесными потоками на Go