基于云的编译器是否可行？
编写一个基于云的编译器，将编译后的代码单元传播到云中的不同机器上，有什么实际好处吗？编译后立即在应用程序中获得软件即服务架构是否会带来好处，或者固有的延迟是否会使这种方法不切实际？
Would it be any practical benefit to write a cloud-based compiler, that would spread compiled units of code on different machines in the cloud? Could there be a benefit from obtaining a software-as-a-service architecture right within the app just after compiling, or would the inherent latency make such an approach impractical?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我不确定我是否误解了您的观点，或者其他答案是否误解了。您是在谈论某种自动并行化任务吗？到目前为止给出的答案似乎是在谈论分布式编译——即使用云来加快编译时间。我假设您正在谈论针对云计算资源的编译器。
如果您实际上谈论的是分布式编译，那么显然像 distcc 这样的东西就可以满足您的需要。
如果您问一个更有趣（恕我直言）的问题，即针对分布式架构的编译器是否有用，我的答案是响亮的“是”。然而，可行性是问题的核心。延迟本身并不是问题，但是一致性（即确保所有单元的正确版本都到位）和具有适当的启发式方法将是一个问题。
最好的地方可能是奥卡姆编程语言 - 它针对的是晶片机，这与我们现在感兴趣的分布式系统架构类型并没有完全不同。我相信奥卡姆的一些后续工作可能会为了解最先进的技术提供有用的线索。
I'm not sure if I've misunderstood your point or if the other answers have. Are you talking about some sort of automatic parallelisation task? The answers given so far appear to be talking about distributed compilation - i.e. using a cloud to speed up compilation times. I assumed you were instead talking about a compiler that targets cloud computing resources.
If you were in fact talking about distributed compilation, then obviously things like distcc will do what you need.
If you were asking the much more interesting (IMHO) question about whether a compiler that targets distributed architectures would be useful, my answer is a resounding 'yes'. However, feasibility is at the heart of the problem. Latency is not the problem as such, however coherence (i.e. ensuring that the correct versions of all the units are in place) and having decent heuristics would be an issue.
The best place to look would probably be the Occam programming language - it targeted the transputer, which was not entirely dissimilar to the kinds of distributed systems architectures we're interested in these days. I believe there is some work that follows on from Occam that might provide useful clues as to what the state of the art is.
我使用过这样的系统，但它在本地集群上运行，而不是在云上运行。但原理是完全相同的。不幸的是，我不记得它叫什么了 - 但看着你的源文件被外包给你部门的其他电脑，这很酷。
编辑：它被称为 IncrediBuild。
I've used such a system, but it worked on a local cluster, not a cloud. But the principle would be exactly the same. Unfortunately I can't remember what it was called - but it was cool, watching your source files get farmed out to the other PCs in your department.
Edit: It was called IncrediBuild.
您可以使用
distcc和make -j来分布式编译最典型的 UNIX 代码。如果您定期编译大块代码，它可能会大大加快速度...afaik samba（免费 smb 实现）开发人员使用它来实现此目的。distcc仅以分布式方式执行编译阶段，将预处理和链接留给主机。与“云”的交互可能会导致延迟，但我仍然认为对于更复杂的 C++ 代码来说它可能非常有用。我想如果您有超过 100 个编译单元（fe .cpp 文件），您可能会获得显着的加速。
You can use
distccandmake -jfor distributed compilation of most typical unix code. If you regularly compile big chunks of code, it might get you big speedups... afaik samba (free smb implementation) developers use it for this.distccdoes only the compilation phase in a distributed way, leaving preprocessing and linking to the master machine.Interaction with "the cloud" might induce latency, but I still think with more complicated c++ code it might be very useful. I guess if you have more than 100 compilation units (f.e. .cpp files), you could get noticeable speedup.
我相信这是不切实际的。今天的硬件可以在合理的时间内完成任何中小型项目的编译；对于多核 CPU 来说更是如此。
唯一的例外是从源代码构建整个操作系统（例如 Debian）；对于这样的应用，建造农场被广泛使用。然而，需要构建农场的用户通常可以自己创建农场，而不需要去云端。
I believe it would be impractical. Today's hardware can do any compilation of small and medium-sized projects in reasonable time; more so with multi-core CPUs.
The only exception is building an entire operating system (e.g. Debian) from sources; for such application, build farms are in widespread use. However, users in need of build farms can typically create them themselves, and don't need to go to the cloud.
Xcode 有一个分布式构建功能，可以让你做到这一点，但我认为在 LAN 以外的任何地方，大多数时候都会非常慢。
Xcode has a distributed build feature that lets you do this, but I think that on anything other than a LAN it would be very slow most of the time.
这取决于。我们曾经使用旧的基于 C++ 的编译，需要 3-4 小时。对于类似的事情，卸载编译将非常有用。但在 C++ 项目中，这通常更不可能。
使用 C# 或 Java，编译时间明显更快，因此它可能不那么重要。
It depends. We used to have old C++ based compiles that took 3-4 hours. For something like that, it would be very useful to offload the compile. But in C++ projects, this is often even less possible.
With C# or Java, the compile times are significantly faster, so it may not be as important.
我认为如果它是某种持续集成工具，这可能会很有用。对于某些开发环境，进行正确的设置很困难。例如，我曾经参与过一个项目，团队使用 FlashDevelop 和 Adobe 的 Flex SDK。有时在个人计算机上进行设置很痛苦。如果服务可以监视项目目录或 git/SVN/等。存储库并构建最新的 SWF，但是，我认为这会很有用。
我想这也适用于跨平台项目。或者，此服务可以支持浏览器内 IDE，例如 Mozilla 的 Bespin。
I think this could be useful if it were some kind of continuous integration tool. For some development environments, getting the proper setup is difficult. For example, I once worked on a project where the team compiled SWF files using FlashDevelop and Adobe's Flex SDK. It was sometimes a pain to set up on an individual's computer. If a service could monitor a project directory or git/SVN/etc. repository and build the latest SWF, however, I think that would have been useful.
I imagine this would have a use for cross-platform projects too. Or, this service could support an in-browser IDE like Mozilla's Bespin.
我看过一个在 GridGain 之上运行 JUnit 测试的精彩演示，并且 GridGain 可以在云中运行。
不过，我认为云中的编译器没有太大价值。
I've seen a nice demo of running JUnit tests on top of GridGain, and GridGain can be run in the cloud.
I don't see much value in the compiler being in the cloud though.
是的，谢谢你的提问，我也在研究这个领域。
实际上它很有意义并且存在，http://www.cloudcompiling.com/，但是对于据我所知，它距离排名前十的服务还有很长的路要走。
延迟仅存在于代码上传中，因此如果开发人员使用良好的连接并且不太远（就网络跳数和具有“良好”跳数而言），那么这不会成为问题。
云上的延迟是云提供商的问题，如果是您的云提供商，那么您需要一个良好的平衡策略。
Yes, thanks for asking, I'm researching as well in this field.
actually it makes a lot of sense and it exist, http://www.cloudcompiling.com/, but for what I can see it's still far to be a top 10 service.
The latency is only in the upload of the code, so if the developers are working with a good connection and not too far (in terms of network hops and having "good" hops), it would not be an issue.
Latency on the cloud is an issue of the cloud provider, if it's you the cloud provider, well, then you need a good balancing strategy.