Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Увеличение размера стека GCC или G++

55K
27 декабря 2009 года
Rialzista
3 / / 27.12.2009
Добрый вечер.

Есть необходимость увеличения стека в С++. Как это возможно сделать для g++ или gcc.
412
27 декабря 2009 года
grgdvo
323 / / 04.07.2007
Не уверен, что правильно уловил суть вопроса... Вообще-то стек - больше имеет отношение к времени выполнения, а не к времени компиляции. Компилятор не такой умный, чтобы предсказывать рекурсию в вашей программе. Боюсь, что таких опций у gcc в принципе нет. Может речь идет о системных ограничениях ?? (см. ulimit)
55K
27 декабря 2009 года
Rialzista
3 / / 27.12.2009
Вопрос был понят правильно. Смысл заключается в том, чтобы увеличить количество стека, для того чтобы дать возможность программе захватить как можно больше памяти. И в результате посчитать как можно большее количество точек. (В целом речь идет о аппроксимации функций многих переменных)
2
27 декабря 2009 года
squirL
5.6K / / 13.08.2003
операционная система, конечно же, OpenVMS, да?

для Linux - дефолтное ограничение можно посмотреть через ulimit -s. обычно это 8Мб. увеличте его через setrlimit и не надо трогать gcc
5
27 декабря 2009 года
hardcase
4.5K / / 09.08.2005
Цитата: Rialzista
Смысл заключается в том, чтобы увеличить количество стека, для того чтобы дать возможность программе захватить как можно больше памяти. И в результате посчитать как можно большее количество точек. (В целом речь идет о аппроксимации функций многих переменных)

Что-то у вас с алгоритмом нелады. 8Мб памяти на стеке хватает для практически любых задач (даже космической сложности). Подозреваю, что у вас аргументы передаются копированием на стеке (по значению), а не через кучу (по ссылке), что для глубокой рекурсии равносильно отстрелу одной из нижних конечности из дедушкиного ружья (собственно, у вас это и происходит).

55K
27 декабря 2009 года
Rialzista
3 / / 27.12.2009
История обстоит вот каким еще образом. Сами функции придумывают далеко не глупые люди т.е. Физики =) И эти люди просят реализовать возможность работы программы в целом для n-ого количества переменных и точек разбиения по каждой переменной. Что в наших задачах рождает великое множество коэффициентов которые где-то необходимо хранить или записывать в файл. Понятно, что первое предложение является более выгодным, но при произвольном задании переменных и точек разбиения сложность задачи возрастает экспоненциально. (переменные^точки разбиения) И сейчас идет этап тестового написания алгоритма на C++ для последующего счета и переноса на T++ и счета на компьютерах семейства Скиф.
А вот пока никакой рекурсии в программе нет, и пока, не предвидится. Уж так построен алгоритм, только считай.

Если интересно можно распространяться и дальше на эту тему т.к. это мой диплом, а дальше и кандидатская.
5
27 декабря 2009 года
hardcase
4.5K / / 09.08.2005
Цитата: Rialzista
История обстоит вот каким еще образом....

История интересная. Только где в ней место малому стеку? ;)


Цитата: Rialzista
для последующего счета и переноса на T++ и счета на компьютерах семейства Скиф.

Хмм, а вот про T++ я не слышал.

Цитата: Rialzista
А вот пока никакой рекурсии в программе нет, и пока, не предвидится. Уж так построен алгоритм, только считай.


Если мне не изменяет память, в скифах есть(будут) и не-фоннеймановские вычислители, типа CUDA или ПЛИСок "толстых"? Тогда отсутствие рекурсии вполне понятно. :)

412
28 декабря 2009 года
grgdvo
323 / / 04.07.2007
Если не ошибаюсь 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
Википедиа - рулит!
260
28 декабря 2009 года
Ramon
1.1K / / 16.08.2003
Цитата: Rialzista
...великое множество коэффициентов которые где-то необходимо хранить или записывать в файл. Понятно, что первое предложение является более выгодным, но при произвольном задании переменных и точек разбиения сложность задачи возрастает экспоненциально. (переменные^точки разбиения)



Но не на стеке же это хранить, для сего существуют: куча, алоцируемые сегменты и, что самое веселое, отмапированные в память файлы.

PS: А по поводу T++ - очередной, свой "особенный" велосипед с колесами за ушами, созданный отечественными нанотехнологами в лучшем случае в виде ксерокса OpenMP, а то и тупого как пробка препроцессора к нему же.

412
02 января 2010 года
grgdvo
323 / / 04.07.2007
Цитата: Ramon

PS: А по поводу T++ - очередной, свой "особенный" велосипед с колесами за ушами, созданный отечественными нанотехнологами в лучшем случае в виде ксерокса OpenMP, а то и тупого как пробка препроцессора к нему же.



Ну я бы не стал так прямо хаять "отчественного производителя". Все же T++ и OpenMP - это идеологически разные подходы, хотя реализация на уровне языка немного похожа (пичкаем код некоторыми декларациями).

1
02 января 2010 года
kot_
7.3K / / 20.01.2000
ИМХО изобретение собственного "лисапеда" вне зависимости от идеологии достойно порицания - если это не воплощено в реальный код и конкретные решения которые способны дать опеределенный выиграш. Потому как использование готовых решений - это хорошо - но накладывает в свою очередь массу ограничений и не стимулирует роста специалистов в своей стране - а это уже шаг назад в развитии собственной науки. Не стоит надеятся на альтруизм МИТ и подобных научных заведений - они решают в первую очередь задачи конкретного госдепартамента - а потом уже научные задачи. Поэтому прежде чем обхаять - стоит посмотреть зачем и почему создавался конкретный "велосипед" - и на столько ли он на самом деле "велосипед" как это кажется с первого взгляда.
260
03 января 2010 года
Ramon
1.1K / / 16.08.2003
Цитата: grgdvo
Ну я бы не стал так прямо хаять "отчественного производителя". Все же T++ и OpenMP - это идеологически разные подходы, хотя реализация на уровне языка немного похожа (пичкаем код некоторыми декларациями).



"Идеологически разные подходы" это, видимо, распределенность вычислений по сети. Однако упс и где здесь идеологическая разница? А бытность особенными есть самое закоренелое заблуждение. Хотя нет - работа провЕдена, средствА освоены.

PS: А видимость "проделанной" работы реализуется посредством тройки студентов ваяющих макроподстановщик к МИТ'овскому бояну. Естественно никто из них ни в бумажках ни на словах никак не упоминается. Вот и вся "наука" на сегодняшний день. К сожалению.

412
03 января 2010 года
grgdvo
323 / / 04.07.2007
Распределенность вычислений по сети здесь не причем. Идеологическое различие состоит в том, что OpenMP явное описание параллелизма на уровне потоков, а T++ неявное описание параллелизма в виде специальных функций, работа которых контролируется специальными T-переменными, имеющиим два состояния: готова, неготова. В результате: OpenMP - это то, что теоретики называют императивным подходом к описанию параллелизма - параллельный поток управления описывается ЯВНО, а T++ - это уже ближе к функциональному подходу - параллельный поток управления НЕ описывается ЯВНО.

Приходим к извечному спору, что лучше: императивные языки программирования или функциональные. Императивные языки программирования проще для понимания и работы, функциональные - мозги свернешь, пока придумаешь, зато нигде не говориться, что используется понятие потока, процесса или еще чего, что привязывает нас к архитектуре компьютера. Для первых нужен простой компилятор, который "не думает", как надо параллелить - все написано в программе, для вторых нужен "умный" компилятор, которые "должен думать", как параллелить.

Это не доказано, но, опять же, теоритики утверждают, что функциональный подход обладает бОльшим потенциалом параллелизма. Так что в свете удвоения количества ядер в процессоре примерно каждые два года, мы скоро очень быстро устанем их программировать и потребуется нечто, похожее на T++.
260
03 января 2010 года
Ramon
1.1K / / 16.08.2003
Цитата: grgdvo
Распределенность вычислений по сети здесь не причем. Идеологическое различие состоит в том, что OpenMP явное описание параллелизма на уровне потоков, а T++ неявное описание параллелизма в виде специальных функций, работа которых контролируется специальными T-переменными, имеющиим два состояния: готова, неготова. В результате: OpenMP - это то, что теоретики называют императивным подходом к описанию параллелизма - параллельный поток управления описывается ЯВНО, а T++ - это уже ближе к функциональному подходу - параллельный поток управления НЕ описывается ЯВНО.



В обоих случаях параллелизм описывается явно в OpenMP прагмами, а в T++ ключевыми словами.

OpenMP

Код:
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;
}


T++
 
Код:
tfun int fib(int n)
{
    return n < 2 ?
        n : fib(n - 1) + fib(n - 2); // Здесь не забываем, что функция fib объявлена с tfun
}


А реализация в этом самом магическом T++ аля: жуем соурс препроцессором, разжовывающим новые ключевые слова в ядреную смесь макросов с добавлением магических инклудов, о них далее, далее сие поступает на вход к компилятору C++. А теперь про макросы и инклуды: посредством тех самых магических макросов генерятся активные функциональные объекты с контекстом, посредством месива (из подсасонных инклудов) из все тех же макросов, классов, шаблонов, да чего там только нет, а в каком виде...

Итого: Посмотрев код, моя опала o_O. Авторы заслуживают как минимум маек с надписями "Master of Achtung!!!" ибо они похоже ушли в самадхи и уже очень давно. Да, это наше родное, преклоняюсь.
1
03 января 2010 года
kot_
7.3K / / 20.01.2000
Любопытно.
Странно что код приведен из википедии. При таком запале стоило бы приводить фрагменты рабочего кода - явно демонстрирующего бдыдлокодерство разработчиков.
260
03 января 2010 года
Ramon
1.1K / / 16.08.2003
Цитата: 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);
}


А это кусочег магического хедера, в нем еще семь с половиной тысяч строчег аналогичного кода:
Код:
// 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()


PS: Запала никакого нет. Это тупой беглый анализ на пять минут.
412
04 января 2010 года
grgdvo
323 / / 04.07.2007
Цитата: Ramon
В обоих случаях параллелизм описывается явно в OpenMP прагмами, а в T++ ключевыми словами.



Мне кажется, в этом месте заблуждение. Понятие "функция" не имеет никакого отношения к параллелизму. Хоть на Вики и написали, что она является гранулой параллелизма, но нигде явно не сказано, что если указали tfun, то значит запуститься отдельный поток. Опять же... Если брать во внимание tvar-ы, то не факт, что вызов tfun-функции приведет к ее немедленному запуску в отдельном потоке.

В макросах, конечно, намешали чего-то много всего... Но не факт, что OpenMP выглядит прощще после препроцессинга. Да и надо бы разобраться, чего в макросах намешали-то.

Пока не убедительено, почитаю я подробнее про T++. Продолжение дискуссии на усмотрение участников.

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог