Так сталось, что четверть загрузки моего процессора уже не достаточна для обработки данных (работа с комбинаторикой). Предвидится ли в будущем поддержка AutoIt-ом многоядерных систем? Или быть может такую поддержку можно как-то реализовать программно самому?
AutoIt и многоядерные процессоры: предвидися ли поддержка?
- Автор темы Kalisnik
- Дата начала
- Сообщения
- 4,020
- Репутация
- 626
- Сообщения
- 4,020
- Репутация
- 626
Добавлено:
Сообщение автоматически объединено:
Kalisnik [?]
не силен в этом, но не думаю что использовать GPU можно в средах отличных от CUDA. ну может есть что-то от ATI. но суть в том, что программировать в этом случае все равно надо будет на C.
и еще, использовать в расчетах AutoIt - не самая лучшая идея.
Kaster
На сколько мне известно современные GPU считают в несколько раз быстрее чем современные CPU. А поскольку мой GPU от NVIDIA, то самый оптимальный вариант использовать для расчетов C, как я понимаю. Дабы извлечь все вкусности из архитектуры CUDA. Но... основная программа написана на AutoIt.Предположим, пишу отдельно движок для расчетов на С... а вот как потом организовать обмен данными мне как-то с трудом представляется (вообще это для меня пока больная тема, поскольку не было опыта в организации такой работы скриптов). По сути скорость самого обмена данными между скриптами не принципиальна. Скрипт AutoIt'а отправляет исходные данные в "скрипт-С". Тот обрабатывает и возвращает результат обратно. Вопрос в том, как вообще наладить такой обмен данными. Я уже вроде что-то подобное спрашивал, но как-то до меня так и не дошла хитрость сего момента (по крайней мере сейчас в голову приходит только глупая мысль производить обмен данными через интерфейс GUI :laugh
))
На сколько мне известно современные GPU считают в несколько раз быстрее чем современные CPU. А поскольку мой GPU от NVIDIA, то самый оптимальный вариант использовать для расчетов C, как я понимаю. Дабы извлечь все вкусности из архитектуры CUDA. Но... основная программа написана на AutoIt.Предположим, пишу отдельно движок для расчетов на С... а вот как потом организовать обмен данными мне как-то с трудом представляется (вообще это для меня пока больная тема, поскольку не было опыта в организации такой работы скриптов). По сути скорость самого обмена данными между скриптами не принципиальна. Скрипт AutoIt'а отправляет исходные данные в "скрипт-С". Тот обрабатывает и возвращает результат обратно. Вопрос в том, как вообще наладить такой обмен данными. Я уже вроде что-то подобное спрашивал, но как-то до меня так и не дошла хитрость сего момента (по крайней мере сейчас в голову приходит только глупая мысль производить обмен данными через интерфейс GUI :laugh
))
- Сообщения
- 4,020
- Репутация
- 626
Kalisnik
смотря кто кому передает данные. к примеру, можно передавать параметры расчета в виде ключей командной строки, или, если параметров много, сформировать файл со всеми данными и скормить путь к нему в виде ключа ком. строки. выводные данные можно в другой файл. по крайней мере так делал я. правда я не программировал под CUDA. и еще, кажись CUDA доступен только под unix*
смотря кто кому передает данные. к примеру, можно передавать параметры расчета в виде ключей командной строки, или, если параметров много, сформировать файл со всеми данными и скормить путь к нему в виде ключа ком. строки. выводные данные можно в другой файл. по крайней мере так делал я. правда я не программировал под CUDA. и еще, кажись CUDA доступен только под unix*
Garrett
Вот передомной сейчас выбор стоит: какой же все-таки взять ЯП... Нужно написать движок для расчетов (исключительно для рассчетов, но довольно массивных) и прикрутить его к скрипту AutoIt (по скольку, как выяснилось AutoIt для серьездных расчетов не лучшее решение). Отсюда чем более быстрый код будет у ЯП, тем лучше, но при этом не в ущер дружелюбности самого ЯП по отношению к пользователю - что бы как можно более снизить время-затраты на освоение основ языка. Исходя из этого, интересно было бы узнать Ваше мнение: что же все-таки выбрать? Бэйсик? Да, он имеет схожий с AutoIt'ом синтаксис, но достаточно ли он быстр?.... Хотя, наверно он должен поддерживать многоядерные системы - это уже большой плюс! ) А с Fortran я еще не ознакомился, скачал пока компилятор. Завтра поищу справку или какое-нибудь руководство к нему... тогда уж и решу что с ним делать.
Вот передомной сейчас выбор стоит: какой же все-таки взять ЯП... Нужно написать движок для расчетов (исключительно для рассчетов, но довольно массивных) и прикрутить его к скрипту AutoIt (по скольку, как выяснилось AutoIt для серьездных расчетов не лучшее решение). Отсюда чем более быстрый код будет у ЯП, тем лучше, но при этом не в ущер дружелюбности самого ЯП по отношению к пользователю - что бы как можно более снизить время-затраты на освоение основ языка. Исходя из этого, интересно было бы узнать Ваше мнение: что же все-таки выбрать? Бэйсик? Да, он имеет схожий с AutoIt'ом синтаксис, но достаточно ли он быстр?.... Хотя, наверно он должен поддерживать многоядерные системы - это уже большой плюс! ) А с Fortran я еще не ознакомился, скачал пока компилятор. Завтра поищу справку или какое-нибудь руководство к нему... тогда уж и решу что с ним делать.
- Сообщения
- 4,020
- Репутация
- 626
Kalisnik
Fortran немного проще, т.к. это мамонт и в нем нет ООП, чисто процедурное программирование. в нем есть параллелизация кода и многопоточность, но нет CUDA-интерфейса. Basic, хм никогда не слышал чтобы вычислительно-затратные программы писали на нем, хотя сам с этим ЯП не слишком знаком. так что если хочешь задействовать GPU, то тут либо C, либо, как выяснилось, Python. если хватит и многоядерности, то можно и C/C++/C#/Fortran. но я с недавних пор узнал, что при работе с векторными величинами всех обходит Matlab - ибо реализация векторных операций там реализовано на уровне архитектуры самого процессора. но там где Matlab проигрывает люди просто имплементируют коды на Fortrane. получается что такая связка быстрее всех считает
Fortran немного проще, т.к. это мамонт и в нем нет ООП, чисто процедурное программирование. в нем есть параллелизация кода и многопоточность, но нет CUDA-интерфейса. Basic, хм никогда не слышал чтобы вычислительно-затратные программы писали на нем, хотя сам с этим ЯП не слишком знаком. так что если хочешь задействовать GPU, то тут либо C, либо, как выяснилось, Python. если хватит и многоядерности, то можно и C/C++/C#/Fortran. но я с недавних пор узнал, что при работе с векторными величинами всех обходит Matlab - ибо реализация векторных операций там реализовано на уровне архитектуры самого процессора. но там где Matlab проигрывает люди просто имплементируют коды на Fortrane. получается что такая связка быстрее всех считает
