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

Ты не знаешь С. Т.е. вообще. Есть ли смысл с тобой спорить?

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

В С++ не так сильно используется куча, как в Java. Иногда она вообще не используется, иногда делают свои пулы. И пр. Если писать на С++, как на Java, то C++ сольет в плане выделения памяти, да. Но так не пишут.

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

Пока не допилят Rust - приходится. Go, к сожалению, тоже не айс. Просто признай, что ты пока не сталкивался с такого рода задачами. Это нормально.

Ты не знаешь С. Т.е. вообще. Есть ли смысл с тобой спорить?

Знаю. Намного лучше тебя знаю. Так что да, смысла спорить нет - ты обосрешься.

В С++ не так сильно используется куча, как в Java.

А не по хер, где именно объекты выделяются? Куча, стек, пулы самопальные? Без динамического перемещения (не важно, в рамках GC оно делается или еще как) все равно память под кеш не сможешь соптимизировать.

Пока не допилят Rust - приходится. Go, к сожалению, тоже не айс.

Эти-то сюда каким боком?

Просто признай, что ты пока не сталкивался с такого рода задачами. Это нормально.

Перечисли задачи, с которыми я «не сталкивался». Числодробильня? Сталкивался, еще как. Байтодрочерство в драйверах? Сталкивался. Везде у Си нет никаких преимуществ.

Байтодрочерство в драйверах? Сталкивался. Везде у Си нет никаких преимуществ.

А на чём бы ты драйверы писал?

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

Ты, шалава, совсем завонялась. Какие на хер «умные указатели», шалава?!?

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

Молодец, сучка, добавил еще один уровень dereferencing. Тормоза гарантированы.

Что может быть проще?

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

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

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

А ты только один GC видел,

Да ну? В одном только Oracle HotSpot их знаешь сколько?

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

Ты нереально туп, дятел.

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

На Java, естественно.

добавил еще один уровень dereferencing. Тормоза гарантированы.

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

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

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

И как ты это сделаешь без инструментирования кода, без VM?

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

Приведи пример профита от двигания объектов в стеке. А то я пока тебе не понимаю.

Примерно так же, как делает Boehm, только с другими алгоритмами. Собственно так же, как делают GC в Java.

Stop&copy от рождения real time, про mark&sweep можно тут почитать:

http://doc.cat-v.org/inferno/concurrent_gc/concurrent_gc.pdf http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.7791

Примерно так же, как делает Boehm

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

Собственно так же, как делают GC в Java.

Не так же.

Приведи пример профита от двигания объектов в стеке. А то я пока тебе не понимаю.

А чем стек от любой другой памяти отличается? Для кеша он точно такой же, как все. И если хочешь избежать промахов, то тебе придется располагать объекты в таком порядке, в каком ты их с наибольшей вероятностью будешь читать. А порядок этот, понятное дело, во время работы программы может много раз поменяться.

Stop&copy от рождения real time

facepalm.jpg

Да, промахи кэша — проблема. Если Java эту проблему умеет решать — это здорово. Java-кун, покажи перемножение матриц.

Тупой? Размер поколения постоянный.

Я знаю, что Boehm не перемещает. Он не может менять значения ссылок даже теоретически, т.к. он работает с обычными указателями, для которых доступна адресная арифметика, а так же он ищет значение указателя без учета типов и не может быть до конца уверен в том, что это именно указатель, а не просто левое число(т.е. заменять его будет неправильно).

Если же мы вводим свои типы ссылок(без адресной арифметики и с запретом к прямому доступу), свой собственный gcnew(или еще как-то) и т.д. и т.п., то никаких проблем уже не будет - мы и отслеживать их сможем, и перемещать, и значение менять и пр. И я думаю, что такие сборщики будут появляться ближайшее время.

Тупой?

Нет, а ты?

Размер поколения постоянный.

Просто для протокола: алгоритмы сборки мусора в действительно реальном времени только начинают появляться, а у тебя stop-and-copy, которому уже 40+ лет, изначально рилтаймовый.

Может, у тебя сборщик мусора Явы располагает объекты с учетом паттернов доступа?

Молодец, сучка, добавил еще один уровень dereferencing. Тормоза гарантированы.

этот уровень встроен в твою java by design. В C/C++ его можно не использовать, а юзать прямую адресацию. Тогда да, ни о каком уплотнении не может быть и речи, если адреса у тебя используются напрямую. Просто ущербная жаба так не умеет. Смирись.

Ты, шалава, совсем завонялась. Какие на хер «умные указатели», шалава?!?

попробуй изучить то, что ты пытаешься обосрать. Иначе ты пытаешься срать на потолок. Это смешно, да.

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

таких как ты, я бы и дворниками не нанимал.

Эм. Что-то ты меня обманываешь. Для реалтайм явы же специальные GC есть. Ладно. Я думал, ты знаешь.

Тебе, сучка, сколько раз про кеши надо повторить, чтоб дошло?

пойми, если ты пишешь по-русски, то нет никакой разницы, где ты пишешь - хоть на бумаге, хоть гусиным пером, хоть на iMac'е - ты всё равно неграмотное быдло.

этот уровень встроен в твою java by design.

Ты его не понял. У него ссылка на данные, которые gc переместить, а значение ссылку поменяет. Ты же предлагаешь, чтобы у тебя был некоторый объект-ссылка, который ссылается еще на одну ссылку, которая уже ссылается на данные.

Ты его не понял. У него ссылка на данные, которые gc переместить, а значение ссылку поменяет. Ты же предлагаешь, чтобы у тебя был некоторый объект-ссылка, который ссылается еще на одну ссылку, которая уже ссылается на данные.

у него переменная XYZ, которая ссылается на некий внутренний адрес, в котором 0x12345, и его GC меняет этот адрес на 0x54321. А у меня объект класса - XYZ, в котором внутреннее поле, в котором 0x12345. И где тут «оверхед»? Да, мне надо самому велосипедить класс для XYZ, но кто мешает мне взять готовый? Уверен, есть прям как в жабе. А Джефф Элджер рассказывал, как их делать. Не вижу проблемы.

И я думаю, что такие сборщики будут появляться ближайшее время.

О хвостовой рекурсии (комментарий), http://herbsutter.com/2011/10/25/garbage-collection-synopsis-and-c.

Ну вот. И я о том. Спасибо за Саттера. Но у него там битая ссылка на Страуструпа, а жаль.

http://www.stroustrup.com/C 11FAQ.html#gc-abi — новый домен и 0x -> 11.

этот уровень встроен в твою java by design.

Ты дебил и быдло, а папка твой был обдолбан героином, когда тебя делал.

Нет там никакого лишнего dereferencing, адресация вся прямая.

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

Ты тупой. Ссылки меняются на месте во время работы GC. Никакого лишнего уровня dereferencing там нет, идиот.

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

Ололо, они всегда были реалтаймовыми.

а у тебя stop-and-copy, которому уже 40+ лет, изначально рилтаймовый.

Ну попробуй придумать, в каком именно месте он не риалтаймовый. Размер поколения фиксированный (N). Размер стека тоже фиксированный (M). Больше чем за O(N+M) ты его при всем желании не скопируешь и ссылки в стеке не переправишь. То есть, имеется четко заданная верхняя граница времени работы алгоритма. То есть, hard real time.

Если же мы вводим свои типы ссылок(без адресной арифметики и с запретом к прямому доступу), свой собственный gcnew(или еще как-то) и т.д. и т.п., то никаких проблем уже не будет - мы и отслеживать их сможем, и перемещать, и значение менять и пр.

И как же это ты их отслеживать сможешь? В стеке, в регистрах, в массивах на куче. Или у тебя вся память managed, или у тебя очень серьезные проблемы там, где «обычные» поинтеры перемешиваются с GC-managed.

Ты его не понял.

А было ли хоть раз, чтоб этот поциент вообще хоть что-то понял? Он же шизофреничен абсолютно. Я уверен, он даже если захочет, никогда не сможет понять, что такое GC.

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

Ололо, они всегда были реалтаймовыми.

Понятно.

Ты абсолютно невменяемый урод.

Допустим, есть три элемента однонаправленного списка, с адресами A, B и C соответственно. На A и B указывают локальные переменные (то есть, регистры или записи в стеке). Оба A и B указывают на C как на следующий элемент.

У меня GC переместил A, B и C в новую область. В процессе этого указатель на C был изменен при переписывании A и B, а указатели на A и B были изменены в регистрах или в стеке.

У тебя же для A, B и C где-то еще есть объекты A', B' и C', в каждом из которых по указателю на A, B и C. В A и в B следующим элементом задан C', и только оттуда ссылка на реальное положение C. Ты идиот.

Отвечать на конкретно поставленный вопрос будешь, а, failgunner?

Рассказывай, как это у тебя stop&copy вдруг начал работать за непредсказуемое время.

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

С GC некоторые проблемы в С++ будут в любом случае, хотя бы из-за его семантического неисправимого недостатка - время жизни объекта не детерминировано. Отсюда костыли в виде finally и пр. при управлении ресурсами(я знаю про try-with-resources, это тоже костыль, хоть и не такой страшный). Но тут трудности именно семантические, а не технические. Лично мне GC в С++ вообще-то не нужен. Если у меня настолько высокоуровневый код, то С++ в любом случае будет не самым удачным выбором.

Если у меня настолько высокоуровневый код, то С++ в любом случае будет не самым удачным выбором.

При чем тут «уровень»? Оптимизировать динамически расположение структур данных в памяти под текущие потребности кеша надо полезно независимот от уровня. Точнее, для низкоуровневых задач это намного важнее, чем для высокоуровневого формошлепства.

Как по мне, так непосредственно «сборка мусора» - это давно уже второстепенная задача GC, которую можно бы и отбросить. Намного важнее динамическая оптимизация.

Я тебя понял. Не согласен во многом, но профит некий получил. Спасибо.

Рассказывай, как это у тебя stop&copy вдруг начал работать за непредсказуемое время.

А почему я должен об этом рассказывать? Я этого не утверждал. Могу только сказать, что ограничение времени ответа сверху - это еще не реальное время (и неважно, что говорит по этому поводу Вики). Ну а дальше - в гугл, там куча литературы по real-time GC, и ищи объяснение, почему куча народа до сих пор работает над RTGC, хотя всё решено 40 лет назад.

и ищи объяснение, почему куча народа до сих пор работает над RTGC, хотя всё решено 40 лет назад.

У разного народа задачи разные. Кто-то хочет Java код без изменений в реальном времени гонять (то есть, с растущей кучей, да еще и на неприспособленном для этого x86 железе). А мне для embedded hard realtime на FPGA более чем достаточно stop&copy (который еще и очень легко реализуется аппаратно). Коллеги, наоборот, mark&sweep используют, в реальном времени, добавили тоько барьеры в soft cpu, и радуются.

Так что все уже давно известно и применяется на практике.

мне для embedded hard realtime на FPGA более чем достаточно stop&copy

добавили тоько барьеры в soft cpu,

Ну да, ну да. Специальное железо для использования GC. Тебя не об этом спрашивали.

Ну да, ну да. Специальное железо для использования GC. Тебя не об этом спрашивали.

А для риалтайма по любому нужно «специальное железо». x86 - гавно на палочке.

Кроме того, как раз для stop&copy ничего специального не надо, на самом деле.

Java от промахов тебя не сильно спасет. Ибо у тебя там везде ссылки. Так что миф.

А для риалтайма по любому нужно «специальное железо».

Наверное, и для драйверов на Яве нужно «специальное железо»?

x86 - гавно на палочке.

Доо.

Так GC не настолько часто вызывается. И вообще в твоих постах слишком много теории и абсолютно отсутствует практика.

А у тебя на сишечке не ссылки, да?

Ну так как, поможет ли мне умный аллокатор java в этой простой задачке или нет? Мне интересно, правда.