Он может и ламерище. Но пока мне частенько в моем хайлоаде приходится брать плюсы, хотя предпочитаю scala(а то и python).

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

Ты невменяемо ничтожное ламерище, как всегда.

слив засчитан.

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

не нужно. А что, в жабе действительно нельзя сменить аллокатор на свой? Или таки можно, но ты не осилил?

Очевидный ответ

Ну очевидно же. Надо написать на С++ реализацию Scheme и пользоваться ФП.

А так...Если бы остался на едине с С++... то написал бы в PureC стиле компилятор языка, а то без языка программирования как программировать?

А так...Если бы остался на едине с С++... то написал бы в PureC стиле компилятор языка, а то без языка программирования как программировать?

ФП гойловнога моска.

Реальные системы разные бывают. Как минимум, языки со встроенным GC умеют автоматически дефрагментировать память. Иногда это большой плюс, особенно для серверного софта, который должен работать долго и постоянно. Конечно, можно похожего добиться и на Си, но за счет очень строгой дисциплины и N-го количества геммора.

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

Какая срала? Какой какамл? Java, java и только java!

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

Аллокатор у явы(как и у любого языка с нормальным сборщиком) действительно быстрее СТАНДАРТНОГО плюсового(ты можешь написать миллион своих - и не обманывай, они помогают), но проявляется это только на синтетике.

Он быстрее ЛЮБОГО плюсового, какой ты только сможешь написать. По определению. У тебя нет никакой возможности его обогнать на плюсах.

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

Диванный теоретик такой диванный.

Jit в LLVM может и плохой, но хороший сделать никто не мешает.

Слишком низкоуровневая семантика VM мешает. Одна только необходимость aliasing analysis убивает почти все возможные оптимизации.

Сучонок, какой такой «слив»?

самый обычный. У тебя кончились аргументы, и ты сам себя опустил до банальных оскорблений. Слился, как говно в унитазе.

тут, например:

Как мне надоели ссылки на этот гомосяцкий ламеризм. Они вообще бенчмарки делать не умеют.

GC не быстрее

Быстрее. Ты никогда не сможешь без компактификации получить результаты лучше, чем с компактификацией.

Он быстрее ЛЮБОГО плюсового, какой ты только сможешь написать. По определению.

и конечно, сейчас ты это докажешь. Ждём.

Аргументы тебе выдавались много раз, и ты их всегда игнорировал. Так что теперь я просто повторяю, что ты мразь и вырожденец, мамка твоя шлюха, а папка - наркоман. Потому что аргументы можно применять только в разговоре с человеком, а ты не человек, ты свинья.

Покажи аллокатор в одну инструкцию на плюсах. Ждем.

Покажи компактификацию. Покажи stop & copy на плюсах.

Во-первых, использовать такого говно, как Java при наличии scala как-то тяжело. Силы воли не хватает. Во-вторых, ocaml быстрее java. И до памяти не такой жадный. В-третьих, все равно сишечка и плюсы быстрее даже ocaml'а и не такие прожорливые в умелых руках. Так что пока приходится кушать кактус...

Аргументы тебе выдавались много раз, и ты их всегда игнорировал.

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

Покажи аллокатор в одну инструкцию на плюсах. Ждем.

new;

Одну инструкцию x86, придурок.

Нет, не быстрее. Я тоже могу написать аллокатор, который будет просто сдвигать указатель при выделении. А для удаления использовать разные стратегии. Кроме того, я могу написать вообще полноценный GC(не только консервативный, консервативный уже написан для С/С++ и работает с обычными указателями), предоставив специальный вид указателя. Просто это не нужно. Если у вас такие задачи, что с GC вам легче жить, а его использование не приводит к проблемам - значит вам и другие оптимизации в стиле С/С++ не нужны - возьмите нормальный язык.

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

Слишком низкоуровневая семантика VM мешает

Сделайте более высокоуровневую. Язык-то тут при чем?

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

Одну инструкцию x86, придурок.

ты ужрался? Как это на java?

Покажи нам свои тесты. Не синтетические. Понятно, что если у тебя GC не вызывается, то двигать указатель быстрее, чем искать свободный кусок.

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

Напиши. Чтоб при этом своя кучка на каждый тред выделялась (и при этом не надо было тащить лишних аргументов в new).

А для удаления использовать разные стратегии.

Ну используй. Stop&copy с компактификацией. Что, не получается? А я предупреждал.

Кроме того, я могу написать вообще полноценный GC(не только консервативный, консервативный уже написан для С/С++ и работает с обычными указателями), предоставив специальный вид указателя.

Не сможешь ты написать полноценный GC для C++ никогда. Boehm - неполноценный. Ты не сможешь перемещать объекты, не сможешь правильно расставить read- и write- барьеры без инструментирования кода.

Просто это не нужно.

Нужно. Это эффективнее.

Если у вас такие задачи, что с GC вам легче жить, а его использование не приводит к проблемам - значит вам и другие оптимизации в стиле С/С++ не нужны - возьмите нормальный язык.

«Проблемы» GC - это идиотская сказочка из середины 70-х, которую некоторые слоупоки до сих пор перепевают. Не надоело?

Сделайте более высокоуровневую. Язык-то тут при чем?

Это уже не LLVM тогда будет. А, например (та-да!) JVM.

Ты, шалава, такой безграмотный. На java это один инкремент, шалава.

Как мне надоели ссылки на этот гомосяцкий ламеризм. Они вообще бенчмарки делать не умеют.

я уже говорил - давай задачу и решение на Java

Быстрее. Ты никогда не сможешь без компактификации получить результаты лучше, чем с компактификацией.

компактификация имеет свой оверхед, это не бесплатная операция и не простая, а в С++ можно большую часть аллокаций вынеси вообще на стек - т.е. аллокация будет не только «в одну инструкцию», но еще и для пачки переменных

Во-первых, использовать такого говно, как Java при наличии scala как-то тяжело.

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

Во-вторых, ocaml быстрее java.

Утютюшечки. У них даже GC нормального нет. Они даже потоки поддерживать без глобальной блокировки не научились.

В-третьих, все равно сишечка и плюсы быстрее даже ocaml'а и не такие прожорливые в умелых руках

Не быстрее они. По вышеизложенным причинам - работа с памятью в Java быстрее, за счет runtime-оптимизаций, за счет компактификации и быстрого аллокатора (по кучке на поток).

компактификация имеет свой оверхед, это не бесплатная операция и не простая,

Это операция с всегда гарантированным временем задержки. Оверхед минимален и предсказуем. И он намного, на порядки ниже, чем оверхед от кеш-промахов, которые так тичпины для говнокода на говносишечке.

а в С++ можно большую часть аллокаций вынеси вообще на стек

Ну ну. Повыделяй на стеке красно-черное дерево.

Ты, шалава, такой безграмотный. На java это один инкремент, шалава.

кто мешает сделать new с одним инкрементом? Работать он будет точно также быстро, как и в яве. И его код будет именно inc, как ты и хотел.

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

ЗЫЖ можешь хоть ещё 10 раз назвать меня шалавой, но факт остаётся фактом - как сделать другой аллокатор в яве - ты не сказал. Откуда вывод: либо никак, либо ты просто не знаешь яву.

Ну ну. Повыделяй на стеке красно-черное дерево.

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

http://www.boost.org/doc/libs/1_53_0/libs/pool/doc/html/index.html

и будет как минимум не медленнее чем на Java, проверено на собаках бенчмарками

«Проблемы» GC - это идиотская сказочка из середины 70-х, которую некоторые слоупоки до сих пор перепевают. Не надоело?

на самом деле, Кнут это описывал в 60х годах. А в 70х догадались перенести проблемы из аллокатора, в сборщик мусора. Но какая разница, когда и где тормозит? Тормозить-то всё равно будет, чудес не бывает (про GC Кнут тоже писал, кстати. Почитай, оно полезно).

и будет как минимум не медленнее чем на Java, проверено на собаках бенчмарками

Нет. Оно медленнее. Проверенно.

Тормозить-то всё равно будет, чудес не бывает

Не, ну ты тупой! Твоя кривая сишечка будет на кеш-промахах тормозить на порядок больше, чем Java в GC. Тормоза - они разные бывают, знаешь ли.

кто мешает сделать new с одним инкрементом? Работать он будет точно также быстро, как и в яве. И его код будет именно inc, как ты и хотел.

Сделай. Чтоб при этом в разных потоках разные кучи использовались. И еще чтоб разные кучи статически (во время компиляции) выбирались для объектов разного типа. Обломался? Свободен.

когда память кончится, и твой GC запустится - будут точно такими же, как в яве.

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

Нет. Оно медленнее. Проверенно.

я привел ссылку, там есть binary trees, у тебя будет такая? или код, который можно запустить и проверить?

Твоя кривая сишечка будет на кеш-промахах тормозить на порядок больше, чем Java в GC. Тормоза - они разные бывают, знаешь ли.

знаю. Если использовать malloc(3) - будет. А если inc, как ты предложил - не будет. А будет жрать память гигами, и тормозить на GC.

Сделай. Чтоб при этом в разных потоках разные кучи использовались. И еще чтоб разные кучи статически (во время компиляции) выбирались для объектов разного типа. Обломался?

нет. В C++ как раз и не рекомендуют перегружать ::new, а рекомендуют перегружать foo::new для тех классов, которым это надо.

когда память кончится, и твой GC запустится - будут точно такими же, как в яве.

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

ну может ты мне расскажешь?

нет. В C++ как раз и не рекомендуют перегружать ::new, а рекомендуют перегружать foo::new для тех классов, которым это надо.

Попка не треснет всё перегружать? Надо ведь статически по РАЗМЕРУ их сортировать.

ну может ты мне расскажешь?

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

Ты можешь убеждать себя в этом сколько угодно. Я эту разницу вижу на практике. Если у тебя сишечка не быстрее явы, значит ты не умеешь использовать сишечку. Да даже обычный софт на андроидах пишут иногда на NDK именно ради производительности. Не будь религиозным фанатиком. Использовать разные языки - трувей.

А если inc, как ты предложил - не будет.

Ты тупой, что ли? Одного это мало, тупица. Нужен еще и stop&copy с компактификацией, а это в си сделать НЕВОЗМОЖНО. Хоть ты тресни, а ни хера не сможешь сделать.

А будет жрать память гигами,

Оверхед на поддержку GC незначительный, максимум +20%, а для многих задач наоборот меньше footprint будет.

и тормозить на GC.

Ты тупой. Предсказуемая и постоянная задержка на копирование - ничто, по сравнению с потерями на кеш-промахах.

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

Нет, это ты не умеешь использовать яву. Я ж тебе объяснил, почему сишечка яву никогда не догонит. Ты тупой, что ли?

Да даже обычный софт на андроидах пишут иногда на NDK именно ради производительности.

Ну ты сравнил, говнодальвик с нормальной JVM.

Использовать разные языки - трувей.

Да. Но использовать Си для «производительности» - ламеризм.

я привел ссылку, там есть binary trees

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

Ты не заметил, что компактификацией там и не пахнет?

Ты не заметил, что они ни хера не на стеке выделяются?
Ты не заметил, что компактификацией там и не пахнет?

Аналоги функций высшего порядка в С++ (комментарий)

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

Попка не треснет всё перегружать? Надо ведь статически по РАЗМЕРУ их сортировать.

не треснет. В красно-чёрном дереве например целых два размера: красный узел, и чёрный узел. Можно ещё листы выделить (они всегда чёрные).

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

чего я там не видел из того, о чём писал Кнут?

Ты тупой, что ли? Одного это мало, тупица. Нужен еще и stop&copy с компактификацией, а это в си сделать НЕВОЗМОЖНО. Хоть ты тресни, а ни хера не сможешь сделать.

что именно для тебя сделать?

Оверхед на поддержку GC незначительный, максимум +20%

это заметно по распухшим жаба-приложениям. Не ври мне.

Ты тупой. Предсказуемая и постоянная задержка на копирование - ничто, по сравнению с потерями на кеш-промахах.

учи матчасть - задержка GC непредсказуемая и не постоянная. Например ответь на простой вопрос из RL: сколько надо времени, что-бы навести порядок и убрать мусор из той комнаты, где я это пишу?

что именно для тебя сделать?

Компактификацию кучу, сука, компактификацию.

это заметно по распухшим жаба-приложениям. Не ври мне.

Ты, грязное школоло, про Жабу ни хера не знаешь. Так что заткни вонючее хлебало.

учи матчасть - задержка GC непредсказуемая и не постоянная

Идиот. Задержка Stop&Copy - O(N), где N - размер nursery поколения.

Например ответь на простой вопрос из RL: сколько надо времени, что-бы навести порядок и убрать мусор из той комнаты, где я это пишу?

Ты, сучка, ничего про GC не знаешь.

не треснет.

Для всех-всех классов, что у тебя есть?

чего я там не видел из того, о чём писал Кнут?

Во времена Кнута и иерархии памяти-то не было никакой. Так что все, что он писал, кеши не учитывает.

Компактификацию кучу, сука, компактификацию.

ты чурка не русская? Тогда по-русски это «уплотнение». В C++ этот вопрос решается тривиально, с помощью умных указателей. Переносим ненужный объект в другое место, и меняем в SP указатель на этот объект. Что может быть проще?

Если ты думаешь, что в C++ указатели - это всегда тоже самое, что и в Pure C - ты идиот. А если ты не понимаешь разницы между «невозможно в C» и «невозможно в C++» - ты слеподырый идиот.

это заметно по распухшим жаба-приложениям. Не ври мне.

Ты, грязное школоло, про Жабу ни хера не знаешь. Так что заткни вонючее хлебало.

я знаю, что оно тормозит и жрёт много памяти. Этого достаточно.

Для всех-всех классов, что у тебя есть?

а для всех и не нужно. А то тормозная жаба получится.

Во времена Кнута и иерархии памяти-то не было никакой. Так что все, что он писал, кеши не учитывает.

во времена Кнута даже плюсов не было, что не мешало ему писать годные и разные GC на ассемблере. А ты только один GC видел, и почему-то считаешь, что он везде самый лучший. И что он только в жабе возможен. Обломайся - его и в brainfuck можно при желании реализовать, и это - доказано.

Напиши. Чтоб при этом своя кучка на каждый тред выделялась (и при этом не надо было тащить лишних аргументов в new).

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

Не сможешь ты написать полноценный GC для C++ никогда. Boehm - неполноценный. Ты не сможешь перемещать объекты, не сможешь правильно расставить read- и write- барьеры без инструментирования кода.

Смогу, если введу свой тип указателей(и это будет правильный путь для С++, на мой взгляд). Для обычных указателей нельзя, да. Ты вообще читаешь, что цитируешь?

Нужно. Это эффективнее.

Диванный теоретик? Это не эффективнее. Но для очень многих задач это вполне приемлемо. Я не против языков с GC, я всецело за. Просто иногда тебе приходится брать в руки напильник. Чтобы твой демон мог держать хотя бы под 100 тыс. запросов в секунду с одного хоста, а не под десяток и не провисал во время сборки мусора.

«Проблемы» GC - это идиотская сказочка из середины 70-х, которую некоторые слоупоки до сих пор перепевают. Не надоело?

Это не сказка. Еще раз - я это вижу собственными глазами в реальных проектах. Но системы с GC могут быть вполне приемлемы для задачи и тогда нужно использовать их.

По вышеизложенным причинам - работа с памятью в Java быстрее, за счет runtime-оптимизаций, за счет компактификации и быстрого аллокатора (по кучке на поток).

Чувак, у меня есть проекты, где «обычная» куча вообще не используется. Данные хранятся в шаренной памяти/memcached, куда загружаются достаточно редко(но меняются часто) + свои пулы для всякой мелочи, нужной при обработке данных.

Давай повыделяем его в shm или вообще вынесем на отдельный сервис хранения данных?