Это - большое учебное руководство, которое демонстрирует 2D понятия физики с помощью флэш-памяти и не характерно для флэш-памяти. http://www.rodedev.com/tutorials/gamephysics/game_physics.swf
Я не уверен, правильно ли я понял вашу точку зрения или есть другие ответы. Вы говорите о какой-то задаче автоматического распараллеливания? Приведенные до сих пор ответы, похоже, говорят о распределенной компиляции, то есть об использовании облака для ускорения времени компиляции. Я предположил, что вы вместо этого говорите о компиляторе, предназначенном для ресурсов облачных вычислений.
Если вы на самом деле говорили о распределенной компиляции, то очевидно, что такие вещи, как distcc, сделают то, что вам нужно.
Если вы спрашивали гораздо более интересное (IMHO) вопрос о том, будет ли полезен компилятор, ориентированный на распределенные архитектуры, мой ответ - твердое «да». Однако в основе проблемы лежит осуществимость. Задержка не является проблемой как таковая, однако согласованность (т.е. обеспечение наличия правильных версий всех модулей) и наличие хорошей эвристики было бы проблемой.
Лучшим местом для поиска, вероятно, был бы язык программирования Оккама - он нацелен на транспьютер, который не совсем отличался от виды архитектур распределенных систем, которые нас интересуют в наши дни. Я считаю, что есть некоторые работы, которые следует из Оккама, которые могут дать полезные ключи к разгадке современного состояния дел.
You can use distcc
and make -j
for distributed compilation of most typical unix code. If you regularly compile big chunks of code, it might get you big speedups... afaik samba (free smb implementation) developers use it for this. distcc
does only the compilation phase in a distributed way, leaving preprocessing and linking to the master machine.
Interaction with "the cloud" might induce latency, but I still think with more complicated c++ code it might be very useful. I guess if you have more than 100 compilation units (f.e. .cpp files), you could get noticeable speedup.
Я считаю, что это непрактично. Современное оборудование способно выполнить любую компиляцию малых и средних проектов в разумные сроки; тем более с многоядерными процессорами.
Единственное исключение - сборка всей операционной системы (например, Debian) из исходных текстов; для такого применения широко используются строительные фермы. Однако пользователи, которым нужны фермы сборки, обычно могут создавать их сами, и им не нужно переходить в облако.
Я использовал такую систему, но она работала в локальном кластере, а не в облаке. Но принцип будет точно таким же. К сожалению, я не могу вспомнить, как это называлось - но было круто наблюдать, как ваши исходные файлы передаются на другие ПК в вашем отделе.
Редактировать: Это называлось IncrediBuild .
Я думаю, это могло бы быть полезно, если бы это был какой-то инструмент непрерывной интеграции. Для некоторых сред разработки получить правильную настройку сложно. Например, однажды я работал над проектом, в котором команда компилировала SWF-файлы с помощью FlashDevelop и Adobe Flex SDK . Иногда было сложно настроить компьютер на отдельном компьютере. Если служба может отслеживать каталог проекта или git / SVN / etc. репозиторий и собрать последнюю версию SWF, однако я думаю, что это было бы полезно.
Я полагаю, что это также может быть использовано для кроссплатформенных проектов. Или эта служба может поддерживать IDE в браузере, например Mozilla's Bespin .
Это зависит от обстоятельств. Раньше у нас были старые компиляции на C ++, которые занимали 3-4 часа. Для чего-то подобного было бы очень полезно разгрузить компиляцию. Но в проектах C ++ это часто даже менее возможно.
В C # или Java время компиляции значительно меньше, поэтому это может быть не так важно.
Xcode имеет функцию распределенной сборки, которая позволяет вам это делать, но я думаю, что в любом другом устройстве, кроме локальной сети, большую часть времени это будет очень медленно.
Я видел прекрасную демонстрацию запуска тестов JUnit поверх GridGain, и GridGain можно запускать в облаке.
Я не вижу особой ценности в компиляторе, находящемся в хотя облако.