ограничения на выделение памяти malloc()

[arseniiv]

Кстати, насколько понимаю, вопрос о RAM повис в воздухе, а ведь может быть ситуация, что кусок этого громадного массива лежит в свопе на диске. И не нужно говорить, насколько это плохо, если доступ далёк от последовательного.

[Dmitriy40]

Ну если уж "все счётчики поменял на int64", то стопудово проблема где-то в смешении типов, указатель и просто число (например счётчик цикла или промежуточный буфер для хранения указателя или параметр вызова функций или ещё какие-то вычисления над указателями). Причём она никуда не делась, так и осталась ненайденной.
Останов/замирание на 38Г может быть по другой причине, не именно из-за указателя, что-то другое где-то переполняется (и уходит в вечный цикл) или может и правда резко своп начинается, ничего ж не сказано. Но ведь не вылетает же - значит вряд ли дело в указателе в массив.

[Andrey_Kireew]

Dmitriy40 в сообщении #1331680 писал(а):

... причём она никуда не делась, так и осталась ненайденной.
Останов/замирание на 38Г может быть по другой причине ...

Вот и я подозреваю, что где то осталась ошибка, буду пытаться найти (предыдущие копии у меня сохранились). По поводу 38Гб - сейчас ошибки нет, память загружается до 62 Гб без каких либо зависаний, вылечено сменой типов, причём в тех местах, где переменные, на первый взгляд уж ни как не должны принимать такие огромные значения. Вернусь назад и буду смотреть по новой, нудно понять, в чём было дело, это избавит от многих проблем в будущем.

Пока прошу подсказки

Используется синтаксис C

int a;
double *b;

................
double *str=(double*) malloc(a*b*sizeof(double));
 

какого тина результат будет в скобках malloс ?

насколько я понял, указатели 64 разрядные, т.к. с ними я ничего не делал и проблем сейчас нет,
но если я умножаю этот указатель на int то будет 64 разрядным результат, или он будет 32 разрядный, с возможным усечением?
Если второе, то может тогда как то явно указать тип произведения, например:

Используется синтаксис C

................................
double *str=(double*) malloc((_int64)(a*b*sizeof(double));
 

или от этого не будет толку, и нужно заводить переменную _int64, в ней всё сначала перемножить, а потом подставить в malloc() ?

-- 10.08.2018, 22:42 --

arseniiv в сообщении #1331647 писал(а):

Кстати, насколько понимаю, вопрос о RAM повис в воздухе, а ведь может быть ситуация, что кусок этого громадного массива лежит в свопе на диске. И не нужно говорить, насколько это плохо, если доступ далёк от последовательного.

тут вообще то речь идёт не о "лежании" а об обработке, будь он в swap, и без того медленная скорость стала бы просто неприемлемой ...

[Dmitriy40]

Andrey_Kireew в сообщении #1331686 писал(а):

какого тина результат будет в скобках malloс ?

Я не понимаю, у Вас b - указатель на double. Но разве указатель можно умножать?! Мне помнилось для указателей определены лишь операции увеличения/уменьшения и взятия разности двух указателей (даже сумму указателей нельзя!), никаких умножений, делений, синусов, корней, логарифмов и прочего к ним применять нельзя. И тут компилятор должен был ругнуться и не компилить.
В чём собственно смысл умножения указателя на число?
Если у Вас весь код такого уровня ...
PS. Первый попавшийся пруф:

Онлайн справочник программиста на C и C++ писал(а):

К указателям могут применяться только две арифметические операции: сложение и вычитание.
...
Можно добавлять или вычитать из указателей целые числа.
...
Помимо добавления или вычитания указателей и целых чисел, единственную операцию, которую можно выполнять с указателями, - это вычитание одного указателя из другого. В большинстве случаев вычитание одного указателя из другого имеет смысл только тогда, когда оба указателя указывают на один объект, - как правило, массив. В результате вычитания получается число элементов базового типа, находящихся между указателями. Помимо этих операций не существует других арифметических операций, применимых к указателям. Нельзя умножать или делить указатели, нельзя складывать указатели, нельзя применять битовый сдвиг или маски к указателям, нельзя добавлять или вычитать типы float или double.

-- 10.08.2018, 22:31 --

Может Вы путаете указатель и индекс в массиве (или и размер массива)? Это индекс можно и умножать, и делить, и что угодно делать, он как был числом так им и останется. А указатель - не число! И для него определены лишь строго ограниченные операции.

[Andrey_Kireew]

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

Используется синтаксис C

size_t len_y;
int nVars;

................
double *str=(double*) malloc(nVars*len_y*sizeof(double));
 

int nVars я уже поменял на_int64 nVars, и вот думаю, могло это повлиять или нет?
результат sizeof() тоже size_t, а если умножить на int что получится? По идее должен получаться самый большой по размеру тип, но как оно на самом деле не знаю ...

-- 11.08.2018, 00:24 --

P.S.: на счёт умножения указателей я в курсе. Если умножать, то только их разности (ну или смещения). Сейчас посмотрел - они у меня раньше были типа int, а теперь уже _int64 может в этом проблема и была.

[Dmitriy40]

Неявное приведение типов всегда происходит к более точному, для целых - к знаковому большей разрядности. (Жаль что к знаковому, это создаёт проблемы, однако так.)

Используется синтаксис C

int a=1000000;
long int b=1000000000000;
int main(void)
{
    printf("%ld,%ld,%ld\n",a,b,a*b);
    return 0;
}
Вывод:
1000000,1000000000000,1000000000000000000

Использовался онлайн gcc. Как видно произведение реально 64-х битное.

[Andrey_Kireew]

Тогда тут всё нормально. Но первую ошибку я выявил точно, дело было в смещении адресов, на больших данных оно вылезло за пределы int. Больше пока ничего не нашел, но видимо, должно быть смещение, которое переполняется при общем объёме данных 38 Гб.

[Dmitriy40]

Andrey_Kireew

Dmitriy40 в сообщении #1331680 писал(а):

Останов/замирание на 38Г может быть по другой причине, не именно из-за указателя, что-то другое где-то переполняется (и уходит в вечный цикл) или может и правда резко своп начинается, ничего ж не сказано. Но ведь не вылетает же - значит вряд ли дело в указателе в массив.

[Andrey_Kireew]

Dmitriy40 да нет, Вы не правильно меня поняли, как раз тоже попытка доступа к неразрешенной области памяти, появляется такое же как и положено в этом случае сообщение и программа "висит. Это не вечный цикл.

P.S.: swap там отключен, так как необходимости в нём никакой нет, памяти вполне достаточно для всего что нужно

[Dmitriy40]

А-а-а, да, понял неправильно.

[dobrichev]

Некоторые опции компилятора выдают предупреждения когда больший тип int64 неявно присваиваеться меньшему inr32. Попробуйте найти и пользовать ету опцию для вашего компилятора.

[Andrey_Kireew]

dobrichev это было, я исправлял так

Используется синтаксис C

int val=a*Len;
 Warning: .......

int val=int(a*Len);
  Ok!
 

вот и результат такого игнорирования ...
Разумеется, после смены всех типов на _int64 никаких преобразований типов не требуется и предупреждений больше нет (ну разве что одно - сравнение знакового _int64 и без знакового size_t, вылечено как обычно _int64(x), но тут проблем быть не должно, да и сразу будет понятно где, если что)

[dobrichev]

Andrey_Kireew в сообщении #1331721 писал(а):

dobrichev это было, я исправлял так

Используется синтаксис C

int val=int(a*Len);
 

Вот так делать нельзя. Передумайте и попытайтесь найти если кое-что из этих интервенции осталось. Может быть и в другой форме, например val=(int)x.
Ищите в коде sizeof(int), возможно и там что-то перепутано.

Майкрософт имеют непонятною политику ограничывать количество доступной памьяти по разному в разных под-версии ОС. Найдите какие ограничения для вашей версии.

[Andrey_Kireew]

dobrichev спасибо, эти штуки я уже проверил, вроде как не осталось ничего такого.
Что касается Win7 x64, то для prof и выше, все они поддерживают 192 ГБ (по крайней мере так пишут, проверять не довелось), так что для моего железа её более чем достаточно

[Dmitriy40]

Andrey_Kireew в сообщении #1331721 писал(а):

ну разве что одно - сравнение знакового _int64 и без знакового size_t, вылечено как обычно _int64(x)

Пока такой код работать будет. Пока size_t не стал больше int64_t (вдруг через несколько лет захотите запустить код на машине с 10 и более экзабайтами памяти? ) - а тогда получите снова аналогичную проблему с обрезанием чисел, т.е. этим Вы рассыпаете по коду грабли места возможных в будущем ошибок, причём труднее обнаруживаемых (это уже не указатели с вылетом по ошибке доступа, тут лишь допустимое обращение в массив будет по другому индексу или зацикливание программы).
Потому я бы при сравнении приводил в обратную сторону, int64_t к size_t. И добавил бы в самое начало программы нечто типа

Используется синтаксис C++

assert(sizeof(int64_t) <= sizeof(size_t));//Надо снова перепроверять все преобразования типов

Как действовать если памяти на машине от 9 до 18 экзабайтов (и вы собрались обрабатывать такие массивы) и потому размер size_t и int64_t совпадает (если и правда совпадёт, а не будет расширен до 128 битов), а вот диапазон значений нет ($10^{19}$ для size_t допустимо, а для int64_t нет) - я не уверен. Одним из выходов было бы использование везде где идёт итерация массивов типа uint64_t вместо int64_t, но это сдвигает проблему в другие участки кода и часто усложняет код из-за пропадания удобного трюка с отрицательным индексом как недопустимого, да ещё и разность индексов станет беззнаковой что может обрушить некоторые алгоритмы. Возможно стоит пользоваться приведением size_t к int64_t как Вы и сделали (с обязательным assert(sizeof(int64)>=sizeof(size_t)) в начале программы), но всегда проверять после выделения больших массивов (или перед циклом их обработки) их размер примерно так

Используется синтаксис C++

assert(sizeof(array) < INT64_MAX);//Слишком огромный массив!

В общем решение с приведением size_t к int64_t выглядит как временное пока работающее, но кардинально лучшего мне в голову не приходит.

UPD.
Да, и если Вы под size_t на самом деле имели в виду указатели, то всё становится ещё в разы хуже, т.к. указатели даже в уже реально существующих системах вполне могут не влезать в int64_t, пример нашёлся тут в единственном ответе.