Pull to refresh

Comments 159

Это был Котопёс, не зря же ему пила в руке :) Символично, кстати.
В связи с этим KPHP поддерживает не все возможности PHP, в частности, в нем отсутствует ООП, за исключением некоторых объектов стандартной библиотеки.

ВК имеет не ООП-шную структуру?
Да, в коде ВК (как мне известно) не используется ООП.
Нет, от ООП было решено полностью отказаться еще во времена использования обычного PHP по соображениям производительности
В связи с этим было бы интересно узнать об архитектуре проекта с программной точки зрения. Надеюсь, когда-нибудь и такая информация станет доступна )
Поверьте, Вам не было бы интересно узнать об архитектуре проекта с программной точки зрения =))
В любом случае было бы интересно узнать, что стоит за одним из самых посещаемых сайтов. Сегодняшняя новость, например, меня именно по этой причине очень обрадовала.
Дык как обычно, подзатыльники и мат.
Выиграли 1% производительности ПО, потеряли 50% производительности разработчиков? Да и как обычно узкое место БД/др. хранилища, потратив те ресурсы, что были потеряны при отказе от ООП на развитие именно БД/хранилищ/сети и т.д., не был бы выигрыш заметно больший?
потеряли 50% производительности разработчиков
Цифры с потолка? Сравните численность штата программистов ФБ и ВК, например.
Сомнительны цифры в 50% производительности разработчиков, ООП не панацея, писать понятно красиво и быстро можно и в функциональном стиле.
Как показывает практика 90%++ кода которое использует синтаксис классов на PHP не ООП ни разу, а всего лишь некоторое подобие неймспейсов и странные попытки упоротых абстракций. А там такое можно накрутить, что ой ой ой, и что лучше бы уж сборники функций. Уж времени на разбор кода тратилось бы меньше, а значит и производительность была бы выше.

Да и наверняка дело не в производительности и экономии серверов, а во времени отработки скриптов и отдачи данных пользователям.
Функциональном? Процедурном, наверно.
Я начинал на паскаля, там было разделение процедур и функций) Поэтому подсознательно я это называю так) Хотя вы правы, не стоит отходить от общепринятых терминов, спасибо.
Вас удивляет, что высоконагруженные проекты стремятся не юзать ооп?
Почему вы так считаете?
Потому что ООП заставляет трактовать всё как объект, создавая в большинстве случаев кучу бессмысленных абстракций, не имеющих позади себя никакой аналогии в реальном мире. В итоге рождаются всякие странные классы вроде BlaBlaManager, BlaBlaBean, BlaBlaContext и прочая хренотень. Когда нужны просто функции, которые принимают на вход A и выдают на выходе B, люди городят какие-то таинственные паттерны.
По-моему из Вашего же комментария следует, что не ООП плох, а то что
люди городят какие-то таинственные паттерны
Ага, Запорожец не говно, просто люди не умеют на нём ездить.
Потому что ООП заставляет трактовать всё как объект

В Java возможно, в PHP никто не заставляет: ООП, ПП и ФП существуют вместе и не просто параллельно, но интегрировано — можно в ФВП передать объект, который вызывает процедуру.
ФВП не делает язык функциональным.
Просто надо избавится от чепухи про «ООП это эмуляция объектов реального мира».
ООП вообще-то и задумывалось как эмуляция объектов реального мира. А потом сделали Джаву, где чей-то воспалённый мозг решил, что всё — объект, и тогда пришлось притягивать к ООП и всё остальное, городить дырявые абстракции над тем, что не имеет физического смысла.
Про «объекты реального мира» это одно из главных заблуждений, которые приходится выбивать из новичков, начитавшихся книжек со стандартным введением. Пытаются всё свести к студентам, унаследованным от человека.
Бедные новички, раз вы пытаетесь им вдолбить в голову то, что всё является объектом, включая даже то, что им не является. Не кажется, что заблуждаетесь вы, а не они?
Не могу сказать наверняка. Программирование, это не таблица умножения и не новости на первом канале. Тут так точно не определишь где заблуждения, а где истина.

Могу только ориентироваться на результат. После того, как люди избавляются от этой бредовой установки, они начинают намного быстрее и эффективнее решать поставленные задачи. И, наконец, получать от этого удовольствие. Что даёт мне небольшу надежду на то, что я на верном пути.
А вы случайно не путаете реальный мир и физический мир? Вот примеры объектов, у которых есть соответствия в реальном мире: ASTNode, WebBrowser, InetAddress, Cache, NetworkClient. Всё это можно себе представить в голове, и для этого даже не надо лезть в документацию. А вот примеры объектов, которым трудно что-то сопоставить: IOUtils, DocumentBuilderFactory, CommandHandler, FileSystemProvider, BeanContextProxy. Все эти классы создаются в основном лишь для того, чтобы преодолеть ограничения, которые ООП само себе понапридумывало.
В джаве был период, когда восторженно городили фабрику на фабрике. Сейчас уже почти всем понятно, что это был перебор, «ООП головного мозга» переболели, становятся популярны более прагматичные фреймворки, такие как Play.
А «всё — объект» придумали задолго до Java, еще в Smalltalk (где, в отличие от Java, действительно всё).
Лично меня несколько удивляет. В общем случае. С учётом того, что язык программирование в вебе самая масштабируемая часть.
В случае вконтакта ничего не знаю, может им и так хорошо.
Меня например удивляет. Ребята имеют на руках транслятор из php-кода в сишный и жалуются на то, что ООП в php медленное. Ничего не мешает превращать ООП'шное представление в любое другое, какое вздумается после парсинга кода.

Вот на этих мыслях я вспомнил свой первый сайт и его код — его переписать себе дороже. А ведь вконтакт — это первый сайт, который начал писать Павел (да ведь?) и сейчас, подозреваю, проще запилить транслятор, нежели переписать =)

Так что про ооп vs. скорость — считаю просто отмазкой или хорошим предлогом. Гитхаб или Твитч вообще на рельсах (очень тяжёлый фрейм для очень медленного языка) написаны и ничего, работают вполне себе нормально.
Твиттер работает на Scala стеке.
Всё верно, twitch. Крупнейший в мире видео-стрим ресурс и партнёр, например таких компаний как Близзард.
О. Тогда прошу прощения :) Деревня я — не слышал про Твитч, думал вы так Твиттер искаверкали.
Твиттер (так же как и Групон) тоже начинал с рельс, но это ни для кого не секрет наверное =) Потом уже перешли на что-то более быстрое.
Не первый — есть еще durov.com.
Ну он на чистом html же, а я об опыте php. Так что думаю можно не считать
По поводу «парсинга PHP кода» и генерации C++ кода. Не забывайте, что С++ язык со статической типизацией а PHP — нет. И трансляция динамического языка в статический вообще говоря проблема неразрешимая в общем смысле. Приходится применять кучу эвристик чтобы сократить количество типов void* в генерируемом коде. И Facebook и MathWorks делали нечто подобное и насколько мне известно, поле это почти не паханное — серебряной пули нет.

Так вот. Теперь представьте ОПП во всей его красе (sub-type полиморфизм как минимум) и все становится еще печальнее.
К тому моменту, когда KittenPHP начинали разрабатывать, классы в коде VK использовались разве что как пространства имен. От них было легко отказаться, и до сих пор они никому особенно не потребовались. Меня самого немного удивляет как они так справляются =)

На самом деле в KittenPHP классы были бы даже быстрее массивов. Добавить ООП по модулю некоторых ограничений не очень сложно. Просто в условиях VK, это никому бы не пригодилось.
Меня удивляет. Когда переписывал свой фреймворк с древнего процедурного стиля на ООП, то получал местами очень приличное ускорение. ООП позволяет программировать быстрее, абстрагироваться от деталей и поэтому реализовывать более сложные, но эффективные в плане производительности механизмы.

Когда 9-летнему Гауссу предложили посчитать сумму всех чисел от 1 до 100, он не стал как другие очень быстро-быстро складывать всё подряд, он подумал и вывел более сложную формулу, по которой и получил результат в десятки раз быстрее одноклассников :)
А что мешает реализовывать эффективные алгоритмы без использования ООП? Haskel, erlang и пр. не позволяют реализовывать масштабные проекты? ООП — это парадигма, людям проще думать объектами, потому и прижилось. Процедурное и функциональное программирование, чаще всего, эффективнее как в плане скорости, так и в плане потребляемых ресурсов.
1+100 = 101
2+99 = 101
И так далее, насколько я помню историю Гаусса
то бишь одноклассники были в пролёте ещё при гауссе )
ах-ха-ха, какой крутой коммент остался без внимания xD
Мне кажется эту остроумную шутку многие пропустили.
Вспомнился старый анекдот: «Я тут слышал новую шутку про UDP, но боюсь до вас не дойдет...»
Не пропустили, просто апнуть кармы не хватило :)
Не удивляет, но проблема тут не в ООП.

1. Парадигма не имеет никакого отношения к нагруженности-ненагруженности. Есть множество примеров эффективного масштабируемого ООП-кода и неэффективного немасштабируемого процедурного.

2. Устоявшееся мнение, что объекты в php тяжелее, чем массивы, неверно для современных версий php. А уж при написании транслятора в c++ это вообще не аргумент.

3. По публикуемому vk коду видно, что их сотрудники предпочитают олдскульный процедурный стиль, и не считают ценности объектного проектирования важными. Их право делать так, как они считают нужным — важен конечный результат. Но я бы туда работать не пошел :)
А для чего, на примере ВК, им требуетя ООП? Чтоб инпуты с формами за ООПэшить?
Чтобы иметь более удобную, заменяемую структуру, например?
ООП для этого — не необходимое и не достаточное условие.
А есть необходимое и достаточное условие? Интересно послушать
Прочитал я, такой, «Совершенный код» и умничаю. Вряд ли. Необходимое — это, видимо, голова на плечах. Достаточное — всё индивидуально. Но конкретно ООП — это просто один из способов упорядочить код. Городить при этом фабрики фабрик чертежей абстрактных фабрик молотков может быть необязательно.
А кто предлагал ВК городить «фабрики фабрик ...»? Вы считаете, что с ООП можно только городить «фабрики фабрик ...»?

Мой пукан готов бомбонуться от таких заявлений ))
Это была отсылка. Конечно, не считаю. Я к тому, что ВК уже много лет развивается без ООП. Как и Линукс, кстати. Т.е. как минимум два проекта нашли способ разработки, который не ООП, но который работает. Точно также, многие проекты ООП как бы следуют, но так, что лучше бы уж писались на Фортране и всем было бы проще. Надеюсь, свою мысль донес.
Эмм… если честно нет ) Ну да ладно. Всему свое место, даже ООП, с этим согласен.
В ядре linux используется ООП. Отсутствие синтаксического сахара не является преградой для использования объектного подхода.
Если Вконтакту с его супер навороченной логикой не нужен ООП, то мы с вами на своих бложиках про кота Василия вообще должны plain-html писать.
HTML-блоггинг посредством гитхаба — прямое тому доказательство.
Многие гитхаб-блоггеры используют Jekyll, а в нём используется Liquid для описания шаблонов страниц. Есть объект-сайт, в нём объекты-посты, объекты-теги… Довольно жирный намёк на ООП.
Вы всерьез думаете, что ООП и другие модно/популярные возможности обязательно необходимы для успешного проекта?
На одной из конференций затрагивали эту тему. Там подтвердили что они не используют ООП, т.к. это ускоряет выполнение кода.
Наконец-то ВК что-то отдали опен сорсу. Как делать бизнес на нём, так ОКи. А как хотя бы встречу программистов провести в офисе — так фиг, мы лучше встречу дискуссионного клуба проведём и т. п.
Спортивное программирование — очень далеко от реального. В любом случае, тут не опенсорс.
Я отвечал про жалобу на отсутствие встреч программистов. И да, какая разница, где их проводить? В офисе ВК или в старбаксе?

Насчет опенсорса — ну, да, не выкладывали, это нарушало лицензии? Я не защищаю ВК, я просто не понимаю ваших претензий.
Ну я говорю о бытовых понятиях справедливости. Например, если кто-то помог тебе в трудную минуту, то когда у тебя всё очень хорошо, а у твоего помощника проблемы — логично помочь (хотя отказ помогать и не будет нарушением каких-то законов).

Посмотрите на другие крупные компании: Яндекс выложил кучу всего, регулярно проводит конференции, делиться опытом; Mail.ru: github.com/mailru; Одноклассники: github.com/odnoklassniki; Фейсбук выложил кучу кода, регулярно что-то рассказывает; Гугл выложил кучу кода, помогает другим проектам деньгами и Summer of Code; Групон: github.com/groupon (русский Групон выложил тоже кучу проектов в рамках Злых марсиан).
Ну вот и ВК подтянулся. В чём претензии?
Могли бы и раньше, учитывая сколько у них было ресурсов и денег.
Сравните возраст ВК с возрастом Мэйла и Одноклассников.
Да это просто праздник какой-то ) добавьте плз к каждой технологии количество нодов и количество задач, которые обрабатываются этими технологиями, вот это будет интересно
Да тут половина ВК ушло в opensource, спасибо ребят!
Нет это лишь часть набора наших инструментов разработки, но уверен, что это действительно большой вклад в развитие OpenSource
Ну, теперь то уж точно любой сможет сделать свой ВКонтакт с блекджеком и котятами.
Давно ждали, выложить в опенсорц наработки по базам данных обещали еще несколько лет назад. Как я понимаю, с тех пор многое изменилось, но за опенсорц — респект!
UFO just landed and posted this here
Facebook срочно перепиливает свои решения на новые рельсы!
UFO just landed and posted this here
Офигеть, есть даже документация на русском!
Только на русском, что скорее минус, потому что затрудняет обмен опытом с большей частью сообщества.
Это плюс, теперь ребята с забугра пусть поломают головы над документацией, что неминуемо сблизит два народа)
Документация на Nginx тоже изначально была только на русском.
Потом перевели на английский и другие.
Ой, вряд ли. При всем уважении к инициативе ВКонтакте, этот набор довольно специфичных для соцсетей и конкретно для самого ВКонтакте компонент несопоставим по полезности с nginx. Учитывая, какое есть на Западе предубеждение против всего русского, которое влияет и на nginx, а еще учитывая тамошний имидж самого ВКонтакте как клона Фейсбука, не думаю что найдутся энтузиасты развивать англоязычное сообщество.
Да нет никаких предубеждений, IT-специалисты — не политики. Изначально, когда еще не было nginx inc., документация переводилась энтузиастами на вики, и уже тогда nginx вытеснил lighttpd. Сейчас nginx — самый популярный вебсервер для нагруженных сайтов в мире.
Очень классно! Еще вчера планировали писать на PHP новый проект, а сегодня выходит kPHP. Спасибо огромнейшее! Это очень большой вклад в сообщество разработчиков.
Зачем, ассемблер же быстрее. Вы же понимаете что там ни разу ни php, а функциональная линейно-процедурная приблуда. Тем более уже давно есть HHVM, который даже поддерживает некоторые фреймворки, есть phalcon — как расширение. Вот только надо ли оно вам?
Функциональная? O_o В PHP есть зачатки функциональщины, но подозреваю, что в KPHP их ещё меньше.
Товарищ имел ввиду процедурные приблуды.
Процедурные он написал отдельно.
И всё же ограниченность синтаксиса kPHP делает в тестах фаворитом HHVM. Скорость HHVM сопоставима, в принципе, со скоростью PHP (Zend), но при этом он почти на 100% совместим, что в большинстве не вынуждает каким-либо образом менять исходный код.
А kPHP — слишком узкоспециализированная штука получается. Вот когда будет поддержка ООП, и синтаксиса на уровне PHP 5.4 — тогда и посмотрим на скорость.
Полностью поддерживаю. Хочу посмотреть скорость проекта на Phalcon (ядро) + HHVM (бизнес-логика) с полной поддержкой языка, против kPHP с подходом, от которого отказались лет 5-6 назад.
Опечатка, сопоставим, конечно же, с kPHP.
Абсолютно те же мысли, зачем kPHP если HHVM имеет почти ту же скорость, но близкую к 100% совместимость с оригинальным PHP?
KPHP (как и HHVM) даром не нужны, а вот за все остальное огромное спасибо!
Что значит «как и HHVM»? Вопрос: Что лучше, сайт или очень быстрый сайт, жрущий меньше оперативы и процессорного времени? Разница между ними всего лишь в одном. Во втором случае потратили 30 секунд и написали apt-get.
Заглянуть в composer.json и удалить оттуда всякий хлам, и переписать нормально сайт — вот от чего сайт точно будет «жрать меньше оперативы и процессорного времени». От одного apt-get install hhvm у вас разве что только установленных пакетов на 1 больше станет, а больше ничего не изменится. Не вводите людей в заблуждение.
Ну, допустим, я не писал «apt-get install hhvm», там много всякого надо подставить через apt-get.

Цель комментария не в том, как поставить хип-хоп — мануалов на просторах интернета полно, а в том, что это не сложно и ничего переписывать нигде не надо в подавляющем большинстве случаев: www.hhvm.com/frameworks/ в отличие от представленного в топике. И я буду только рад (да простят меня ВК-разработчики), если не найдётся такого человека, который решится написать крупный проект в процедурно-лапшевидном стиле, напичканный глобалсами, как чаще всего и бывает у начинающих. Прошу заметить, что я не имел ввиду то, что любой процедурный код ужасен, просто он куда больше поощряет «кодоблудие», нежели прототипный, оо или иные подходы.
и в ООП тоже много говнокодеров
Знаете, что мне это напоминает?

Вот написал ты заявление об увольнении, осталось 2 недели отработать. И ты разгребаешь стол, уносишь домой любимую чашку, выкидываешь барахло в мусорку, раскладываешь рабочие файлы по правильным папкам, чтобы от проклятий сменщика не «икалось».

Знакомоме ощущение, да?

Вот что-то мне кажется, через недельку-другую мы прочитаем, что гендиректор ВК «тут больше не работает». А выкладка на Гитхаб — это «дембельский» привет новым акционерам.
Вот еще на хабре осталось начать постить новости о войнах Дурова с акционерами. Спасибо, не надо. Хватает того, что каждое СМИ не упускает возможности написать очередную новость по этому поводу.
Очень круто.
Но местами, видно отсутствие времени на отделение от кода ВК. (Пользователь 6492)
UFO just landed and posted this here
Почитал код бенчмарков, нашел «применимыми к реальности» только hash*, а в них kPHP не так уж и быстрее HHVM (и самого PHP), закрыл код бенчмарков. Про поддержку только 1251 и UTF-8 в mbstring я вообще молчу. Про бенчмарки с фиксированным числом итераций тоже промолчу (компилятор C++ спокойно справится с простейшей задачей выкидывания «ненужного» кода).
Стоит заметить, что этот бенчмарк взят (с незначительными изменениями) из исходников PHP (php-src/Zend/bench.php)
Он проверяет основные конструкции языка от производительности которых зависит производительность всего кода, но конечно не претендует на какую любо универсальность.
Любые бенчмарки кроме реально используемого кода немного условны. В том смысле, что они могут не иметь никакого отношения к реальной жизни.

Даже без фиксированного числа итераций компилятор C++ может многое упростить. Например в тесте nestedloop С++ (и соответственно KPHP) оптимизирует вложенные циклы в вычисление простой формулки.

Про mbstring справедливое замечание. Я бы удалил оттуда ещё и поддержку cp1251, потому что чаще всего те, кто используют его вместо utf-8, неправы.
Большое спасибо за вклад в open source.

Хотелось бы также увидеть сравнения с аналогами, хотя бы поверхностные. Например:
PMemcached, Lists, Lists-X vs Redis
Search vs Sphinx, Solr (Lucene)
Storage vs даже не знаю, не понял что это. OpenStack Swift? GlusterFS? Или это больше похоже на виртуальный HDD?

Правильно ли я понял, что Hints это штука, которая быстро делает WHERE name LIKE 'Иванов Ива%'?
Hints.

Скорее WHERE name1 LIKE 'ива%' OR name2 LIKE 'ива%' OR name3 LIKE 'ива%'… с сортировкой по релевантности.

Причём Иванова Василия мы найдём по любому из следующих запросов:
ива васи
васи ива
iva vasi
bdf dfcb
шмф мфыш
и в

и т.д.
Скажите, есть ли план не только выложить, но и поддерживать выложенные проекты, принимать пулл реквесты? Или дальнейший цикл — это форки, кто во что горазд?
Думается мне таки будущее за zephir/hhvm. Отказываться от ООП — довольно прискорбно. Если хочется скорости — можно плюсы взять и написать парочку оптимизированных функций
По мне это какой-то пхп-ный си. Слишком специфичный продукт.
Что вы как маленькие. KPHP используется исключительно там, где нужна высокая производительность — на фронтенде.
По сути это шаблоны, компилируемые в http сервера.

Под ним — слой сервисов, которые обрабатывают данные, обеспечивают взаимодействие с хранилищами и готовят данные для фронтендов. Понятно, сервисы написаны на нормальных языках ООП. Ибо гораздо дешевле поставить еще одну ферму апликейшн серверов, чем оплачивать работу программистов по поддержке простыней. А без ООП там будут ого-го какие простыни и костыли. VK скрывает правду.
Все определяет масштаб. Работа программистов может быть дешевле аренды N серверов.
Я бы даже сказал «N ферм апликейшн серверов». При суммарном количестве серверов в районе 25 тысяч каждый сэкономленный процент — это, условно, 250 серверов. VK же использует универсальные серверы.
Странно, но простыни и костыли как-то проще и дешевле в поддержке, особенно при наличии документации. По моему скромному опыту.
Нету этого слоя сервисов, написанных на нормальных языках ООП =(
Я, может быть, проглядел это в статье, но с какой версией PHP проводилось сравнение в тестах?
Производительность PHP как бы несколько отличается от версии к версии )
спасибо, будем изучать и внедрять
А куда? Что за специфические задачи?
HHVM и прочее не внедряли, а вот КРНР срочно всем понадобилось внедрять?
когда-то мне нужно было внедрить фейсбуковский движок, но тогда они не поддерживали монгу. Пришлось шаманить…
не хочется наступать на грабли, ну прежде чем внедрить — надо знать, что это за зверь
по этому будем изучать…

Смотрю пхп-код и такая ностальгия, как будто на 10+ лет помолодел — практически PHP3 :)
1. Выражаю благодарность VK за KPHP.

2. Когда вы делали тесты, вы учли, что у HHVM есть стадия разогрева и реальные результаты надо снимать после хрен знает какого по счету прогона? Напишите подробнее, как тестировали HHVM.
Учли конечно. Это данные где-то 12-ого запроса к серверу. По умолчанию на разогрев происходит во время выполнения первых 11-ти запросов.
На 12-ом заметен скачок с 3.5 до 0.44 секунд.
Похожих результатов можно добиться простым однократным запуском hhvm с параметром -v«Eval.Jit=true». Учитывая специфику теста, на саму компиляцию уйдет совсем немного времени и результат будет около 0.49 секунд.
В таком случае все круто. Буду разбираться с KPHP.
Еще вопрос вдогонку… А вы не производили замеры потребляемой памяти KPHP и HHVM? Ведь потребление памяти для high load тоже важно, но в тестах производительности этот момент часто упускают.
Вконтактовцы, пожалуйста, не поленитесь и сделайте документацию KPHP для обычных (не гуру) пользователей. Что-то типа «getting started» для тех, кто в танке…

Я попытался было разобраться, но не нашел никакой технической инфы про KPHP. В вашем репозитории в папке kphp-kdb/docs/ru/ лежит документация только для базы данных, а про KPHP ничего нет.

У HHVM документация тоже не ахти, но она все же есть. И есть еще собранные бинарники для популярных дистрибутивов. Если бы вы такое сделали, вообще было бы шикарно.
UFO just landed and posted this here
Скоро нас захлестнет волна сайтов написанных школьниками на «движке от ВК».
Лопоухим клиентам будут втридорога «втюхивать» сайты-визитки, на новом, навороченном движке, от самого ВК.
Не раньше, чем вы напишите «getting started» и сделаете пакеты для популярных ОС.
Да и вообще, сейчас школьники смотрят скорее в сторону навороченных ООП фреймворков, что для PHP, что для других языков.
Такое ощущение, что вы своих программистов, которые писали KPHP, не выпускали из офиса, пока они доку не накатают и код не поправят.
Документация написанна на плевок в OpenSource сообщество. Вот по этому я и не люблю русских программистов в OpenSource сообществе.
Без паники. Теперь, когда есть документация, ее можно и улучшить, в т.ч. силами сообщества.
У меня получились менее убедительные результаты в этом бенче на одной машине:

KPHP: 0.118
HHVM 2.5: 0.271
PHP 5.5.9: 1.982
PHP 5.3.28: 2.524

Проверить на чем-то более реальном нет возможности, поскольку «привет ООП».

Прирост скорости в 2 раза относительно HHVM в этом синтетическом тесте при таком урезанном функционале PHP не впечатляет, особенно если учесть, что в этом бенче производится ничто иное, как числодробительные операции и копирование блоков памяти в больших циклах, которые прекрасно оптимизирует компилятор gcc, в том числе не выполняя ничего вообще. Это легко заметить, если немного изменить код, чтобы результаты вычисления были где-то использованы. Другими словами, этот двукратный прирост — это заслуга gcc, а не KPHP.

Прироста в 7-9 раз в случае HHVM хватает с головой, при этом остается полноценный набор возможностей PHP уровня 5.5 с ООП и другими плюшками, и можно выполнить любой существующий код без изменений.

На самом деле ребята из команды HHVM уже проходили этот путь и у них в блоге доходчиво объясняется, почему трансляция PHP в C++ — это пройденный этап.
Числа, указанные в статье получены при компиляции с ключом -O3, а в выложенных исходниках она по-умолчанию происходит с ключом -Os
При желании можно исправить KPHP/tests/Makefile и пересобрать bench.php, предварительно удалив директорию в которую происходила компиляция. По-умолчанию это KPHP/tests/kphp_tmp.

Написание jit компилятора несколько более масштабная задача, чем написание транслятора. В частности его разработчикам придется проделать весь тот путь, который прошел gcc. И если gcc что-то оптимизирует, а HHVM нет, то только потому что в HHVM этот путь пройден не до конца.

Я не вижу никаких плюсов для VK в подходе с виртуальной машиной. Работать она будет медленней, усилий и ресурсов на нее пришлось бы потратить в разы больше.
Но конечно я понимаю, что всех интересует применимость KPHP к их задачам, а не только к VK.
Интересно, зачем нужно было писать транслятор, который, объективно говоря, можно применить в единичных случаях?
Почему нельзя было просто переписать все на С и облегчить себе поддержку проекта?
Всё равно пришлось бы городить каким-то образом песочницы. Когда случается рантайм-ошибка в PHP-коде — ничего страшного. Когда случается segmentation fault в сях — ломается всё.
xчто-то не получилось создать… все библиотеки создались объектные файлы,
сделал make kphp но результата ни какого.
не могу найти исполняемый файл kphp2c
все вопрос снят, разобрался… майк немного страдает отсутствием диагностики
Добавьте сравнение с HHVM Hack, который теперь полная копия KPHP.
А есть где-то тесты для разных CMS?
Или вообще нереально чтобы kittenPHP + Magento скажем?
Тестов к цмс нет. kPHP не совместим с PHP. kittenPHP + Magento нереально без портирования.
Позвольте, почти совместим с PHP 4ой версии! Так что в теории можно попробовать запустить код 2000 года производства ;)
Я на 99.9% уверен что не совместим он с PHP 4.
Я так и думал. ;0( а жаль… ускорение маженты -золотое дно
Скоро выйдет новый PHP, там его ускорили + вроде как HHVM стал почти совместим с PHP, можно его попробовать.
Sign up to leave a comment.