К вопросу о Chrome:
Sep. 4th, 2008 02:35 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Результаты теста производительности 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
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
no subject
Date: 2008-09-04 12:40 am (UTC)no subject
Date: 2008-09-04 09:53 am (UTC)no subject
Date: 2008-09-04 10:50 am (UTC)в perl нет smart pointers, но есть GC. но вобщем-то это все одно сборка мусора.
no subject
Date: 2008-09-04 06:19 pm (UTC)Или у меня информационное переполнение на тему терминологии smart pointers vs. GC - запутался где что.
//сел читать сорцы...
no subject
Date: 2008-09-04 06:24 pm (UTC)http://en.wikipedia.org/wiki/Malloc#Implementations
no subject
Date: 2008-09-04 07:38 pm (UTC)no subject
Date: 2008-09-04 06:27 pm (UTC)a->x=b;
b->x=a;
у b и a количество рефов >= 1, хотя на них может больше никто не ссылаться и нигде они больше не учавствуют и можно спокойно мочить.
no subject
Date: 2008-09-04 07:47 pm (UTC)Но в последних версиях перла есть выход - так называемое ослабление ссылок. При этом для одного элемента из ссылаемых данных количество ссылок на 1 меньше "виртуальных ссылок". И при разрушении ключевого элемента структуры всё нормально освобождается - деструкторы вызываются.
В перле это выглядит так:
{
my ( %a, %b );
$a{x} = \%b; # ссылка на b
$b{x} = \%a; # ссылка на a
use Hash::Util 1.19 qw(weaken);
weaken $b{x};
}
# Все данные сносятся. Точнее освобождаются. Что при этом происходит с реально захаваной памятью - второй вопрос (к вопросу о malloc-е).
no subject
Date: 2008-09-04 07:20 pm (UTC)Посмотрел исходники:
Код по работе с 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 же - другое. Насколько я понимаю - это когда есть связанный список разных объектов, и специальный тред или функция пробегает по этому списку в моменты нужды и как-то обнаруживает, что на этот объект больше никто живой не ссылается, после чего грохает. И круче это тем что будучи реализованным на уровне объектной модели уменьшает перегрузку процессора от постоянного мониторинга рефкаунта при почти каждом обращении к переменной (даже такой тривиальной, как строка или число).