Извини, я сначала это написал у le-lesya, а потом заметил, что она дала ссылку, куда писать. Так что я просто перепощу то, что написал туда:
Хм, я, к сожалению, с библиотекой тесно не знаком и помочь смог бы не быстрее, чем сам бы разобрался, но я бы на его месте поинтересовался альтернативами (которые наверняка есть -- как минимум под Cuda), для этого есть две веских причины: 1) Там написано "Last Updated: 19 August 1997". Это не просто давно, это уже фактически динозавр -- за эти годы массивно-параллельные вычисления очень существенно продвинулись вперед, поэтому вряд ли это оптимальный выбор средства вычислений 2) Также они там пишут "applications of over 200 Gflops have been achieved on the Sandia-Intel TFlop Computer" -- из чего можно сделать вывод, что не самая оптимальная библиотека, и если у него есть выбор, имеет смысл заняться тем же самым на современных видеокартах. К примеру, совершенно обычная игровая видеокарта (за 7500 рублей) для домашнего компьютера сейчас даёт примерно 1,1 терафлопса, и, во-первых, это больше, чем вся Sandia, во-вторых, для них существуют библиотеки с гораздо бОльшим КПД, в-третьих, на Cuda или OpenCL элементарно проще писать, чем на языках для массивно-параллельных решений, и этому он точно сможет научиться быстрее. Почитать об этом можно тут: i) вот тут лежит библиотека под Cuda, которая работает лучше ацтека и умеет делать в точности то же самое, что и он: http://gpgpu.org/tag/sparse-linear-systems Там описания и всё, что нужно. Единственное, что нужно для того, чтобы это работало -- правильно передавать параметры функциям, всё остальное не отличается от обычных C. ii) вот тут наглядно видно, как это вообще работает (написано там очень просто, если он знает, что такое СЛАУ с разреженными матрицами, то это он наверняка поймёт): http://habrahabr.ru/blogs/CUDA/54707/ http://habrahabr.ru/blogs/CUDA/54330/ iii) а вот страница самой технологии: http://www.nvidia.ru/object/cuda_home_new_ru.html
В общем, я бы на его месте выбрал в любом случае что-то другое (даже если и не Cuda), технологий, более современных, чем ацтек, очень много. И дело в том, что старые библиотеки не только медленнее, но их и осваивать гораздо сложнее, потому что писать раньше было существенно сложнее
благодарю за столь развёрнутый ответ удаляюсь изучать аналоги хотя задача у меня поставлена чётко, попробую обратить внимание руководителя на другие продукты не хватает только цифр и прямых сравнений его, к сожалению, не удовлетворят просто слова "лучше","быстрее" и "современнее"
Прямые сравнения я даже, скорее всего, смогу найти, но только после среды -- сначала экзамен сдам и попробую. Вообще советую почитать ещё про OpenCL и поискать библиотеки для него -- это совсем безопасный путь, т.к из OpenCL можно скомпилировать исполняемый код почти на любую массивно-параллельную платформу. В общем, если получится сдать в среду, помогу, чем смогу -- ради науки, разумеется :) Я просто сейчас примерно этим и занимаюсь, и это довольно интересно
*но если бы я знал полную постановку задачи, я мог бы сказать точнее, разумеется. То есть пока что могу сказать только то, что в целом для разнообразных задач матричных расчётов имеет смысл копать в эту сторону, но может всплыть какая-нибудь фигня, которая может завалить всё на корню, т.к свои ограничения есть везде -- и вот эти ограничения как раз стали бы ясны из постановки задачи
ооо, постановка задачи звучит очень просто... запрогать для оченьмногопроцессорной :) машины решение уравнения Пуассона в прямоугольной области с обратной ступенью на прямоугольной неравномерной сетке.
хм, я припоминаю это даже слегка. Всё-таки ещё несколько пунктов: 1) А никакой конкретики про архитектуру этой очень_многопроцессорной_машины ничего не сказано? 2) Что нужно -- очень быстро это считать или подогнать алгоритм под какую-то конкретную существующую машину? 3) Гидродинамические расчёты зашиты, вроде как, чуть ли не во встроенные библиотеки от Nvidia -- во всех видеокартах после 2007 года присутствует даже физический движок, называется PhysX, под него активно программируют в самых сумасшедших расчётах, и я на 99% уверен, что твоя задача уже там решена, причём крайне оптимальным образом. Так и правда очень важно узнать, что является приоритетом -- подсчёты или платформа, потому что есть шанс, что и писать ничего не нужно. Изобретение велосипедов не самое увлекательное занятие :)
хм 1) вот собственно на этом предполагается считать много узлов, технология MPI, компиляторы # Intel Fortran/C++ Compiler 11 # GNU # PGI # PathScale 2) на самом деле и то и то, потому что 3) 3) изобрести велосипед как раз и требуется, в этом смысл, а точнее, он уже изобретен и надо проверить, как он всё-так ездит. Поясню: разработан очередной метод решения уравнений Навье-Стокса и требуется проверить, насколько он эффективен. Теоретическая проверка вроде как выявляет его преимущества, теперь нужно обоснование расчётами, а потом и экспериментальное. Так что писать придётся по-любому немало ) А библиотеку я ищу как раз для того, чтобы посмотреть, как обстоят дела сейчас, потом запрогать новое и сравнить. Поскольку надо сравнить, то лучше понимать всю картину в целом, так что я толком затрудняюсь ответить на 2)
Так, это многое проясняет. Тогда забудь про всё, что я сейчас написал, возможно, кроме OpenCL, хотя и про него, скорее всего тоже. Аспектов несколько: 1) Ограничения на платформу очень серьёзные, тем более, что там нет вычислительных видеокарт :) 2) Производительность этой махины, конечно же, существенно выше, чем то, о чём писал я, мы как раз в прошлом году внимательно рассматривали такие машины. По поводу производительности можно сказать наверняка только одно -- видеокарты могут выигрывать только на относительно маленьких размерах массивов (до 300000х300000), потому что у них нет затрат на синхронизацию. Но как только массивы становятся больше, начинает выигрывать Чебышев, причём выигрывать на много порядков (особенно если запускать несколько расчётов параллельно) 3) Программировать тебе, увы, придётся всё-таки почти наверняка именно на том, о чём ты спросил. Единственное что -- чтобы была возможность выбора, на чём писать, нужно узнать точное устройство операционной системы -- классический ли это юникс, какой-нибудь распределенный red hat, нечто самописное специально для этой машины или что ещё. Особенно важно узнать, существует ли компилятор OpenCL под неё (это можно спросить у любого человека, который знает её характеристики) 4) Поясню для чего -- OpenCL это фактически C/С++, но на нём гораздо удобнее писать параллельные программы, особенно под такие махины. То есть не придётся писать механизмы синхронизации, как минимум, а это очень большое преимущество. Кроме того, к OpenCL есть куча библиотек, и это можно было бы использовать для эталонного сравнения. Если OpenCL там не поддерживается, то выбора у тебя не будет вообще, и придётся писать на ацтеке.
И маленькая совсем субъективная ремарка: у меня есть лёгкое подозрение, что исследование производительности нового алгоритма может ничего не дать, только если разница будет не на два и больше порядков. По очень простой причине -- распределенные алгоритмы очень-очень-очень сильно платформозависимы и два одинаковых алгоритма на машинах с разной архитектурой могут показывать очень существенно разные результаты, это стоит принять во внимание
Я ещё об этом всём постараюсь поузнавать в ИСПе, когда там буду, возможно, там скажут что-то более определенное на этот счёт
Хм, я, к сожалению, с библиотекой тесно не знаком и помочь смог бы не быстрее, чем сам бы разобрался, но я бы на его месте поинтересовался альтернативами (которые наверняка есть -- как минимум под Cuda), для этого есть две веских причины:
1) Там написано "Last Updated: 19 August 1997". Это не просто давно, это уже фактически динозавр -- за эти годы массивно-параллельные вычисления очень существенно продвинулись вперед, поэтому вряд ли это оптимальный выбор средства вычислений
2) Также они там пишут "applications of over 200 Gflops have been achieved on the Sandia-Intel TFlop Computer" -- из чего можно сделать вывод, что не самая оптимальная библиотека, и если у него есть выбор, имеет смысл заняться тем же самым на современных видеокартах. К примеру, совершенно обычная игровая видеокарта (за 7500 рублей) для домашнего компьютера сейчас даёт примерно 1,1 терафлопса, и, во-первых, это больше, чем вся Sandia, во-вторых, для них существуют библиотеки с гораздо бОльшим КПД, в-третьих, на Cuda или OpenCL элементарно проще писать, чем на языках для массивно-параллельных решений, и этому он точно сможет научиться быстрее. Почитать об этом можно тут:
i) вот тут лежит библиотека под Cuda, которая работает лучше ацтека и умеет делать в точности то же самое, что и он:
http://gpgpu.org/tag/sparse-linear-systems
Там описания и всё, что нужно. Единственное, что нужно для того, чтобы это работало -- правильно передавать параметры функциям, всё остальное не отличается от обычных C.
ii) вот тут наглядно видно, как это вообще работает (написано там очень просто, если он знает, что такое СЛАУ с разреженными матрицами, то это он наверняка поймёт):
http://habrahabr.ru/blogs/CUDA/54707/
http://habrahabr.ru/blogs/CUDA/54330/
iii) а вот страница самой технологии: http://www.nvidia.ru/object/cuda_home_new_ru.html
В общем, я бы на его месте выбрал в любом случае что-то другое (даже если и не Cuda), технологий, более современных, чем ацтек, очень много. И дело в том, что старые библиотеки не только медленнее, но их и осваивать гораздо сложнее, потому что писать раньше было существенно сложнее
Reply
удаляюсь изучать аналоги
хотя задача у меня поставлена чётко, попробую обратить внимание руководителя на другие продукты
не хватает только цифр и прямых сравнений
его, к сожалению, не удовлетворят просто слова "лучше","быстрее" и "современнее"
Reply
Вообще советую почитать ещё про OpenCL и поискать библиотеки для него -- это совсем безопасный путь, т.к из OpenCL можно скомпилировать исполняемый код почти на любую массивно-параллельную платформу.
В общем, если получится сдать в среду, помогу, чем смогу -- ради науки, разумеется :) Я просто сейчас примерно этим и занимаюсь, и это довольно интересно
Reply
Reply
запрогать для оченьмногопроцессорной :) машины решение уравнения Пуассона в прямоугольной области с обратной ступенью на прямоугольной неравномерной сетке.
Reply
Всё-таки ещё несколько пунктов:
1) А никакой конкретики про архитектуру этой очень_многопроцессорной_машины ничего не сказано?
2) Что нужно -- очень быстро это считать или подогнать алгоритм под какую-то конкретную существующую машину?
3) Гидродинамические расчёты зашиты, вроде как, чуть ли не во встроенные библиотеки от Nvidia -- во всех видеокартах после 2007 года присутствует даже физический движок, называется PhysX, под него активно программируют в самых сумасшедших расчётах, и я на 99% уверен, что твоя задача уже там решена, причём крайне оптимальным образом. Так и правда очень важно узнать, что является приоритетом -- подсчёты или платформа, потому что есть шанс, что и писать ничего не нужно. Изобретение велосипедов не самое увлекательное занятие :)
Reply
1) вот собственно на этом предполагается считать
много узлов, технология MPI, компиляторы
# Intel Fortran/C++ Compiler 11
# GNU
# PGI
# PathScale
2) на самом деле и то и то, потому что 3)
3) изобрести велосипед как раз и требуется, в этом смысл, а точнее, он уже изобретен и надо проверить, как он всё-так ездит. Поясню: разработан очередной метод решения уравнений Навье-Стокса и требуется проверить, насколько он эффективен. Теоретическая проверка вроде как выявляет его преимущества, теперь нужно обоснование расчётами, а потом и экспериментальное. Так что писать придётся по-любому немало ) А библиотеку я ищу как раз для того, чтобы посмотреть, как обстоят дела сейчас, потом запрогать новое и сравнить. Поскольку надо сравнить, то лучше понимать всю картину в целом, так что я толком затрудняюсь ответить на 2)
Reply
1) Ограничения на платформу очень серьёзные, тем более, что там нет вычислительных видеокарт :)
2) Производительность этой махины, конечно же, существенно выше, чем то, о чём писал я, мы как раз в прошлом году внимательно рассматривали такие машины. По поводу производительности можно сказать наверняка только одно -- видеокарты могут выигрывать только на относительно маленьких размерах массивов (до 300000х300000), потому что у них нет затрат на синхронизацию. Но как только массивы становятся больше, начинает выигрывать Чебышев, причём выигрывать на много порядков (особенно если запускать несколько расчётов параллельно)
3) Программировать тебе, увы, придётся всё-таки почти наверняка именно на том, о чём ты спросил. Единственное что -- чтобы была возможность выбора, на чём писать, нужно узнать точное устройство операционной системы -- классический ли это юникс, какой-нибудь распределенный red hat, нечто самописное специально для этой машины или что ещё. Особенно важно узнать, существует ли компилятор OpenCL под неё (это можно спросить у любого человека, который знает её характеристики)
4) Поясню для чего -- OpenCL это фактически C/С++, но на нём гораздо удобнее писать параллельные программы, особенно под такие махины. То есть не придётся писать механизмы синхронизации, как минимум, а это очень большое преимущество. Кроме того, к OpenCL есть куча библиотек, и это можно было бы использовать для эталонного сравнения. Если OpenCL там не поддерживается, то выбора у тебя не будет вообще, и придётся писать на ацтеке.
И маленькая совсем субъективная ремарка: у меня есть лёгкое подозрение, что исследование производительности нового алгоритма может ничего не дать, только если разница будет не на два и больше порядков. По очень простой причине -- распределенные алгоритмы очень-очень-очень сильно платформозависимы и два одинаковых алгоритма на машинах с разной архитектурой могут показывать очень существенно разные результаты, это стоит принять во внимание
Я ещё об этом всём постараюсь поузнавать в ИСПе, когда там буду, возможно, там скажут что-то более определенное на этот счёт
Reply
Reply
Reply
Leave a comment