История изменений
Исправление
Moisha_Liberman,
(текущая версия)
:
Отребье, мы уже в прошлый раз поржали. Ну давай я тебя опять в говне изваляю.
Да-да-да… Это там, где я Вас, батенька, от души говнецом покормил, когда носом тыкал в спеки на процессор, где явно сказано что IP Cores для математического сопроцессора это отдельная архитектурная часть процессора? Да, было дело, от души Вы тогда вкусили… =))) И сейчас, судя по всему, закуски возжелали? Ну будет Вам закусон. Будет… =)))
О боже, отребье позорное. __builtin_alloca - никакого отношения к glibc не имеет. Ну да, отребье, побежало искать её в glibc. Бегом.
Бггг… «Это фиаско, братан!» =))) Вообще-то, реализация данной функции зависит от платформы. Вот, например, для Sparc32:
ENTRY (__builtin_alloca)
sub %sp, %o0, %sp /* Push some stack space. */
retl /* Return; the returned buffer leaves 96 */
add %sp, 96, %o0 /* bytes of register save area at the top. */
END (__builtin_alloca)
А теперь… горбатый! =)))
Берём однострочник:
#include <alloca.h>
int main(int argc, char *argv[]) {
void *p = __builtin_alloca(10);
return 0;
}
Компилим его (gcc test.c) и смотрим на использование библиотек – ldd a.out. Вывод:
ldd a.out
linux-vdso.so.1 (0x00007fffd417b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fac620db000)
/lib64/ld-linux-x86-64.so.2 (0x00007fac626ce000)
Тут нет никаких фантазий кроме использования одной функции из libc. И угадайте с трёх раз какой именно? =))) Следовательно, __builtin_alloca() это часть системной библиотеки libc. Что и требовалось доказать. Будь она макросом, ссылки на функцию бы и не стояло… Учите, батенька, матчасть. Хоть это и бесполезно в Вашем случае. =)))
И да. В Linux libc.so.* это и есть реализация glibc. man 7 libc это подтверждает словами:
glibc By far the most widely used C library on Linux is the GNU C Library ⟨http://www.gnu.org/software/libc/⟩, often referred to as glibc.
===
В маны пойдёшь ты, собака.
Ну чтож, предлагаю составить мне компанию… =)))
За пруфами побежало, отребье. К стати, говно, ты прибежало через час после того как погуглило? Плохо гуглило, говно, гулилить лучше.
Т.е., я обязан по времени отвечать? Делать мне нефиг, как выпускника ГПТУ просвящать по звонку.
мне насрать на то, что там говорит какой-то ман написанный идиотом для идиотов.
Оггада… И именно поэтому man 3 alloca говорит дословно следующее:
The alloca() function
И да, это именно функция, т.к. она имеет возвращаемое значение (макрос тоже может иметь, а может и не иметь). Но alloca() это именно функция:
The alloca() function returns a pointer
===
За пруфами побежало, отребье.
А пруф из мана опять таки про поведение madvise привести несложно:
Note that, when applied to shared mappings, MADV_DONTNEED might not lead to immediate freeing of the pages in the range. The kernel is free to delay freeing the pages until an appropriate moment. The resident set size (RSS) of the calling process will be immediately reduced however.
Ровно то, что я и сказал насчёт реального освобождения страниц и описания занимаемой памяти в RSS.
Насчёт того, что память может быть не освобождена, если память занята. Пруф:
MADV_DONTNEED cannot be applied to locked pages, Huge TLB pages, or VM_PFNMAP pages.
===
Тут можно над Вами издеваться долго, милейший. Но я, пожалуй, разжалую Вас из Царя С++ (на Цвря С Вы уже давно не тянете) в Пассивные (ну, Вы меня поняли). Так что, отныне Вы Пассивный С++. =)))
А маны читайте, да. Меньше на дурака будете похожи.
Про поведение madvise() в части замедления работы с памятью, так и проще всё. Память приложения очистили, а она потом опять потребовалась. Если бы не очищали, память была бы уже выделена приложению. А так ядру опять надо найти подходящий блок и отдать его приложению. Т.е., опять работа. И работа по выделению области памяти будет ровно столько же занимать времени сколько и обычно.
Вот почему дефолтным поведением не является повальное и повсеместное использование madvise(). Чтобы его использовать, это надо мозг иметь. Но это уже явно не к Вам. Вы даже маны не читаете.
===
Пичаль-тоска… Да… Господи, и это существо кто-то назвал Царём С? Да вы жжоте, господа! Напалм просто! =)))
Исправление
Moisha_Liberman,
:
Отребье, мы уже в прошлый раз поржали. Ну давай я тебя опять в говне изваляю.
Да-да-да… Это там, где я Вас, батенька, от души говнецом покормил, когда носом тыкал в спеки на процессор, где явно сказано что IP Cores для математического сопроцессора это отдельная архитектурная часть процессора? Да, было дело, от души Вы тогда вкусили… =))) И сейчас, судя по всему, закуски возжелали? Ну будет Вам закусон. Будет… =)))
О боже, отребье позорное. __builtin_alloca - никакого отношения к glibc не имеет. Ну да, отребье, побежало искать её в glibc. Бегом.
Бггг… «Это фиаско, братан!» =))) Вообще-то, реализация данной функции зависит от платформы. Вот, например, для Sparc32:
ENTRY (__builtin_alloca)
sub %sp, %o0, %sp /* Push some stack space. */
retl /* Return; the returned buffer leaves 96 */
add %sp, 96, %o0 /* bytes of register save area at the top. */
END (__builtin_alloca)
А теперь… горбатый! =)))
Берём однострочник:
#include <alloca.h>
int main(int argc, char *argv[]) {
void *p = __builtin_alloca(10);
return 0;
}
Компилим его (gcc test.c) и смотрим на использование библиотек – ldd a.out. Вывод:
ldd a.out
linux-vdso.so.1 (0x00007fffd417b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fac620db000)
/lib64/ld-linux-x86-64.so.2 (0x00007fac626ce000)
Тут нет никаких фантазий кроме использования одной функции из libc. И угадайте с трёх раз какой именно? =))) Следовательно, __builtin_alloca() это часть системной библиотеки libc. Что и требовалось доказать. Будь она макросом, ссылки на функцию бы и не стояло… Учите, батенька, матчасть. Хоть это и бесполезно в Вашем случае. =)))
И да. В Linux libc.so.* это и есть реализация glibc. man 7 libc это подтверждает словами:
glibc By far the most widely used C library on Linux is the GNU C Library ⟨http://www.gnu.org/software/libc/⟩, often referred to as glibc.
===
В маны пойдёшь ты, собака.
Ну чтож, предлагаю составить мне компанию… =)))
За пруфами побежало, отребье. К стати, говно, ты прибежало через час после того как погуглило? Плохо гуглило, говно, гулилить лучше.
Т.е., я обязан по времени отвечать? Делать мне нефиг, как выпускника ГПТУ просвящать по звонку.
мне насрать на то, что там говорит какой-то ман написанный идиотом для идиотов.
Оггада… И именно поэтому man 3 alloca говорит дословно следующее:
The alloca() function
И да, это именно функция, т.к. она имеет возвращаемое значение (макрос тоже может иметь, а может и не иметь). Но alloca() это именно функция:
The alloca() function returns a pointer
===
За пруфами побежало, отребье.
А пруф из мана опять таки про поведение madvise привести несложно:
Note that, when applied to shared mappings, MADV_DONTNEED might not lead to immediate freeing of the pages in the range. The kernel is free to delay freeing the pages until an appropriate moment. The resident set size (RSS) of the calling process will be immediately reduced however.
Ровно то, что я и сказал насчёт реального освобождения страниц и описания занимаемой памяти в RSS.
Насчёт того, что память может быть не освобождена, если память занята. Пруф:
MADV_DONTNEED cannot be applied to locked pages, Huge TLB pages, or VM_PFNMAP pages. === Тут можно над Вами издеваться долго, милейший. Но я, пожалуй, разжалую Вас из Царя С++ (на Цвря С Вы уже давно не тянете) в Пассивные (ну, Вы меня поняли). Так что, отныне Вы Пассивный С++. =)))
А маны читайте, да. Меньше на дурака будете похожи.
Про поведение madvise() в части замедления работы с памятью, так и проще всё. Память приложения очистили, а она потом опять потребовалась. Если бы не очищали, память была бы уже выделена приложению. А так ядру опять надо найти подходящий блок и отдать его приложению. Т.е., опять работа. И работа по выделению области памяти будет ровно столько же занимать времени сколько и обычно.
Вот почему дефолтным поведением не является повальное и повсеместное использование madvise(). Чтобы его использовать, это надо мозг иметь. Но это уже явно не к Вам. Вы даже маны не читаете.
Пичаль-тоска… Да… Господи, и это существо кто-то назвал Царём С? Да вы жжоте, господа! Напалм просто! =)))
Исходная версия
Moisha_Liberman,
:
Ну вот... Да, это Царь С++... =)))
Отребье, мы уже в прошлый раз поржали. Ну давай я тебя опять в говне изваляю.
Да-да-да… Это там, где я Вас, батенька, от души говнецом покормил, когда носом тыкал в спеки на процессор, где явно сказано что IP Cores для математического сопроцессора это отдельная архитектурная часть процессора? Да, было дело, от души Вы тогда вкусили… =))) И сейчас, судя по всему, закуски возжелали? Ну будет Вам закусон. Будет… =)))
О боже, отребье позорное. __builtin_alloca - никакого отношения к glibc не имеет. Ну да, отребье, побежало искать её в glibc. Бегом.
Бггг… «Это фиаско, братан!» =))) Вообще-то, реализация данной функции зависит от платформы. Вот, например, для Sparc32:
ENTRY (__builtin_alloca)
sub %sp, %o0, %sp /* Push some stack space. */
retl /* Return; the returned buffer leaves 96 */
add %sp, 96, %o0 /* bytes of register save area at the top. */
END (__builtin_alloca)
А теперь… горбатый! =)))
Берём однострочник:
#include <alloca.h>
int main(int argc, char *argv[]) {
void *p = __builtin_alloca(10);
return 0;
}
Компилим его (gcc test.c) и смотрим на использование библиотек – ldd a.out. Вывод:
ldd a.out
linux-vdso.so.1 (0x00007fffd417b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fac620db000)
/lib64/ld-linux-x86-64.so.2 (0x00007fac626ce000)
Тут нет никаких фантазий кроме использования одной функции из libc. И угадайте с трёх раз какой именно? =))) Следовательно, __builtin_alloca() это часть системной библиотеки libc. Что и требовалось доказать. Будь она макросом, ссылки на функцию бы и не стояло… Учите, батенька, матчасть. Хоть это и бесполезно в Вашем случае. =)))
И да. В Linux libc.so.* это и есть реализация glibc. man 7 libc это подтверждает словами:
glibc By far the most widely used C library on Linux is the GNU C Library ⟨http://www.gnu.org/software/libc/⟩, often referred to as glibc.
В маны пойдёшь ты, собака.
Ну чтож, предлагаю составить мне компанию… =)))
За пруфами побежало, отребье. К стати, говно, ты прибежало через час после того как погуглило? Плохо гуглило, говно, гулилить лучше.
Т.е., я обязан по времени отвечать? Делать мне нефиг, как выпускника ГПТУ просвящать по звонку.
мне насрать на то, что там говорит какой-то ман написанный идиотом для идиотов.
Оггада… И именно поэтому man 3 alloca говорит дословно следующее:
The alloca() function
И да, это именно функция, т.к. она имеет возвращаемое значение (макрос тоже может иметь, а может и не иметь). Но alloca() это именно функция:
The alloca() function returns a pointer
За пруфами побежало, отребье.
А пруф из мана опять таки про поведение madvise привести несложно:
Note that, when applied to shared mappings, MADV_DONTNEED might not lead to immediate freeing of the pages in the range. The kernel is free to delay freeing the pages until an appropriate moment. The resident set size (RSS) of the calling process will be immediately reduced however.
Ровно то, что я и сказал насчёт реального освобождения страниц и описания занимаемой памяти в RSS.
Насчёт того, что память может быть не освобождена, если память занята. Пруф:
MADV_DONTNEED cannot be applied to locked pages, Huge TLB pages, or VM_PFNMAP pages.
Тут можно над Вами издеваться долго, милейший. Но я, пожалуй, разжалую Вас из Царя С++ (на Цвря С Вы уже давно не тянете) в Пассивные (ну, Вы меня поняли). Так что, отныне Вы Пассивный С++. =)))
А маны читайте, да. Меньше на дурака будете похожи.
Про поведение madvise() в части замедления работы с памятью, так и проще всё. Память приложения очистили, а она потом опять потребовалась. Если бы не очищали, память была бы уже выделена приложению. А так ядру опять надо найти подходящий блок и отдать его приложению. Т.е., опять работа.
Вот почему дефолтным поведением не является повальное и повсеместное использование madvise(). Чтобы его использовать, это надо мозг иметь. Но это уже явно не к Вам. Вы даже маны не читаете. Пичаль-тоска… Да… Господи, и это существо кто-то назвал Царём С? Да вы жжоте, господа! Напалм просто! =)))