Веб приложение для генерации фотомозаики с легковесными потоками на Go

[UnickSoft]

Я смотрю, что работа с пикслеми проводится во float-ах. Не знаю как в Go, но вот в C++ перевод такого же кода на целые числа дал бы существенный прирост производительности.

[Pryada]

Сначала подумал, что это ограничение стандартной библиотеки, но я посмотрел, там везде int да uint. Не знаю как обосновать выбор автора. Если ответит мне в фейсбуке, то задам ему этот вопрос.
Наверняка с целыми числами будет быстрей.

[gentee]

А мне вот какой вопрос не понятен. Разве не логично применять average не к оригинальным картинкам из директории, а в начале уменьшить их до размера плиток, а затем уже считать средний цвет. Мне кажется в этом случае картинки более качественно подбираться будут.

[Pryada]

Для этого пришлось бы создавать несколько новых директорий, сохранять там результат изменений, хранить усреднённые цвета в разных отображениях. Или просто с префиксом генерировать уменьшенные картинки в ту же директорию, тогда всё бы помещалось в уже созданное отображение, но непомерно увеличивало бы его.
Это всё ещё раздуло бы эту статью, а в ней и так около 20 страниц текста.

Задача статьи — показать как с помощью Го ускорить приложение, добавив немножко горутин.

[gentee]

Статья полезная, мне понравилась, но кто мешал автору перед вычислением average сделать уменьшенную копию изображения в памяти без всякого сохранения. Ну да, у нас размер плиток может разный быть, тогда взять какое-нибудь максимальное значение, скажем в пикселей 50. Хотя, если картинки в директории уже маленькие, то вопрос отпадает.

[Pryada]

Картинки изначально размером 150х150 пикселей. Приложение ресайзит в 8 размеров от 10 до 100 пикселей.

Но в целом да, ничего не мешало. Улучшить саму генерацию мозаики точно можно.

[vladkens]

Я не понял, почему в программах на одном ядре есть такая разница в производительности? Алгоритм же линеен и по сути только зависит от производительности процессора, а операций типа I/O на которых включается конкурентность особо и нет.

[dblokhin]

Не понимаю почему вас минусуют, замечание вполне уместное.
Мне тоже не ясна причина производительности с использованием go-рутин на 1 ядре. Ведь количество шагов, инструкций процессора будет одинаковым, без разницы в каком порядке будут выполнены go-подпрограммы и на какое количество псевдо-потоков разделится программный код.

В чем именно оптимизация пока непонятна, однако складывается ощущение, что автор недостаточно понимает смысл concurrency:

для того чтобы обрабатывать их одновременно.

[divan0]

Не сильно понял ваше удивление. Есть 4 горутины, которые в случае 1 ядра выполняются *по-факту* последовательно, в случае нескольких — разбрасываются шедулером на несколько ядер и выполняются параллельно. 4-х кратное ускорение вполне логично.

UPD. Или я неверно понял, что именно удивляет?

[vladkens]

Судя по тексту автор гонял код на одном ядре:

… базовое приложение генерировало мозаику за 2,25 секунды, а конкурентная реализация выполняет то же самое в четыре раза быстрее, за 646 миллисекунды.

Внимательный читатель мог отметить, что оба веб приложения запускаются лишь на одном ядре процессора.

[M0sTH8]

Оптимизация по скорости может быть потому, что алгоритм утилизировал не все ресурсы процессора до того как его разбили на четыре части.