Выпущена первая стабильная версия 1.0 (http://fabricengine.com/2012/03/v1-0-is-launched/) открытой платформы Fabric Engine (http://fabricengine.com/), предназначенной для оптимизации производительности и запуска скриптовых языков в полноценном многопотоковом режиме. Платформа распространяется под лицензией AGPL v3.0 (http://fabricengine.com/2012/03/agpl-v3-0/). Данный релиз доступен для Windows, Mac OS X и Linux, также платформа может использоваться и на клиентской стороне - непосредственно в браузерах (поддерживаются Firefox и Chrome), равно как и в облачном окружении.Разработчики подчеркивают, что эта система никак не связана с кешированием или идеями предкомпилирования – это полностью динамическая среда разработки, где все структуры данных, графы, переменные и код вычисляется и исполняется непосредственно во время каждого запуска. Fabric Engine может быть интегрирована практически с любым языком программирования, на данный момент в платформе уже поддерживаются языки JavaScript и Python, а в самое ближайшее время сюда добавятся Ruby и PHP. Для подготовки приложений к запуску на платформе используется собственный язык KL (http://documentation.fabric-engine.com/1.0.22-release/Fabric...), для генерации и трансляции в который используются возможности пакета компиляторов LLVM (http://www.opennet.me/opennews/art.shtml?num=32433), что теоретически делает эту платформу кроссплатформенной.
KL – это строго типизированный язык похожий на Си, который использует динамическую компиляцию в машинный код всегда для текущей для каждого проекта архитектуры, что позволяет достигать максимальной производительности именно для данного оборудования. Таким образом, запуская в рамках этой платформы своё готовое приложение на скриптовом языке - на выходе вы получите современное и хорошо оптимизированное многопоточное приложение, которое будет эффективно использовать для вычислений не только все доступные CPU, но и даже GPU, если они физически доступны в текущей системе. Кроме того KL позволяет использовать (http://fabricengine.com/2012/01/fabric-engine-to-provide-pow.../) унифицированную систему файловых операций, которая позволяет использовать как традиционный подход, не требующий какой-то специальной адаптации, так и специализированный, - создающий хорошо защищенные и безопасные файловые хранилища.Согласно внутреннему тестированию (http://fabricengine.com/technology/benchmarks/) компании-разработчика, приложения основанные на Fabric Engine показывают производительность сопоставимую с нативными приложениями написанными на C++. По мнению компании, такой уровень производительности превращает традиционные скриптовые языки в вполне подходящий выбор для их применения в высокопроизводительных вычислительных задачах (HPC).
URL: http://www.h-online.com/open/news/item/Fabric-Engine-brings-...
Новость: http://www.opennet.me/opennews/art.shtml?num=33493
абалдеееть
Тесты, конечно, впечатляют.Я правильно, понял — исходный текст сценария при каждом запуске преобразуется в некий «KL», который адски быстр и дико мнокопоточен?
>> запуска скриптовых языков в полноценном многопотоковом режиме
>> PHPPHP и потоки? o rly?
>> не только все доступные CPU, но и даже GPU
ну всё, теперь запущу жумлу на видеокарте :)
> PHP и потоки? o rly?думаю никто не заявляет что потоки эти -- будут иметь *общее* пространство (состояние) PHP-объектов
[т.е. думаю каждый PHP-поток будет иметь своё собственное PHP-состояние...
а синхронизация состояния будет производится строго через сущности FabricEngine]
Если скорость выполнения скрипта сопоставима с С++, то скорее всего памяти жрет этот Фабрик Енджин мама не горюй
Ерунда. Очередная "ускорялка интернета". Ну дали набор апи ф-ций которые быстро выполняются, но точно так же можно эти ф-ции самом ну сях написать без всяких там ЛЛВМ и КЛ.
То есть если я не критичную к спорости логику выкидываю в Perl и инлайню С код на участках где нужны быстрые вычисления - мое решение будет быстрее?PS: Предлагаю потестировать. Кому интересно?
Там утверждается про многопоточность, тогда инлайнить придется с чем нить типа OpenMP. Должно быть не медленнее.
И опять таки, там можно вынести не все, а только то, для чего есть готовые ф-ции.
Похоже на заново изобретенный LLVM (добавлена поддержка GPU) с более универсальным frontend-ом (один на все поддерживаемые языки).
А как же parrot?
Они его опередили и он больше не нужен?
Да еще с многопоточностью и скоростью...
Что же, судя по докам - штука годная, имхо. Особенно порадовала поддержка питона. Буду тестить.Любопытно как у этой фабрике дело обстоит с работой на мобильной платформе? Например на андроиде?
потестишь - расскажи, интересно
Я так понимаю у них эйприл фул уже настал?
почему-то такая идея ускорялки Web'ов мне нравится...
напоминает http://www.opennet.me/opennews/art.shtml?num=33484, который нравится мне ещё больше.особенно, учитывая всякое, вроде:
"Gallium3D Compute Infrastructure Is On Approach" (http://www.phoronix.com/scan.php?page=news_item&px=MTA3NTg)
"AMD R600 LLVM Back-End Called For Inclusion" (http://www.phoronix.com/scan.php?page=news_item&px=MTA3NzI)
"Intel Looks To Be Working On Open-Source GPGPU" (http://www.phoronix.com/scan.php?page=news_item&px=MTA3Nzc)
"Gdev: A Competitive Open-Source CUDA Implementation" (http://www.phoronix.com/scan.php?page=news_item&px=MTA3OTI)
"Last Minute For Linux 3.4: DMA-BUF PRIME Support" (http://www.phoronix.com/scan.php?page=news_item&px=MTA3OTQ)
"DRM Render-Nodes Work Back Underway" (http://www.phoronix.com/scan.php?page=news_item&px=MTA3OTU)
И выложили всего одно-единственное сравнение с C++, без кода. Конечно, так и python быстрее C можно сделать, но только формально.
на строковых операциях питон легко обойдет с
хорошая шутка!