К вопросу о Chrome:

[allter]

Результаты теста производительности JavaScript http://www2.webkit.org/perf/sunspider-0.9/sunspider-driver.html (чем меньше, тем лучше):

MSIE 7.0: 28446.4ms +/- 1.7%
FF 2.0.0.16: 14263.2ms +/- 1.6%
Chrome 0.2.149.27: 1575.4ms +/- 1.4%

Т.е. Chrome в 9 раз быстрее FF и в 18 (!) раз быстрее MSIE.

А по отдельному тесту в сравнении Chrome vs. FF - первый быстрее последнего аж 155 раз:
Bitwise-and: 155.3x as fast 2578.0ms +/- 1.4% 16.6ms +/- 4.1% significant

Comments

[kefeer.livejournal.com]

Там JIT и нормальный GC.

[allter]

Про JIT я уже понял, а что за GC? Это имеется в виду не smart pointers, а что-то другое?

[kefeer.livejournal.com]

странно слышать от тебя такую формулировку :)

в perl нет smart pointers, но есть GC. но вобщем-то это все одно сборка мусора.

[allter]

В Perl5 как раз smart pointers (там это называют refcounting), иначе бы не работала RAII. Просто поскольку Perl на C написан, то код реализован в виде макросов и уменьшение счётчика происходит вручную. И что-то там странное с malloc`ом на x86 - память не спешит отпускать (это имеется в виду? есть мнение, что это просто недоработка, а не GC)...

Или у меня информационное переполнение на тему терминологии smart pointers vs. GC - запутался где что.

//сел читать сорцы...

[kefeer.livejournal.com]

а ты почитай про реализацию malloc. там все плохо.

http://en.wikipedia.org/wiki/Malloc#Implementations

[allter]

Да. Тем более в перле она вообще своя.

[kefeer.livejournal.com]

ну и раз в перле только refcounting, то циклические структуры он не умет чистить. Типо

a->x=b;
b->x=a;

у b и a количество рефов >= 1, хотя на них может больше никто не ссылаться и нигде они больше не учавствуют и можно спокойно мочить.

[allter]

Угу.. Вообще. Если такая структура создаётся и не разрывается программером, то живёт до конца жизни скрипта.

Но в последних версиях перла есть выход - так называемое ослабление ссылок. При этом для одного элемента из ссылаемых данных количество ссылок на 1 меньше "виртуальных ссылок". И при разрушении ключевого элемента структуры всё нормально освобождается - деструкторы вызываются.

В перле это выглядит так:
{
my ( %a, %b );
$a{x} = \%b; # ссылка на b
$b{x} = \%a; # ссылка на a
use Hash::Util 1.19 qw(weaken);
weaken $b{x};
}
# Все данные сносятся. Точнее освобождаются. Что при этом происходит с реально захаваной памятью - второй вопрос (к вопросу о malloc-е).

[allter]

А, если ты имеешь в виду то, что refcount хранится в данных ссылаемого объекта а не объекта-ссылки, так это несущественно, учитывая, что конечный информационный объект (строка, число, массив SVшек) ссылается из этого объекта ссылки.

Посмотрел исходники:

Код по работе с SvREFCNT/SvREFCNT_inc/SvREFCNT_dec

А вот код для контроля:

#if defined(__GNUC__) && !defined(__STRICT_ANSI__) && !defined(PERL_GCC_PEDANTIC)
# define SvREFCNT_dec(sv) \
({ \
SV * const _sv = (SV*)(sv); \
if (_sv) { \
if (SvREFCNT(_sv)) { \
if (--(SvREFCNT(_sv)) == 0) \
Perl_sv_free2(aTHX_ _sv); \
} else { \
sv_free(_sv); \
} \
} \
})
#else
#define SvREFCNT_dec(sv) sv_free((SV*)(sv))
#endif

Отличие от C++-сных умных указателей (точнее, от машинального их использования) в том, что всё это делается неавтоматически - например количество ссылок на скаляр увеличивается _перед_ поклажей в массив или хэш, а последним вообще пофиг до ссылок на хранимые данные. За счёт этого достигается "переоптимизированность" перла, которая когда-то была очень нужна, а сейчас, с приходом во все скриптовые языки JIT, стала менее актуальной.

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