жжоте, неудачный у вас примерчик... уже то, что вам надо входить в критическую секцию аукнется на любой более менее активно аллоцирующей в нескольких потоках программе. ну это ладно.
вы можете мне объяснить что мешает скажем Java программе делать почти тоже самое --- найти блок подходящего размера и отдать его программе?
Оставим в стороне счетчик ссылок, но даже glibc дополнительно к запрошенному куску памяти выделаяет еще место под заголовок. Так что оверхеда никакого особого нет. Вообщем никаких доказательств того, что аллокаторы в неуправляемых средах будут работать быстрее я пока так и не увидел.
Теперь что касается удаления. Да, даже при применении различных ухищрений (различные виды incremental/concurrent collection) эта операция дольше чем просто вызов delete/free/VirtualFreeEx. Однако это замедление в общем случае не настолько значительное, чтобы городить велосипед ручного управления памятью. Написать нормальный ручной аллокатор/деаллокатор фактически означает переписать некоторую часть среды управления памятью из какой-нибудь VM. Ну и нафиг это нужно среднестатистическому программисту?
Ась? Вы так и не ответили на мой вопрос... Почему аллокация-то разгонятся... Нету в вашем комментарии слов "аллокация"/"выделение", а есть куча общих слов о том, что GC --- это бяка. Насколько я понял, вы про read/write барьеры говорите. Так ведь некоторое их количество и поудалять можно на основе статического анализа.
На практике мы всё имеем: и специальные компиляторы и особое железо (Azul Systems).
Язык без указателей и при этом не тормозящий в мутьтитредной среде - это как философский камень.
Кхе-кхе, чего-то я не особо секу как наличие указателей ускоряет собственно аллокацию. Не поясните ли? (если же поговорить о распараллеливание, так как раз из-за указателей и проблемы вылезут. зависимость по данным отследить --- это надо пуд соли съесть.)
Если говорить об ускорении аллокации, то Thread Local Heap'ы пока никто не отменял.
Но на сервере из-за нее происходит трешинг кэшей процессора и задержки в обработке запросов (во время обхода кучи сборщиком мусора).
Во-первых, кеши все больше и больше. Во-вторых, седовласые старцы тоже не зря свои бутерброды кушают и изобретают различные подходы к GC позволяющие кэшем меньше шебуршать, да и вообще всякие real-time GC. Ну и наконец, есть всякие железные ухищрения, см. например Azul Systems.
кхе-кхе, вам нужно помнить (или проверять автоматическими тулами), что перед каждым изменением поля указателя возможно необходимо вставить free, т.е. вы хотите сказать, что необходимость делать больше работы улучшает память программиста?
В языках с GC вы можете попросить runtime дать вам дамп кучи. А потом методом внимательного взгляда понять что к чему.
Скажем так, те ошибки, на которые вы указываете для языков с автоматическим управлением памятью, точно также свойственны и языкам с явным управлением: потеряли вы в C указатель и привет семье (причем заметим, что к segfault это не приведёт, просто ресурсы "утекать" начнут, так что не обязательно во время тестирования выявится), нужно расчехлять valgrind или efence, причем может так оказаться, что развертывать это отладочное окружение нужно будет на стороне клиента. А в некоторых управляемых средах вам и развертывать ничего не надо: цепляетесь к запущенному под VM приложению по официальному отладочному интерфейсу и начинаете шукать по сусекам, где чего лишнего осталось.
С другой стороны нельзя не признать, что например C++ благодаря автоматическому вызову деструкторов для стековых объектов делает возможным написание очень красивого кода для управления ресурсами (RAII --- Resource Acquisition Is Initialization), в той же Java приходится во все дырки finally затыкать.
а ежели у вас segfault случается раз в двести лет, когда звезды в ряд становится и древнее зло просыпается?
вот возьмёт и у вас во время тестирования не вылезет, а к клиенту отправите --- порвёт все на кусочки...
вы можете мне объяснить что мешает скажем Java программе делать почти тоже самое --- найти блок подходящего размера и отдать его программе?
Оставим в стороне счетчик ссылок, но даже glibc дополнительно к запрошенному куску памяти выделаяет еще место под заголовок. Так что оверхеда никакого особого нет. Вообщем никаких доказательств того, что аллокаторы в неуправляемых средах будут работать быстрее я пока так и не увидел.
Теперь что касается удаления. Да, даже при применении различных ухищрений (различные виды incremental/concurrent collection) эта операция дольше чем просто вызов delete/free/VirtualFreeEx. Однако это замедление в общем случае не настолько значительное, чтобы городить велосипед ручного управления памятью. Написать нормальный ручной аллокатор/деаллокатор фактически означает переписать некоторую часть среды управления памятью из какой-нибудь VM. Ну и нафиг это нужно среднестатистическому программисту?
На практике мы всё имеем: и специальные компиляторы и особое железо (Azul Systems).
Кхе-кхе, чего-то я не особо секу как наличие указателей ускоряет собственно аллокацию. Не поясните ли? (если же поговорить о распараллеливание, так как раз из-за указателей и проблемы вылезут. зависимость по данным отследить --- это надо пуд соли съесть.)
Если говорить об ускорении аллокации, то Thread Local Heap'ы пока никто не отменял.
Во-первых, кеши все больше и больше. Во-вторых, седовласые старцы тоже не зря свои бутерброды кушают и изобретают различные подходы к GC позволяющие кэшем меньше шебуршать, да и вообще всякие real-time GC. Ну и наконец, есть всякие железные ухищрения, см. например Azul Systems.
Скажем так, те ошибки, на которые вы указываете для языков с автоматическим управлением памятью, точно также свойственны и языкам с явным управлением: потеряли вы в C указатель и привет семье (причем заметим, что к segfault это не приведёт, просто ресурсы "утекать" начнут, так что не обязательно во время тестирования выявится), нужно расчехлять valgrind или efence, причем может так оказаться, что развертывать это отладочное окружение нужно будет на стороне клиента. А в некоторых управляемых средах вам и развертывать ничего не надо: цепляетесь к запущенному под VM приложению по официальному отладочному интерфейсу и начинаете шукать по сусекам, где чего лишнего осталось.
С другой стороны нельзя не признать, что например C++ благодаря автоматическому вызову деструкторов для стековых объектов делает возможным написание очень красивого кода для управления ресурсами (RAII --- Resource Acquisition Is Initialization), в той же Java приходится во все дырки finally затыкать.
вот возьмёт и у вас во время тестирования не вылезет, а к клиенту отправите --- порвёт все на кусочки...