Facebook为什么将PHP代码转换为C ++？[关闭]

42

我读到Facebook是从PHP开始的，然后为了提高速度，他们现在将PHP编译为C ++代码。如果是这样，他们为什么不这样做：

只是用C ++编程？按下将PHP移植到c ++代码的魔术编译器按钮时，肯定会出现一些错误/错误，对吗？
如果这个令人印象深刻的转换器运行得很好，为什么还要坚持使用PHP？为什么不使用Ruby或Python之类的东西呢？注意-我随机选择了这两个，但是主要是因为几乎每个人都说用这些语言进行编码是一种“乐趣”。那么，为什么不开发一种超级出色的语言，然后点击神奇的c ++编译按钮呢？

— 用户名
source

12

这两种选择都可能意味着淘汰所有PHP代码，特定于PHP的工具和专业知识，一半的支持基础结构等，这些都是从头开始的。

为什么？如果您可以将代码转换为C ++，那么肯定任何人都可以使用自己喜欢的语言，单击转换按钮，并将其提交给C ++代码库。没有？

— user72245 2012年

7

不会。编译器总体上会产生有效但丑陋且不自然的代码，并去除诸如变量名，注释之类的内容，更不用说各种抽象了。在很大程度上，这是不可避免的。尽管有一些项目旨在实际转换为另一种语言的可维护代码库，但问题却要困难得多，尤其是在使用多种不同语言的情况下。同样，即使假设完全习惯的C ++出现了，从事代码库工作的每个人都必须学习C ++，否则将被解雇并由了解C ++的人代替。然后您仍然没有解决工具问题。

1

另外（我自己发现了这个，但是这与我的直觉和我在其他动态语言实现中的经验相吻合）请注意，PHP-to-C ++编译器正在逐步淘汰，并被称为HHVM的字节码解释器+ JIT取代（后来作为同一个伞项目的一部分进行了开发），它的性能大大超过了该项目，并且限制较少。见github.com/facebook/hiphop-php/wiki

@Delnan：错误的编译器会产生难看且不自然的代码。但这并非不可避免。看一下Smart，它可以编译为JavaScript。除非您打开混淆和/或缩小功能，否则输出的可读性很强。 <snark>（只要JS可以被称为“可读”，就可以了。）</snark>

— 梅森·惠勒

65

他们没有。至少现在没有了。事实证明，这样做会导致太多问题，包括部署难题，并且首先消除了使用脚本语言的主要优势之一-能够更改脚本而无需重新编译-因此他们将HipHop系统改造为具有透明JIT阶段的VM体系结构，并且不建议使用C ++编译器。

有趣的是，显然，这样做的速度（大约是性能上）是原始C ++反编译方法的两倍。

— 梅森·惠勒
source

4

我从中得到的是，Facebook很难平衡业务需求和开发人员功能之间的时间。有趣的是，尽管我会补充说，从JIT解决方案获得优于本机解决方案的性能只是意味着他们的PHP-> C ++ jiggerypokery实际上是裤子。

— 詹姆斯

7

@James虽然我怀疑“ HipHopc”是有史以来最强大的优化编译器，但特定的结果并不能说明它们在编写编译器时很烂，而只是表明动态语言的静态编译远不如动态编译有效。确实知道如何编写优化编译器的人们反复发现这是对的。JIT编译器可以轻松执行大量优化。一个AOT编译器（无需非常昂贵的整个程序分析）几乎可以做很多事情，而不必消除解释本身的开销，而无需实际消除动态性。

2

@delnan嗯，是的，如果您通过指出AOT编译器的整个要点（有很多时间来进行分析）来削弱AOT编译器（整个程序分析）的主要好处，那么可以肯定，它不会与从事JIT擅长的工作（快速的Peekhole优化）。但这不公平，是吗？

— 爱丽丝

2

@delnan这根本不是真的，或者至少在思想上是不诚实的。与AOT相比，JIT的时间非常有限。Java编写了有关寄存器分配器的论文，这些论文虽然不理想，但对于JIT使用来说足够快。使用SSA可以免费进行大量优化，这是大多数JIT难以跟上的。AOT可以使用不复杂的经过验证的类型推断算法（Hindley–Milner和W算法），而JIT绝对不能免费获得它，而要在内存方面付出成本。JIT可以更好地进行一些优化，而AOT也可以。

— 爱丽丝

1

@Alice我们正在谈论高度动态的语言。对于像Python或JavaScript这样的语言，没有简单有效的AOT（即静态）类型推断算法。有许多有效的复杂在线/运行时算法（例如，在SpiderMonkey中使用的算法），而有许多复杂的AOT算法（例如Starkiller）到目前为止都无法证明自己是有效的。算法W甚至还没有开始解决动态语言的复杂性。

34

Facebook的高级工程师Zhao Haiping Zhao可能最能回答您的问题。

HipHop以编程方式将您的PHP源代码转换为高度优化的C ++，然后使用g ++对其进行编译。HipHop以语义等效的方式执行源代码，并牺牲了一些很少使用的功能（例如eval（））以换取更高的性能。

解决这些低效率问题的一种常用方法是直接在C ++中将PHP应用程序的更复杂部分重写为PHP扩展。这在很大程度上将PHP转换为前端HTML和C ++中的应用程序逻辑之间的粘合语言。从技术角度来看，这很好，但是可以大大减少能够在整个应用程序上工作的工程师数量。

博客文章的其余部分都是不错的读物，我建议您这样做。它提供了一些有关Facebook处理的编程挑战以及它们如何尝试解决这些问题的见解。

— josh3736
source

7

请注意，这已经过时了。那是他们的第一次尝试，但是Facebook不再这样做。请在下面查看我的答案。

— 梅森惠勒2012年

@MasonWheeler-很棒的链接和更新。

19

只是用C ++编程？按下将PHP移植到c ++代码的魔术编译器按钮时，肯定会出现一些错误/错误，对吗？

没错，但是使用C ++进行编程将需要替换其整个现有代码库-这个想法因其完全愚蠢和毁灭性而享誉世界。

如果这个令人印象深刻的转换器运行得很好，为什么还要坚持使用PHP？为什么不使用Ruby或Python之类的东西呢？注意-我随机选择了这两个，但是主要是因为几乎每个人都说用这些语言进行编码是一种“乐趣”。那么，为什么不开发一种超级出色的语言，然后点击神奇的c ++编译按钮呢？

因为那又需要替换其现有的PHP代码库。

在理想的情况下，他们只需从头开始使用C ++进行编码。不幸的是，因为他们在PHP中拥有大量现有代码，所以这是不可能的。因此，他们改掉了这个问题。便宜得多。

— 死神MG
source

2

对此表示+1：“因此，他们解决了这个问题。它便宜得多。” 的确是这样-如果他们有3500名工程师来从事其产品开发，与让整个工程团队重写6年的代码相比，让一个5至50人的小组专注于编写优秀的PHP-> C ++编译器，这种方法更便宜。

— 苏曼（Suman）2012年

对不起，我很困惑。他们为什么要重写它。您只是自己说了一下-HipHop将所有代码转换为C ++。因此，只需对其进行转换，然后坚持使用C ++。

— user72245 2012年

16

@ user72245仅仅因为将其转换为C ++并不意味着将其转换为可读或可维护的C ++

— Mr.Mindor

为什么会这样they hack around the problem呢？使用C ++甚至汇编语言来优化代码根本不是什么新鲜事，自从有了PC以来就一直在这样做。

— 史蒂夫

还请记住，Facebook程序员是PHP程序员。当然，您可以将其全部转换为C ++并开始使用C ++进行编程，但是您现有的程序员没有使用该语言的经验。您需要重新培训他们，或雇用新的程序员才能继续开发。

— 加文·科茨

8

“实际上，为什么不直接在汇编中工作，因为C ++代码最终会转换为机器代码指令？”

–从本质上讲，这就是论点减少到的内容。希望这可以使为什么不这样做变得显而易见：

在汇编（C ++）中进行编程与在C ++（PHP）中进行编程需要（非常多！）不同的技能。
由于多种原因，这可能会使编程更加困难
即使您可以从头开始以汇编语言（C ++）编写可读程序，但汇编程序/编译器产生的代码可能不是人类可读的（说：可维护）。

— 康拉德·鲁道夫
source

2

我曾经维护过一份以1970年代构思的汇编形式编写的保险申请。在10月，我受命将“字母”上的问候改为“节日快乐”。由于复杂性，它仅在第二年2月完成。只要不超过数千行，我就会精通汇编并可以编写最佳代码。但是，COBOL和C编译器让我大吃一惊，并为我们正在运行的平台（尤其是对于汇编行超过1m的系统）提供了更优化的代码。这没有商业意义。

— bloudraak 2015年

5

我不在Facebook，但我对动机的最佳猜测是“避免重大风险”。在这一点上，切换到另一种语言不再是技术决定：首先，这是业务决定。

当您是一家有机成长为FB的大公司时，您会慢慢吸引那些在您的编程平台上获得专业知识的人（在FB的情况下就是PHP）。一对一地，您将获得数千名在PHP方面具有丰富专业知识的员工。在这一点上，切换到任何其他语言变得非常危险：您的工程师将无法适应新的生态系统，并且可能需要大量时间才能达到其当前工作所需的专业知识水平，更不用说提高他们的技能了。

抛开PHP和其他语言的相对优点，再加上FB对PHP技术的大量投资，以至于认为切换会很轻松就太嚣张了，试一试也太愚蠢了。在商业中，技术是达到目的的手段，因此编程的“欢乐”甚至没有进入讨论。

— dasblinkenlight
source

4

我只能想到一个用C ++实现的主要网站。H2G2

即使到那时，当前的实现工具实际上还是具有大量内置的文本和数据库操作功能的解释器（听起来有点像早期的PHP :-）。

Facebook对其网站的功能感到非常满意。它们已经发展到普通PHP无法支持其处理的卷的地步。因此，将那里的PHP编译为C ++机器代码。可以为PHP编写完整的编译器，但他们会错过进入gcc编译器堆栈的20年细微优化。关键是“ C ++”代码并不意味着人类可读或可维护，它只是机器代码方式的中间步骤。

像该站点上的许多程序员一样，我觉得您低估了在现有应用程序中嵌入的业务逻辑和功能方面投入的工作量，并且为自己着想而重视代码。

— 詹姆斯·安德森
source

现在，WT成功了，我能想到很多。

— 爱丽丝

@爱丽丝-有趣！但是我找不到任何人将它用于大量网站。再加上hello world 30行代码来执行5行PHP代码。

— James Anderson

比较一个“ hello world”的例子有点荒谬。在不到100行的时间内，我可以设置启用Web套接字，长时间回退，具有最佳SEO的逐步增强的小部件，使用AJAX无需整页加载的自动清理URL，以及很小的CPU / RAM占用空间。至少在典型配置中，PHP无法执行网络套接字，长时间轮询，在没有帮助的情况下清除URL，使用AJAX清除URL，并且肯定会使用大量（相对）的RAM / CPU。对于webapp而不是简单的示例，WT和C ++的优势非常明显，并且与C ++ 11的长度相当。

— 爱丽丝