Инженеры одного из хостинг-операторов, специализирующегося на размещении сайтов на базе WordPress, опубликовали (https://kinsta.com/blog/the-definitive-php-7-final-version-h.../) результаты оценки производительности PHP 7.0 (https://www.opennet.me/opennews/art.shtml?num=43449) в сравнении с прошлой веткой PHP 5.6 и развиваемой инженерами Facebook виртуальной машины HHVM (http://hhvm.com/) (HipHop Virtual Machine), снабжённой JIT-компилятором. Следует отметить, что стабильный выпуск HHVM 3.10.1 не является полностью совместимым с PHP 7.0, базовая совместимость с PHP 7.0 пока обеспечена (http://hhvm.com/blog/10859/php-7-support) только в экспериментальной ветке HHVM 3.11.Тестирование проводилось с использованием WordPress 4.3.1, Drupal 8, Magento 2.0 CE, OctoberCMS build 309, PyroCMS v3 beta2, Laravel 5.1.11 и Flarum v0.1.0-beta.4. Во всех тестах, за исключением Laravel, наибольшую производительность продемонстрирвоал HHVM, но отставание PHP 7.0 было не столь существенным, как в случае использования PHP 5.6. Например, в тесте Magento PHP 7.0 и HHVM продемонстрировали 183.87 и 192.19 транзакций в секунду, а в WordPress - 357.69 и 306.24. В тесте Laravel PHP 7.0 даже обогнал HHVM. Тест форумом Flarum провести не получилось, так как его не удалось запустить с HHVM и PHP 7. В тесте
Drupal 8 разрыв в производительности оказался почти в два раза 1739.28 у HHVM против 917.10 у PHP 7.0.<center><a href="https://kinsta.com/wp-content/uploads/2015/12/Copy-of-Copy-o... src="https://www.opennet.me/opennews/pics_base/0_1450083877.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
<center><a href="https://kinsta.com/wp-content/uploads/2015/12/Drupal-8.png&q... src="https://www.opennet.me/opennews/pics_base/0_1450083895.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
<center><a href="https://kinsta.com/wp-content/uploads/2015/12/Copy-of-Transa... src="https://www.opennet.me/opennews/pics_base/0_1450083913.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
<center><a href="https://kinsta.com/wp-content/uploads/2015/12/OctoberCMS.png... src="https://www.opennet.me/opennews/pics_base/0_1450083933.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center><center><a href="https://kinsta.com/wp-content/uploads/2015/12/PyroCMS-3.png&... src="https://www.opennet.me/opennews/pics_base/0_1450083954.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
<center><a href="https://kinsta.com/wp-content/uploads/2015/12/Laravel-5.1.pn... src="https://www.opennet.me/opennews/pics_base/0_1450083977.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>URL: https://kinsta.com/blog/the-definitive-php-7-final-version-h.../
Новость: http://www.opennet.me/opennews/art.shtml?num=43515
Жаль JIT не вошёл в PHP 7, но зато есть куда двигаться в PHP 8.
Может тогда уж сразу переходить на HHVM и не ждать PHP 8?
А вы пробовали использовать его в продакшене не перезапуская каждые пол часа?
Он валится от каждого чиха. Там, где php просто в лог ошибку пишет, hhvm падает совсем. Это ппц как тупо.
Лучше пусть SIMD адаптируют, JIT не поможет.
Жаль, что Jommla! в тест не попала.
и битрикс
Битрикс не работает на PHP 7.0.0
Неплохо
О как! Слышал от знакомого пхпешника, что скорость PHP уже можно сравнить с С++. А HHVM выходит побыстрее С++ будет. =)
> Слышал от знакомого пхпешника, что скорость PHP уже можно сравнить с С++С кодом на C++, написанным пехапешником? Верю.
АХахахахаха
сравнить-то, конечно, можно.
на 30-40% медленнее в сравнении 50-60% пхп5
Лет десять назад, кажется, в моде было утверждение, что Java код на ассемблере обгоняет.
Код написанный на С++, обгоняет сам себя, переписанный на PHP. О, как!
Смотря какой код. За счет JIT в определенных случаях запросто может обгонять.
JIT'ов написаны уже сотни, но что-то на практике этих "определйнных условий" так ни у кого и не наступило. Забудьте, никогда никакие JITы, а тем более в динамически типизированных языках не обгонят нормальный скомпилированный код.
Про LuaJIT не слышали?
Срочно гуглить LibJit.
> Лет десять назад, кажется, в моде было утверждение, что Java код на
> ассемблере обгоняет.Особенно если его написал тот же жабо-программист )
В 2005 уже был GCC4.
Обогнать его или интеловский/мсовский конечно было можно, но отнюдь уже не "дуриком" и в основном на SIMD.За 2005 не скажу, но в 2009, после вдумчивой оптимизации (т.е. изучения документации интеля к конкретному цпу) можно было выжать 10-12 дополнительных процентов. Правда, ЧСХ – для этой самой конкретной модели, т.к. для других производительность падала на этот самый десяток процентов )
Да-да. Как-то пришло ко мне одно чудо с заявой что его программа на жабе быстрее эквивалента на C.Ничего не сказала рыбка, лишь посмотрела на вызовы strlen() в условии цикла for() и ушла в глубокое море.
Бесспорно, взять PHP и сравнить эту программу с C++ на каком нибудь IBM PC/AT 286... PHP будет опережать код на C++!
т.е. движение в сторону типизации/строгости языка и внесения ясности, сказывается положительно на производительности приложений. Главное непереусердствовать.Плюс, некоторые фреймворки, демонстрируют неплохие результаты. Видимо сказывается: грамотное использование новых возможностей языка, успешное применение подходов DI/IoC
Было бы небезинтересно взглянуть тесты на производительность для: массивов, строк, подключений модулей, объектов.
честно говоря, не ясно, зачем вообще нужны языки без строгой типизациинеужто всго лишь забота о программистах, которым трудно пару переменных объявить перед использованием?
Всего лишь забота о программистах, у которых в противном случае 10% типового скрипта будут занимать переводы строки в число и обратно.
А где они столько строкового ввода берут, на который отдельный код надо писать, а не циклы какие-нибудь? Насчёт "обратно" - тем более бред - код останется РОВНО таким же, как и был. А вообще - такие проблемы решаются удобным синтаксическим сахаром и вменяемым проектированием интерфейсов
Ну, например, "сырые" данные из БД - это таки строки. Которые, вполне возможно, не требуется преобразовывать для вывода, однако по ходу дела нужно, скажем, отсортировать по одному из столбцов. И в столбце этом может оказаться текст, дата, числа - где целые, где нет... так вот, сейчас в РНР это неважно, сравнение работает без явного приведения. Строки и даты будут сравниваться лексически, числа - по значению. Теоретически неявное приведение может привести к полной неразберихе, но именно в той области, где применяется PHP, оно сплошь и рядом оправдано. Потому что, вполне возможно, даже неверное приведение - совсем не сломает систему, просто порядок сортировки будет не тем, который, возможно, ожидался.
> Ну, например, "сырые" данные из БД - это таки строки.Это вы где-то ядреной травы покурили.
Другое дело, что веб-разработка имеет дело в основном со строками, но вот базы данных тут совершенно ни при чем
Речь про РНР. Функции РНР возвращают результаты из БД в виде массива строк.
Время программулек, которые брали строковые аргументы из шелл, конвертили как им удобно и жили сами в себе, давно ушло. Сейчас межпроцессорное коммуникации строятся на json'оподобных наречиях, а участниками обмена часто является ПО несовместимое на уровне типов переменных, поэтому передавать бинарные структуры как есть даже в голову никому не приходит.
не из БД, а из MySQL, но да ее впрочем и БД то назвать сложно.
А самой распространенной БД в интернете - еще сложнее. Но придется.
Ну вот тебе простая задача: получить от пользователя два числа, перемножить их и вывести результат. Два преобразования из строки в число, одно полезное действие и преобразование из числа в строку.
Теперь усложним задачу, при указании типа требуется различать не только строки и числа, но и числа разных типов, самый минимум byte/int/longint/float/double, а лучше больше десятка, известных процессору. Предусмотреть вариант с тем, что введенное или полученное число не влезет в указанный тип. Обеспечить максимальное сохранение мантисы. Все еще не понимаешь, зачем нужны языки в которых можно написать просто 'say $ARGV[0] * $ARGV[1]' ?
А теперь учти, что вместо чисел от пользователя может прийти мусор и нужно корректно среагировать а не упасть всем скриптом.
Может тогда будет понятно, чт простота выражения 'say $ARGV[0] * $ARGV[1]' это иллюзия.
Ты не поверишь, но никакого падения не произойдет:$ perl -E 'say $ARGV[0] * $ARGV[1]' dsf dsf
0
> честно говоря, не ясно, зачем вообще нужны языки без строгой типизацииСравните Template Haskell и reader macros в LISP - начнете догадываться.
Одну экзотику с другой, причём обе вообще не относятся к делу? Зачем?
Для понятности.
Вы не путаете строгую типизацию со статической?
> зачем вообще нужны языки без строгой типизацииТ.е. по вашему, Си не нужен – зато "да здравствует питон!"? 0_o
Ага, вместо $var = $_GET['id']; нужно будет писать $var = (int)$_GET['id']; Трогедия.
Например. И получать эксепшн, если оно не преобразуется. Вполне имеющий право на жизнь вариант.
И не получать если преобразуется. Приехало "улица Ленина", положили в $last_name, порадовались статической типиизации, которая всех спасла.
Лучше выловить эксепшн, чем потом в продакшне выяснять какого полового органа оно задним числом погоду в унитазе посчитало из-за того что одна обезьяна проверку ввода не сделала, а вторая вместо десятичной точки запятую поставила.
Ну если вы хотите быть уверены что там именно int, то сейчас вы делаете проверку на is_int(), а завтра будете ловить эксепшен.
А б*триксом протестировать слабо?
Так уже: http://idea.1c-bitrix.ru/to-make-the-product-compatible-with.../
(слеш в конце съедает местный парсер).
А что это за такие мегапопулярные цмс системы OctoberCMS PyroCMS ? Обычные цмски вроде битрикса жумлы и прочей нечести на HHVM видимо не запускаются(в силу отсутствия ПХПшных модулей) ? =)
Про битрикс ссылка выше, Джумла собирается выкатить версию 3.5 с заявленной поддержкой PHP 7 только к концу февраля.
Так что - кто успел обеспечить совместимость, того и померили.
Ничего, что жрет на один скрипт HHVM (87MB), PHP 7.0 (16мб)?
