LINUX.ORG.RU

100500-й вопрос по realloc

 ,


0

1

почему в С98 и С++ realloc() пытается расширить текущий блок, и лишь в случае неудачи выделяет память на новом месте а в С99 — сразу выделяет память на новом месте?

★★★★★★

Последнее исправление: cetjs2 (всего исправлений: 1)
Ответ на: комментарий от anonymous

Тебе это ничего не даст

Если это правда, то от realloc() версии С99 нет толка, а от С98/С++ есть

причем пруфцов нет

Сказал же: Гербердт Шилдт, справочник программиста 3-е издание, страница 221, русскоязычная версия. Нет основания считать, что переведена не верна: там явно делается акцент на то, что realloc() С++ и С99 работают по разному

Вообще кому сейчас нужен реалок я не знаю - выкинь его и забудь про него.

скорость

next_time ★★★★★★
() автор топика
Ответ на: комментарий от next_time

Если это правда, то от realloc() версии С99 нет толка, а от С98/С++ есть

Это почему ещё? С чего ты сделал такой вывод? Судя по тестам поцанов оно таки расширят.

Сказал же: Гербердт Шилдт, справочник программиста 3-е издание, страница 221, русскоязычная версия. Нет основания считать, что переведена не верна: там явно делается акцент на то, что realloc() С++ и С99 работают по разному

Ну это какбэ не пруфец. Вычислить это не реально, а ссылки на стандарт он похоже не привёл.

скорость

Реалок и скорость понятия не совместимые. Если ты имеешь ввиду скорость посравнению с с89 реалоком?

anonymous
()
Ответ на: комментарий от anonymous

Это почему ещё? С чего ты сделал такой вывод? Судя по тестам поцанов оно таки расширят.

я же сказал: если правда, сказанное Шилдтом

Вычислить это не реально, а ссылки на стандарт он похоже не привёл.

вообще не видел ни в одной книге пачки ссылок на стандарт

Если ты имеешь ввиду скорость посравнению с с89 реалоком?

по моим тестам реаллок быстрее, чем маллок + фри в 1,69 раза

next_time ★★★★★★
() автор топика
Ответ на: комментарий от next_time

вообще не видел ни в одной книге пачки ссылок на стандарт

Патамучто жалкие книженки пишут бездари, не?

по моим тестам реаллок быстрее, чем маллок + фри в 1,69 раза

Тесты в студию.

anonymous
()
Ответ на: комментарий от anonymous
#include "stdio.h"
#include "stdlib.h"
#include "time.h"

int main(void)
{
void *p = malloc(5);
unsigned int i;
clock_t time = clock();
for(i = 0; i<0x1FFFFFE; i++){
	p = realloc(p, 6);
	p = realloc(p, 5);
	/*p = new char[6];
	delete[] p;
	p = new char[5];
	delete[] p;*/
	/*p = malloc(6);
	free(p);
	p = malloc(5);
	free(p);*/

}

printf("time: %ims\n", (clock() - time)/(CLOCKS_PER_SEC/1000));

}

next_time ★★★★★★
() автор топика
Ответ на: комментарий от next_time

Ну и что ты этим забенчил? В этом(этот случай какбэ вообще не имеет смысла, но предположим, что оно растёт у тебя по 10) случае просто юзается malloc(100500) и реалок нахрен не нужен.

anonymous
()
Ответ на: комментарий от next_time

Вообще кому сейчас нужен реалок я не знаю - выкинь его и забудь про него.

скорость

ты в этом ТОЧНО УВЕРЕН?

emulek
()
Ответ на: комментарий от next_time

по моим тестам реаллок быстрее, чем маллок + фри в 1,69 раза

дай тесты, и я скажу, ЧТДНТ.

emulek
()
Ответ на: комментарий от anonymous

Ну и что ты этим забенчил?

фэйспалм

этот случай какбэ вообще не имеет смысла

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

просто юзается malloc(100500)

ога, юзается. только он работает медленней, что и требовалось доказать

next_time ★★★★★★
() автор топика
Ответ на: комментарий от next_time

ну доказательство в том, что на самом деле glibc выделяет не 5 или 6 байт, а скажем 16. И когда ты делаешь realloc, у тебя просто размер этой области меняется с 5и на 6 и наоборот. Т.е. твой «тест» равносилен чему-то подобному:

void realloc1(size_t x)
{
  static int y;
  y = x;
}

int main()
{
  int j;
  for(j = 0; j < 100500; j++)
    realloc1(5), realloc1(6);
  return 0;
}

ну если не веришь, то посмотри в отладчике. Я на 146% уверен, что у тебя будет именно так.

emulek
()
Ответ на: комментарий от emulek

И когда ты делаешь realloc, у тебя просто размер этой области меняется с 5и на 6 и наоборот

кстати, это должна делать ОС. в этом весь смысл реаллока

next_time ★★★★★★
() автор топика
Ответ на: комментарий от next_time

где доказательство?

доктор прав, такие маленькие области аллокатор glibc выделяет из пула и не возвращает.

просто посмотри strace'ом

AptGet ★★★
()
Ответ на: комментарий от next_time

не, не так: оптимизация-то отключена

нет, так. Я как раз про случай без оптимизации говорил. Потому что код realloc засунут внутрь glibc, и на него никакая оптимизация ессно не действует.

emulek
()
Ответ на: комментарий от next_time

кстати, это должна делать ОС. в этом весь смысл реаллока

кстати ОС не умеет выделять 5 байтов. И 6 тоже. Моя только 4096 умеет.

emulek
()
Ответ на: комментарий от AptGet

glibc — GNU C Library (GNU библиотека). Glibc является библиотекой Си, которая обеспечивает системные вызовы и основные функции

хотя, если учесть, что ядро само на сях, ответ на вопрос зависит от точки зрения

next_time ★★★★★★
() автор топика
Ответ на: комментарий от next_time

смысл реаллока

на самом деле, malloc(3) запрашивает у системы память, не менее 4096 байтов(1 страница в x86). Если нужно 5 или 6, то malloc(3), распиливает 4096 на куски, но не меньше 16 байт. Эти куски и отдаёт приложению как области «в 5 байтов». На самом деле, ничего страшного не случится, если в массив из 5и байт записать 6й(конечно не нужно такой быдлокод юзать IRL!!! Это только сейчас и только в x86!!!)

Т.е. если ты делаешь realloc 5=>6, то не происходит ровным счётом ничего. Если делаешь 5=>25, то glibc в пределах этой страницы обычно реаллоцирует, и адрес области не меняется. Т.е. блок просто расширяется, скажем 16=>32. Естественно, это возможно не всегда. Если делаешь 5=>9001, то данный механизм отключается, и выделяется три страницы(12288), из которых ты получаешь адрес начала первой страницы.

Т.о. в malloc(3) имеется два аллокатора, один для мелких кусочков <<4096, другой для более крупных. А твой «тест» вообще ничто «тестирует».

emulek
()
Ответ на: комментарий от next_time

вы начинаете догадываться зачем нужен реаллок и почему он может быть быстрее

быстрее ЧЕГО?

emulek
()
Ответ на: комментарий от next_time

а чем плохо такое поведение?

ничем, это оптимизация

AptGet ★★★
()
Ответ на: комментарий от next_time

а чем плохо такое поведение?

ничем не плохо. Было-бы лучше, давно бы поменяли. Вышеописанный способ самый лучший в сферически-вакуумном случае. А если тебе не нравится, сделай свой СБИШ.

emulek
()
Ответ на: комментарий от AptGet

ну дык? значит, realloc эффективней: позволяет обходиться без (ре)аллокаций, там, где не может обойтись маллок+фри

next_time ★★★★★★
() автор топика
Ответ на: комментарий от next_time

значит, realloc эффективней: позволяет обходиться без (ре)аллокаций, там, где не может обойтись маллок+фри

угу. Разве это тебе не очевидно? Вот только откуда ты этот бред выкопал:

в С99 — сразу выделяет память на новом месте

Что-то не верится, что Шилдт такою чушь писал. Может это ГСМ-переводчик?

А смысл realloc'а как раз в этом и состоит, что-бы расширить память, если есть такая возможность(и нет желания велосипедить своё).

emulek
()
Ответ на: комментарий от next_time

Ты мне ответь - ты реально идиот? Ты понимаешь, что твой тест мериет «реалокацию» в том случае, когда после того куска, который ты реалоцируешь НЕ ВЫЗЫВАЛСЯ МАЛЛОК.

for(i = 0; i<0x1FFFFFE; i++){
	p = realloc(p, 6);
	p = realloc(p, 5);

Это равнозначно:

p = malloc(6);//работает, если ты догадался, на порядки быстрее.

Если ты напишешь более реальный юзкейс(у идиотов, конечно же):

for(i = 0; i<0x1FFFFFE; i++){
	p = realloc(p, i);

Это равнозначно:

p = malloc(0x1FFFFFE);//работает, если ты догадался, на порядки быстрее.

Если ты не совсем тотальный идиот ты поймёшь, почему ты несёшь херню, если же нет - мне тебя жаль.

Реалок имеет смысл только в таком юзкейсе:

for(i = 0; i<0x1FFFFFE; i++){
	p = realloc(p, i);
        ptr = malloc(10);
}

В это же случае реалок будет работать так же, как малокафри.

anonymous
()
Ответ на: комментарий от next_time

Ты мне ответь - ты реально идиот? Ты понимаешь, что твой тест мериет «реалокацию» в том случае, когда после того куска, который ты реалоцируешь НЕ ВЫЗЫВАЛСЯ МАЛЛОК.

for(i = 0; i<0x1FFFFFE; i++){
	p = realloc(p, 6);
	p = realloc(p, 5);

Это равнозначно:

p = malloc(6);//работает, если ты догадался, на порядки быстрее.

Если ты напишешь более реальный юзкейс(у идиотов, конечно же):

for(i = 0; i<0x1FFFFFE; i++){
	p = realloc(p, i);

Это равнозначно:

p = malloc(0x1FFFFFE);//работает, если ты догадался, на порядки быстрее.

Если ты не совсем тотальный идиот ты поймёшь, почему ты несёшь херню, если же нет - мне тебя жаль.

Реалок имеет смысл только в таком юзкейсе:

for(i = 0; i<0x1FFFFFE; i++){
	p = realloc(p, i);
        ptr = malloc(10);
}

В это же случае реалок будет работать так же, как малокафри.

anonymous
()
Ответ на: комментарий от emulek

Что-то не верится, что Шилдт такою чушь писал. Может это ГСМ-переводчик?

А смысл realloc'а как раз в этом и состоит, что-бы расширить память, если есть такая возможность(и нет желания велосипедить своё).

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

next_time ★★★★★★
() автор топика
Ответ на: комментарий от AptGet

хотя можете не отвечать на вопрос выше: суть в том, что в треде гражданин утверждал, что вызов realloc() _всегда_ обходится дороже, чем вызов free()+malloc(), я же просто привёл пример, когда это не так

next_time ★★★★★★
() автор топика
Ответ на: комментарий от next_time

Эй, нулёвая прошмандовка, ты мне тут ещё покукарекай. Ты обосрался и слился как животное.

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

anonymous
()
Ответ на: комментарий от next_time

хотя можете не отвечать на вопрос выше: суть в том, что в треде гражданин утверждал, что вызов realloc() _всегда_ обходится дороже, чем вызов free()+malloc(), я же просто привёл пример, когда это не так

Если ты это про меня, то будь добр приведи цитатку-пруфец доказывающий твой выхлоп.

Специально для тебя, кукарекушка, я восстановлю дискуссию - сначала питушок кукарекал, что реалок в 1.6* раза быстрее маллока+фри, потом я курочке ответил: «ты врёшь», потом курочка навая кусок говна, который я лучше бы не видел. Далее я обсоску пояснил, что его «тест» - говно, а так же объяснил 3раза почему.

Т.е. кусок обоссаного бабуина мериет неимеющий в рально мире смысла юзкейс и либо настолько туп, чтобы это понять, либо просто пробалаболил и пытается это скрыть.

С каких пор нулёвой ссанине вообще дали слово балаболить и спорить? Знай своё место и уж поверь мне - кукарекать тебе оно не особо позволяет, вернее только кукарекать и позволяет.

anonymous
()
Ответ на: комментарий от next_time

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

да я читал. Что ж, я рад за вас. А проблема таки наверное в ГСМ переводчике.

emulek
()
Ответ на: комментарий от next_time

так почему реаллок в итоге работает быстрее, чем маллок + фри?

потому-что free+malloc обязаны освободить и выделить память, хоть и не у ядра, но в своём маленьком пуле. А вот realloc даже этого не обязан, и может ничего не выделять, и вообще обычно ничего не делает, только проверяет, не вылез-ли ты за пределы доступного.

emulek
()
Ответ на: комментарий от next_time

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

emulek
()
Ответ на: комментарий от emulek

А проблема таки наверное в ГСМ переводчике.

скорее всего

next_time ★★★★★★
() автор топика
Ответ на: комментарий от emulek

ну он так разнервничался, что 2 раза одну и ту же простыню текста добавил и не заметил. такое активное разбрызгивание слюны может вызывать только улыбку)

next_time ★★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.