Скорость распределения памяти в Java и C/C++

Ссылку в студию!

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-lnx...

Элементарно. malloc - суть обертка над некоторым системным вызывом (в linux-е наверное над mmap-ом, впрочем - хз, неважно). Соотвественно он снабжен всем гемороем, характерным для системных вызыов вроде переключения конеткста и ковыряния с виртуальной памятью. Все это мягко говоря небыстро. Способ убыстрить выделение памяти очевиден. Надо завести "локальный" (юзерспейс) пул памяти в процессе и раздавать из него память под нужные выделения. Ну т.е. один раз выделить при помощи malloc-а большой объем памяти, а потом самомоу делить его между различными объектами в процессе. Все. В итоге один системный вызов из malloc (или несколько, если первоначального объема не хватило), один из free, все остальное делится на уровне юзерспейса и работает на порядок быстрее

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

Дык, имеются весьма шустрые юзерспейсовые malloc'и, появившиеся через много лет после указанной статьи.

Вообще, это впечатляет: сравнивать новейшие достижения Жабских компилеров с ситуацией с Цешном компилеростроении аж 11 (одиннадцать!) лет назад...

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

Короче, просто бред (я про жабофила, а не про статью).

OCaml - 5 инструкций, без вызовов.

Скорость не единственный критерий. Есть еще фрагментация, например.

А если там и правда 10 иструкций - к гадалке не ходи, это неудачная в плане фрагментации реализация. Мат. часть, господа, никто не отменял.

PS: мне вот на лекции когда-то говорили, что опратор new, не путать с new( nothrow ), при нехватке памяти возвращает 0. Не верить же в это.

> malloc - суть обертка над некоторым системным вызывом

неизвестно о какой реализации malloc() вы говорите, но
для glibc это неверно.

> гемороем, характерным для системных вызыов вроде переключения
> конеткста

и это неправда, при системном вызове переключения контекста
не происходит.

да и вообще...

> Скорость распределения памяти в Java и C/C++

в С/С++ НЕТ распределения памяти, так же там нет операций
i/o и так далее.

Вообще кроме времени выделения объекта на младшем поколении надо ещё учитывать время его переноса в старшее (и вообще время всего stop'n'copy), и дальнейшие накладные расходы на его сопровождение mark'n'sweep GC на протяжении всей жизни объекта. Так что не всё так уж и тривиально, как кащется.

> неизвестно о какой реализации malloc() вы говорите, но для glibc это неверно.

Так неизвестно о какой реализации malloc спрашивалось. Я просто объяснил указанный в статье факт. А что для glibc так на ней свет клином не сошелся.

> и это неправда, при системном вызове переключения контекста не происходит.

Ну да нагнал. Путаюсь в понятиях. Окей не "переключение контекста" а переход на kernel level.

> в С/С++ НЕТ распределения памяти, так же там нет операций i/o и так далее.

А вот тут вы уже гоните. Во-первых для чего тогда предназанчены new и delete ? А во-вторых все зависит от того что вы понимаете под "Си/Cи++". Например я под "Си/Cи++" понимаю языки, описываемые в соответсвующих стандантах, которые помимо лексики, синтаксиса и семантики еще описывают и стандартную библиотеку. Если в вашем Cи++, например, нету средств i/o, то он не соответсвует стандарту.

> в С/С++ НЕТ распределения памяти, так же там нет операций i/o и
> так далее.

> А вот тут вы уже гоните. Во-первых для чего тогда предназанчены
> new и delete ?

new/delete это операторы достаточно высокого уровня, память
они все равно получают с помощью malloc и могут бывть переопределены.

> А что для glibc так на ней свет клином не сошелся.

правильно. ну так и надо писать, сравнение memory allocation
такой-то реализации виртуальной машины и реализации malloc
из вот этой библиотеки.

при чем здесь JAVA и С/С++ ?

>> неизвестно о какой реализации malloc() вы говорите, но для glibc это неверно.

>Так неизвестно о какой реализации malloc спрашивалось. Я просто объяснил указанный в статье факт. А что для glibc так на ней свет клином не сошелся.

Предположение о том, что каждый malloc влечет за собой обращение к системе, неверно применительно к современным реализациям общего назначения, так что объяснение скорее неверное.

> так что объяснение скорее неверное.

Вот именно что _скорее_ всего. А _может быть_ что оно и верно. Ромашка ?

> new/delete это операторы достаточно высокого уровня, память они все равно получают с помощью malloc и могут бывть переопределены.

Детали реализации в стандарте кажется не оговариваются. Разве new/delete это не распределение памяти ?

> правильно. ну так и надо писать, сравнение memory allocation такой-то реализации виртуальной машины и реализации malloc из вот этой библиотеки. > при чем здесь JAVA и С/С++ ?

Так вроде порешили что статья изначально тупая.

idle:

> правильно. ну так и надо писать, сравнение memory allocation такой-то реализации виртуальной машины и реализации malloc из вот этой библиотеки.

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

И как-то не акцентируется внимание, что данные по Жабе новые и намеряны Сантехниками на _своем_ железе, и сравниваются с данными, полученными в начале 90-х годов на Дековских Альфах. Данными, полученными просто для статистики, исключительно для сравнения алгоритмов между собой в рамках одной рассматриваемой платформы, даже без упоминания версий компиляторов и ключей оптимизации.

И сравнивается почему-то кол-во машинных инструкций -- интересно, какое отношение это имеет к скорости? -- на совершенно различных платформах.

>Есть еще фрагментация, например.

>А если там и правда 10 иструкций - к гадалке не ходи, это неудачная в плане фрагментации реализация. Мат. часть, господа, никто не отменял.

Ты статью то посмотри. Какая фрагментация? Память выделяется п_о_с_л_е_д_о_в_а_т_е_л_ь_н_о. А потом при работе GC также последовательно живые объекты копируются в новый участок памяти, и затем последовательно с конца этого участка JVM опять начинает выделять память. И так по кругу