> На Go что-нибудь юзабельное написал? :-)

нет, я ж написал для чего эти языки использую, причина не в GC, однако, говорят, в Go посредственный GC на данный момент

> в коментах написали, как *ускорить* решение на С++. Это не ошибки, это оптимизации.

ну да, передавать значение по ссылке, а не копировать - это такая оптимизация, а не здравый смысла

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

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

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

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

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

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

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

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

Просто Go для меня на данный момент очень интересен ^^" И тоже балуюсь. GC там сейчас очень слабенький, да и перфоманс пока тоже. В gcc'шном компиляторе go-рутины толком не работают.

Не истины ради, но флейма для.
Всем описавшимся насчет auto_ptr напоминаю, что в C++0x он defecated^W^W^W deprecated и вместо него придуман unique_ptr. Ура.

В C++ указатели не использую и вообще динамическое распределение за пределами контейнеров. Во встроенном интерпретаторе использую велосипедный GC.

есть еще всякие прикольные техники вроде region inference

с удовольствием, кстати, обсудил бы оные. встречал на практике только в JHC

Forth? Нет, я с ним не работал. Судя по описанию - GC там нет. ПО крайней мере умолчального, как в Java. Или это не современный язык?

Использую как язык без GC (C) так и языки с GC (Scheme, Java). На тему принципов работы не задумывался, студент(причем не IT), вышеупомянутые языки только учу/начинаю изучать. Разница в методах GC становится важна ИМХО только в случает real-time приложений требовательных ко времени реакции. А их пишут сейчас на языках с GC? Кстати, дополнительный вброс - в Java есть принудительный вызов/запрет вызова GC? Где то вопрос уже поднимался, сейчас не помню где...

>tradeoff при использовании умных указателей не смущает?

Имелись в виду shared_ptr'ы?

Ведь насколько я понимаю, при использовании scoped_ptr и auto_ptr/unique_ptr какого-либо оверхеда быть не должно.

В работе не использую, на досуге играюсь с D и цацкелем.

В плюсах либо использую scoped_ptr+auto_ptr+ptr_containers (предпочтительнее), либо shared_ptr+weak_ptr/intrusive_ptr (реже). Алгоритмы не знаю, жду, пока здесь полезных ссылочек накидают.

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

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

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

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

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

> используете ли языки с GC, и какими их преимуществами при этом пользуетесь?

Мне нравится то, как намного проще с помощью GC обрабатывать данные с циклическими связями, и, вообще, со сложной иерархией. На более примитивных языках типа Си++ это был бы такой геморрой!

А циклические данные у меня возникали часто. Не то чтобы целенаправленно, но таковы были задачи. Есть на мой взгляд несуразное мнение, распространенное особенно среди сишников и плюсистов, что циклы - якобы ошибка дизайна. Считаю, что это полнейшая глупость. С такой же легкостью тогда можно было бы сказать, что и рекурсия с индуктивностью тоже дефектны, что, очевидно, - полнейшая ложь. Просто бытиё формирует сознание :)

> то и рекурсия с индуктивностью тоже дефектны, что, очевидно, - полнейшая ложь. Просто бытиё формирует сознание :)

Вы не радиотехник в прошлом?

Если вопрос ко мне, то я учился на математика.

А если ты про «индуктивность», то тогда читай Пола Хьюдака. У него есть прекрасная книга по хаскелю.

Мм, откуда индуктивность взялась?

В шарпе точно есть, в жабе вроде не было...

Paul Hudak, «The Haskell School of Expression»

И что дальше-то?

Индуктивность aka inductance не имеет отношения ни к математике, ни к CS. Это из области основ электрохники: http://ru.wikipedia.org/wiki/Индуктивность

Может быть я просто чего-то не знаю?

мб он так «индукцию» обозвал?

> Или это не современный язык?

Точно.

>> есть еще всякие прикольные техники вроде region inference

с удовольствием, кстати, обсудил бы оные. встречал на практике только в JHC

А я только в учебнике. Вроде в Cyclone что-то такое было, но Cyclone умер.

нет, все умерли. остались только жабисты, которые написали на жабе объектно-ориентированное ведро, способное выполнить бесконечный цикл быстрее процессора.

у shared_ptr есть одно проблемное место - авторы хотели цеплять им все возможные классы, а поэтому счётчик ссылок лежит отдельно от объекта. соотвественно, высока вероятность лишнего cache-missа. Скорость от этого проседает существенно.

> Просто ради любопытства, чем «вебель» отличается от всего остального в плане разработки? или ещё в каком плане?

Просто мне лично это неинтересно - как говорится, «not my idea of fun» (c). Мне интересен уровень ниже - ОС, языки и всё такое.

>> А остались люди, которые не пользуются языками с GC?

нет, все умерли. остались только жабисты

Вижу, еще остались последние бойскауты и кэш-миссионеры.

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

«Bump allocating from a huge preallocated pool without ever freeing is surprisingly slow» wtf?????

это из какой жопы должны расти руки, чтоб подбирая память из массива фактически, получить худшие результаты?

мб он так «индукцию» обозвал?

Мне кажется, можно и так, и так. Рекурсивные или индуктивные типы данных. Правда, распространен только один вариант названия.

Значит, книгу не смотрел?

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

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

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

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

Жуть какая. Очень гармонично пост смотрится с аватаркой.

Какая глава хоть? Proof by induction?

на самом деле в тестах не хватает информации о том, срабатывал ли хоть раз собственно 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

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

вот несколько более объективное (хоть и устаревшее) обсуждение

в принципе, было бы очень интересно посмотреть зависимость производительности GC от объёма доступной памяти

нашёл упоминание о том, что region inference упоминается в RT Specification for Java. кто-нибудь на RT Java пишет?