Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70992 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55822 invoked from network); 3 Jan 2014 19:41:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jan 2014 19:41:24 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.155 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.155 smtp155.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.155] ([67.192.241.155:40587] helo=smtp155.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2C/C5-12805-36217C25 for ; Fri, 03 Jan 2014 14:41:24 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp32.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 70EEF5026C; Fri, 3 Jan 2014 14:41:20 -0500 (EST) X-Virus-Scanned: OK Received: by smtp32.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 1DF0E50203; Fri, 3 Jan 2014 14:41:20 -0500 (EST) Message-ID: <52C7125F.204@sugarcrm.com> Date: Fri, 03 Jan 2014 11:41:19 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 CC: zhifeng hu , PHP internals References: <52C6E2F2.2020408@ajf.me> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Is it possible introduce HHVM into PHP kernel tree? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Syntax: Yes, HHVM is an equivalent engine.* > Runtime Library: This is the big gap. PHP has a bunch of bundled From what I understand, there's also a certain gap in semantics - while hhvm accepts PHP syntax (or most of it), it doesn't do the same with it as PHP does. With the result that if you're going to run real life app on it, there are chances that it wouldn't work unless it was developed against hhvm from the start. Building hhvm is right now not for the faint of heart either, at least compared to how easy it is to build PHP on any reasonable supported platform. E.g., for centos you need to manually rebuild whole gcc toolchain, and the same for mac os x 10.8 (earlier versions not even supported). Also, while I greatly appreciate the efforts of folks at Facebook to make the engine available and working, I am still not sure organizationally how important it is for Facebook that this engine is running anything but Facebook, or, even wider, everything (PHP) that is not Facebook. I.e. it may be important for some people within Facebook as their project, but organizationally it is a project to run Facebook, isn't it? Which implies some decisions when they need to be made, and corners cut when they need to be cut, etc. I understand hhvm works really good for Facebook, and may even work fine with some lucky PHP apps, but the last 10% is the hardest. Does it make sense to make the investment? I of course have no idea what Facebook as an org answers to this question... -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227