多平台多线程：真正的挑战是什么？

尽管像SDL这样的库提供了用于线程的跨平台包装器API，但我认为天真地假设这直接导致了在非常不同的平台（台式机/移动设备）上轻松开发游戏的想法。

考虑以下因素，解决这种问题的最佳方法是什么（考虑到任何跨平台线程API）：

• 不同数量的核心
• 每个内核的处理能力大不相同
• 总体上不同的系统架构，例如 缓存，RAM和I / O访问的不同延迟

我觉得这样做的唯一方法是评估您打算支持的每个设备可以运行多少个线程，并找出最低的公分母。但是，这仍然使我对可用的处理吞吐量总量一无所知。我是否认为有效地做到这一点的唯一方法是在整个开发过程中积极开发我打算支持的最低规格的移动设备？-即最低公分母？这大概足够了吗？还是比这还更多？

编辑：请其他人对此提供进一步的经验，因为我还没有完全回答我的问题。

您谈论的是“多线程困难”，但实际上您在谈论什么困难？从某种意义上说，您引用的是一个幻影问题，甚至可能不存在。真正的挑战是您自己做的-如果您绝对决心要从一块硬件中获得最后一滴电，那的确涉及使用硬件以达到最佳效果，但同时也扩大了功能最强大的机器之间的差距。和最不强大的 这就意味着，如果您拥有一款能够充分利用PS3的游戏（例如），则无论如何您都无法真正在便宜的手机上运行它，因此您的问题不再是“我如何获得一个程序可以在非常不同的硬件上工作”，但变成“我如何以几种不同的方式实现一个游戏构想，以使其在不同动力的硬件上工作”。

尽管像SDL这样的库提供了用于线程的跨平台包装器API，但我认为天真地假设这直接导致了在非常不同的平台（台式机/移动设备）上轻松开发游戏的想法。

轻松开发游戏-当然可以。最佳多线程，否。但是您不需要多线程即可制作游戏。要制造出高性能的产品，肯定会有所帮助。但是，许多出色的游戏只能在一个线程中运行。

考虑以下因素，解决这种问题的最佳方法是什么（考虑到任何跨平台线程API）：

• 不同数量的核心
• 每个内核的处理能力大不相同
• 总体上不同的系统架构，例如 缓存，RAM和I / O访问的不同延迟

不必尝试将系统分配给线程，而是将任务分配给线程。为每个任务提供运行所需的数据，并将任务分配给任何可用的硬件。通常，您将拥有某种线程池以抽象出各种内核或处理器，还有一个任务管理器，该任务管理器具有一个任务队列，并在线程发出已完成上一个任务且已完成任务的信号时，将它们分配给各个线程。准备一个新的。具有更多内核的硬件显然将更快地完成任务，并能够更快地渲染。专门使该系统在具有不同特征的系统上最佳工作成为一个高级优化问题，但可以基于某些启发式方法（例如，一项任务不会

但是，将游戏功能分解为分散的任务是一件很复杂的事情，通常不值得花精力，除非您非常确定需要性能，因此大多数人甚至都不会尝试。

一些进一步的阅读：

http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_engine_.php-参见“数据并行”部分。使用此模型，数据被拆分为几个相同的任务，并被分配到各个线程中。

http://software.intel.com/zh-cn/articles/designing-the-framework-of-a-parallel-game-engine/-非常密集，描述了操作系统级别而不是游戏级别的内容。

http://drdobbs.com/high-performance-computing/216500409-不是特定于游戏的，但是在告诉您如何划分任务方面完全相关。

http://www.itfgaming.com/news/tech-focus-crysis-2-and-the-future-of-cryengine-3-采访的中途是关于他们如何迁移到基于任务的系统的轶事。

当我做手机游戏时，我们首先开发了“黄金”版本（即功能齐全的游戏），然后将其分为三个主要版本（大屏幕，中型和小屏幕）。这些被进一步转换为11个版本：要求苛刻的图形（读占用大量内存/ cpu）与低调等（也有几个“特殊平台版本”）。

最大的问题是（这是我的工作），隔离所需的平台并确定那些版本以及如何创建它们（例如，大屏幕，但“低轮廓”应该是大屏幕/高轮廓的降级版本，或者应该是中等尺寸的屏幕/ lo轮廓制成大屏幕？）。

当然，我们在编写代码时会牢记这一点，因此游戏与屏幕尺寸的关系非常松散。

高温超导

[edit]我的意思是，您需要以不同的品质（例如1核，2核，1核，但速度快两倍）来拆分目标平台，然后确定所需的虚拟目标数（例如“然后将所有平台置于各自的“质量”中，并针对每种质量，采用最低分母并“移植”代码，使其符合那些要求（即工作且快速）足够）。

似乎您必须进行大量的猜测才能做到这一点，但是您已经可以通过最差的平台找到最差的质量。我会选择每个下一个质量，至少要比前一个质量好“两倍”，这可能不会产生超过3-4个“质量”的问题。如果代码是从黄金版本移植过来的，则任何性能不佳的平台都可以升级到较低的“质量”以使其加速。任何新平台都可以很容易地以正确的质量放置。

我感到这样做的唯一方法是评估您打算支持的每个设备可以运行多少个线程，并找出最低的公分母。

不一定-可能希望有一个更动态的解决方案，但这取决于您要解决的实际问题（如果有）。您的问题有点含糊，因此我的答案也必须含糊。

如果要运行的平台组具有通过API进行硬件枚举的功能，则可以使用该接口检测系统可以处理的最大线程数，并将其用作应用程序有多少线程的基础应该创造。这里唯一的挑战是找到这些API。是否进入操作系统级别，搜索第三方库，还是跨平台的SDK / API取决于您，并且取决于您要支持的平台。

考虑以下因素，解决这种问题的最佳方法是什么（考虑到任何跨平台线程API）：

different numbers of cores
vastly different processing capabilities per core
A generally different systems architecture with eg. different

缓存，RAM和I / O访问的延迟

我认为，这些都不是您关心的问题。您的关注点应该是开发自己的游戏。如果遇到瓶颈并决定为特定的处理器密集型任务生成单独的线程会更好，那么请生成线程，然后让OS和其他低级软件决定如何处理硬件以处理线程。