я должен отбросить Google App Engine?
Почему моя многопоточная реализация ухудшает производительность?
blockquote>Классический вопрос:)
Вы перебираете только живые ячейки. Это на самом деле довольно интересно. Наивная реализация «Игры жизни» Конвея смотрела бы на каждую клетку. Ваша версия оптимизирована для меньшего количества живых, чем мертвых клеток, что, как мне кажется, является распространенным явлением позже в игре. Я не могу судить по вашему отрывку, но я предполагаю, что он может быть заменен, возможно, выполнением избыточной работы, когда соотношение живых и мертвых клеток выше.
Предупреждение о
omp parallelсостоит в том, что нет никакой гарантии, что потоки не будут созданы / уничтожены при входе / выходе из параллельной секции. Это зависит от реализации. Я не могу найти какую-либо информацию о реализации MSVC. Если кто-нибудь знает, пожалуйста, взвешивайте.Таким образом, это означает, что ваши потоки могут создаваться / уничтожаться при каждом цикле обновления, что приводит к значительным накладным расходам. Чтобы это того стоило, объем работы должен быть на порядок дороже, чем накладные расходы.
Вы можете профилировать / измерить код для определения накладных расходов и рабочего времени. Это также должно помочь вам увидеть, где находятся настоящие узкие места.
Visual Studio имеет профилировщик с приятным графическим интерфейсом. Вам необходимо скомпилировать код с оптимизацией выпуска, но также включить символы отладки (они исключены в конфигурации выпуска по умолчанию). Я не изучал, как настроить это вручную, потому что я обычно использую CMake, и он автоматически устанавливает конфигурацию RelWithDebInfo.
Используйте
high_resolution_clockдля определения временных отрезков, которые трудно измерить с помощью профилировщика.Если вы можете использовать C ++ 17, он имеет стандартную параллель for_each (перегрузка ExecutionPolicy). Большинство функций стандартов алгоритмов делают. https://en.cppreference.com/w/cpp/algorithm/for_each . Они настолько новы, что я почти ничего о них не знаю (у них также могут быть те же проблемы, что и у OpenMP).
кажется, что со временем становится медленнее.
blockquote>Может быть, вы не очищаете один из своих векторов?
6 ответов
After chewing over the subject, I have decided to go for a django + rdbms solution. It seems that GAE needs time to reach maturity.
если вам нужны фоновые транзакции + облачная масштабируемость Amazon Elastic Cloud Computing - это единственная известная мне возможность. его немного сложнее поддерживать, так как вы в основном получаете всю свою операционную систему, но это также дает вам гибкость для запуска всего, что вы хотите.
As you learned, often one does not discover all the issues and pitfalls of a development environment like GAE untill after one has used it for a while. This is most likely true of any environment.
Before committing to an alternate environment ( Django + rdbms), how familiar are you with that platform? If you are new to it, you may just find that you run into other issues.
If on the other hand you are throughly familiar with Django + rdbms then it is another story. Of course one wonders if you are familiar with them, why did you pick GAE in the first place? You must have felt that it offered some benefits that you will be giving up by dropping GAE.
Perhaps you need to make a list of the pluses and minuses for each platform and then try to balance the lists to make a decision. Ultimately there are no magic bullets, and you will undoubtably have some issues no matter wich way you go.
Как сказал Андреас, взгляните на Amazon Web Services, это серьезная производственная среда, которая даст вам много вещей, о которых вы, возможно, еще не думали, включая сеть доставки контента (экономит пропускную способность). Простой дб и интересный (но я еще не придумал, как использовать его) Сервис Machanical Turk, Oh year и виртуальные серверы EC2 - запускайте на них все что угодно.
Сколько работы потребуется для его перемещения? Интересно услышать о вашем опыте с GAE.
Я всегда думаю, что лучше иметь больше контроля, и если вы бьете по кирпичным стенам, вы должны двигаться. Это мое мнение, надеюсь, это поможет!
транзакции: Вы правы, GAE не может обрабатывать сложные запросы, но ничего с подходом Big-Table сможет обрабатывать сложные вычисления, такие как RDB.
полнотекстовый поиск: поработав с «примитивным» API для полнотекстового поиска, вы вправе держаться подальше, он очень тусклый и никоим образом не масштабируемый (не может объединить более четырех терминов для поиска, если я правильно помню).
фоновый процесс: процесс CRON, доступный в последней версии, неплох, но опять же, я думаю, что вы мы хотим сделать гораздо больше с фоновыми процессами.