AMD открыла свою библиотеку для ускорения разработки приложений

[Gogast]

Сегодня AMD объявила о том, что сделала свободной для доступа и изменений свою библиотеку AMD Performance Library (APL), которая в виде open source будет называться Framewave версии 1.0. Цель этой инициативы, помочь быстрее разрабатывать высокопроизводительные приложения для платформы AMD, расширять и дополнять саму библиотеку.

Вклад в разработку партнеров, потребителей и сообщества open-source должен ускорить оптимизацию самой библиотеки в соответствии с их потребностями, в то время как инженеры AMD продолжат основную работу по развитию проекта Framewave.

На сегодняшний день функциональность библиотеки затрагивает большое число аспектов – от простой арифметической рутины до комплексных задач обработки изображений, использования внутреннего распределения потоков и построения архитектуры для многоядерных и многопроцессорных систем. В библиотеку входят 3200 инструкций для платформы x86, работа над которыми продолжается уже три года. Ресурс должен помочь разработчикам приложений полнее задействовать мощь современных процессоров. Медиа функции Framewave позволяют ускорить разработку таких приложений, как медиа-проигрыватели, кодеки, аудио приложения и редакторы изображений.

По словам Эрла Стала (Earl Stahl), вице-президента AMD по программному обеспечению, переход от APL к Framewave это важный шаг для компании. В AMD верят, что вскоре этот ресурс станет незаменимым в среде разработчиков, работа с которыми является важным элементом стратегии компании.

Многие потребители мультимедиа-приложений, например Dreamworks Animation очень позитивно встретили переход библиотеки в формат open source. CTO компании, Эд Леонард (Ed Leonard), считает, что это ускорит появление на рынке новых мультимедийных приложений, которые смогут использовать все преимущества многоядерной архитектуры современных процессоров.


http://framewave.sourceforge.net/
http://ko.itc.ua/node/34514

[deninok]

Ресурс должен помочь разработчикам приложений полнее задействовать мощь современных процессоров.

Современных процессоров - это каких? В том числе и многоядерных, так? Значит, эта библиотека позволит создавать многопоточные приложения?

[olelukoie]

Ресурс должен помочь разработчикам приложений полнее задействовать мощь современных процессоров.

Современных процессоров - это каких? В том числе и многоядерных, так?

Написано же:

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

Вот меня интересует другой вопрос - насколько хорошо эта библиотека будет работать на не-AMD процссорах (винда работает также на Intel, а если говорить о Linux, FreeBSD и прочих Solaris, то тут вообще куча различных архитектур). Если библиотека окажется привязана только к Athlon-Opteron-... (в смысле различных оптимизаций), то ну ее нафиг. Сейчас рынку нужны кроссплатформенные решения.

[Gogast]

Java?

[olelukoie]

Java?

В каком смысле? Как кроссплатформенное решение? Не катит по нескольким причинам, главные из которых - тормоза и необходимость наличия виртуальной машины (читай - интерпретатора). На обычном языке я могу скомпилить файл со статическими библиотеками, он получится громоздким, архитектурно зависимым, но для его работы будет требоваться только ядро системы и выполняться его код будет непосредственно на железе. С Явой этот номер не пройдет. Кроме того, ООП используется далеко не всегда. На самом деле нужны "нативные", но кроссплатформенные библиотеки и технологии, вроде технологии OpenGL. В принципе, языки C/C++, паскаль, фортран и другие сами по себе уже изначально являются полностью кроссплатформенными (в отличие от ассемблера). Например, функция printf будет работать одинаково в любой системе и на любом железе - была бы текстовая консоль. А для цикла for вообще не надо ничего, кроме ЦП. Дело портят аппаратно- и системно-зависимые части, для унификации которых и разрабатываются кроссплатформенные библиотеки.

Что же касается данной библиотеки от AMD, то вопрос в том, насколько она в своих оптимизациях привязана к архитектуре AMD. Например, будет ли прога, написанная с ее помощью, одинаково хорошо работать на, скажем, одноядерном 32-битном AMD Athlon XP и четырехядерном Intel Core 2 Quad в 64-битном режиме, или в одном из этих случаев (или даже в обоих) начнутся косяки?

[gabell]

Что же касается данной библиотеки от AMD, то вопрос в том, насколько она в своих оптимизациях привязана к архитектуре AMD.

Ну наверняка, если библиотека от AMD, то и оптимизировать ее будут в первую очередь для AMD-шных камушков. Например AMD “Barcelona” Processor.

Я далеко не программист, но думаю, что "прога, написанная с ее помощью, одинаково хорошо работать на, скажем, одноядерном 32-битном AMD Athlon XP и четырехядерном Intel Core 2 Quad в 64-битном режиме" не будет. Более того, если существуют две версии библиотеки, для 32-х и 64-х разрядных процессоров, то и проги для одноядерного 32-битного AMD Athlon XP и четырехядерного Intel Core 2 Quad в 64-битном режиме должны быть разные. Или я не прав?

[olelukoie]

если существуют две версии библиотеки, для 32-х и 64-х разрядных процессоров, то и проги для одноядерного 32-битного AMD Athlon XP и четырехядерного Intel Core 2 Quad в 64-битном режиме должны быть разные. Или я не прав?

Проги, а вернее прога, должна быть одной и той же. Только компилируется она в одном случае с использованием 32-битного компилятора (т.е. компилятора, генерирующего 32-битный код) и линкуется с 32-битной версией библиотеки, а во втором случае компилятор и библиотека должны быть 64-битными. А дальше возникает вопрос: я использовал эту библиотеку в своей проге, скомпилил ее на одном компе, в котором стоит камень от АМД (пусть это будет 32-битный камень), прогнал через профайлер и увидел значительный прирост производительности по сравнению с использованием стандартных средств ОС/компилятора/языка программирования. Затем перенес эту прогу на комп, в котором стоит камень от Интел (тоже 32-битный). Каков будет результат прогона профайлера? Каков будет результат прогона профайлера, если эту же 32-битную прогу запустить на 64-битной платформе в режиме совместимости? Будет ли прирос производительности одинаковым для камней от АМД и Интел? И не столкнусь ли я при таком переносе с тормозами вместо ускорения работы (а при использовании очень специфических оптимизаций - с полной неработоспособностью)? Хорошая библиотека должна сама определять (причем в рантайме) железо, на котором она работает, и использовать подходящие для него оптимизации или не использовать их вовсе. А разработчик прикладной программы этими вопросами заморачиваться не должен - его код должен быть один и един на все случаи жизни.

ЗЫ Удивило наличие версий этой библиотеки для Mac OS X 32 и 64 бита. Я и не знал, что Apple выпускает маки на базе АМД...

[ShadowFlash]

ЗЫ Удивило наличие версий этой библиотеки для Mac OS X 32 и 64 бита. Я и не знал, что Apple выпускает маки на базе АМД...

Забота о пользователях хакинтошей

[olelukoie]

ЗЫ Удивило наличие версий этой библиотеки для Mac OS X 32 и 64 бита. Я и не знал, что Apple выпускает маки на базе АМД...

Забота о пользователях хакинтошей

А на чем они эти версии писали и тестировали?

[gabell]

Проги, а вернее прога, должна быть одной и той же. Только компилируется она в одном случае с использованием 32-битного компилятора (т.е. компилятора, генерирующего 32-битный код) и линкуется с 32-битной версией библиотеки, а во втором случае компилятор и библиотека должны быть 64-битными. А дальше возникает вопрос: я использовал эту библиотеку в своей проге, скомпилил ее на одном компе, в котором стоит камень от АМД (пусть это будет 32-битный камень), прогнал через профайлер и увидел значительный прирост производительности по сравнению с использованием стандартных средств ОС/компилятора/языка программирования. Затем перенес эту прогу на комп, в котором стоит камень от Интел (тоже 32-битный). Каков будет результат прогона профайлера? Каков будет результат прогона профайлера, если эту же 32-битную прогу запустить на 64-битной платформе в режиме совместимости? Будет ли прирос производительности одинаковым для камней от АМД и Интел? И не столкнусь ли я при таком переносе с тормозами вместо ускорения работы (а при использовании очень специфических оптимизаций - с полной неработоспособностью)? Хорошая библиотека должна сама определять (причем в рантайме) железо, на котором она работает, и использовать подходящие для него оптимизации или не использовать их вовсе. А разработчик прикладной программы этими вопросами заморачиваться не должен - его код должен быть один и един на все случаи жизни.

Пробуйте. Потом расскажите

[Kondrat]

Для кого эти библиотеки будут полезны в первую очередь? Для разработчиков различных компиляторов, а также для разработчиков ядра, а точнее его архитектурозависимых компонентов. Ну еще разве что для фанатов ассемблера, стремящихся оптимизировать ПО под собственную машину.