Pryada Jul 21 2015 at 08:53

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

15 min

12K

Programming*Go*

Translation

+26

Comments 12

UnickSoft Jul 21 2015 at 11:49

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

Pryada Jul 21 2015 at 14:14

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

gentee Jul 21 2015 at 13:28

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

Pryada Jul 21 2015 at 13:41

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

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

gentee Jul 21 2015 at 14:05

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

Pryada Jul 21 2015 at 14:21

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

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

UFO just landed and posted this here

vladkens Jul 21 2015 at 23:45

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

dblokhin Jul 22 2015 at 05:50

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

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

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

divan0 Jul 23 2015 at 18:15

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

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

vladkens Jul 23 2015 at 19:53

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

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

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

M0sTH8 Jul 23 2015 at 20:21

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

Show the best of all time