Вышли новые версии оригинальных компиляторов языков D2 и D1

>Злостное 4.2. Кодят.

Я имел в виду не абсолютные цифры, а относительное соотношение по сравнению с числом кодеров на mainstream языках.

«Оптимизаторов» нужно отстреливать, однозначно. Ибо много зла они принесли.

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

Может попилить

Поздно его пилить

Сарказм же

>Плюсы - пакет надстроек над Си.

А я думал, что в постбустовскую эпоху, людей, считающих, что C++ - это такой C, только с классами, не осталось уже.

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

Никогда не говори никогда и погугли «C++0x Garbage collection ABI».

> А я думал, что в постбустовскую эпоху, людей, считающих, что C++ - это такой C, только с классами, не осталось уже.

остались, хоть С++ это и не С с классами, но его можно использовать в таком качестве

> Я считаю, что ни одна реализация смарт-пойнтеров не работает правильно с циклическими ссылками. Пока что никто не привел ссылок в опровержение моей точки зрения.

щас спою :-)

существуют алгоритмы сборки «подвисших» циклических структур

тыкнуть в готовую либу не могу (хотя по непроверенным слухам, это дело имеется в гномовских либах (???))

глюки Boehm GC подозреваю отнюдь от неотлаженности (концептуально там все просто, глючить нечему), а от того, что сборка мусора добавляет недетерменированности в программу, и баг *программы* воспроизвести становится сложно; это, понятно, будет при любом GC... хотя, возможно, именно сборка «подвисших» циклических структур будет в этом смысле лучше, т.к. ее недетерменированность меньше (т.е. бОльшая часть мусора удаляется детерменированно)

дальше — насчет weak_ptr — медицинский факт состоит в том, что без них не обойтись даже при наличии GC, почему их и ввели в яве

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

понятно, чтобы это заюзать в плюсах, нужна помощь компилятора, которую он предоставляет только в малой степени (я про type&&); тут мы опять нарываемся на типичный недостаток плюсов — компилятор, редиска, проводит искейп-анализ, но с нами этими данными не делится

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

> Более того, shared_ptr (и QSharedPointer) медленнее, чем GC, когда используются блокировки, которые необходимы для многопоточных программ.

откуда инфа?

инкремент (в принципе, не знаю как щас в бусте) можно делать через CopyAndSwap, так что на первый взгляд это не должно быть проблемой

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

а циклические структуры это так, мелочи...

Мндэ, блин... ЛюбовЪ & ПорядокЪ несомненно более «ценное» достижение чем сабж. 8)

На счет реализации могут быть варианты. В том же Qt их оптимизируют ассемблерными вставками, быть может, удается добиться атомарных изменений счетчика без явных блокировок. Но факт остается:

Shared_ptr (и QSharedPointer) медленнее, чем хороший GC.

За доказательством обращаться к товарищу Jon Harrop. Он любит проводить подобные сравнения. Кстати, автор книги «F# for Scientists».

>> Ага, и производительность станет как не дотнете. Тогда уж плюсы действительно не будут нужны. Нет уж, не надо таких «улучшений»!

Думаешь с new память выделять быстрее, чем с GC?

Это типа ответ на мой комментарий? Сравни-ка лучше скорость обращения к памяти. Насколько я знаю, эта операция производится гораздо чаще, чем выделение/освобождение.

>> Плюсы - пакет надстроек над Си.

А я думал, что в постбустовскую эпоху, людей, считающих, что C++ - это такой C, только с классами, не осталось уже.

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

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

Никогда не говори никогда и погугли «C++0x Garbage collection ABI».

Может, ты не заметил, но у тебя в кавычках стоит C++0x, а не С++. Си совместим с ассемблером, С++ совместим с Си, и если C++0x сделают совместимым с С++ и сделают Garbage collection, у них автоматически получится Garbage collection для ассемблера. Дошло?

> основная вроде бы претензия к счетчику ссылок — это его *тормознутость* — при локальных копированиях и уничтожениях приходится делать инкременты и декремены, в то время как явовские указатели можно копировать свободно.

при этом вашем «свободном копировании» инкременты и декременты делает ява-машина, так что на ЦП нагрузка та же.

> Более того, shared_ptr (и QSharedPointer) медленнее, чем GC, когда используются блокировки, которые необходимы для многопоточных программ.

Ложь и клевета. Эти блокировки нужны только в тех случаях, когда к объекту имеют доступ два или более потоков. А это уже на порядок реже.

Выше.

Или ты несогласный с Jon Harrop?

Shared_ptr (и QSharedPointer) медленнее, чем хороший GC.

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

> дальше — насчет weak_ptr — медицинский факт состоит в том, что без них не обойтись даже при наличии GC, почему их и ввели в яве

Не сразу. Так что _необходимости_ в нем нет - это средство оптимизации.

основная вроде бы претензия к счетчику ссылок — это его *тормознутость* — при локальных копированиях и уничтожениях приходится делать инкременты и декремены

Меня это не волнует.

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

>Это типа ответ на мой комментарий? Сравни-ка лучше скорость обращения к памяти. Насколько я знаю, эта операция производится гораздо чаще, чем выделение/освобождение.

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

>да, и тормознутость shared_ptr при исключениях — если в яве можно просто подвинуть указатель стека, то в плюсах придется вызывать деструкторы со всеми их декрементами

декремент ресурсоемок?

>> Более того, shared_ptr (и QSharedPointer) медленнее, чем GC, когда используются блокировки, которые необходимы для многопоточных программ.

Ложь и клевета. Эти блокировки нужны только в тех случаях, когда к объекту имеют доступ два или более потоков. А это уже на порядок реже.

Ложь и клевета. На большинстве платформ используется lock-free реализация shared_ptr.

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

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

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

> В случае исполнения на интерпретаторе программа оперирует ID-шниками блоков памяти, которые JVM/mono/т.п. преобразовывает в реальные адреса

O_o

С чего ты это взял?

>Может, ты не заметил, но у тебя в кавычках стоит C++0x, а не С++. Си совместим с ассемблером, С++ совместим с Си, и если C++0x сделают совместимым с С++ и сделают Garbage collection, у них автоматически получится Garbage collection для ассемблера. Дошло?

Последний раз такую убедительную цепочку рассуждений читал у Фомы Аквината, когда он обосновывал выпиливание еретиков. Чем схоластикой заниматься, лучше бы почитал предложения по введению GC в C++, там написано, как собираются «GC для ассемблера» делать.

> лучше бы почитал предложения по введению GC в C++

И где оно лежит?

> С чего ты это взял?

Начнем хотя бы отсюда - http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BF%D1%80%D0%B5...

Зачем по-вашему нужна была VM, если б команды шли непосредственно в проц?

http://www2.research.att.com/~bs/C++0xFAQ.html#gc-abi http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2310.pdf

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

http://portal.acm.org/citation.cfm?doid=1542431.1542437

> Начнем хотя бы отсюда - http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BF%D1%80%D0%B5...

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

Спасибо.

Читаю я этот C++ 0x... просто страшно, чем стал Си++

> лучше бы почитал предложения по введению GC в C++, там написано, как собираются «GC для ассемблера» делать.

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

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

Более того, shared_ptr (и QSharedPointer) медленнее, чем GC, когда используются блокировки, которые необходимы для многопоточных программ.

пример некорректен, но таки работает:

#include <cstdlib>
#include <pthread.h>
#include <tr1/memory>

using std::tr1::shared_ptr;

static shared_ptr<int> gValue( new int );

void* foo( void* pm )
{
	int s = 0;
	for( int i = 0 ; i < 1000000 ; ++i )
	{
		shared_ptr<int> v = gValue;
		*v = rand();
		s += *v;
	}

	return NULL;
}
 
int main( void )
{
	pthread_t threads[ 5 ];
 
	for( int i = 0 ; i< 5 ; ++i )
    	pthread_create( &threads[ i ], NULL, foo, NULL );
 
   	for( int i = 0 ; i < 5 ; ++i )
		pthread_join( threads[ i ], NULL );
}

работает 1.9сек, вместо 1.7сек для того же без shared_ptr, в реальном приложении shared_ptr практически не влияет на скорость

Ну я-то вообще про FORTRAN IV...

>В случае исполнения на интерпретаторе программа оперирует ID-шниками блоков памяти, которые JVM/mono/т.п. преобразовывает в реальные адреса, и это преобразование не всегда столь тривиально как таблица подстановки.

Земля стоит на трех слонах, а они, в свою очередь, - на огромной черепахе. Такого уровня у тебя представления о JVM/mono/т.п. Нет там никаких интерпретаторов и получение указателя по «айдишнику» - тривиальная операция. GC просто не будет двигать этот объект в куче, пока ты держишь на него указатель. В С++, если ты не хочешь втихаря уплотнять кучу, можно обойтись без всяких «айдишников». GC не связан напрямую с алгоритмом распределения памяти, ему важно лишь указатели отслеживать.

>Читаю я этот C++ 0x... просто страшно, чем стал Си++

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

> декремент ресурсоемок?

думаю не сам декремент, а поддержание списка деструкторов

вот я делал тесты без смарт пойнтеров: http://www.linux.org.ru/forum/development/3856841

> За доказательством обращаться к товарищу Jon Harrop. Он любит проводить подобные сравнения. Кстати, автор книги «F# for Scientists».

давай ссылку или достаточно ключевых слов

>Да читал я это. Идея прочесывать оперативу в поисках указателей не канает - на низком уровне такие тормоза не нужны. К тому же, метод не защищен от псевдо-указателей - переменных, содержащих старые необнуленные указатели. Других идей пока нет.

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

> Меня это не волнует.

возможно, был бы полезен консервативный (как Boehm GC) сборщик циклов, которому известен лейаут смарт-пойнтеров

Смешались в кучу люди, кони... С тобой я говорил про тормоза обращения к памяти, при чем тут GC? Получение указателя по «айдишнику» - таки тривиальная операция, но выполняется она не менее чем за 1 такт процессора (на практике - от 3 до 10 тактов), и это все при условии нахождения таблицы ID в кэше процессора. Это недопустимо там, где нужен high-performance. В компилированном коде обращение к памяти - всего 1-2 такта.

А чтоб больше не спорить, посмотри, пожалуйста, бенчмарки.

> Ложь и клевета. На большинстве платформ используется lock-free реализация shared_ptr.

я это и подозревал; CAS в конце концов для кого делали?

Укажите, пожалуйста, где именно. По-моему, там указывался лишь порядок этого поиска.

> Получение указателя по «айдишнику» - таки тривиальная операция

Нет никакой «таблицы айдишников».

>Непонятно одно - нафига нужен интерпретатор, если можно сразу скомпилировать?

Непонятно одно - нафига Джимми деньги собирал, если ты википедией не пользуешься? (http://en.wikipedia.org/wiki/Just-in-time_compilation)

> Нет никакой «таблицы айдишников».

Тем более, ведь проще таблицы соответствия ID->pointer ничего нет.

> Не сразу. Так что _необходимости_ в нем нет - это средство оптимизации.

необходимость в weak_ptr есть уже в любой гуевой проге, использующей listener (иначе память если не течет, то перерасходуется точно) — т.е. можно считать сразу

хотя да, кое-что работает и без weak_ptr

> Непонятно одно - нафига Джимми деньги собирал, если ты википедией не пользуешься? (http://en.wikipedia.org/wiki/Just-in-time_compilation)

Ну и где там доказывается выигрыш в производительности при интерпретации? В итоге все равно компилируем. Ответа на свой вопрос я так и не получил - почему ты и прочие здесь собравшиеся считают, что JVM + JIT + прочие плюшки выигрывает по производительности у бинарников?

чувак, тебе уже про трех слонов сколько человек сказали... я присоединяюсь

>Смешались в кучу люди, кони... С тобой я говорил про тормоза обращения к памяти, при чем тут GC?

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

но выполняется она не менее чем за 1 такт процессора

Если ты начал такты подсчитывать, то не пользуйся GC. Это опционально.

А чтоб больше не спорить, посмотри, пожалуйста, бенчмарки.

Бенчмарки чего?

> чувак, тебе уже про трех слонов сколько человек сказали... я присоединяюсь.

Уж кто бы говорил. Если, по-вашему, байт-код исполняется процессором, то почему JVM называется виртуальной машиной, а не, скажем, Java-launcher???

Компиляция же жаба-кода дает профит только по сравнению с некомпиляцией его же. Большинство сишных прог уже заканчивают свою работу пока JVM только память под исполняемый код выделяет.

> Притом, что ты очевидно считаешь, что при использовании GC указателями пользоваться нельзя.

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

Если ты начал такты подсчитывать, то не пользуйся GC. Это опционально.

Блин, ты до тебя туго доходит? Еще раз повторяю: какое GC имеет отношение к обращению (чтение/запись) к памяти ?!

Бенчмарки чего?

Скорости работы реализаций заданных алгоритмов на различных ЯП. Например, http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest...

Не согласен - приведи пример других бенчмарков или проведи свои.