Заставить iPhone симулировать выполнение ресурсоемких задач?

Question

Для обычного приложения вы никогда не захотите это делать.

Но ... я делаю учебное приложение, чтобы показать людям, что именно происходит с различными моделями потоков на разных устройствах iPhone и на уровне ОС. OS 4 радикально изменила различные модели (IME: много существующего кода НЕ РАБОТАЕТ при запуске в OS 4).

Я пишу интерактивное тестовое приложение, которое позволяет вам запускать потоки для разных моделей (основной поток селектора, фон селектора, nsoperationqueue и т. Д.) И видеть, что происходит с основным приложением GUI +, пока оно происходит.

Но один из распространенных сценариев использования, которые я хочу воспроизвести, это: «Поток, который загружает backgorund, затем анализирует результаты с интенсивным использованием процессора». Мы часто видим это в реальных приложениях.

Это не совсем тривиально; манера «быть занятым» имеет значение.

Итак ... как я могу смоделировать это? Я ищу что-то, что гарантированно не будет выброшено оптимизирующим компилятором (или сейчас, или с лучшим компилятором), и этого достаточно, чтобы заставить поток работать с максимальной загрузкой процессора в течение примерно 5 секунд.

Примечание: в моих реальных приложениях я заметил некоторые странные вещи, которые случаются, когда нить iPhone занята - например, фоновые потоки будут истощать основной поток, даже когда установлен более низкий приоритет. Хотя это явно ошибка в планировщике потоков Apple, я хотел бы выделить занятое, демонстрирующее это - и / или альтернативное занятое, показывающее, что происходит, когда вы НЕ запускаете такое поведение в планировщике.

UPDATE:

Например, следующие эффекты могут иметь разные эффекты:

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 - для некоторых сборок он не показал разницы, для некоторых -: ()

ОБНОВЛЕНИЕ 2:

25 потоков на iPhone первого поколения, каждый из которых производит по миллиону MD5 ... и почти не заметно ощутимого эффекта в GUI.

Принимая во внимание, что 5 потоков, анализирующих XML с помощью встроенного синтаксического анализатора SAX, обычно приводят к остановке графического интерфейса.

Похоже, что хеширование MD5 не вызывает проблем в глючном планировщике потоков iPhone :(. Вместо этого я собираюсь изучить распределение памяти, посмотреть, будет ли это иметь другой эффект.

Answer 1

Apple на самом деле предоставляет пример кода, который похож на то, что вы ищете на developer.apple.com , с целью подчеркнуть разницу в производительности между использованием LibXML (SAX) и CocoaXML. Акцент не на производительности процессора, но при условии, что вы действительно можете измерить загрузку процессора, вы, скорее всего, можете просто увеличить (повторить в своем XML) набор данных, загружаемый образцом.

Answer 2

Вы можете избежать оптимизации компилятором, убедившись, что компилятор не может легко определить, что вы пытаетесь сделать во время компиляции.

Например, это:

for( int i=0; i<1000000; i++ )
    CC_MD5( cStr, strlen(cStr), result );

имеет инвариантный ввод, поэтому компилятор может понять, что он будет получать один и тот же результат каждый раз.Или что результат не привыкает, поэтому его не нужно вычислять.Вы можете избежать обеих этих проблем следующим образом:

for( int i=0; i<1000000; i++ )
{
    CC_MD5( cStr, strlen(cStr), result );
    sprintf(cStr, "%02x%02x", result[0], result[1]);
}

Если вы видите проблему с SAX, то я бы начал с того, что потоки в вашем приложении для симуляции делают SAX и проверим, видите ли вы то же самоепроблемы вне вашего основного приложения.

Если проблема не связана с чистой мощностью процессора или выделением памяти, другие области, на которые вы могли бы обратить внимание, это дисковый ввод-вывод (в зависимости от того, откуда поступает ваш XML-ввод),мьютексы или вызывающие селекторы / делегаты.

Удачи, и доложите, как вы попали!