форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
Сообщение от opennews (ok) on 07-Янв-15, 11:10
Инфраструктура свободной энциклопедии Wikipedia переведена (http://hhvm.com/blog/7205/wikipedia-on-hhvm) со штатного интерпретатора языка программирования PHP на развиваемую инженерами Facebook виртуальную машину HHVM (http://hhvm.com/) (HipHop Virtual Machine), которая благодаря поддержке JIT-компиляции позволила существенно (https://blog.wikimedia.org/2014/12/29/how-we-made-editing-wi.../) ускорить выполнение кода движка MediaWiki. В настоящее время все некешируемые операции в Wikipedia, такие как функции редактирования и запросы к API, производятся с использованием HHVM. Процесс миграции Wikipedia на HHVM начался (https://www.mediawiki.org/wiki/HHVM) в марте и продолжался 9 месяцев, за которые совместно с разработчиками из Facebook была проделана большая работа по устранению возникающих проблем, выявляемых в процессе тестового внедрения. В частности, была выявлена несовместимость реализации класса DOMDocument (http://us3.php.net/manual/en/class.domdocument.php) в HHVM c используемым в MediaWiki кодом для экспорта и импорта данных в формате XML, а также проблемы с расширением для выполнения скриптов на языке Lua. Кроме того, была проделана работа по внесению оптимизаций, рассчитанных на специфику использования MediaWiki, которые были упущены из-за разработки HHVM с оглядкой на виды нагрузки, свойственные Facebook. Например, была обеспечена поддержка JIT при выполнении регулярных выражений и изменён метод отслеживания состояния объектов с заданными дескрукторами, что дополнительно ускорило выполнение кода на 8% и 4%. В итоге, внедрение HHVM позволило в среднем на 45% (почти в два раза!) ускорить обработку динамического контента Wikipedia  и значительно снизило нагрузку на CPU, по сравнению с конфигурацией на основе PHP 5.3. Например, время сохранения изменений сократилось в среднем с 6 до 3 сек, а загрузка процессоров на типовом сервере Wikipedia снизилась почти в 6 раз. Отмечается, что по сравнению с PHP 5.3 в актуальной версии PHP 5.6 наблюдается заметный прогресс в области увеличения производительности, поэтому разрыв между PHP 5.6 и HHVM был бы не столь значимым. <center><a href="http://hhvm.com/wp-content/uploads/2015/01/save-time-0-e1420... src="http://www.opennet.dev/opennews/pics_base/0_1420615302.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> <center><a href="http://hhvm.com/wp-content/uploads/2014/12/Screenshot-2014-1... src="http://www.opennet.dev/opennews/pics_base/0_1420615329.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> Основная причина высокой производительности HHVM заключается в возможности применения JIT-компиляции и динамических оптимизаций, учитывающих особенности выполнения скрипта. В процессе выполнения кода производится определение типов данных и генерация на лету эффективных наборов машинных инструкций, оптимизированных специально для используемых типов. Перед выполнением PHP-скрипты преобразуются в специальное промежуточное абстрактное представление AST (Abstract Syntax Tree), которое затем транслируется в байткод HHBC (HipHop bytecode), который выполняется внутри высокоуровневой виртуальной машины. URL: https://news.ycombinator.com/item?id=8847934 Новость: http://www.opennet.dev/opennews/art.shtml?num=41409
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–7 +/–
Сообщение от Ящ (ok) on 07-Янв-15, 11:10
А вот написали бы педивикию хотя бы на жабе, таких проблем бы не было.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+1 +/–
	Сообщение от vitalif (ok) on 07-Янв-15, 11:19
	Что кстати характерно, она может и не сильно тооще бы стала... у них там в последнее время тоже обертка оберткой погоняет и стеки километровые... Вообще в 2 раза по сравнению с 5.3 - это да, как-то не очень серьезно.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	9. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+1 +/–
	Сообщение от Нанобот (ok) on 07-Янв-15, 11:59
	На графике загрузка ЦП уменьшилась с 60% до 10% - в шесть раз, что вполне неплохо А время выполнения скриптов может ещё хорошо зависить от СУБД, например
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	10. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
	Сообщение от Ящ (ok) on 07-Янв-15, 12:01
	> она может и не сильно тооще бы стала... +1. И поддерживать было бы проще, чем устраивать попрыгушки с одной среды исполнения на другую, потом ещё тестить, всё ли на месте. Пхпшники, по ходу, принялись догонять жабу, пых всё больше и больше стал похож на неё, и по рекомендациям, а то и правилам (писать код не ООП уже стало считаться б-гопротивным), и по дизайну. Всё из неё тащат к себе. Zend Framework – это вообще кошмарная вермишель. Если на то пошло, не лучше ли тогда просто писать на эталоне, к которому они стремятся? Жаба то всяко не хуже.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	31. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
	Сообщение от Grammar_Nazi on 07-Янв-15, 15:51
	Жаба-то
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	85. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Аноним (??) on 09-Янв-15, 00:43
	> Жаба-то Жаба - не то!
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	101. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от count0krsk (ok) on 09-Янв-15, 20:27
	edited: Не-торт!
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	33. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–2 +/–
	Сообщение от cmp (ok) on 07-Янв-15, 16:24
	Да будто их каждый день устраивают. > Жаба то всяко не хуже Жаба всяко не лучше, уж кол-во непереносимого никуда г-на на ней написано не меньше, а про скорость, которую обещали значительно улучшить году еще наверное в 2005 даже вспоминать не хочется, там загрузка одной только вм наверное занимает секунд ~дцать. Даром чтоле гугл слезать с нее собрался.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	38. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Аноним (??) on 07-Янв-15, 18:36
	Мсье, вы когда в последний раз видели Java? Или вы пишите нам из криокамеры?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	41. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+1 +/–
	Сообщение от edwin3d (ok) on 07-Янв-15, 18:53
	> Жаба всяко не лучше, уж кол-во непереносимого никуда г-на на ней написано > не меньше, а про скорость, которую обещали значительно улучшить году еще > наверное в 2005 даже вспоминать не хочется, там загрузка одной только > вм наверное занимает секунд ~дцать. Вы не работали с Java всерьез и порете чушь Эта платформа на сегодня обеспечивает высочайшую производительность
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	52. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от cmp (ok) on 07-Янв-15, 22:02
	Даже палкой с трех метров трогать не хочу Потому что, дистр какого размера? бинарник какого размера? а сравните ка это с той же пхпшкой и 15 метровой rpm-кой На рабочем компе 250Кб скриптик (или как эта хрень зовется) прогружается минут пять, а "серьезный" софт на вашей яве, это реальный ретурн ту виндовс 98, речь исключительно о корпоративном секторе. но это субъективно. > Вы не работали с Java всерьез и порете чушь с явой как языком на котором бы что-то писал нет, но во-первых, я не люблю оракель, и не стану ничего писать на яве буть она хоть самой быстрой и масшабируемой средой. А во-вторых, сама идея такой вм в которой бы исполнялось все - уже стухла, имхо, вы можете предерживаться друго мнения, но контейнерная виртуализация позволяет хоть жопой набитый код исполнять, гарантируя при этом безопастность системы и обеспечивая масштабируемость которая яве и не снилась.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	54. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
	Сообщение от vn971 (ok) on 08-Янв-15, 00:43
	Разрабатываете случаем не на PhpStorm? А то он тоже долго грузится, если вы понимаете на что я намекаю..
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	56. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от cmp (ok) on 08-Янв-15, 04:06
	нет, не разрабатываем, исключительно эксплуатируем и как показывает практика - адекватных решений просто нет, либо монстры на яве к которым не знаешь с какой стороны подойти, которые умеют то, что умеют, а любая автоматизация сверх того обречена на провал, либо свистоперделки, которые умеют все после обработки напильником.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	109. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Аноним (??) on 12-Янв-15, 10:16
	Дружище, абсолютно согласен по поводу Java. Нет, может проггерам и видно, что там "быстрее, выше, сильнее". Но потом шишки от пользователей не им же перепадают. Когда очередной клоун презентует "новое решение" и начальство радостно кричит внедряем, начинается Ж. с этими "энтерпрайз решениям". Так что ООП, переносимость и т.д. - это, конечно, круто. И важно. Но для сферических программистов в вакууме (куда, кстати, авторов с их поделками и хочется отправить после очередного мегарешения).
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	61. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+1 +/–
	Сообщение от edwin3d (ok) on 08-Янв-15, 08:40
	> Даже палкой с трех метров трогать не хочу Т.е. открываем рот не имея реального опыта работы. > Потому что, дистр какого размера? бинарник какого размера? > а сравните ка это с той же пхпшкой и 15 метровой rpm-кой Когда ф-ть php достигнет 5% от Java сообщите. Хотя-бы когда в php появиться зачатки нормальной многопоточности, что-то класса NIO > На рабочем компе 250Кб скриптик (или как эта хрень зовется) прогружается минут > пять, а "серьезный" софт на вашей яве, это реальный ретурн ту > виндовс 98 Только отчего-то результаты на серверах иные, не такие как Вы рассказали. Простая замена с ruby на jruby производительность повышает с лету в разы. ПРо HL задачи вообще говорить не стоит - высоконагруженные системы класса Cassandra на PHP никто писать не будет. > жопой набитый код исполнять, гарантируя при этом безопастность системы и обеспечивая > масштабируемость которая яве и не снилась. Да, вот что значит перечитать статьи про Docker, когда тело путает одно  решение с совершенно иным, при это не осознавая что сравнивает совершенно разные вещи. Обратите внимание в чем достоинство описанного в статье решения - применяется VM для PHP. Разрыв шаблона. Потому что VM - это куда больше чем те 1% не главного, которые вы перечислили Мне совершенно не понятно как контейнерная визуализация решит проблему отсутствия JIT и соот. низкой производительности, когда запросы которые должны выполнятся в пределах 200 мс, а пилятся секундами   И другие 10к. проблем, которые вообще не в той плоскости лежат
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	73. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+1 +/–
	Сообщение от рубин on 08-Янв-15, 13:12
	Когда функциональность java достигнет хотя-бы 1% от наушников сообщите. А вообще - давайте строить дома из лопат и копать мидиями.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	77. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–2 +/–
	Сообщение от cmp (ok) on 08-Янв-15, 16:01
	> Т.е. открываем рот не имея реального опыта работы. Уважаемый, опыт работы может быть разным, ваши супер нагруженные сервера это отличный пример того, как задачи перекладываются с одних больных голов на другие - вместо запила нормальной архитектуры с распределением нагрузки. > Да, вот что значит перечитать статьи про Docker Статей по докеру читал может парочку, и его не вспоминал, так как речь не о нем, а о подходе в целом, разница в производительности 2-3 раза у вм не решает ничего, нагрузки растут и будут расти и не можете вы их общитывать сегодя на пхп, завтра на яве. Вместо создания примитивов на нормальном си или даже асме которые можно бы было использовать в любой вм, каждый натирает свой кокос, кто-то яву, кто-то руби, но никто не пишет на чистой яве или руби, все пользуют фреймворки, запихнутые в виртуалки, ну и зачем столько наворотов, тем более, что не решают они ничего. JSON и XML уже решили проблему обмена структурированными данными, о каком таком сверх функционале вы говорите. > решит проблему отсутствия JIT и соот А мне вот не понятно как люди живут без регулярных выражений, ну и что живут же. > запросы которые должны выполнятся в пределах 200 мс А это вообще отдельная тема, которая к яве и вм какбы не имеет отношения, ну есть это там, и что с того, прикрутить это к пхп абсолютно тривиальная задача. Могу привести пример ламповых компьютеров, тоже монстры, тоже многое умели, но вымерли как динозавры, которых кстате заменили люди как доминирующий вид, хотя люди не быстрее, не сильнее и совсем ни чем не лучше. Так и ява, и пр. сольются рано или поздно, в угоду луа или js'у.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	110. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от tor (??) on 12-Янв-15, 14:15
	>> она может и не сильно тооще бы стала... > +1. И поддерживать было бы проще, чем устраивать попрыгушки с одной среды > исполнения на другую, потом ещё тестить, всё ли на месте. > Пхпшники, по ходу, принялись догонять жабу, пых всё больше и больше стал > похож на неё, и по рекомендациям, а то и правилам (писать > код не ООП уже стало считаться б-гопротивным), и по дизайну. Всё > из неё тащат к себе. Zend Framework – это вообще кошмарная > вермишель. Если на то пошло, не лучше ли тогда просто писать > на эталоне, к которому они стремятся? Жаба то всяко не хуже. Жаба как эталон дырявости ?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	7. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+6 +/–
	Сообщение от YetAnotherOnanym (ok) on 07-Янв-15, 11:51
	На жабе или не на жабе, на, в любом случае, с самого начала надо писать на нормальном языке.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	49. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+1 +/–
	Сообщение от Гаражник on 07-Янв-15, 20:44
	стартапы редко пишутся на нормальных языках. быстренько набросать на руби сайтик - норма. всё равно 99% года не живет
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	22. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+5 +/–
	Сообщение от Аноним (??) on 07-Янв-15, 14:00
	Ага, её бы тогда вообще не существовало. Нет сайта - нет проблем.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	40. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от edwin3d (ok) on 07-Янв-15, 18:51
	Это как раз общая беда многих проектов. Сначала некие энтузиасты, часто весьма невысокой квалификации берутся что-то делать. в 99.9% случаев это - никому не нужный хлам. Но есть небольшой % действительно хороших идей, которые "выстреливают" ... и приходит высокая нагрузка, сложность и т.д. И "простые" решения становятся дико сложными, все это подпирается вагоном костылей и т.д. Но с другой стороны - возможность быстро что-то наваять позволяет устроить автопросеивание и снизить планку реализации некой идеи.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	48. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+4 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 07-Янв-15, 20:24
	а потом приходят "профессионалы" с такой же низкой квалификацией и начинают переписывать на java заменяя одни простые решения на другие.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	50. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от edwin3d (ok) on 07-Янв-15, 21:41
	> а потом приходят "профессионалы" с такой же низкой квалификацией и начинают переписывать > на java заменяя одни простые решения на другие. Ваше словоблудие не имеет ничего общего с реальным положением дел. К примеру принятый как стандарт разработки в стартапах и засунутый во все дыры ORM (увеличение скорости разработки - что поделаешь) назвать простой вещью может только человек, который не понимает, какая прослойка стоит за ним. Равно как и не понимающий, что начиная с определенного уровня нагрузки в ряде участков он должен быть выкинут. Реальные архитектуры не умерших приложений не имеют ничего общего с "простыми решениями". Так и так все сложно. или очень сложно. А на сложные проекты приходят команды, уровень квалификации которых куда выше, чем кажется Вам. И берутся разгребать. И делается это очень успешно, вопреки Вашим сказкам. Примеров - тьма, как к примеру в Twitter, где после анализа ряд крит. участков переписали на Java, что решило ряд проблем.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	80. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 08-Янв-15, 17:24
	Знал бы типичную аудиторию пыхеров и ява гогнокодеров, то не писал бы такой херни. Во-первых, пыхеры слишком тупы чтобы пользоваться какими-то там ORMами, типичный их упровень это портянки из SQL шаблонов. А прослойки между всем типичен как раз для ява кодеров, благо в ява стеке они есть практически для всего и характерный ява кодер вообще почти ничего не знает за пределами API всех этих прослоек - сырой SQL видел только в википедии, протоколы для них это какая-то загадка и тому подобное. Грубо говоря, пыхеры и ява кодеры это две противоположности дилетанства, одни любят обвешиваться ненужными прослойками, а другие не в состоянии пользоваться даже простым абстрагирующим API. > А на сложные проекты приходят команды, уровень квалификации которых куда выше это сильно зависит от бюджетов и области деяетельности. Реально таких специалистов могут себе позволить только крупные компании завязанные на инет бизнес. Даже у них не всегда с кадрами всё так хорошо и в принципе ява кодеров подпускают фрагментально к сложным задачам. А уже в высокобюджетном энтерпрайз классе работают дилетанты немногим выше уровня пыха.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	51. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от edwin3d (ok) on 07-Янв-15, 21:59
	> а потом приходят "профессионалы" с такой же низкой квалификацией и начинают переписывать > на java заменяя одни простые решения на другие. Да, в дополнении: Java позволяет делать такие вещи, про которые в других платформах в общем то ... только подбираются Вот Вам самый простой пример: у Вас есть задача периодической обработки большого количества входящих запросов, пусть http, без блокирования основных потоков AS, без выноса этих задач куда-то в 3-е штуки. в Java все весьма просто - я отправлю в отдельный поток из пула, основной поток освобождается, как обработка закончиться - клиенту отдается ответ. Статусы, синхронизации, блокировки - все работает, если руки не из ж.. Теперь возьмем Ruby и любимый RoR ... мало вспоминать про GIL И других вещах, которые буквально ограничивают нас всех при решении задач такого класса. Могу ли я сделать тоже самое ? С костылем - да, потратив больше времени. Будет ли оно работает - будет. Только с большими проблемами в плане производительности, из-за нюансов блокировок, невозможности сделать то или иное нормально и т.д. Именно потому, такие вещи как Cassandra на Java, а MongoDB - C++, а Redis - на C
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	75. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
	Сообщение от Crazy Alex (ok) on 08-Янв-15, 14:05
	Тоже мне, аргумент. Сейчас такая задача тривально решается на Go или node.js. Раньше - для этого был (и есть) erlang/OTP. Обратите внимание - абсолютно разные подходы к построению языка и рантайма, что намекает - не в "особенности" явы или JVM дело, а в том, что всяким рубистам оно не слишком-то надо. Не говоря о том, что поднять пачку более-менее изолированных потоком или аналогичную пачку процессов по нагрузке почти одинаково, а по надёжности - процессы куда получше будут. Очереди (которые *MQ), опять же, тоже не вчера придумали. То, что жаба распрстранена - никто не спорит. Но язык убогий, каковым, он,  вобщем-то, и планировался.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	76. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–2 +/–
	Сообщение от edwin3d (ok) on 08-Янв-15, 14:53
	> Тоже мне, аргумент. Сейчас такая задача тривально решается на Go или node.js. С Go не работал проф., комментировать не имею права.   Про Node... У Вас недопонимание разницы между понимание асинхронной обработки с псевдо потоками и полноценной многопоточной архитектурой. Вы пытаетесь мне доказать, что Node.js который по фактически не имеет нормальной многопоточности и инструментов работы с ней будет сопоставим с нормальной многопоточностью в Java при решении одинаковой задачи. Про то, что в Node.js просто не способен реализовать ряд решений, Вы забываете ? > Раньше - для этого был (и есть) erlang/OTP. Знаете, Erlang - решение крайне нишевое, но почему Вы его в раньше поставили - ума не приложу. Он весьма активно используется в соот. кругах и теперь, более того - активность его использования растет, причем на глазах. Erlang - это д-но шедевр для HL. К примеру RabbitMQ - это очень яркий пример. А вот ставить его в один ряд с Node.js не стоило - это платформы разных уровней, т очень большое оскорбление для детища Ericsson >  Не говоря о том, что поднять пачку более-менее изолированных потоком или аналогичную пачку процессов по нагрузке почти одинаково, а по надёжности - процессы куда получше будут. Мы не может реализовать нормальную многопоточность и потому будем искать аргументы почему она не нужна, позиция удобная аж жуть берет ... Теперь про нагрузку - на ЦПУ относительно да. А вот по памяти ... извините, но fork и послед. события дают такой расход, что. Даже такие фишки как copy on write не всегда кардинально меняют ситуацию, да и платформенно зависимые они. Ед. здравый аргумент - многопроц. приложение и сделать проще и работать с процессами отдельными также проще, это факт.   > Очереди (которые *MQ), опять же, тоже не вчера придумали. Ну вот, опять встраиваете костыли которые делают решение оригинальной задачи иным. Технологически иным, при это добавляя сложность и т.д. Забавно выходит ... сперва мы ставим некий Node, привязываем еще вагон внешних систем,  которые компенсируют ублюдочность самой платформы приложений. Давайте честными будем перед самим собой - на сегодня для большей части новых проектов ед. критерий - скорость разработки независимо от степени ублюдочности результат. Но это не повод обзывать более корректно реализованные тех. решения ... каждому -свое.   > Но язык убогий, каковым, он,  вобщем-то, и планировался. Знаете если Java экосистему называть убогой, то как тогда называть JS и Node.js ?
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	83. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Crazy Alex (ok) on 08-Янв-15, 19:31
	Я намекал, что есть масса способой обработать большой поток запросов. И "нормальные потоки" - только один из них. Там, где вычислений мало, а I/O много - нода вполне на месте. Где летает мало данных, но у них тяжелая обработка - хороши MQ и независимые узлы, что почти автоматом даёт масштабируемость, в отличие от тупой потоковой модели. А можно всё это скомбинировать, достаточно дешево добавив решения, оптимальные для той или иной задачи. Собственно, я ещё не видел больших проектов, где было бы меньше трёх языков задействовано. Бывало, что это были очевидные костыли - пришел кто-то и добавил скрипт на питоне в проект на PHP, а потом его тащат три года. А бывает осознанный выбор решений с учётом их сильных сторон - где-то хорош демон на сях, который предельно экономно расходует память, где-то веб-морда на рубях, для которых разрабатывать удобно, где-то бизнес-логика - хоть и на той же джаве, хоть на Go, хоть на чём. Эрланг "был" - потому что, во-первых, он был первым индустриальным решением, умеющим хорошо работать с подобными задачами, а, во-вторых, он всё же несколько архаичен в синтаксисе и сейчас, когда есть больше альтернатив, можно выбрать что-нибудь более распространённое. С другой стороны - в плане "индустриальности" - то есть надёжности и наличия инструментов деплоя, мониторинга, обновлений и т.п. - он спокойно поспорит с J2EE в любой инкарнации. Если говорить про оверхед по памяти - не согласен, сорри. Сейчас, по факту, всё больше дело идёт к тому, что каждый поток держит свою копию практически всех данных. Банально потому, что иначе имеем лишнюю связность и рано или позно - проблемы с синхронизацией. Конечно, если форкать JVM или ещё что-то подобное - то оверхед велик. А если нечто, что не тащит такой здоровеный рантайм и без необходимости память не забирает - тут получше ситуация. А что до платформозависимости - по факту сейчас есть только одна мейнстримная платформа, если речь идёт о джаве, пхп или альтернативах - Linux/Intel. И на ней форк крайне дёшев. > Знаете если Java экосистему называть убогой, то как тогда называть JS и Node.js ? А вот тут и кроется непонимание. Экосистема - велика и хорошо проработана. J2EE и тому подобное. Отлаженные фреймворки. туча специалистов и документации. И, собственно, этой проработанностью и берёт - даже там, где можно сделать красивее, часто разумнее и выгоднее пойти по хорошо накатанной дороге и нагородить стандартный тяжелый стек - со спрингом каким-нибудь и тому подобным. А как язык джава по сравнению с тем же C#, C++, Rust, D - примитивна и многословна. И по сравнению с Ruby примитивна. Одно время была надежда, что Scala будет лучше в этом плане, но, насколько я понимаю, на практике всё оказалось не так красиво, как хотелось.  Эта примитивность и выливается в монструозные фреймворки с полутора десятками уровней иерархии, которые плохо понимаемы и плохо оптимизируемы. А JS с нодой - он на отдельную экосистему, как мне кажется, пока не тянет, и как язык лично мне не нравится, но здесь многие не согласятся. Зато на её элемент - вполне. У него есть свои жирные плюсы - то, что один и тот же код умеет работать на клиенте и сервере - иногда очень удобно. Что можно легко перебрасывать людей между фронтэндом и бэкэндом в зависимости от загрузки - тоже. В общем, выбирать надо разумно, а не упираться в одну технологию.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	91. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от edwin3d (ok) on 09-Янв-15, 10:26
	Теперь я понял, что Вы изначально имели ввиду ... жаль, что нам понадобилось так много времени и жаль, что я не понял Вас с самого начала. Если говорить о Scala, то там как мне кажется основная корень проблемы лежит в том, что многие разработчики пытаются на ней разрабатывать в привычном стиле, не используя плюшки. Т.е. по сути переходя на нее, они остаются на фактически чистой Java. Это накладывает отпечаток, причем серьезный ... у нас на работе была одна подсистема, которую решили перевести как раз на Scala, Так вот вместо 3-х месяцев понадобилось почти 6. Чтобы люди начали писать именно на ней. И люди не дураки были К слову обратите внимание на Groovy, он также весьма привлекателен в плане возможностей и  по моему мнению более прост в изучении и восприятии. то касается нашей дискуссии о fork, То если поставить граничные условия: - одна платформа, главное - где работает copy on write - минимум общих данных То в рамках таких допущений можно принять что выгода от скорости разработки позволяет пренебречь некоторыми моментами. Но в других случаях - не могу согласиться
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	84. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 08-Янв-15, 22:30
	> Вас есть задача периодической обработки большого количества входящих запросов... > Java позволяет делать такие вещи, про которые в других платформах в общем то ... только подбираются > в Java все весьма просто - я отправлю в отдельный поток из пула, основной поток освобождается, как обработка закончиться - клиенту отдается ответ. Это какой-то детский сад, как раз иллюстрация к картине профессионализма типичного ява кодера. Для "большого количества входящих запросов" (tm) тупая схема из начала 90 давно уже не работает. Причём даже для всех скриптовых ЯП делают сложнее обвязки, за исключением быть может пыха.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	90. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от edwin3d (ok) on 09-Янв-15, 10:13
	>> Вас есть задача периодической обработки большого количества входящих запросов... >> Java позволяет делать такие вещи, про которые в других платформах в общем то ... только подбираются >> в Java все весьма просто - я отправлю в отдельный поток из пула, основной поток освобождается, как обработка закончиться - клиенту отдается ответ. > Для "большого количества входящих запросов" (tm) тупая схема из начала > 90 давно уже не работает. Вообще-то в 90-е самым продвинум откровением был prefork. Та модель в которой говорю я стала по настоящему массово работоспособной в первой половине 2000-х и до сих пор применяется и будет применятся в приложениях. Безотносительно того, как каком ЯП написано решение. > Причём даже для всех скриптовых ЯП > делают сложнее обвязки Потому что сами платформы не способны обеспечить элементарные инструменты. Решение задачи передается внешней подсистеме, которая обладает необходимым качеством. Еще раз разберитесь, что представляют собой технически сегодня многие популярные вещи, разберитесь что такое GIL B т.д. Т.е. дело как раз в коренной ущербности, где для простоты выкидывается множество функционала. Это оправданно в ряде случаев, но технологически это порождает схемы, при которых в роли стержня выступает убогая обвязка на которую нанизываются внешние системы, которые решают эти задачи. Но не надо делать вид, что убогость - это мол благо. Надо просто и честно говорить, что к примеру разработчики способные работать с такими вещами стоят денег и их не так много, а типовой конструктор покрывает 99% стартаперских задач > Это какой-то детский сад, как раз иллюстрация к картине профессионализма типичного ява кодера. Это степень иллюстрации степени грамотности лиц, которые вместо применения одного из стандартных решений начинают изобретать структуры совершенно ненужной сложности, при этом делая вид, что технологически так лучше. Но Вы делаете вид, что объявляете основу ряда систем "приветом из 90-х" И вообще конечно, пулы потоков, выносы в отдельный потоки Slow запросов и т.д.  - это не для Вас. Пользуясь Cassandra написанной на Java в роли NoSQL БД Вы конечно будете продолжать орать какая Java плохая и какие там кодеры плохие Или пользуясь Pum'ой (как по мне - самый лучший Web для Ruby приложений при высокой нагрузке), где применены похожие принципы
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	105. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 09-Янв-15, 22:15
	Сколько же словестного поноса, ужас... > Это степень иллюстрации степени грамотности лиц, которые вместо применения одного из стандартных решений начинают изобретать структуры совершенно ненужной сложности Всё верно, только писать нужно правильно, вот так: > Это степень иллюстрации грамотности лиц, которые используют подходящую архитектуру сервиса вместо применения единственного известного одному гогнокодеру "стандартного" решения
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	44. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
	Сообщение от Аноним (??) on 07-Янв-15, 19:48
	Беглого взгляда на исходный код mediawiki достаточно, чтобы понять, что проблема там не в php, а в программистах на нем. Такие на чем угодно напишут crap.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	68. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от dev (??) on 08-Янв-15, 12:04
	> Беглого взгляда на исходный код mediawiki достаточно, чтобы понять, что проблема там > не в php, а в программистах на нем. Такие на чем > угодно напишут crap. mediawiki в свое время поразил меня качеством кода, по сравнению с другими php-проектами. Было с чем сравнивать.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	47. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 07-Янв-15, 20:21
	> А вот написали бы педивикию хотя бы на жабе, таких проблем бы не было. ага, были бы проблемы куда круче.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
Сообщение от Аноним (??) on 07-Янв-15, 11:19
>на 45% (почти в два раза!) А разве "2 раза" не равно 200%?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+5 +/–
	Сообщение от EHLO on 07-Янв-15, 11:31
	Если сократить среднее время сохранения страницы на 200%, получится машина времени.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	12. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
	Сообщение от юзер (??) on 07-Янв-15, 12:22
	Увеличение на 45% - это почти в полтора раза. Но никак не в два.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	15. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Аноним (??) on 07-Янв-15, 13:26
	> Увеличение на 45% Не увеличение, а сокращение (ускорилось)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	16. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+1 +/–
	Сообщение от Аноним (??) on 07-Янв-15, 13:33
	ЕГЭ-шные математики понабежали... x-45% = 0,55x x/(0,55x)=~1.8 - что и есть почти 2
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	27. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
	Сообщение от anonymous (??) on 07-Янв-15, 14:32
	Непонятно чего на человека налетели - написано ведь неправильно: > ...внедрение HHVM позволило в среднем на 45% (почти в два раза!) ускорить обработку... тоесть скорость обработки возросла на 45% (в 1.45 раза), а не время обработки сократилось на 45% (что должно соответствовать увеличению скорости обработки в 2.(2) раза или на 122.(2)%)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	28. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от anonymous (??) on 07-Янв-15, 14:42
	Прошу прощения, конечно, не 2.(2) а 1.(81) и соответственно ускорение на 81.(81)%
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

4. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–2 +/–
Сообщение от Аноним (??) on 07-Янв-15, 11:22
А есть сравнение сабжа с opcache
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+3 +/–
	Сообщение от Аноним (??) on 07-Янв-15, 11:29
	Это вопрос
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	13. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+3 +/–
	Сообщение от EHLO on 07-Янв-15, 12:30
	> Это вопрос Это вопрос
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	24. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
	Сообщение от Kodir (ok) on 07-Янв-15, 14:06
	Вопрос ли это вопроса или вопрошение спрашивающего?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	39. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+5 +/–
	Сообщение от Какаянахренразница (ok) on 07-Янв-15, 18:46
	Ты задаешь слишком много вопросов.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	62. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от йцу on 08-Янв-15, 09:08
	Написано же, что с 5.6 (где опкеш по дефолту включен), разрыв не такой уж большой.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	66. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от funny_falcon on 08-Янв-15, 10:43
	Уверен, дело явно не в опкеше, ибо ни кто в здравом уме и до этого без опкеша не деплоил. Сильно сомневаюсь, что в викимедиа наблюдается недостаток здравомыслящих людей.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	72. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от йцу on 08-Янв-15, 13:07
	Значит неверно понял вопрос. Вообще бенчмарков за последний код была целая куча, гугл в помощь. Обычно получается что HHVM действительно в 1,5-2 раза шустрее чем PHP 5.5-5.6. Однако, с PHP7 (бывший NG) результаты уже не так однозначны - в основном они сопоставимы, местами PHP оказывается быстрее. Так что есть неслабая вероятность, что в будущем Викимедиа мигрируют обратно.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

8. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+2 +/–
Сообщение от Аноним (??) on 07-Янв-15, 11:57
Вот и славно поработали, а то понимаешь "прочтите сообщение от Джимми Уэйлса"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+7 +/–
Сообщение от Аноним (??) on 07-Янв-15, 12:11
>HHVM (HipHop Virtual Machine) А что ты сделал для хип-хопа в свои годы?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–3 +/–
	Сообщение от Kodir (ok) on 07-Янв-15, 14:07
	> А что ты сделал для хип-хопа в свои годы? гггг :) Я так понимаю, Богдан Титомир и был основоположником ПХП?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	103. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от count0krsk (ok) on 09-Янв-15, 21:17
	>> А что ты сделал для хип-хопа в свои годы? > гггг :) Я так понимаю, Богдан Титомир и был основоположником ПХП? А разве это не Децл пел в свое время?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

14. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
Сообщение от Sylvia (ok) on 07-Янв-15, 13:05
не дождались PHP NG, а могли бы получить тот же двухкратный прирост на "самом обычном" PHP к октябрю 2015 (релиз)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+3 +/–
	Сообщение от Аноним (??) on 07-Янв-15, 13:49
	Некоторые вон реактос уже ждут 17 лет. Может быть, ну его, это ожидание? :)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	108. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+1 +/–
	Сообщение от EuPhobos (ok) on 10-Янв-15, 23:51
	> Некоторые вон реактос уже ждут 17 лет. Да ладно? Зачем? Для чего?.. почему?? Разве они не вымерли(выросли) ещё, так и ждут?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	19. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от бедный буратино (ok) on 07-Янв-15, 13:49
	и как там с совместимостью? если в обычном php только и успевают раздавать deprecated (некоторые вещи в рамках 5-й ветки успели и появиться, и прожить, и стать deprecated), то слово -ng не внушает доверия. а вообще - впервые слышу про этот ng. а хип-хоп вроде бы реально работает.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	36. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+1 +/–
	Сообщение от Sylvia (ok) on 07-Янв-15, 17:31
	PHP NG тоже уже реально работает, это текущая ветка разработки релиз планируется к октябрю, я тестировала php-fpm sapi, вордпресс вполне работоспособен, работает, как и обещано, в 2 раза быстрее проблемы - конфигурация пулов php-fpm не прогружается полностью, ну и расширения пока готовы не все, для меня важен xcache, который к сожалению даже не в PECL'e Вообщем люди стараются, в первую очередь - Дмитрий Стогов если что - новости были, на php.net есть страничка в вики (там и про совместимость есть, не все совместимо, расширения так вообще надо серьезно перелопачивать), не нравится NG, ок. PHP 7.0 А вообще хорошо что занялись наконец стандартизацией и повышением производительности, давно пора, а то популярность зашкаливает, а вот качество не дотягивает
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	46. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от Аноним (??) on 07-Янв-15, 20:02
	xcache - это стороннее расширение, которое никогда не было частью проекта php. В части опкод кэшера он больше не нужен - в ng встроенный opcache. В остальном, может быть, его автор (или кто-то еще) сделает его форк без опкод-кэшера на новом api, по аналогии с apcu.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	53. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Sylvia (ok) on 07-Янв-15, 22:02
	не надо мне рассказывать, автор не только не сделает форк без опкод кешера, но и планирует дальше его развивать, в частности сделать сваппинг на диск (фича была в eaccelerator) не все готовы принять opcache, если честно, я не знаю почему Xuefer не хочет продвинуть xcache в PECL, но бросать или как-либо менять проект он не собирается, он не из тех кто делали APC
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	78. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Аноним (??) on 08-Янв-15, 17:17
	а что не так с opcache?
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	86. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Sylvia (ok) on 09-Янв-15, 01:57
	нет свапа на диск -> требуется выделение большого сегмента памяти, сразу под все скрипты желательно удаление старых скриптов из памяти идет только через сброс всего кеша нет кеша переменных, соответственно придется тянуть redis,xcache,apcu xcache кстати как кеш переменных, даже в паре с opcache для кода, все равно рвет и memcached и прочие варианты при применении на одном сервере, за счет того что обращение идет к памяти а не по tcp, ну и в xcache есть namespaces (!)
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	100. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Аноним (??) on 09-Янв-15, 18:09
	Ну я имею ввиду чисто как опкод-кэшер. Со свопом понятно, хотя у меня даже крупные проекты на Симфони2 прекрасно в память помещаются. Для виртуалок или мини-серверов, согласен, актуально.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	74. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от йцу on 08-Янв-15, 13:14
	> PHP NG тоже уже реально работает, это текущая ветка разработки > релиз планируется к октябрю, я тестировала php-fpm sapi, вордпресс вполне работоспособен, > работает, как и обещано, в 2 раза быстрее > проблемы - конфигурация пулов php-fpm не прогружается полностью, ну и расширения пока > готовы не все, для меня важен xcache, который к сожалению даже > не в PECL'e > Вообщем люди стараются, в первую очередь - Дмитрий Стогов Что интересно - PHP7 даёт сопоставимую (по крайней мере) производительность при том, что в нём ещё нет JIT. Интересно, что получится когда его всё-таки запилят (а над этим, если судить по рассылке активно работают).
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	79. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Аноним (??) on 08-Янв-15, 17:24
	Учитывая динамизм php и как следствие невозможность предсказать, каким будет тип переменной через пару инструкций, плюс частое использование динамических вызовов по строковому имени функций и классов, от  jit в джавовском смысле толку будет мало, тут скорее нужен гибрид jit-а с рантаймом, вроде того, как в objective c в плане обмена сообщениями, ну и zval-ы оставить как есть кроме совсем простых случаев.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	94. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от йцу on 09-Янв-15, 11:20
	> Учитывая динамизм php и как следствие невозможность предсказать, каким будет тип переменной > через пару инструкций, плюс частое использование динамических вызовов по строковому имени > функций и классов, от  jit в джавовском смысле толку будет В плане типов - уже сто лет как существует type hints и активно используется для аргументов, сейчас аналогично внедряют для указания типа результата. Да, пока только для объектов и массивов, но активно обсуждается и для скаляров. К тому же в том же JS, например, вообще никак нельзя указать тип, однако, это не мешает использовать JIT (сейчас, если не ошибаюсь, все актуальные JS-движки компилируют код в рантайме). Вызов по строке - крайне редко используется сейчас, т.к. с появляением лямбд, а так же всяких ::class становится почти не нужным.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	87. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Sylvia (ok) on 09-Янв-15, 02:15
	так уже работоспособно , берем снапшот с git ( master ) и вперед на подвиги :D не в production естественно
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	88. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Graynder (ok) on 09-Янв-15, 02:51
	> так уже работоспособно , берем снапшот с git ( master ) и > вперед на подвиги :D > не в production естественно PHP, Wordpress - Тяп ляп и в production )
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	89. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Sylvia (ok) on 09-Янв-15, 05:46
	ну у большинства так и есть http://blog.bnkomi.ru/content/post/13855/vovka_32787390_orig...
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	92. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от йцу on 09-Янв-15, 11:08
	> так уже работоспособно , берем снапшот с git ( master ) и вперед на подвиги :D стоп, а разве JIT уже в мастере? Стогов вроде писал, что пока только работают над этим и NG - это первый шаг. Т.е. у них уже были какие-то наработки в плане just-in-time, но оказалось, что гораздо больший профит можно получить от оптимиизации аллокаций памяти + В рамках того же NG был проделан огромный рефакторинг, на основе которого и планируют добавить JIT. Разве нет? Я что-то пропустил?
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	93. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Sylvia (ok) on 09-Янв-15, 11:19
	ветку phpng уже отправили в master, да что там с JIT я пока не в курсе, большинство стандартных расширений (включенных в поставку) уже портировали
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	95. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от йцу on 09-Янв-15, 11:22
	> ветку phpng уже отправили в master, да > что там с JIT я пока не в курсе, большинство стандартных расширений > (включенных в поставку) уже портировали Ну да, про это в курсе. Но нет, JIT там пока нет. Не факт что будет в PHP7, хотя часто проскакивает в интерналсах, что та или иная новая оптимизация нужна для внедрения JIT в будущем.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	45. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Аноним (??) on 07-Янв-15, 19:57
	Совместимость на уровне php-кода - практически 100%, за исключением пары недокументированных хаков, эксплуатирующих особенности старой реализции. Сишные расширения - да, все надо портировать.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

17. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–8 +/–
Сообщение от бедный буратино (ok) on 07-Янв-15, 13:48
хип-хоп маньяки на острие атаки! ps. не взлетит. в смысле, завтра ещё 400 серверов потребуется для нормальной жизни.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+3 +/–
	Сообщение от Аноним (??) on 07-Янв-15, 13:50
	> ps. не взлетит. Уже взлетело и развернуто.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	43. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от Нанобот (ok) on 07-Янв-15, 19:25
	>не взлетит чтоб взлетело, попробуй его авиатопливом заправлять. а то на самогоне оно ясен пень не взлетит
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

23. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–2 +/–
Сообщение от manster (ok) on 07-Янв-15, 14:02
этот хихивм поддерживает последние фичи пыха?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	34. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от vitalif (ok) on 07-Янв-15, 17:10
	больше того он ещё и типизированный PHP поддерживает =)) под названием Hack...
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	55. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от SubGun (ok) on 08-Янв-15, 02:20
	Да. У меня завелся и взлетел портал без проблем. Проблемы возникли со сторонними модулями, типа predis.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

30. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
Сообщение от universite (ok) on 07-Янв-15, 15:18
>поэтому разрыв между PHP 5.6 и HHVM был бы не столь значимым Вместо миграции на новую версию php, они смигрировали куда-то вбок....
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

32. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–2 +/–
Сообщение от qwerty (??) on 07-Янв-15, 15:56
а где исходники?  хочу под слакварей попробывать
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	37. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Sylvia (ok) on 07-Янв-15, 17:34
	http://hhvm.com/ на i686 не работаеть, и не будет.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

35. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
Сообщение от th3m3 (ok) on 07-Янв-15, 17:28
За 9 месяцев можно было переписать всё на что-то более адекватное, чем php. И никакие костыли типо хип-хопов не понадобились бы. И хип-хоп этот, тоже не панацея. Чудеса он не творит, ибо php во все поля.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	42. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+4 +/–
	Сообщение от vitalif (ok) on 07-Янв-15, 19:19
	Ага, давай, начинай переписывать. Ты сначала посмотри сколько там кода, а потом говори. Там же расширений ещё over 2000
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	60. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от th3m3 (ok) on 08-Янв-15, 07:42
	А что поделать.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	63. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от йцу on 08-Янв-15, 09:11
	> А что поделать. Может попробовать перестать нести чушь?
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	96. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Kodir (ok) on 09-Янв-15, 15:28
	Если бы разрабы вики имели мозги, они сам проект никогда не начали бы на похапэхе, так что вы слишком лестного мнения об их возможностях :) Я б тоже переписал, тем более, что уже понаписана куча веб-движков на всех мыслимых языках.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

57. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–3 +/–
Сообщение от Dzmitry (??) on 08-Янв-15, 04:47
> время сохранения изменений сократилось в среднем с 6 до 3 сек Эээ. Я на жаве пишу веб-приложения, и у нас такие вещи считаются в миллисекундах. Если 500+ мс на выполнение реквеста -- это уже баг, надо фиксить, обычно меньше 100 должно быть. Теперь понятно почему Викимедия клянчит деньги на поддержку. Планету греет датацентрами.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	69. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+1 +/–
	Сообщение от gaga (ok) on 08-Янв-15, 12:07
	Верно ли я понимаю, что у вашего приложения также не меньше 20 миллиардов просмотров в месяц и десятки тысяч хитов в секунду?
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	82. "Проект Wikipedia перешёл на использование HHVM для..."	+1 +/–
	Сообщение от arisu (ok) on 08-Янв-15, 18:35
	> Эээ. Я на жаве пишу веб-приложения бывает, да. ну ничего, со стороны это незаметно обычно: если будешь молчать, окружающие будут считать человеком.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	97. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от Kodir (ok) on 09-Янв-15, 15:30
	> Эээ. Я на жаве пишу веб-приложения, и у нас такие вещи считаются в миллисекундах. +1! Запрос дольше 1 секунды - это уже дикость. Тем более, что у вики структура задачи проще, чем гугл.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	99. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от edwin3d (ok) on 09-Янв-15, 17:51
	>> время сохранения изменений сократилось в среднем с 6 до 3 сек > Эээ. Я на жаве пишу веб-приложения, и у нас такие вещи считаются > в миллисекундах. Если 500+ мс на выполнение реквеста -- это уже > баг, надо фиксить, обычно меньше 100 должно быть. Понимаете, запросы бывают разные, совсем разные ... я займу у Вас 5 мин. вот бы у меня случай, когда работали над оптимизацией ... ну скажем так - приложения. И была там подсистема, которая отвечала за генерация аналитики. Выглядело это так: Клиент (графики на d3.js) <> J2EE приложение <> БД Oracle Суть в том, что каждый клиент (а их было порядка 300-400 online) должны были получать свои персональные графики. А генерация данных для этих графиков peer client занимала порядка 2c. Причем это было именно то время, за которое отрабатывала хранимка на БД. Применять пул потоков для slow запросов такого рода было нецелесообразно, т.к. это непроизводительная трата ресурсов, потому мы добавили еще один backround слой, который для online клиентов в цикле постоянно генерирует данные, а запросы от клиента просто эти данные получают. Так вот это все рассказал к тому, что в реальности slow запросы есть в любой серьезном приложении и их наличие не есть признак плохих разработчиков. Не факт, что их видит клиент ... но ведь операция внесения изменений не простая, согласитесь - это не тупой UPDATE одной записи, там очень серьезная логика ...
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

58. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
Сообщение от Аноним (??) on 08-Янв-15, 06:02
древний движок википедии не тормозил на 64киб, а щас гамно. на андроиде в фирефоксе.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

59. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
Сообщение от Аноним (??) on 08-Янв-15, 06:03
форкать надо ето дело.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	98. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–2 +/–
	Сообщение от Kodir (ok) on 09-Янв-15, 15:31
	> форкать надо ето дело. ДАВНО УЖЕ. Лурк - наше всё. :))
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

64. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–3 +/–
Сообщение от Аноним (??) on 08-Янв-15, 10:27
Долго читаю здесь подобные разговоры. Насколько я понял, от качества языка зависит только скорость отладки. Скорость интерпретатора явно меньше, чем скорость "найтивного" приложения, поэтому со стороны сервера должно быть нормально скомпилированый сервер(не важно с какого языка). Таким образом, я полагаю, чем больше мы оптимизируем компилятор для сервера, тем больший получим "профит". Отсюда следует, что надо оптимизировать серверные компиляторы, а интерпретаторами пока пусть пользуются клиенты - типа - "хреновая скорость - куплю машину помощнее". У серверов(потому что это серверы) аппаратная часть поменьше, поэтому компилятор языка написать полегче. Попытки сделать нормальный сервер на машине с клиентскими возможностями ни к чему хорошему не приводят пока - только к бо-о-ольшим дебатам на opennet и на LOR. В чём я не прав?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	65. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–2 +/–
	Сообщение от Аноним (??) on 08-Янв-15, 10:42
	Дополню свое сообщение. От качества языка зависит, конечно же, не только скорость отладки, но и, возможно, качество сопровождения программы - чем менее популярный язык, тем сопровождение может быть хуже(а может и нет, если она написана достаточно качественно?) Поправлюсь: у серверов(потому что это серверы) аппаратная часть поуже - и если кто-то из своего смартфона на ARM пытается сделать web-сервер, то последнее время он "светится" на opennet, что грустно :(
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	67. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от edwin3d (ok) on 08-Янв-15, 10:58
	> Поправлюсь: у серверов(потому что это серверы) аппаратная часть поуже - Шире, причем сильно. И соседство PowerPC и x86 серверов вполне реальная картина   > и если > кто-то из своего смартфона на ARM пытается сделать web-сервер Вы не в курсе реального положения дел. ARM сервера - уже реальность. Начиная от ProLiant m400 до продукции "Рикор" И продукты набирают популярность, хотя на данный момент ориентация - нишевая. С силу ряда очевидных причин, не последняя из которых - эффективность энергопотребления
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	70. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
	Сообщение от Аноним (??) on 08-Янв-15, 12:10
	И всё-таки я пока не понимаю, почему серверная часть компилируется в лучшем случае в байт-код, а не в инструкции процессора.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	71. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Аноним (??) on 08-Янв-15, 12:17
	> И всё-таки я пока не понимаю, почему серверная часть компилируется в лучшем > случае в байт-код, а не в инструкции процессора. С точки зрения энергосбережения это было бы О-ГО-ГО
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	81. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Аноним (??) on 08-Янв-15, 17:45
	потому что "бутылочное горлышко" у серверов уже давно не процессоры, а ПЗУ и сеть ;)
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

102. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
Сообщение от Ящ (ok) on 09-Янв-15, 21:14
Жесть :) Стоило раз в позитивном ключе заикнуться про жабу...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

104. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	–1 +/–
Сообщение от Аноним (??) on 09-Янв-15, 21:21
Давно пора ее переписать на ноде-дж-с
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	107. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
	Сообщение от Ящ (ok) on 10-Янв-15, 08:12
	Шило на мыло.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

106. "Проект Wikipedia перешёл на использование HHVM для выполнени..."	+/–
Сообщение от Vitold S on 10-Янв-15, 03:38
Мне вот интересно, а когда уже напишут граматику MediaWiki на C и вкопилят в Си? Сколько еще ждать? Сколько еще смотреть на то как они кобяняться с PCRE и кучей каких-то костылей?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема