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

кто такие?

Ты же спрашивал, что будет если вдруг другой камень, Да не оптимально, но будет работать. Если очень приспичит, то можно обратиться к разработчику, если он все еще ведет проект. Если твоя личная мулька, то запили сам. Прям вода какая-то, а не разговор.

Нет, не нахожу. Если минута - вполне достаточная скорость выполнения для этой задачи, то зачем делать быстрее? Лучше улучшить какие-то другие параметры. Меньше оптимизаций - меньше кода, код понятнее, приложение в целом более поддерживаемо.

Я бы очень хотел посмотреть на полового гиганта, который способен под Itanium и прочие EPIC на ассемблере писать более быстрый код, чем тот что выдаёт компилятор.

Ты что-то имеешь против умения составлять эффективные алгоритмы?

Оптимизировать на асме в 99% случаев бесполезно

слово «асм» тут лишнее.

Лишнее, если ты - кодогенератор за бабло.
А если пишешь софт для людей, то нифига подобного.

Один регистр сэкономился (edx). Это способ оптимизации используемой памяти же.

а что, этот регистр теперь жрать энергию не будет? Место занимать? Или у тебя есть x86 без edx? Или что-то другое будешь хранить? Что конкретно?

В большинстве случаев в тормознутости современного софта виноваты алгоритмы.

практически во всех случаях тормознутость современного софта - миф.

нет, не миф. Проблема не в плохих алгоритмах, а в НЕ ТЕХ алгоритмах. Не нужно забывать о том, что пузырёк в некоторых случаях лучше qsort.

Кто сказал, что нет куска который будет работать на большинстве?

работать конечно будет... Как говно. Попробуй например выполнить код i8086 на своём компе.

Мы на портале о линукс и гну, денежная сторона вопроса мало должна волновать.

тебе здесь никто ничего не должен.

И вот в 201х появляется новая хайскалабилити хайавалабалити энтерпрайз вундервафля на до-диез++, весит как полагается годному софту пару десятков мегабайт, работает над этой же задачей эту же минуту на топовом i7,

ничего, что в первом случае база данных была в 100Мб, а во втором в 100Гб?

И вот в 201х появляется новая хайскалабилити хайавалабалити энтерпрайз вундервафля на до-диез++, весит как полагается годному софту пару десятков мегабайт, работает над этой же задачей эту же минуту на топовом i7,

ничего, что в первом случае база данных была в 100Мб, а во втором в 100Гб?

...И что на разработку первого ПО ушло 6 человеко-месяцев работы высокооплачиваемых опытных кодеров, а для второй потребовалось 6 человеко-месяцев студентов-практикантов?

Ты можешь объяснить, зачем делать софт быстрее, чем необходимо? Какой смысл в том, что твоя программа «для людей» будет складывать числа за миллисекунду, а не за секунду?

http://en.wikipedia.org/wiki/Analysis_of_algorithms тоесть это говно мамонта ? Или тебя опять неправильно поняли?

да неправильно, речь о конкретном кодировании, а не о алгоритмах в сферическом вакууме. Повторяю: IRL бывает и пузырёк быстрее qsort'а. А теорию надо знать не просто так, а для применения к конкретной ситуации.

ничего, что в первом случае база данных была в 100Мб, а во втором в 100Гб?

Та же задача. Одна и та же.

Ты что-то имеешь против умения составлять эффективные алгоритмы?

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

Кроме того надо помнить, что «глупый» алгоритм вовсе не обязательно «глупый». Достаточно вспомнить BWT, который всех изрядно веселил в 80х(настолько, что автор даже постеснялся его публиковать).

Лишнее, если ты - кодогенератор за бабло. А если пишешь софт для людей, то нифига подобного.

ты не прав. Людям нужны фичи, и ускорение на 5% — тоже фича. Нужная, но НЕ самая нужная. Это с точки зрения твоих пользователей так, я спрашивал.

Ты можешь объяснить, зачем делать софт быстрее, чем необходимо? Какой смысл в том, что твоя программа «для людей» будет складывать числа за миллисекунду, а не за секунду?

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

откуда мне знать, что для тебя «та же задача»? Явно первая программа выполнялась на монохромном мониторе, который умел только текст, оперативки было 64К(ты хоть ПРЕДСТАВЛЯЕШЬ, сколько ЭТО?!), и HDD на 20Мб, который ты делил с ещё Over9000 юзерами.

Битовые операции со знаковыми целыми сами по себе - не UB.

Сдвиги со знаковыми - UB. Но XOR все же не UB, тут я ошибся.

*a ^= *b; *b ^= *a; *a ^= *b;

Тут же UB.

нет

Посыпаю голову пеплом, попутал со сдвигами.

ты хоть ПРЕДСТАВЛЯЕШЬ, сколько ЭТО?!

мало того, что представляю, так еще и спекки с c64 ковырял.

Явно первая программа выполнялась

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

а что, этот регистр теперь жрать энергию не будет?

Неграмотный лапоть опять имеет наглость иметь мнение? Ты не догадываешься, что регистр тратит энергию только когда меняется его значение?

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

это называется «масштабирование».

масштабирование тут не при чем, ты невнимательно читаешь

Потому асимптотический анализ алгоритмов следует применять осторожно и с оглядкой на RL.

ЕМНИП, асимптотический анализ показывает рост зависимость роста числа операций от количества входных данных. И для большого объема входных данных он таки эффективен. Правда, прежде, чем радостно его (алгоритм, не анализ) применять, стоит посмотреть, как минимум, сколько памяти отъест реализация. Если у тебя количество входных элементов маленькое, а вот каждый элемент - здоровый, то медленный алгоритм, не использующий доп. память, будет эффективней.

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

define «глупый алгоритм». А то я не распарсил.

Почему современная программа с железом на порядок более мощным работает за то же время?

Потому что ей нету смысла работать быстрее. А в чем проблема?

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

Ну и сколько потратит D-type flip-flop за один цикл простоя? Разница будет в пару порядков с затратами на изменение значения.

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

мало того, что представляю, так еще и спекки с c64 ковырял.

я тоже ковырял. Написал отладчик, ассемблер и дизассемблер. И ещё нарастил до 512и.

Почему современная программа с железом на порядок более мощным работает за то же время?

потому что данных НАМНОГО больше. Сейчас тебе кнопочка из 100 точек не понравится, это не ZX. Тебе минимум нужно 100×100, да чтоб SVG с анимацией! Ты никогда не задумывался о том, что в такой кнопочке как минимум в 100000 раз больше информации? Сегодня один UI весит Over9000 килобайт, причём убогий, на уровне Win95.

Потом слои абстракции, которых сейчас тупо больше.

Ты не догадываешься, что регистр тратит энергию только когда меняется его значение?

ну напиши программу которая делает ТОЛЬКО inc rax 9`223`372`036`854`775`808 раз, и посмотри, как у тебя медленно батарейка садится.

ты невнимательно читаешь

нет ты. Для тебя я там написано: иди в ☣.

ЕМНИП, асимптотический анализ показывает рост зависимость роста числа операций от количества входных данных.

верно.

И для большого объема входных данных он таки эффективен

да. Вот только там не объясняется, что такое «большие».

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

а вот это как раз там есть: память — тоже ресурс, не только время можно считать. Обычно считают и то и другое. Ну например qsort жрёт O(N²)≥T≥O(Nlog(N)) времени и M=O(Nlog(N)) памяти. (если данные любые, а алгоритм оптимальный).

define «глупый алгоритм». А то я не распарсил.

«глупый» это тот, который по твоему «жрёт много ресурсов». Одним словом. Вот как BWT например жрёт ресурсов больше, чем все компьютеры Мира вместе взятые. Это «много». Потому BWT глупый и не нужный. Как и ПО с ним, bzip2 например.

Тебе минимум нужно 100×100, да чтоб SVG с анимацией!

Нет, не нужно. Да почти никому не нужно, кроме продаванов.

в такой кнопочке как минимум в 100000 раз больше информации?

Переборщил на 5 порядков.

Сегодня один UI весит Over9000 килобайт, причём убогий, на уровне Win95.

потому что ООП и фреймворки, потому что скорость разработки важнее скорости софта.

Нет, не нужно. Да почти никому не нужно, кроме продаванов.

юзерам нужно. Тем, кто готов платить бабло. Мнение остальных юзеров(как и самих программистов) всем до☣.

скорость разработки важнее скорости софта.

ты диванный теоретик. IRL если у тебя низкая скорость, то твоего софта тупо НЕ БУДЕТ.

Вот только там не объясняется, что такое «большие».

Тем не менее, можно вполне обоснованно предположить, что с ростом объема входных данных время работы одного алгоритма растет медленнее, чем второго.

а вот это как раз там есть: память — тоже ресурс, не только время можно считать

Ну ОК, пусть можно.

«глупый» это тот, который по твоему «жрёт много ресурсов»

«Жрёт много ресурсов» - это не «глупый», это надо посмотреть, что за ресурсы жрет.

Тем не менее, можно вполне обоснованно предположить, что с ростом объема входных данных время работы одного алгоритма растет медленнее, чем второго.

ну да. И при объёме данных в Over9000 петабайт второй аллгоритм станет быстрее. Или при объёме в 9 байт. Ответа нет. Нужны константы пропорциональности, а именно их мы и отбросили для упрощения анализа этим способом.

Ну ОК, пусть можно.

ещё и нужно, и все это считают. Правда это менее популярно почему-то. Не знаю почему.

«Жрёт много ресурсов» - это не «глупый», это надо посмотреть, что за ресурсы жрет.

да пофиг что. Ну конкретно BWT жрёт памяти немерено. Больше, чем у тебя есть. Впрочем, времени он тоже жрёт вечность. Там кстати асимптота сортировки(по времени) O(N²log(N)) при N в несколько миллионов(меньше нет смысла). Можно путём постфиксной сортировки снизить время до O(Nlog²(N)), это в теории лучше, но на практике это медленнее в разы.

Ну ОК, пусть можно.

и да, из этого вашего анализа есть интересный вывод: константой является произведение асимптот памяти и времени. Т.е. это значит, что программист может сделать:

1. алгоритм, который жрёт Over9000 памяти и работает быстро
2. алгоритм который жрёт мало памяти, но работает вечность
3. алгоритм который работает долго и жрёт много. Но более-менее.

Это если конечно программист будет стараться.

Обычно реализуют №3, и потом пихают его во все дыры.

Нужны константы пропорциональности, а именно их мы и отбросили для упрощения анализа этим способом.

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

ещё и нужно, и все это считают. Правда это менее популярно почему-то. Не знаю почему.

Ничего не скажу тебе по этому поводу, ибо в работе мне это не требуется вообще. Потому, что не программер.

Ну конкретно BWT жрёт памяти немерено.

Видимо, для малых объемов он эффективен.

Я одного понять не могу. Почему алгоритмы с хорошей асимптотой - говно мамонта?

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

данные известны. Обычно полагают, что если на входе 3 бита, то допустимы следующие комбинации:

1. 000
2. 001
3. 010
4. 011
5. 100
6. 101
7. 110
8. 111

и вероятность каждой комбинации равна ⅛.

ещё и нужно, и все это считают. Правда это менее популярно почему-то. Не знаю почему.

Ничего не скажу тебе по этому поводу, ибо в работе мне это не требуется вообще. Потому, что не программер.

ну вот а мне не повезло...

Видимо, для малых объемов он эффективен.

нет. Для малых объёмов он тоже неэффективен. Как неэффективен Камаз для перевозки ОДНОЙ пачки сигарет.

Я одного понять не могу. Почему алгоритмы с хорошей асимптотой - говно мамонта?

сами алгоритмы вечные. Они существуют объективно, мы их открываем как законы природы вроде E=mc². «Говно мамонта» — устаревшие книжки, в которых рассказывают, как правильно выбирать и надевать хомут на кобылу, если речь идёт про транспорт. Но это никак не опровергает сами физические законы, которые действуют и на кобылу, и на любой другой транспорт.

Это было сказано про первый пост и про «современные компиляторы» оттуда.

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

Его надо в клетку посадить и людям показывать

Зойчем? Он же и сам прекрасно с этим справляется. Сидит и показывает.

Там кстати асимптота сортировки(по времени) O(N²log(N)) при N в несколько миллионов(меньше нет смысла). Можно путём постфиксной сортировки снизить время до O(Nlog²(N)), это в теории лучше, но на практике это медленнее в разы.

Это как ? http://www.wolframalpha.com/share/clip?f=d41d8cd98f00b204e9800998ecf8427elua4...

Батти - это леденящий душу ☣ц. Его надо в клетку посадить и людям показывать, чтоб знали, насколько низко можно пасть, насколько невменяемым * может быть человек.

спасибо. Я как завещание буду писать, попрошу своих внуков это на моём могильном камне выбить.

Это как ? http://www.wolframalpha.com/share/clip?f=d41d8cd98f00b204e9800998ecf8427elua4...

ты совсем тупой? Возьми что-ли ручку с бумажкой...

Прекрати, пожалуйста, позориться.

Выучи разницу между implementation defined и UB

Хотя вижу, что ты исправился. Предъявы отозваны.

Компилятор гораздо лучше среднестатистического программиста.

Но если у тебя 20 лет опыта на асме и ты наизусть знаешь даташиты по ЦПУ, то компилятор с тобой не сравнится