[@] GC

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

Короче, общий поинт в том, что плюсовый код заоптимизировали по-всякому, а он все равно в 4 раза тормозит. ЧТД, собственно говоря. А наш друг просто демонстрирует свою слабость и банальную защитную реакцию и не может признать фейл плюсов :)

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

я и не обобщал, в отличие от тебя

> Короче, общий поинт в том, что плюсовый код заоптимизировали по-всякому, а он все равно в 4 раза тормозит. ЧТД, собственно говоря

для ЧТД надо предоставить код на ocaml + код на С++, автор что-то менял, что-то писал, но то что написано по ссылке явно не дает возможности повторить его «эксперимент»

А наш друг просто демонстрирует свою слабость и банальную защитную реакцию и не может признать фейл плюсов :)

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

> ну если тебе приведенного по ссылке достаточно, чтоб сделать выводы - спорить не буду конечно, твое право

О чём выводы? Что подсчёт ссылок в лексических контекстах уступает продвинутым GC? Ничего удивительного.

> О чём выводы? Что подсчёт ссылок в лексических контекстах уступает продвинутым GC? Ничего удивительного.

не спорю, и это очевидно, но в данном случае была претензия показать разницу «в цифрах» - вот их достоверность и вызывает сомнения

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

> > О чём выводы? Что подсчёт ссылок в лексических контекстах уступает продвинутым GC? Ничего удивительного.

не спорю, и это очевидно (...)

А мне вот не очевидно ни первое, ни второе. Особенно первое. Потому что, во-первых, всегда можно посетовать на отжираемую сборщиком мусора память, а во-вторых, совсем не понятно, как сравнивать гц и не-гц. Потому что в подобных вещах не выделить время, потраченное чисто на подсчет ссылок и выделение/освобождение памяти. Нет «чистых» параметров, есть только время работы программы.

Я вот склонен считать, что время работы программы — показатель. Но мне это отнюдь не очевидно.

на самом деле в тестах не хватает информации о том, срабатывал ли хоть раз собственно GC.

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

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

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

идиотский подсчет ссылок не надо делать, только и всего.

С и С++ - языки низкоуровневые, и там важно представлять, как работает тот же shared_ptr. например, shared_ptr как аргумент функции сущетсвенно медленнее const shared_ptr& (прирост производительности у автора тестов 60%), intrusive_ptr со встроенным счетчиком - прирост производительности 40%. работа в один поток с соотв. оптимизацией shared_ptr - +25%. дереференс shared_ptr перед передачей результата в функцию даст еще некоторую прибавку к скорости, потому что пока передается ссылка на ссылку на объект.

Ну вот, тут такие бешеные оптимизации с подсчетом ссылок. Там +60%, а там +40%, а там +25%. Это все отличный показатель того, как этот подсчет ссылок тормозит. Ну и на хер он такой нужен? Причем после всех произведенных оптимизаций все равно тормозит.

> По своему опыту профилирования ответственно заявляю, что нормальный

копирующий гц как правило больше пары процентов времени работы

программы не ест.

Очень сильно зависит от того, насколько интенсивно идёт работа с памятью.

С тем, что сильно зависит от программы, спроить не буду. Сам не раз натыкался на 90% GC в профайлере. Правда быстро сводилось потом к 20% и меньше.

>Причем после всех произведенных оптимизаций

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

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

Не бывает полностью дуракоустойчивых языков. Да и не про дураков речь. А про тормоза конкретного метода работы с памятью.

Аргумент поди забыл дать программе. Там же atoi(argv[1]) в первой строчке main'а.

gcc 4.4.5, полет нормальный.

Аргумент поди забыл дать программе. Там же atoi(argv[1]) в первой строчке main'а.

и правда - никакой дуракоустойчивости :)