LINUX.ORG.RU

Нужность эффективных алгоритмов

 


2

4

У меня на работе большинство разработчиков негативно относятся к усложнениям алгоритмов. Например вместо глупого перебора среди нескольких ГБ данных использование специализированых структур данных вызывает бурю негодования. Аргументы следующие: алгоритм запускается раз в неделю и ускорение с 1 часа, до 3 мин ничего не меняет, но усложняет поддержку и понимание. Зато кто из среднестатистических сениоров в нашем ущербном перегретом рынке знает дальше ArrayList и HashMap? Суффиксные деревья, триграммы, 100 строчечные geospatial индексы пугают людей, ибо написаны вручную, а максимум что дозволено - интегрировать какой-то фреймворк. Доки умеют читать все. Я велосипедист и не нужен.

Не будучи категоричным «быдлокодеры не нужны», в их аргументах есть здравый смысл. Действительно, задача не критична по скорости и нормально будет приносить деньги даже в простейшей реализации. Зато любой дебил поймет что происходит и сможет что-то исправить в будущем. Я с их стороны могу так же подписаться под каждым словом.

Насколько у вас развито ощущение того, что код нужно писать правильно и эффективно просто потому что код нужно писать правильно и эффективно?

★★☆☆☆

ускорение с 1 часа, до 3 мин ничего не меняет, но усложняет поддержку и понимание

Не все так однозначно. Когда есть какие-то ошибки в этом «простом» коде, то на воспроизведение ситуации может уходить до часа времени. Тогда как с 3 мин можно быстрее воспроизвести и понять в чем проблема.

kamre ★★★ ()
Ответ на: комментарий от kamre

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

vertexua ★★☆☆☆ ()

код нормально комментировать и документировать просто надо. а всем это делать лень. некоторым доки писать - вообще как серпом по яйцам. вот и пытаются делать вариант «программа хорошо документирована на языке программирования c++»

ananas ★★★★★ ()

Насколько у вас развито ощущение того, что код нужно писать правильно и эффективно просто потому что код нужно писать правильно и эффективно?

На 9 из 10. Но критерий «правильности и эффективности» варьируется.

tailgunner ★★★★★ ()

От задачи же зависит.

Если это поделие на коленке/что то тошнотворное, вызывающие омерзение/жуткий цейтнот - то работаешь в стиле «сделал и забыл», там не до красивостей.

Если это произведение искусства, «для себя» - то конечно ищешь оптимальное решение не считаясь с затратами времени на поиск. Тут важен процесс, а не результат;-)

AIv ★★★★★ ()

Ни насколько.

Для начала нужно написать правильно, но совершенно необязательно эффективно. Конечно, явных глупостев тоже лучше не делать, но зачастую обычный вектор будет лучше всяких КЧ-деревьев.

Затем, если будут тормоза, можно переписать какие-то места эффективно, но совершенно необязательно правильно. Заменить один массив на КЧ-дерево, остальные не трогать.

Miguel ★★★★★ ()

Это бизнес, детка. Если ты работаешь на НИИ или университет, пишешь софт для ресерчеров, то конечно, алгоритмы надо юзать на 100%, а если пылишься в подвале у ОАО, где менеджеры по продажам срубают зарплату в 15 раз превышающую твою, то сиди, пиши как будет быстрее, компилируй и продавай.

Печально, но факт.

unt1tled ★★★★ ()

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

unanimous ★★★★★ ()

А на собеседованиях-то и в резуме обычно «Advanced algorithms understanding is an advantage». А потом сидишь и пишешь фабрики фабрик.

cdshines ★★★ ()

Насколько у вас развито ощущение того, что код нужно писать правильно и эффективно просто потому что код нужно писать правильно и эффективно?

Наверное, надо убить в себе перфекциониста.

Вспомнилось. Надо было вытащить данные из кучи html'ок. За час написался скрипт с использованием BeautifulSoup, четыре часа заняла вся обработка. Итого пять часов. Как ни крути, это оказался самый быстрый вариант, несмотря на python и однопоточность.

индексы пугают людей, ибо написаны вручную, а максимум что дозволено - интегрировать какой-то фреймворк

Доверия нет? А фреймворк — это «надёжно».

i-rinat ★★★★★ ()

Всё верно говорят.

Нужна взаимозаменяемость мартышек.

Bad_ptr ★★★ ()
Ответ на: комментарий от unanimous

А иногда по мере модификации оптимизация приводит к лишним тормозам.

AIv ★★★★★ ()
Ответ на: комментарий от swwwfactory

Эта цитата очень хороша для того, чтобы отмазаться за быдлокод.

tailgunner ★★★★★ ()

Потому что ты эстетствуешь, а они деньги зарабатывают.

vasilenko ★★ ()
Ответ на: комментарий от tailgunner

доводы:

код имеет мало практической пользы без данных и ценности с т.з. потребителя т.е. конечного пользователя

отмазаться можно другими путями...

swwwfactory ★★ ()

Если быстродействие некритично, то прозрачность кода всегда имеет приоритет.

geometer ()
Ответ на: комментарий от swwwfactory

код имеет мало практической пользы без данных и ценности с т.з. потребителя т.е. конечного пользователя

И что? Более-менее сложные данные без кода тупо бесполезны.

отмазаться можно другими путями...

Я и не говорил, что это единственный.

tailgunner ★★★★★ ()

Читаемость кода не нужна.

Запускается? Шикарно. Делает то, что нужно? Просто чудесно!

makyrros ()

Аргументы следующие: алгоритм запускается раз в неделю и ускорение с 1 часа, до 3 мин ничего не меняет, но усложняет поддержку и понимание.

А вот срочно подоткнуть в работающий ворксшейшен 32 гига оперативки уже малость проблематично.

DNA_Seq ★★★☆☆ ()
Ответ на: комментарий от ananas

вот и пытаются делать вариант «программа хорошо документирована на языке программирования c++»

Тут еще всплывает такая область для холивара «эффективные алгоритмы на скриптовых языках vs тупые алгоритмы на с++/java»

DNA_Seq ★★★☆☆ ()

это пост о здравом смысле

subwoofer ★★★★★ ()

Насколько у вас развито ощущение того, что код нужно писать правильно и эффективно просто потому что код нужно писать правильно и эффективно?

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

alienclaster ★★ ()

При таком раскладе, я бы не трогал..

vromanov ★★ ()
Ответ на: комментарий от DNA_Seq

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

subwoofer ★★★★★ ()
Ответ на: комментарий от alienclaster

Совсем не факт что читабельный и неоптимизированный код легче масштабировать. Например такой код вполне может оказаться однопоточным by design или очень прожорливым в плане оперативки.

DNA_Seq ★★★☆☆ ()

в этом же и есть мастерство - создавать программу с такими свойствами, с какими нужно.

с другой стороны, механизм всегда можно спрятать под интерфейс, а интерфейс сделать понятным... типа sort, сразу понятно что делает, а как он это делает на понимания общей картины не влияет.

Например вместо глупого перебора среди нескольких ГБ данных использование специализированых структур данных вызывает бурю негодования.

сделай интерфейс find и меняй как знаешь.

dimon555 ★★★★★ ()

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

Есть общее правило: выигрывая в малом, обычно проигрываем в большом, и наоборот. Поэтому не всегда стоит заморачиваться на тех оптимизациях, которые не дадут большого выигрыша в целом.

dave ★★★★★ ()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от DNA_Seq

Совсем не факт что читабельный и неоптимизированный код легче масштабировать

Я указал, что код должен быть масштабируемым - это предполагает наличие какой-никакой архитектуры.

Например такой код вполне может оказаться однопоточным by design

Если это небольшой по объему код - переписать его легко, а для большого кода с вероятностью 99% придется писать свою систему распараллеливания, если не подходят какие-то стандартные юзкейсы - типа там clojure, mpi итд.

или очень прожорливым в плане оперативки.

Современный декларативный код практически всегда таким будет. Поэтому изначально прописываю ТЗ «с запасом», и предполагают отступные варианты - т.е. как например в случае большого потребления ресурсов из няшного но тормознутого кода, не переписывая все нафиг, получить быстрый императивный код желательно на том же высокоуровневом языке.

alienclaster ★★ ()
Ответ на: комментарий от AIv

Если это произведение искусства, «для себя» - то конечно ищешь оптимальное решение не считаясь с затратами времени на поиск. Тут важен процесс, а не результат;-)

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

vertexua ★★☆☆☆ ()
Ответ на: комментарий от i-rinat

За час написался скрипт с использованием BeautifulSoup, четыре часа заняла вся обработка. Итого пять часов. Как ни крути, это оказался самый быстрый вариант, несмотря на python и однопоточность.

А регекс в grep?

Доверия нет? А фреймворк — это «надёжно».

Надебагался я уже этих надежных вреймворков.

vertexua ★★☆☆☆ ()
Ответ на: комментарий от vasilenko

Потому что ты эстетствуешь, а они деньги зарабатывают.

Деньги зарабатывают другие люди, а они программисты и я с ними работаем за зп

vertexua ★★☆☆☆ ()
Ответ на: комментарий от geometer

А отвращение к коду? Потом мне надоест писать говнокод, я свалю и бизнес пострадает на денежку для поиска нового человека

vertexua ★★☆☆☆ ()
Ответ на: комментарий от DNA_Seq

Да, у меня тут недавно dict из Python обогнал красно-черное дерево на C. Просто потому что хеш-мапа вместо сбалансированого дерева и хешу везло

vertexua ★★☆☆☆ ()
Ответ на: комментарий от alienclaster

Для меня еще самая естественная структура данных - часто залог корректности. Другое дело что многим нужно краткую лекцию прочитать о этой структуре данных

vertexua ★★☆☆☆ ()
Ответ на: комментарий от alienclaster

Если это небольшой по объему код - переписать его легко, а для большого кода с вероятностью 99% придется писать свою систему распараллеливания, если не подходят какие-то стандартные юзкейсы - типа там clojure, mpi итд.

Серьезные алгоритмисты обычно не сильно полагаются на распаралеливание, Скиенна об этом прямо говорит. Идеально паралельный алгоритм ускоряется в два раза при покупке второй машины. Но поменяв «O» можно что-то ускорить в 1000 раз. Готовы купить тысячу машин? Естественно разговор имеет смысл дествительно если параллелизм требует слишком большого количества машин

vertexua ★★☆☆☆ ()
Ответ на: комментарий от vertexua

Зачем же каждому? Только тем, кто имеет к этому отношение (должен копаться в кишках алгоритма). Если таких людей много (а два это число много большее единицы), то у вас явный косяк с декомпозицией задачи.

И по скромному личному опыту - простые решения самые правильные. Т.е. какие нить хитровыкрученные деревья не имеют существенных преимуществ перед обычным rb-tree или дихотомией. KISS!

В интересных задачах создание новго кода это очень прикольно и доставляет эстетическое наслаждение, но код это всего лишь молоток. Интересны результаты, получаемые с помощью кода.

AIv ★★★★★ ()

на задачу есть тз, в тз прописано какое время должно чего работать либо явно либо косвенно. если данные временные промежутки соблюдены и всё работает, то не трогай - иди покури. если нет, то надо «усложнять алгоритмы».

а так в российских реалиях код должен быть максимально простым, по одной причине - постоянно меняющиеся требования. вот когда ты напишешь (или только начнешь писать) супер друпер оптимально, а завтра к тебе придут и скажут, что «концепция поменялась» и надо не то что описано, а кое что совсем другое и это надо уже вчера, вот тогда то и поймешь сию простую истину. :) ибо в простой код костыли по быстрому вставлять намного легче чем в алгоритмы.

vtVitus ★★★★★ ()
Последнее исправление: vtVitus (всего исправлений: 1)

Никак. Я сам не программист, для меня программирование - просто инструмент. Видимо, поэтому легко не поддаваться перфекционизму.

В данном случае я бы рассуждал так - глупый перебор укладывается в требования по времени, не нуждается в длительном написании/отладке/тестировании, значит он годится. Конечно, можно прикинуться олдфагом и оптимизировать производительность с ассемблером в зубах, но свое время тоже дорого.

lu4nik ★★ ()
Ответ на: комментарий от vertexua

Другое дело что многим нужно краткую лекцию прочитать о этой структуре данных

Так прочти, не?

alienclaster ★★ ()
Ответ на: комментарий от vertexua

Серьезные алгоритмисты обычно не сильно полагаются на распаралеливание

Это ты байки какик-то задвигаешь.

Скиенна об этом прямо говорит.

Кого е^W волнует, что он там говорит?

Идеально паралельный алгоритм ускоряется в два раза при покупке второй машины.

У нас тут в каждой машине по 4 ядра, ничего покупать не нужно - чтобы ускорить алгоритм в 3-4 раза.

Но поменяв «O» можно что-то ускорить в 1000 раз.

Зависит много от чего: от объема данных, от типа задачи (параллелизм на тяжелых вычислениях или конкурентность на легких), от степени высокоуровневости языка.

Готовы купить тысячу машин? Естественно разговор имеет смысл дествительно если параллелизм требует слишком большого количества машин

Имеет смысл параллелить даже на одной машине, потом оптимизировать алгоритмы, дальше уже думать о кластерах мета^W.

alienclaster ★★ ()
Ответ на: комментарий от vertexua

А регекс в grep?

Это оказалось не очень надёжно, в некоторых случаях лажает, даже если на 10 случайно выбранных всё хорошо. А с парсерами DOM проще: если сработало на двух-трёх, сработает и на 10000. Плюс склонность python бросаться исключениями исключает явные пропущенные ошибки.

i-rinat ★★★★★ ()
Ответ на: комментарий от vertexua

Были другие разы, с другими данными. (Недавно узнал, что это теперь называется data science.) Тогда я знал немного php и немного regexp'ов. Поэтому это были cli скрипты на php (не знаю, чего его все так ненавидят, вполне приемлемый инструмент).

Кстати, тебе может ещё и повезло. Представь другую ситуацию: ты пишешь понятный код, а тебе указывают, что нужно многое поменять, причём замены не по сути алгоритмов, а всякие мелочи типа склеивания строк в одну, чтобы рядом были и в кэш влезали, переупорядочивание полей в структуре, замена массива структур на несколько массивов или наоборот, замена небольших деревьев на простые массивы, ибо последовательное сканирование лучше ляжет в кэш и тому подобное. Ты всё меняешь, и в результате твой красивый код превращается в нагромождение костылей, но тем не менее работает на 5-10% быстрее. И его страшно трогать.

i-rinat ★★★★★ ()
Ответ на: комментарий от vertexua

Не понял. Отвращение к прозрачному коду? Или к тормозному? Что ты имеешь в виду?

geometer ()
Ответ на: комментарий от geometer

К тормозному, когда есть быстрый и элегантный

vertexua ★★☆☆☆ ()
Ответ на: комментарий от i-rinat

работает на 5-10% быстрее

Насколько я понимаю, топик о выигрышах в разы.

tailgunner ★★★★★ ()
Ответ на: комментарий от i-rinat

скрипты на php (не знаю, чего его все так ненавидят

Ну, для скриптов-то можно использовать что угодно: написал и выбросил. В случае пхп этот процесс (особенно фаза «выбросил») должен наверное приносить даже чуть больше удовольствия, чем обычно :P

alienclaster ★★ ()
Ответ на: комментарий от tailgunner

После выигрыша в разы может быть выигрыш в 5%. Это две крайности; неизвестно, какая хуже.

i-rinat ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.