哪些挑战促进了并行/并发架构的使用？
我对使用内置并行性/并发性的语言的可能性感到非常兴奋，例如 stackless python 和erlang，并坚信不久之后我们都必须朝这个方向前进 -或者会想要，因为这将是获得可扩展性和性能的好/简单的方法。
然而，我太习惯以线性/串行/OOP/函数的方式思考解决方案，以至于我正在努力以值得使用并发的方式来解决我的任何领域问题。 我怀疑我只需要忘记很多东西，但我想我会问以下问题：
- 你是否在 stackless 或 erlang 或其他中实现了相当大的东西？
- 为什么这是一个不错的选择？ 这是一个好的选择吗？ 你会再做吗？
- 您的问题的哪些特征意味着并发/并行是正确的？
- 您是否重新构建了现有问题以利用并发/并行性？ 如果
- 是这样，怎么办？
有谁愿意分享一些经验吗？
I am quite excited by the possibility of using languages which have parallelism / concurrency built in, such as stackless python and erlang, and have a firm belief that we'll all have to move in that direction before too long - or will want to because it will be a good/easy way to get to scalability and performance.
However, I am so used to thinking about solutions in a linear/serial/OOP/functional way that I am struggling to cast any of my domain problems in a way that merits using concurrency. I suspect I just need to unlearn a lot, but I thought I would ask the following:
- Have you implemented anything reasonably large in stackless or erlang or other?
- Why was it a good choice? Was it a good choice? Would you do it again?
- What characteristics of your problem meant that concurrent/parallel was right?
- Did you re-cast an exising problem to take advantage of concurrency/parallelism? and
- if so, how?
Anyone any experience they are willing to share?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
过去，当台式机只有一个 CPU 时，并行化仅适用于“特殊”并行硬件。 但现在台式机通常有 2 到 8 个核心，因此现在并行硬件已成为标准。 这是一个很大的区别，因此它不仅涉及哪些问题建议并行性，而且还涉及如何将并行性应用于比以前更广泛的问题集。
为了利用并行性，您通常需要以某些方式重新构建您的问题。 并行性在很多方面改变了游戏环境：
in the past when desktop machines had a single CPU, parallelization only applied to "special" parallel hardware. But these days desktops have usually from 2 to 8 cores, so now the parallel hardware is the standard. That's a big difference and therefore it is not just about which problems suggest parallelism, but also how to apply parallelism to a wider set of problems than before.
In order to be take advantage of parallelism, you usually need to recast your problem in some ways. Parallelism changes the playground in many ways:
在我们拥有操作系统之前，构建应用程序的人们会坐下来讨论以下问题：
操作系统是从“开发人员库”的集合中出现的。
操作系统的美妙之处在于您的未编写的软件具有某些特征，它可以：
一旦您转移到操作系统- 你不会回到原来的状态...
Erlang/OTP（即不是Erlang）是一个应用程序系统 - 它运行在两台或更多计算机上。
应用程序系统的美妙之处在于，您的未编写的软件具有某些特征，它可以：
猜猜看，一旦您转移到应用程序系统 - 您就不会再去也不回来...
你不必使用 Erlang/OTP，Google 在他们的应用程序引擎中有一个很好的应用程序系统，所以不要担心语言语法。
在 Erlang/OTP 堆栈而不是 Google App Engine 上构建很可能有很好的商业理由 - 您公司的业务开发人员会为您做出决定。
Before we had operating systems people building applications would sit down and discuss things like:
Operating systems emerged from collections of 'developer libraries'.
The beauty of an operating system is that your UNWRITTEN software has certain characteristics, it can:
Once you have shifted to an operating system - you don't go back to the status quo ante...
Erlang/OTP (ie not Erlang) is an application system - it runs on two or more computers.
The beauty of an APPLICATION SYSTEM is that your UNWRITTEN software has certain characteristics, it can:
Guess what, once you have shifted to an Application System - you don't go back neither...
You don't have to use Erlang/OTP, Google have a good Application System in their app engine, so don't get hung up about the language syntax.
There may well be good business reasons to build on the Erlang/OTP stack not the Google App Engine - the biz dev guys in your firm will make that call for you.
未来问题将几乎保持不变，但实现的底层硬件正在发生变化。 为了使用它，对象（组件、进程、服务，无论你如何称呼它）之间的通信方式将会改变。 消息将异步发送，无需等待直接响应。 相反，在工作完成后，该过程将给发件人回电并提供答案。 这就像人们一起工作。
我目前正在设计一个基于 Erlang/OTP 的轻量级事件驱动架构。 它被称为 Tideland EAS。 我在这里描述这些想法和原则：http://code.google。 com/p/tideland-eas/wiki/IdeasAndPrinciples。 它还没有准备好，但也许你会明白我的意思。
穆埃
The problems will stay almost the same inf future, but the underlying hardware for the realization is changing. To use this, the way of compunication between objects (components, processes, services, how ever you call it) will change. Messages will be sent asynchronously without waiting for a direct response. Instead after a job is done the process will call the sender back with the answer. It's like people working together.
I'm currently designing a lightweighted event-driven architecture based on Erlang/OTP. It's called Tideland EAS. I'm describing the ideas and principles here: http://code.google.com/p/tideland-eas/wiki/IdeasAndPrinciples. It's not ready, but maybe you'll understand what I mean.
mue
Erlang 让你并行地思考问题。 你一秒钟都不会忘记。 过了一段时间你就适应了。 问题不大。 除了解决方案在每个小角落变得平行之外。 所有其他语言都必须进行调整。 要并发。 这感觉不自然。 然后你最终会讨厌你的解决方案。 不好玩。
Erlang 最大的优点是它没有全局垃圾收集。 它永远不会休息。 当你每秒有 10000 次页面浏览时，这一点很重要。
Erlang makes you think of the problem in parallel. You won't forget it one second. After a while you adapt. Not a big problem. Except the solution become parallel in every little corner. All other languages you have to tweak. To be concurrent. And that doesn't feel natural. Then you end up hating your solution. Not fun.
The biggest advantages Erlang have is that it got no global garbage collect. It will never take a break. That is kind of important, when you have 10000 page views a second.