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

Современные компиляторы типа GCC и clang очень хорошо умеют автоматическую векторизацию. До такой степени, что в некоторых случаях разумной оптимизацией может быть противоположное — _отказ_ от интринсиков/асма и переписывание кода на чистый C, чтобы компилятор мог векторизовать циклы.

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

в некоторых случаях разумной оптимизацией может быть противоположное — _отказ_ от интринсиков/асма и переписывание кода на чистый C, чтобы компилятор мог векторизовать циклы.

+1

Два чая автору!

Ручная оптимизация - удел Про, коими 99% кодерочков точно не являются. Речь даже не о том, чтобы «знать где оптимизировать». А о том, что при оптимизации используется информация извне - физика, математика. Кодерочки не знают физ-мат в подавляющем большинстве.

Взять к примеру ФФТ тот же.

Тот, кто обладает ноу-хау, уже получает минимум 10 тонн зеленых, и не выложит в сеть «нахаляву». Зачем? Хотите знать - топайте в университеты.

А правда, что в наше время при некоторых задачах оптимизация более оправдана, чем покупка нового камня с over9000 ядрами?

да, правда.

все помнят, что менять местами целочисленные значения XOR'ом — это супрекруто и супероптимально

... было до изобретения конвейера.

Например, недавно я писал парсер для ручных заметок, и он хорошенько притормаживал, но после nytprof'а стало ясно, что нужно переразбить регэкспы на частичные матчи и т.о. направить хотспоты в самые активные ветки — и это было нетривиально и зависело от инпута. Ускорилось в разы.

Аналогично. Добавил в генератор статистики перед разбором по регэкспам тупую проверку на подстроку а-ля grep. Генерилось за 10-15 минут, теперь генерится за полминуты :)

Ручная оптимизация - удел Про, коими 99% кодерочков точно не являются. Речь даже не о том, чтобы «знать где оптимизировать». А о том, что при оптимизации используется информация извне - физика, математика. Кодерочки не знают физ-мат в подавляющем большинстве.

а физики/математики ничего и знать не желают, и не понимают очевидных вещей. Потому и формулируют задачи в терминах математического аппарата времён Исаака Ньютона.

Взять к примеру ФФТ тот же.

может БПФ или FFT? Что с ним не так?

А правда, что в наше время при некоторых задачах оптимизация более оправдана, чем покупка нового камня с over9000 ядрами?

да, правда.

пример?

Добавил в генератор статистики перед разбором по регэкспам тупую проверку на подстроку а-ля grep. Генерилось за 10-15 минут, теперь генерится за полминуты

а если-бы ты знал, КАК эти регэкспы работают, то у тебя сразу за 10 сек было. Но костыли конечно проще костылить.

Да? Ну соптимизируй это:

line =~ (/\002C(\d\d)0(\d\d)(\d\d)\s+(\S+)\s+C(\d\d)0(\d\d)(\d\d)\s+(\d+)\s+(\d\d)-(\d\d)-(\d\d)\s+(\d\d):(\d\d):(\d\d)\s+(\d+)\s+/)

в 10 раз быстрее без «костылей». Разбирать в несколько этапов нельзя, ибо «костыли».

Ну соптимизируй это: line =~ (/\002C(\d\d)0(\d\d)(\d\d)\s+(\S+)\s+C(\d\d)0(\d\d)(\d\d)\s+(\d+)\s+(\d\d)-(\d\d)-(\d\d)\s+(\d\d):(\d\d):(\d\d)\s+(\d+)\s+/)

что-то у тебя не то с regex'ами. Regex(7)(GNU) такое должна по любому быстрее любых костылей напрямую выполнять, если конечно ты догадался скомпилировать данное выражение.

Regex(7)(GNU) такое должна по любому быстрее любых костылей напрямую выполнять

Не знаю что это такое, регэкспы парсит стандартная библиотека Ruby. И с ней предварительная проверка строки менее тормозным способом ускоряет работу в десятки раз.

Видимо Руби компилит регэкспы по умолчанию. Что так, что эдак время выполнения одинаковое. И не сравнимо с изменением алгоритма aka костылём.

Не знаю что это такое, регэкспы парсит стандартная библиотека Ruby.

ну в этом и проблема наверное.

Потому и формулируют задачи в терминах математического аппарата времён Исаака Ньютона.

Чего было плохого в матаппарате Ньютона? :)

Ну попробуй оптимизируй ФФТ. Все либы типа ФФТВ - гуано, дерьмо полнейшее, не используют даже 50% процессора. Я уж не говорю об цлФФТ, который для опенЦЛ - там вообще даже не пахло 30% утилизации.

физики/математики ничего и знать не желают

Если физмат не пишет программы, в специализированном софте типа Математики, или просто в Си - неважно, он просто не имеет права ассоциировать себя как-то с наукой. И так уже 40 лет как.

Чего было плохого в матаппарате Ньютона?

он устарел.

Ну попробуй оптимизируй ФФТ.

зачем?

Все либы типа ФФТВ - гуано, дерьмо полнейшее, не используют даже 50% процессора.

С чего ты это взял и как посчитал?

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

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

И да, ты там говорил про 30% - расскажи мне как ты посчитал теоретическую производительность для своего ффт.