Функциональные языки являются по сути медленными? [закрытый]
Решение Herer:
/**
* Tests two data structures for equality
* @param {object} x
* @param {object} y
* @returns {boolean}
*/
var equal = function(x, y) {
if (typeof x !== typeof y) return false;
if (x instanceof Array && y instanceof Array && x.length !== y.length) return false;
if (typeof x === 'object') {
for (var p in x) if (x.hasOwnProperty(p)) {
if (typeof x[p] === 'function' && typeof y[p] === 'function') continue;
if (x[p] instanceof Array && y[p] instanceof Array && x[p].length !== y[p].length) return false;
if (typeof x[p] !== typeof y[p]) return false;
if (typeof x[p] === 'object' && typeof y[p] === 'object') { if (!equal(x[p], y[p])) return false; } else
if (x[p] !== y[p]) return false;
}
} else return x === y;
return true;
};
Работает с любой вложенной структурой данных и, очевидно, игнорирует методы объектов. Даже не думайте о расширении Object.prototype с помощью этого метода, когда я это пробовал один раз, jQuery сломался;)
Для большинства массивов он все же быстрее, чем большинство решений для сериализации. Вероятно, это самый быстрый метод сравнения для массивов записей объектов.
9 ответов
Ничто - по сути ничто. Вот пример, где интерпретировал , OCaml работает быстрее, чем эквивалентный код C , потому что оптимизатор OCaml имеет другую информацию в наличии для него, из-за различий в языке. Конечно, было бы глупо предъявить общую претензию, что OCaml категорически быстрее, чем C. Точка, она зависит от того, что Вы делаете, и как Вы делаете это.
Тем не менее OCaml является примером (главным образом) функционального языка, который на самом деле разработан для производительность , в отличие от чистоты.
Функциональные языки требуют устранения изменяемого состояния, которое видимо на уровне абстракции языка. Поэтому данные, которые были бы видоизменены на месте императивным языком, должны быть скопированы вместо этого, с мутацией, происходящей на копии. Для простого примера посмотрите быструю сортировку в Haskell по сравнению с C.
, Кроме того, сборка "мусора" требуется, потому что free() не чистая функция, поскольку она имеет побочные эффекты. Поэтому единственный путь к свободной памяти, которая не включает побочные эффекты на уровне абстракции языка, со сборкой "мусора".
, Конечно, в принципе, достаточно умный компилятор мог оптимизировать большую часть этого копирования. Это уже сделано до некоторой степени, но создание компилятора, достаточно умного для понимания семантики кода на том уровне, просто трудно.
Короткий ответ: потому что C быстр. Как в, ослепительно смехотворно сумасшедший быстрый . Язык просто не должен быть 'медленным' для получения его задней части, врученной ему C.
причина, почему C быстр, состоит в том, что он был создан действительно великими кодерами, и gcc был оптимизирован в течение пары большего количества десятилетий и десятками более блестящих кодеров, чем 99% языков там.
Короче говоря, Вы не собираетесь побеждать C за исключением специализированных задач, которые требуют очень определенных конструкций функционального программирования.
C быстр, потому что это - в основном ряд макросов для ассемблера :) Существует не "позади сцены", когда Вы пишете программу в C. Вы память выделения, когда Вы решаете, что пора сделать, это и Вы освобождает тем же способом. Это - огромное преимущество, когда Вы пишете приложение реального времени, где predictabily важен (больше, чем что-либо еще, на самом деле).
кроме того, компиляторы C обычно чрезвычайно быстры, потому что сам язык прост. Это даже не делает проверок типа :) Это также означает, что это легче сделать трудно для нахождения ошибок. Преимущество рекламы с отсутствием проверки типа состоит в том, что имя функции может просто быть экспортировано с его именем, например, и это заставляет C кодировать легкий связаться с кодом другого языка
Поток управления процедурных языков намного лучшие соответствия фактический шаблоны обработки современных компьютеров.
карты C очень тесно на ассемблерный код его компиляция производит, следовательно псевдоним "межплатформенный блок". Производители компьютеров провели несколько десятилетий, делая ассемблерный код выполненным максимально быстро, таким образом, C наследовал всю эту необработанную скорость.
В сравнении, никаких побочных эффектах, свойственный параллелизм функциональных языков не отображается на единственный процессор вообще хорошо. Произвольный порядок, в котором функции могут быть вызваны потребности, которые будут сериализированы вниз к узкому месту ЦП: без чрезвычайно умной компиляции Вы собираетесь быть контекстным переключением весь время, ни одна из упреждающей выборки не будет работать, потому что Вы постоянно нещадно критикуете место... В основном вся работа оптимизации, которую производители компьютеров сделали для хороших, предсказуемых процедурных языков, в значительной степени бесполезна.
Однако! С перемещением к большому количеству менее мощных ядер (а не одного или двух ядер с турбинным двигателем), функциональные языки должны начинать преодолевать разрыв, поскольку они естественно масштабируются горизонтально.
Что касается теперь, функциональные языки не используются в большой степени для промышленных проектов, таким образом, недостаточно серьезной работы входит в оптимизаторы. Кроме того, оптимизация обязательного кода для обязательной цели является, вероятно, легче путем.
Функциональные языки имеют один подвиг, который позволит им превзойти императивные языки действительно скоро теперь: тривиальное распараллеливание.
Тривиальный не в том смысле, что это легко, но что это может быть встроено в языковую среду без разработчика, бывшего должного думать об этом.
стоимость устойчивой многопоточности на агностическом потоком языке как C является чрезмерной многим проектам.
Хорошо Haskell только в 1.8 раза медленнее, чем C++ GCC, который быстрее, чем реализация GCC C для типичных задач сравнительного теста. Это делает Haskell очень быстро, еще быстрее, чем C# (Моно, который является).
относительная скорость Языка
- 1,0 C++ GNU g ++
- 1,1 C GNU gcc
- 1.2 ATS
- 1.5 Java 6 - сервер
- 1.5 Чистых
- 1.6 Pascal Free Pascal
- 1.6 Фортрана Intel
- 1.8 Haskell GHC
- 2.0 Моно C#
- 2,1 GNAT Scala
- 2.2 Ada 2005
- 2,4 источника Lisp SBCL
- 3.9 Lua LuaJIT
Для записи я использую Lua для Игр на iPhone, таким образом Вы могли легко использовать Haskell или Lisp, если Вы предпочитаете, так как они быстрее.
Я не соглашаюсь с tuinstoel. Важный вопрос состоит в том, обеспечивает ли функциональный язык более быстрое время разработки и приводит к более быстрому коду, когда он привык к тому, какие функциональные языки были предназначены, чтобы использоваться. Посмотрите раздел проблем эффективности по Википедии для проблеска того, что я имею в виду.
Еще одной причиной большего исполняемого размера могли быть отложенные вычисления и нестрогий. Компилятор не может выяснить во время компиляции, когда определенные выражения оценены, таким образом, некоторое время выполнения наполнено в исполняемый файл для обработки этого (для призыва оценки так называемого преобразователи ). Что касается производительности, лень может быть и хорошей и плохой. С одной стороны это допускает дополнительную потенциальную оптимизацию, с другой стороны, размер кода может быть больше, и программисты, более вероятно, будут принимать плохие решения, например, видеть Haskell foldl по сравнению с foldr по сравнению с foldl' по сравнению с foldr' .