исходные функции vs написанные функции
Нет, не всегда
не всегда. смотри флуд от serezha про реализованную им string, котрая быстрее std::string
нет, их писали тоже люди.
код библиотек это не божественное откровение.
ты случайно не бот кохтпы?
код библиотек это не божественное откровение.
ты случайно не бот кохтпы?
Смотря на чём написаны эти исходные функции, и какие у тебя мозги+время.
Примеры:
1) PHP. Исходные функции, как ты не бейся, всегда будут быстрее написанных тобой, потому что во втором случае будет ещё добавляться какое-то время на их интерпретацию. То есть, даже если твоя функция до предела оптимизирована, и её C-код будет гораздо быстрее библиотечного, засчёт этой добавки от интерпретатора всё равно получится медленнее (насколько я понимаю).
2) C. Куча людей кучу времени писала стандартные функции. Если ты посидишь годик, сможешь написать аналог библиотечной функции с таким же временем работы. Ещё годик - твоя функция станет быстрее. Но нужно ли это?
2а) Исключение: смотришь в исходники библиотечных функций, и тебе просто в глаза бросается - "а вот тут вот можно всё оптимизировать, чтобы работало в десять раз быстрее!" Флаг тебе в руки. Только не забудь сначала понять, все ли последствия ты учёл, и будет ли твоя функция всегда работать так же, как и старая.
Примеры:
1) PHP. Исходные функции, как ты не бейся, всегда будут быстрее написанных тобой, потому что во втором случае будет ещё добавляться какое-то время на их интерпретацию. То есть, даже если твоя функция до предела оптимизирована, и её C-код будет гораздо быстрее библиотечного, засчёт этой добавки от интерпретатора всё равно получится медленнее (насколько я понимаю).
2) C. Куча людей кучу времени писала стандартные функции. Если ты посидишь годик, сможешь написать аналог библиотечной функции с таким же временем работы. Ещё годик - твоя функция станет быстрее. Но нужно ли это?
2а) Исключение: смотришь в исходники библиотечных функций, и тебе просто в глаза бросается - "а вот тут вот можно всё оптимизировать, чтобы работало в десять раз быстрее!" Флаг тебе в руки. Только не забудь сначала понять, все ли последствия ты учёл, и будет ли твоя функция всегда работать так же, как и старая.
Это ты сейчас написал про то, что зачастую константа у библиотечных функций меньше, чем у кода, написанного собственноручно. Есть еще вариант, когда ускорения можно добиться за счет смены алгоритма. Например, в Perl умножение длинных чисел (модуль, кажется называется BigInteger, но могу врать, т.к. 4 года прошло с тех пор, как имел дело с этим) реализовано "в столбик" с асимптотикой O(n^2). В то же время существуют алгоритмы перемножения чисел O(n log^2(n которые на числах длиной 1000 цифр и более дают заметное ускорение даже будучи написанными на интерпретируемом языке без какой-либо оптимизации с целью уменьшения константы.
Ну это всё-таки редкие случаи...
А как можно перемножить числа за o(n*lnn)? По идее, если их рассматривать как массив цифр, то надо рассматривать отдельно каждую пару ("цифра первого числа","цифра второго числа" т.к. каждая такая пара влияет на результат...
А как можно перемножить числа за o(n*lnn)? По идее, если их рассматривать как массив цифр, то надо рассматривать отдельно каждую пару ("цифра первого числа","цифра второго числа" т.к. каждая такая пара влияет на результат...
ты случайно не бот кохтпы?Нет, я бот БОГОМОЛА.
Твой пример укладывается в пункт 3 "исключение" и говорит о том, что не стоит доверять тяжелые программы кривой реализации Perl.
написал дело.
Реально не стоит полагать, что разработчики стандартной библиотеки — лохи (иначе зачем вообще пользоваться реализацией языка от лохов?). А это значит, что их код проверен и заоптимизирован достаточно хорошо, чтобы прикладные программисты занимались своим делом, а не переделывали библиотеку.
Стоит отметить один аспект. Оптимизация суть колдовство и оптимальный для Intel Pentium III код может сливать на Intel Pentium IV. Разрабочитчики стандартных функций далеко не всегда заморачиваются оптимизацией под разные архитектуры. Ты можешь выиграть, если тебе точно известно железо (размеры кешей и прочая фигня). Есть книжка Криса Касперски "Техника оптимизации программ. Эффективное использование памяти", там вот автор реально проработал эту тему.
Реально не стоит полагать, что разработчики стандартной библиотеки — лохи (иначе зачем вообще пользоваться реализацией языка от лохов?). А это значит, что их код проверен и заоптимизирован достаточно хорошо, чтобы прикладные программисты занимались своим делом, а не переделывали библиотеку.
Стоит отметить один аспект. Оптимизация суть колдовство и оптимальный для Intel Pentium III код может сливать на Intel Pentium IV. Разрабочитчики стандартных функций далеко не всегда заморачиваются оптимизацией под разные архитектуры. Ты можешь выиграть, если тебе точно известно железо (размеры кешей и прочая фигня). Есть книжка Криса Касперски "Техника оптимизации программ. Эффективное использование памяти", там вот автор реально проработал эту тему.
Ну это всё-таки редкие случаи...+1. И обычно это бывает, когда в библиотеку включают метод для какого-то нестандартного приложение и делается самая простая реализация, т.к. большую часть людей она устроит. Т.е. неоптимальный метод туда включен не потому что разработчики лохи (следуя терминологии . Идея: число рассматривается как полином над полем [0,1]. К двум числам (полиномам) применяется операция свертки (с помощью быстрого преобразования Фурье это делается за n ln n дальше умножаются компоненты и дальше обратное преобразование Фурье за то же время.
> 2) C. Куча людей кучу времени писала стандартные функции.
> Если ты посидишь годик
Достаточно заглянуть в исходники и увидеть, что можно ускорить почти все функции.
---
"Расширь своё сознание!"
> Если ты посидишь годик
Достаточно заглянуть в исходники и увидеть, что можно ускорить почти все функции.
---
"Расширь своё сознание!"
Т.е. неоптимальный метод туда включен не потому что разработчики лохи (следуя терминологии -а а потому что этот алгоритм для тех целей, где и не требуется быстрая работа на больших размерностях задачи.
Автор спрашивал про случай, когда функции используются для одинаковых целей. Если у тебя цели специфические (более узкие или немного в стороне от тех, что закладывали разработчики то да, есть дополнительное поле для оптимизации.
В противном случае отсутствие оптимизации стандартной функции говорит о сырости ее реализации.
Достаточно открыть специальную литературу и почитать, что
1. просто ускорить можно с n^2 до n * log n, в остальных случаях хорошо бы добавлять архитектуру, в терминах которой мы ускоряем.
2. правильно увидеть, где нужно подправить, чтобы ускорить, часто можно только с помощью измерений.
1. просто ускорить можно с n^2 до n * log n, в остальных случаях хорошо бы добавлять архитектуру, в терминах которой мы ускоряем.
2. правильно увидеть, где нужно подправить, чтобы ускорить, часто можно только с помощью измерений.
Оставить комментарий
Fofa
Всегда ли функции уже заданные в к-л языке программировангия (например, в DELPHI, не важно) работают быстрее функций, написанных на этом же языке собственноручно. (И та, и та функция выполняют ОДИНАКОВЫЕ задачи).