Comments 45
Для справки: Дмитрий Стогов познакомился с программированием в 1984, когда еще далеко не все из читателей появились на свет
Седина яиц — не признак ума или мудрости, она всего лишь признак старости.
В данном случае это все не умаляет заслуг Дмитрия, но ремарка явно лишняя.
Во-вторых, предвижу аргумент типа «технологии быстро меняются, опыт устаревает».
Это не относится к тем людям, которые не только используют, но и создают технологии, потому что такой опыт намного глубже и фундаментальнее. Если Вася Пупкин поверхностно выучил условный Ангуляр, не понимая что там под капотом, а потом приходит условный Реакт — действительно, опыт Васи сильно обесценился. А вот если Вася писал Ангуляр, досконально понимает его архитектуру и знает как и почему принимались подкапотные решения — такой опыт по-прежнему ценен.
"в 2006 мне не понравился ни язык, ни средства разработки", сейчас уже почти 2020, к чему Вы это написали?
Насколько я знаю, как раз таки только Дельфи гвоздями прибита к своей IDE. С другими языками такой проблемы нет.
Понимаю, что в вашем возрасте и при вашем опыте между 2006 и 2019 кажется, что прошло немного времени, но для php это вообще разные эпохи. PhpStorm прекрасен (вообще семейство Идейки на порядок выше любых вижуал-студий, да и кроссплатформенны), да и сам язык и его инфраструктура развились кардинально.
Лично для меня ПХП Сторм версии 3, 4 — был отвратилен. И я предпочитал Зенд Студио.
После версии 5.5 Зенд студио, мне мягко говоря не понравилась, и я решил снова побробовать ПХП Сторм (он уже 6й версии был, если я правильно помню) И вот уже с 6й версии я использую ПХП Сторм и очень доволен ним.
Ну один из бенчей довольно старый: https://gist.github.com/dstogov/12323ad13d3240aee8f1
Ещё под php 7.0, примерно отсюда: https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit
P.S. Но естественно бенчи на скринах более свежие, уже под php 8.0, где PHP уже не с gcc -o2 соревнуется, а с gcc -o3
P.P.S А, не, кажется наврал с веткой. Та как раз под эксперименты на 7ке. Современные версии, кажется, уже шли от https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit
Мне кажется что будущее за многопотоком.
Привет из 2019-го! У нас тут в телефонах по 8 ядер, что уж говорить о серверах.
А эра многопотока уже настала? Много ли чего кроме рендера, некоторых вычислений и определенных игр задействует больше 1-2 ядер? Скажите браузер. Нет, js — самая тяжелая часть — выполняется на 1 потоке. Консольные утилиты — большинство на 1 потоке. Да почти все как и 10-20 лет назад работает не задействуя много ядер.
У нас тут в телефонах по 8 ядер, что уж говорить о серверах.
А Винда как тормозила, так и тормозит )))
Мне кажется что будущее за многопотоком. Я постоянно сталкиваюсь с упором в 1 поток.
В каких задачах постоянно появляется нужда в многопоточности? Какие-то тяжелые вычисления, что нужно распараллелить, на PHP?
Если задачи IO-bound, может для них хватит просто асинхронной модели выполнения и корутин?
Все просто. Я занимаюсь разработкой на magento 2. Просто папка vendor/magento у меня сейчас содержит ~56000 файлов. Без кэша с режимом production страница может грузится несколько секунд, стоит ли говорить про режим developer бз кэшей и с логами. Без php7 и opcache m2, можно сказать, неюзабельна.
Или вот регенерация картинок. Запускается консольная команда которая ресайзит изображения. На более-менее приличных объемах это занимает часы, просто потому что идет в 1 поток. А могло бы занимать десятки минут загружай оно 6-8 ядер сразу.
Просто папка vendor/magento у меня сейчас содержит ~56000 файлов. Без кэша с режимом production страница может грузится несколько секунд, стоит ли говорить про режим developer бз кэшей и с логами.
Ну это проблема magento, а не технологий. Как вам многопоточность в этом поможет? В том, в чем она может помочь, может помочь и асинхронность — отправили запрос в БД, не ждем ответа, а сразу следующий формируем, ответ обработается соответствующим обработчиком когда придет.
vendor/magento
Судя по названию, в Magento используется composer, а значит и автозагрузка файлов. Поэтому неважно, сколько там файлов, загружаются они только по требованию, когда выполняющийся код обращается к соответствующему классу.
Запускается консольная команда которая ресайзит изображения. На более-менее приличных объемах это занимает часы, просто потому что идет в 1 поток. А могло бы занимать десятки минут загружай оно 6-8 ядер сразу.
Что мешает запустить несколько процессов, по одному на ядро?
Что мешает запустить несколько процессов, по одному на ядро?На проде ничего не мешает, там и кэш есть. А на локалке в дев окружении начинается боль.
И самое обидное что раньше, в 2012 на 3770 было комфортно как никогда, что однопоток был отличный, что многопоток. Сейчас, даже на 9900k 5ггц, ощущение заторможенности везде. И если многопоточные штуки можно залить ядрами, то однопоток за эти года почти не изменился, зато изменились пк разработчиков на i7 и i9.
Запускается консольная команда которая ресайзит изображения. На более-менее приличных объемах это занимает часы, просто потому что идет в 1 поток. А могло бы занимать десятки минут загружай оно 6-8 ядер сразу.
Для консольной команды не составит труда создать столько форков, сколько нужно.
Без кэша с режимом production страница может грузится несколько секунд, стоит ли говорить про режим developer бз кэшей и с логами. Без php7 и opcache m2, можно сказать, неюзабельна
Не думаю, что многопоточность смогла бы повлиять на холодный старт magento. А, сложность кода возросла бы однозначно.
С первого взгляда, кажется, что многопоточность была бы уместна для graphQL: собираем комментарии, пользователей, лайки из разных БД не последовательно друг за другом, а параллельно. Но, тут вопрос, сможем ли мы получить лайки не зная id комментариев.
Как мне кажется, в 95% случаев где хочется многопоточности — можно использовать очереди. В остальных 5% — использовать другой язык.
С первого взгляда, кажется, что многопоточность была бы уместна для graphQL: собираем комментарии, пользователей, лайки из разных БД не последовательно друг за другом, а параллельно. Но, тут вопрос, сможем ли мы получить лайки не зная id комментариев
В этой конкретной задаче может быть это и не помогло бы, но у меня вот была задача: сделать «таймлайн» общения с клиентом — в 12:00 мы ему звонили, в 12:30 — письмо послали, в 15:00 — в чате пообщались и т.д. И все эти данные лежали по 3 базам в 3 разных микросервисах. К сожалению в данном случае пришлось все это тащить одно за другим, а потом составлять из всего этого упорядоченный по времени таймлайн.
но у меня вот была задача: сделать «таймлайн» общения с клиентом — в 12:00 мы ему звонили, в 12:30 — письмо послали, в 15:00 — в чате пообщались и т.д. И все эти данные лежали по 3 базам в 3 разных микросервисах. К сожалению в данном случае пришлось все это тащить одно за другим, а потом составлять из всего этого упорядоченный по времени таймлайн.
И это как раз решается неблокирующим IO, многопоточность тут не нужна.
Ожидая данных от запущенного запроса PHP просто простаивал.
С первого взгляда, кажется, что многопоточность была бы уместна для graphQL: собираем комментарии, пользователей, лайки из разных БД не последовательно друг за другом, а параллельно.
Это асинхроный ввод-вывод вполне решает со времён PHP3
Бенчить jit имеет смысл на современном коде с strict types и джава-подобным ООП; на вордпрессе и подобном легаси ожидать прорывных результатов точно не стоит, но это никак не говорит о бесполезности jit в целом.
Ещё смутило:
в PHP, каждый файл компилируется отдельно от других. Делается это потому, что каждый из них может изменяться отдельно.
В проде приложение может работать месяцами без изменений. И поэтому лично моё мнение, в проде должно быть что-то вроде сборки, которую нельзя было бы править руками, никаких composer и т.п.
apc примерно так и работает. Но смысл фразы, по-моему, в том, что сам PHP не предусматривает каких-то отдельных режимов (apc вроде может после первого чтения перестать следить за отслеживанием изменений). А сейчас есть preload, который (по описанию) работает как вы хотите — изменения фавйлов требуют перезагрузки демона (fpm)
Может быть появится возможность сохранять/загружать массив в виде бинарных данных без сериализации?
Мне вот интересно, а в PHP 8 собираюсь ломать обратную совместимость?
Былоб интересно например рассмотреть замену возвращаемого типа данных для функций типа fopen(), fsockopen(), mysql_connect() и т. д. в случае ошибки.
Сейчас:
/**
* @return resource|false
*/
fopen(/* ... */): mixedА могло бы быть:
fopen(/* ... */): ?resourceВ PHP 8 будет (уже есть по факту) fopen(): resource|false, не просто для документации, а на уровне языка union типы вводятся, в том числе библиотечные функции будут
А в целом вроде в следующих версиях планируется сначала задепрекейтить, а потом полностью отказаться от таких библиотечных функций, а перевести их на ООП основу с исключениями для ошибок. Может что-то путаю, но в целом у меня ощущение, что в условном PHP 10 работа с fopen и другими ресурсными функциями будет или невозможна в принципе, или будет объявлена legacy оставленным для совместимости с PHP 3+, может без формальных deprecated варнингов, а просто на уровне документации "не пишите новый код с этими функциями", а рекомендуемым способом работы с ресурсами будет объектный API с исключениями для ошибок.
Ну resource|false это все таки не union тип. Это микс из типа и одного из значений типа. Если говорить о union, то это будет resource|bool, что подразумевает, что true так же является возможным возвращаемым значением. В этом то основная проблема.
Вчера правил баг в PHPStan и PhpStorm связанный с этим и задумался, а не пора ли наконец привести все в порядок, тем более, что выходит мажорная версия. И править нужно не сказать, что очень много.
А в целом вроде в следующих версиях планируется сначала задепрекейтить, а потом полностью отказаться от таких библиотечных функций, а перевести их на ООП основу с исключениями для ошибок.
А есть какие-то ссылки подтверждающие, что это планируют именно в PHP 8? Разговор об этом ведется уже много лет, еще со времен PHP 5.4 кажутся, но подвижек я как-то не заметил.
false вводится как псевдотип, подтип bool (технически, емнип, в PHP 7 и так bool — это объединение true и false, просто явно как типы в юзерспейсы недоступные. Теперь, получается false делается доступным для union, немного подкапотная магия PHP раскрывается. То есть именно resource|false можно указывать в своих подобных функциях.
Перевод ресурсов на ООП НЕ планируется в PHP 8, по крайней мере в юзерспейсе. Если ничего не путаю, то то ли планируется, то ли уже начат перевод ресурсных функций на ООП модель под капотом, так, чтобы существующие функции были адаптерами к объектам, но пока в юзерспейсе недоступные.
Самое интересное в PHP 8