int fib(int n)
{
int x, y;
if ( n < 2 ) return n;
#pragma omp task shared(x)
x = fib(n - 1);
#pragma omp task shared(y)
y = fib(n - 2);
#pragma omp taskwait
return x + y;
}
Увеличение размера стека GCC или G++
Добрый вечер.
Есть необходимость увеличения стека в С++. Как это возможно сделать для g++ или gcc.
Есть необходимость увеличения стека в С++. Как это возможно сделать для g++ или gcc.
Не уверен, что правильно уловил суть вопроса... Вообще-то стек - больше имеет отношение к времени выполнения, а не к времени компиляции. Компилятор не такой умный, чтобы предсказывать рекурсию в вашей программе. Боюсь, что таких опций у gcc в принципе нет. Может речь идет о системных ограничениях ?? (см. ulimit)
Вопрос был понят правильно. Смысл заключается в том, чтобы увеличить количество стека, для того чтобы дать возможность программе захватить как можно больше памяти. И в результате посчитать как можно большее количество точек. (В целом речь идет о аппроксимации функций многих переменных)
операционная система, конечно же, OpenVMS, да?
для Linux - дефолтное ограничение можно посмотреть через ulimit -s. обычно это 8Мб. увеличте его через setrlimit и не надо трогать gcc
для Linux - дефолтное ограничение можно посмотреть через ulimit -s. обычно это 8Мб. увеличте его через setrlimit и не надо трогать gcc
Цитата: Rialzista
Смысл заключается в том, чтобы увеличить количество стека, для того чтобы дать возможность программе захватить как можно больше памяти. И в результате посчитать как можно большее количество точек. (В целом речь идет о аппроксимации функций многих переменных)
Что-то у вас с алгоритмом нелады. 8Мб памяти на стеке хватает для практически любых задач (даже космической сложности). Подозреваю, что у вас аргументы передаются копированием на стеке (по значению), а не через кучу (по ссылке), что для глубокой рекурсии равносильно отстрелу одной из нижних конечности из дедушкиного ружья (собственно, у вас это и происходит).
История обстоит вот каким еще образом. Сами функции придумывают далеко не глупые люди т.е. Физики =) И эти люди просят реализовать возможность работы программы в целом для n-ого количества переменных и точек разбиения по каждой переменной. Что в наших задачах рождает великое множество коэффициентов которые где-то необходимо хранить или записывать в файл. Понятно, что первое предложение является более выгодным, но при произвольном задании переменных и точек разбиения сложность задачи возрастает экспоненциально. (переменные^точки разбиения) И сейчас идет этап тестового написания алгоритма на C++ для последующего счета и переноса на T++ и счета на компьютерах семейства Скиф.
А вот пока никакой рекурсии в программе нет, и пока, не предвидится. Уж так построен алгоритм, только считай.
Если интересно можно распространяться и дальше на эту тему т.к. это мой диплом, а дальше и кандидатская.
А вот пока никакой рекурсии в программе нет, и пока, не предвидится. Уж так построен алгоритм, только считай.
Если интересно можно распространяться и дальше на эту тему т.к. это мой диплом, а дальше и кандидатская.
Цитата: Rialzista
История обстоит вот каким еще образом....
История интересная. Только где в ней место малому стеку? ;)
Цитата: Rialzista
для последующего счета и переноса на T++ и счета на компьютерах семейства Скиф.
Хмм, а вот про T++ я не слышал.
Цитата: Rialzista
А вот пока никакой рекурсии в программе нет, и пока, не предвидится. Уж так построен алгоритм, только считай.
Если мне не изменяет память, в скифах есть(будут) и не-фоннеймановские вычислители, типа CUDA или ПЛИСок "толстых"? Тогда отсутствие рекурсии вполне понятно. :)
Если не ошибаюсь T++ восходит корнями к такой вещи как T-система (разработка ИПС РАН), в которой была реализована концепция Т-функции - нечто, вычисляющее какие-то данные (близко к функциональному программированию). Программа, состоящая из T-функций, может естественным образом параллелиться (эффективно или нет - другой вопрос), так как каждая Т-функция может выполняться... ну что ли независимо... и вернет результат только тогда, когда будут готовы данные для ее вычисления. В итоге реализуется так называемая концепция программирования потока данных, перетекающих между T-функциями.
Соответственно, очень много зависит от того как эти данные передаются между фукнциями и как это реализуется на языков уровне T++. Покажите пример функции, для которой вам нужен большой стек. Hardcase вам уже намекал на это :)
Вот... даже все написано
http://ru.wikipedia.org/wiki/%D0%A2-%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0
Википедиа - рулит!
Соответственно, очень много зависит от того как эти данные передаются между фукнциями и как это реализуется на языков уровне T++. Покажите пример функции, для которой вам нужен большой стек. Hardcase вам уже намекал на это :)
Вот... даже все написано
http://ru.wikipedia.org/wiki/%D0%A2-%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0
Википедиа - рулит!
Цитата: Rialzista
...великое множество коэффициентов которые где-то необходимо хранить или записывать в файл. Понятно, что первое предложение является более выгодным, но при произвольном задании переменных и точек разбиения сложность задачи возрастает экспоненциально. (переменные^точки разбиения)
Но не на стеке же это хранить, для сего существуют: куча, алоцируемые сегменты и, что самое веселое, отмапированные в память файлы.
PS: А по поводу T++ - очередной, свой "особенный" велосипед с колесами за ушами, созданный отечественными нанотехнологами в лучшем случае в виде ксерокса OpenMP, а то и тупого как пробка препроцессора к нему же.
Цитата: Ramon
PS: А по поводу T++ - очередной, свой "особенный" велосипед с колесами за ушами, созданный отечественными нанотехнологами в лучшем случае в виде ксерокса OpenMP, а то и тупого как пробка препроцессора к нему же.
Ну я бы не стал так прямо хаять "отчественного производителя". Все же T++ и OpenMP - это идеологически разные подходы, хотя реализация на уровне языка немного похожа (пичкаем код некоторыми декларациями).
ИМХО изобретение собственного "лисапеда" вне зависимости от идеологии достойно порицания - если это не воплощено в реальный код и конкретные решения которые способны дать опеределенный выиграш. Потому как использование готовых решений - это хорошо - но накладывает в свою очередь массу ограничений и не стимулирует роста специалистов в своей стране - а это уже шаг назад в развитии собственной науки. Не стоит надеятся на альтруизм МИТ и подобных научных заведений - они решают в первую очередь задачи конкретного госдепартамента - а потом уже научные задачи. Поэтому прежде чем обхаять - стоит посмотреть зачем и почему создавался конкретный "велосипед" - и на столько ли он на самом деле "велосипед" как это кажется с первого взгляда.
Цитата: grgdvo
Ну я бы не стал так прямо хаять "отчественного производителя". Все же T++ и OpenMP - это идеологически разные подходы, хотя реализация на уровне языка немного похожа (пичкаем код некоторыми декларациями).
"Идеологически разные подходы" это, видимо, распределенность вычислений по сети. Однако упс и где здесь идеологическая разница? А бытность особенными есть самое закоренелое заблуждение. Хотя нет - работа провЕдена, средствА освоены.
PS: А видимость "проделанной" работы реализуется посредством тройки студентов ваяющих макроподстановщик к МИТ'овскому бояну. Естественно никто из них ни в бумажках ни на словах никак не упоминается. Вот и вся "наука" на сегодняшний день. К сожалению.
Распределенность вычислений по сети здесь не причем. Идеологическое различие состоит в том, что OpenMP явное описание параллелизма на уровне потоков, а T++ неявное описание параллелизма в виде специальных функций, работа которых контролируется специальными T-переменными, имеющиим два состояния: готова, неготова. В результате: OpenMP - это то, что теоретики называют императивным подходом к описанию параллелизма - параллельный поток управления описывается ЯВНО, а T++ - это уже ближе к функциональному подходу - параллельный поток управления НЕ описывается ЯВНО.
Приходим к извечному спору, что лучше: императивные языки программирования или функциональные. Императивные языки программирования проще для понимания и работы, функциональные - мозги свернешь, пока придумаешь, зато нигде не говориться, что используется понятие потока, процесса или еще чего, что привязывает нас к архитектуре компьютера. Для первых нужен простой компилятор, который "не думает", как надо параллелить - все написано в программе, для вторых нужен "умный" компилятор, которые "должен думать", как параллелить.
Это не доказано, но, опять же, теоритики утверждают, что функциональный подход обладает бОльшим потенциалом параллелизма. Так что в свете удвоения количества ядер в процессоре примерно каждые два года, мы скоро очень быстро устанем их программировать и потребуется нечто, похожее на T++.
Приходим к извечному спору, что лучше: императивные языки программирования или функциональные. Императивные языки программирования проще для понимания и работы, функциональные - мозги свернешь, пока придумаешь, зато нигде не говориться, что используется понятие потока, процесса или еще чего, что привязывает нас к архитектуре компьютера. Для первых нужен простой компилятор, который "не думает", как надо параллелить - все написано в программе, для вторых нужен "умный" компилятор, которые "должен думать", как параллелить.
Это не доказано, но, опять же, теоритики утверждают, что функциональный подход обладает бОльшим потенциалом параллелизма. Так что в свете удвоения количества ядер в процессоре примерно каждые два года, мы скоро очень быстро устанем их программировать и потребуется нечто, похожее на T++.
Цитата: grgdvo
Распределенность вычислений по сети здесь не причем. Идеологическое различие состоит в том, что OpenMP явное описание параллелизма на уровне потоков, а T++ неявное описание параллелизма в виде специальных функций, работа которых контролируется специальными T-переменными, имеющиим два состояния: готова, неготова. В результате: OpenMP - это то, что теоретики называют императивным подходом к описанию параллелизма - параллельный поток управления описывается ЯВНО, а T++ - это уже ближе к функциональному подходу - параллельный поток управления НЕ описывается ЯВНО.
В обоих случаях параллелизм описывается явно в OpenMP прагмами, а в T++ ключевыми словами.
OpenMP
Код:
T++
Код:
tfun int fib(int n)
{
return n < 2 ?
n : fib(n - 1) + fib(n - 2); // Здесь не забываем, что функция fib объявлена с tfun
}
{
return n < 2 ?
n : fib(n - 1) + fib(n - 2); // Здесь не забываем, что функция fib объявлена с tfun
}
А реализация в этом самом магическом T++ аля: жуем соурс препроцессором, разжовывающим новые ключевые слова в ядреную смесь макросов с добавлением магических инклудов, о них далее, далее сие поступает на вход к компилятору C++. А теперь про макросы и инклуды: посредством тех самых магических макросов генерятся активные функциональные объекты с контекстом, посредством месива (из подсасонных инклудов) из все тех же макросов, классов, шаблонов, да чего там только нет, а в каком виде...
Итого: Посмотрев код, моя опала o_O. Авторы заслуживают как минимум маек с надписями "Master of Achtung!!!" ибо они похоже ушли в самадхи и уже очень давно. Да, это наше родное, преклоняюсь.
Любопытно.
Странно что код приведен из википедии. При таком запале стоило бы приводить фрагменты рабочего кода - явно демонстрирующего бдыдлокодерство разработчиков.
Странно что код приведен из википедии. При таком запале стоило бы приводить фрагменты рабочего кода - явно демонстрирующего бдыдлокодерство разработчиков.
Цитата: kot_
Любопытно.
Странно что код приведен из википедии. При таком запале стоило бы приводить фрагменты рабочего кода - явно демонстрирующего бдыдлокодерство разработчиков.
Странно что код приведен из википедии. При таком запале стоило бы приводить фрагменты рабочего кода - явно демонстрирующего бдыдлокодерство разработчиков.
Да пожалуйста, это то что получается на выходе из преепроцессора:
Код:
TFUNDEF(int, fib, (int n), (n), /*static*/, int n ;, { ts::Freezer _f; ts::ParentTemporaryOn _p(_tf); _tf->n = n; } ;, , )
TFUNIMPL(int, fib, (int n), (n), /*static*/, int n ;, { ts::Freezer _f; ts::ParentTemporaryOn _p(_tf); _tf->n = n; } ;, , )
{
return n < 2 ? n : fib(n-1) + fib(n-2);
}
TFUNIMPL(int, fib, (int n), (n), /*static*/, int n ;, { ts::Freezer _f; ts::ParentTemporaryOn _p(_tf); _tf->n = n; } ;, , )
{
return n < 2 ? n : fib(n-1) + fib(n-2);
}
А это кусочег магического хедера, в нем еще семь с половиной тысяч строчег аналогичного кода:
Код:
// Add to factory (New) tct() from definition
#define TFUNDEF(type,fun,pars,purepars,stas,args,argi,outs,outi) \
extern ts::TFunCtxt fun##TFunCtxt; \
struct fun##TArgDef { args ts::TFunCtxt* _fid; }; \
struct fun##TFunDef: public ts::TFun<type, fun##TFunCtxt>, fun##TArgDef { \
outs \
virtual ts::TFrz<type> body() = 0; \
static fun##TFunDef* New(); \
}; \
type fun##Cversion pars; \
static inline ts::TFrz<type> fun pars { \
ts::TSLocker _l; \
MAYBE_C_CALL(type,fun,purepars); \
fun##TFunDef *_tf = fun##TFunDef::New(); \
argi \
_tf->stopAndContParent(); \
_tf = (fun##TFunDef*)fun##TFunDef::tryToReuseMemo(_tf,(fun##TArgDef*)_tf,sizeof(fun##TArgDef)); \
outi \
return _tf->retfrz; \
}
// Add tct here
#define TFUNIMPL(type,fun,pars,purepars,stas,args,argi,outs,outi) \
ts::TFunCtxt fun##TFunCtxt(#fun);\
struct fun##TArgImpl { args ts::TFunCtxt* _fid; }; \
struct fun##TFunImpl: public ts::TFun<type,fun##TFunCtxt>, fun##TArgImpl { \
outs stas \
virtual ts::TFrz<type> body(); \
virtual ts::SData* clone(); \
}; \
ts::SData* fun##TFunImpl::clone() { \
size_t extra = ts::Task::get_extra(); \
ts::SData* p = \
(ts::SData*)(new(extra) fun##TFunImpl(*this)); \
if (extra > 0) \
memcpy((char*)p + sizeof(fun##TFunImpl),(char*)this + sizeof(fun##TFunImpl),extra); \
return p; \
} \
fun##TFunDef* fun##TFunDef::New() { \
size_t extra = ts::Task::get_extra(); \
fun##TFunDef* p = (fun##TFunDef*)(new(extra) fun##TFunImpl); \
p->_fid = &fun##TFunCtxt; \
ts::Task::after_ctor(p); \
return p; \
} \
ts::TFrz<type> fun##TFunImpl::body()
#define TFUNDEF(type,fun,pars,purepars,stas,args,argi,outs,outi) \
extern ts::TFunCtxt fun##TFunCtxt; \
struct fun##TArgDef { args ts::TFunCtxt* _fid; }; \
struct fun##TFunDef: public ts::TFun<type, fun##TFunCtxt>, fun##TArgDef { \
outs \
virtual ts::TFrz<type> body() = 0; \
static fun##TFunDef* New(); \
}; \
type fun##Cversion pars; \
static inline ts::TFrz<type> fun pars { \
ts::TSLocker _l; \
MAYBE_C_CALL(type,fun,purepars); \
fun##TFunDef *_tf = fun##TFunDef::New(); \
argi \
_tf->stopAndContParent(); \
_tf = (fun##TFunDef*)fun##TFunDef::tryToReuseMemo(_tf,(fun##TArgDef*)_tf,sizeof(fun##TArgDef)); \
outi \
return _tf->retfrz; \
}
// Add tct here
#define TFUNIMPL(type,fun,pars,purepars,stas,args,argi,outs,outi) \
ts::TFunCtxt fun##TFunCtxt(#fun);\
struct fun##TArgImpl { args ts::TFunCtxt* _fid; }; \
struct fun##TFunImpl: public ts::TFun<type,fun##TFunCtxt>, fun##TArgImpl { \
outs stas \
virtual ts::TFrz<type> body(); \
virtual ts::SData* clone(); \
}; \
ts::SData* fun##TFunImpl::clone() { \
size_t extra = ts::Task::get_extra(); \
ts::SData* p = \
(ts::SData*)(new(extra) fun##TFunImpl(*this)); \
if (extra > 0) \
memcpy((char*)p + sizeof(fun##TFunImpl),(char*)this + sizeof(fun##TFunImpl),extra); \
return p; \
} \
fun##TFunDef* fun##TFunDef::New() { \
size_t extra = ts::Task::get_extra(); \
fun##TFunDef* p = (fun##TFunDef*)(new(extra) fun##TFunImpl); \
p->_fid = &fun##TFunCtxt; \
ts::Task::after_ctor(p); \
return p; \
} \
ts::TFrz<type> fun##TFunImpl::body()
PS: Запала никакого нет. Это тупой беглый анализ на пять минут.
Цитата: Ramon
В обоих случаях параллелизм описывается явно в OpenMP прагмами, а в T++ ключевыми словами.
Мне кажется, в этом месте заблуждение. Понятие "функция" не имеет никакого отношения к параллелизму. Хоть на Вики и написали, что она является гранулой параллелизма, но нигде явно не сказано, что если указали tfun, то значит запуститься отдельный поток. Опять же... Если брать во внимание tvar-ы, то не факт, что вызов tfun-функции приведет к ее немедленному запуску в отдельном потоке.
В макросах, конечно, намешали чего-то много всего... Но не факт, что OpenMP выглядит прощще после препроцессинга. Да и надо бы разобраться, чего в макросах намешали-то.
Пока не убедительено, почитаю я подробнее про T++. Продолжение дискуссии на усмотрение участников.