强制iPhone模拟执行CPU密集型任务? [英] Force the iPhone to simulate doing CPU-intensive tasks?
问题描述
对于普通的应用程序，您永远都不想这样做.
For a normal app, you'd never want to do this.
但是...我正在制作一个教育性应用程序，向人们确切演示在不同的iPhone硬件和操作系统级别上使用不同的线程模型会发生什么. OS 4从根本上改变了不同的模型(IME:在OS 4上运行时，许多现有代码不起作用).
But ... I'm making an educational app to show people exactly what happens with the different threading models on different iPhone hardware and OS level. OS 4 has radically changed the different models (IME: lots of existing code DOES NOT WORK when run on OS 4).
我正在编写一个交互式测试应用程序，它可以让您启动不同模型的线程(选择器主线程，选择器背景，nsoperationqueue等)，并查看GUI +主应用程序发生什么情况.
I'm writing an interactive test app that lets you fire off threads for different models (selector main thread, selector background, nsoperationqueue, etc), and see what happens to the GUI + main app while it happens.
但是我要重现的常见用例之一是:执行backgorund下载的线程然后对结果进行CPU密集型解析".我们在现实世界的应用程序中经常看到这一点.
But one of the common use-cases I want to reproduce is: "Thread that does a backgorund download then does a CPU-intensive parse of the results". We see this a lot in real-world apps.
这并不完全无关紧要； 忙碌"的方式很重要.
It's not entirely trivial; the manner of "being busy" matters.
那么...我该如何模拟呢?我正在寻找可以保证不会被优化的编译器(无论是现在还是更好的编译器)丢弃的东西，足以迫使线程在最大CPU上运行约5秒钟.
So ... how can I simulate this? I'm looking for something that is guaranteed not to be thrown-away by an optimizing compiler (either now, or with a better compiler), and is enough to force a thread to run at max CPU for about 5 seconds.
NB:在我的真实应用中，我注意到当iPhone线程繁忙时会发生一些奇怪的事情-例如后台线程将饿死主线程，即使将其设置为较低的优先级也是如此.尽管这显然是Apple线程调度程序中的一个错误，但我想让一个忙碌的人对此进行演示-和/或另一个忙碌的人来显示当您不在调度程序中触发该行为时会发生什么.
NB: in my real-world apps, I've noticed there are some strange things that happen when an iPhone thread gets busy - e.g. background threads will starve the main thread EVEN WHEN set at lower priority. Although this is clearly a bug in Apple's thread scheduler, I'd like to make a busy that demonstrates this - and/or an alternate busy that shows what happens when you DON'T trigger that behavioru in the scheduler.
更新:
例如，以下内容可能具有不同的效果:
For instance, the following can have different effects:
for( int i=0; i<1000; i++ )
for( int k=0; k<1000; k++ )
CC_MD5( cStr, strlen(cStr), result );
for( int i=0; i<1000000; i++ )
CC_MD5( cStr, strlen(cStr), result );
...至少有时，编译器似乎对后者进行了优化(而且我不知道编译器voodoo的用途是什么-有些构建没有什么区别，有些却表现出:()
...sometimes, at least, the compiler seems to optimize the latter (and I have no idea what the compiler voodoo is for that - some builds it showed no difference, some it did :()
更新2:
在第一代iPhone上有25个线程，每个线程执行一百万个MD5 ...并且对GUI几乎没有明显的影响.
25 threads, on a first gen iPhone, doing a million MD5's each ... and there's almost no perceptible effect on the GUI.
使用捆绑的基于SAX的解析器解析XML的5个线程通常会使GUI停止运行.
Whereas 5 threads parsing XML using the bundled SAX-based parser will usually grind the GUI to a halt.
MD5散列似乎不会触发iPhone越野车线程调度程序中的问题:(.我将改为研究内存分配，看看是否有不同的效果.
It seems that MD5 hashing doesn't trigger the problems in the iPhone's buggy thread-scheduler :(. I'm going to investigate mem allocations instead, see if that has a different effect.
推荐答案
Apple actually provides sample code that does something similiar to what you are looking for at developer.apple.com, with the intent to highlight the performance differences between using LibXML (SAX) and CocoaXML. The focus is not on CPU performance, but assuming you can actually measure processor utilization, you could likely just scale up (repeat within your xml) the dataset that the sample downloads.
这篇关于强制iPhone模拟执行CPU密集型任务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
