urn:lj:livejournal.com:atom1:bacek Старое криведко Старое криведко 2009-12-20T07:27:03Z urn:lj:livejournal.com:atom1:bacek:352375 2009-12-20T07:27:03Z 2009-12-20T07:27:03Z В 2-х словах - GC в Parrot'е ужасен. Нет, даже не так. ЧУДОВИЩЕН. Никто не хочет помочь с написанием нормального Generational GC with bells and whistles?<br /><br />(Да, пока нормального GC нет, приходится управляться "в ручную". Я тут замутил мелкий бранч в котором сильно уменьшил количество мусора на каждом вызове функций. Типа ~15% ускорения за несколько часов работы) urn:lj:livejournal.com:atom1:bacek:352059 2009-11-17T11:55:15Z 2009-11-17T11:55:15Z Предистория - пару лет назад я работал над XQuery. Очень красивый язык, для запросов по XMLю. Чуток оверинжиниред, но это обходимо. В кратце - некий декларативно-функциональный язык, без сайд-эффектов, заточеный на обработку древовидных структур. Так как целевой платформой был "embedded linux" (fsvo "embedded") то приходилось экономить на всём. Самая большая проблема - память. Ибо несмотря на свою раздутость, распарсенное XML дерево (например DOM) в пямяти занимает в 4-5 раз больше места, чем его тектовое представление.<br /><br /><a name="cutid1"></a><br />Откуда получается "4-5 раз"? Очень просто - возьмём скажем классическую структуру для представления одной ноды:<br /><br /><pre> struct XMLNode { char *local_name; char *namespace; char *namespace_prefix; XMLNode *first_child; XMLNode *next_child; XMLNode *previous; XMLNode *next; char *content; // for attributes/text/cdata }; </pre><br /><br />(Это примерно соответсвует тому, что есть в libxml2/xerces/etc). Итого 8 указателей. На 32-х битной архитектуре это 32 байта. Тег "&lt;tag/&gt;" занимает 6 байт... Да, конечно, такое представление каждой ноды не оптимально, но позволяет легко ходить по всему дереву (что в XQuery и требуется). С другой стороны - есть классическое "табличное" представление того же самого дерева в виде массива кортежей вида:<br /><br /><pre>(tagname, pre-order, post-order, depth, elementType, content)</pre><br /><br />где pre-order и post-order порядок узла в depth-first traversal. Для примера дерево (foo (bar (@baz "blah"))) может быть представлено в виде<br /><br />foo, 1, 5, 1, tag, null<br />bar, 2, 4, 2, tag, null<br />baz, 3, 3, 3, attribute, "blah"<br /><br />Итого: 12 байт на имя, 4 pre-order, 4 post-order, 4 depth, 4 elementType, 4 content. Те же 32 байта, но с неким полем для манёвра. А далее мы начинаем применять некое количество хаков и ограничений для ужимания каждой ноды в 8 байт.<br /><br />1. Засовываем все эти кортежи в массив. Понимаем, что pre-order нам хранить не нужно, ибо он соответсвует индексу в массиве. Ещё -4 байта.<br /><br />2. Одно из основных понятий в XML 1.1/XQuery это QName. Тег+неймспейс+неймспейс_префикс. Т.е. у &lt;foo:bar xmlns:foo="#uri"&gt; QName будет примерно таким:<br /><br />name: bar<br />ns: #uri<br />prefix: bar<br /><br />Естественное движение - засовываем это всё в какой-нибудь QNameDictionary и храним один индекс вместо 3-х указателей. Итого - -8 байт.<br /><br /><br />3. Начинаем считать биты.<br /> а) Типов элементов у нас 7 (tag, attribute, text, comment, cdata, processing-instruction, namespace-node). 3-х бит достаточно.<br /> б) Количество различных QName даже в самых развевистых XMLях достаточно мало. Ну скажем 64к. (Опять же - ембедщина, нам не то, что бы нужно обрабатывать "сферический xml в вакууме). Итого - 16 бит.<br /> в) Глубина дерева тоже не так, чтобы большая. Сурово лимитируем её на 4096. Итого 12 бит.<br /><br />В сумме - 31 бит. Описываем с битовой длинной, задаём прагму, что бы компилятор не умничал - профит. Ещё минус 12 байт.<br /><br />На текущий момент структура выглядит примерно так:<br /><br /><pre> struct XMLNode { QName_t name:16; int elementType:3; int depth:7; // total 4 bytes size_t post_order; // index in array char *content; }; </pre><br /><br />Последний "финт ушами" - pre-order имеет значение только для element'ов, но у них нет указателя на content. У всех остальных нод не может быть "детей", только content. Засовываем их в один union! Итого:<br /><br /><pre> struct XMLNode { QName_t name:16; int elementType:3; int depth:7; // total 4 bytes union { size_t post_order; // index in array char *content; } data; // 4 bytes }; </pre><br /><br />И таки ужали эту всю марахайку в 8 байт :)<br /><br />А дальше уже совсем просто: вместо "стандартного" vector&lt;XMLNode&gt; делаем свой, с <s>блекджеком и шлюхами</s> со страничной организацией (скажем в 4 килобайта), берём mmap и пишем сваппинг на диск неиспользуемых страниц. Для увеличения скорости храним в памяти только текущую и предыдущую страницу. Итого - 8 килобайт на хранение структуры. <br /><br />Применяем тот же приём для хранения content'а - аллокируем всё через StringFactory и храним айдишники вместо указателей. У StringFactory внутри "неонка" с "mmap"ом и пейджингом (чуть более сложная, чем первая. Ибо могут понаботится строки больше 4-х килобайт).<br /><br />Step 3 - Profit! У нас в памяти живёт 8 килобайт на структуру, примерно 8 килобайт на строки, словарь QName'ов (в реальной жизни достаточно мелкий). При парсинге мы скидываем страницы на диск, при обработке - подчитываем их обратно. В большинстве случаев - одни раз.<br /><br />Вот как-то так. Обработать гигабайтные xml-и в минимуме памяти можно. И даже достаточно быстро. А учитывая особенности аллокации, то даже быстрее, чем в "классическом" древовидном представлении, ибо локальность нод в памяти просто чудовищная :) urn:lj:livejournal.com:atom1:bacek:351830 2009-11-17T09:40:41Z 2009-11-17T09:40:41Z Итого - сабж. Мне просто больше нечего сюда больше присать.<br /><br />Про "технологии" - не хочется. Есть много людей которые пишут лучше и больше чем я.<br /><br />Про "жизнь" - тем более. Оно нафиг не нужно. Ни мне, ни вам.<br /><br />Если есть какие-то вопросы - задавайте в комментариях тут. Обещаю ответить предельно честно, если это не задевает личную жизнь других людей.<br /><br />"Театр закрывается, нас всех тошнит" urn:lj:livejournal.com:atom1:bacek:351732 2009-09-15T14:09:57Z 2009-09-15T14:09:57Z Parrot 1.6.0 released. FSVO. It's tagged in svn. And I already broke trunk...<br /><br />A lot of major refactorings and improvements were made:<br /><br />- Last crappy bit about using refcounts was removed.<br />- Profiling was rebuilt from scratch and fully functional. urn:lj:livejournal.com:atom1:bacek:351373 2009-09-06T08:07:46Z 2009-09-06T08:07:46Z <a href="http://fotki.yandex.ru/users/bacek/view/172092/"><img src="http://img-fotki.yandex.ru/get/3700/bacek.d/0_2a03c_d9b8a479_L.jpg" width="500" height="313" title="" alt="" border="0" /></a><br /><br />Profiling for Parrot is mostly done! urn:lj:livejournal.com:atom1:bacek:351174 2009-09-04T09:37:49Z 2009-09-04T09:37:49Z Эта... А прошлогодний GSoC проект по отрыванию GC из Apache Harmony в отдельную библиотеку так и не случился? Или я просто его нагуглить не могу? urn:lj:livejournal.com:atom1:bacek:350744 2009-09-03T13:21:44Z 2009-09-03T13:21:44Z <a href="https://trac.parrot.org/parrot/changeset/40958/trunk">https://trac.parrot.org/parrot/changeset/40958/trunk</a><br /><br />Зафигачил нефиговую фигню в паррот. &gt;7500 строк в диффе. Таки убил последнее место, где использовались реф-каунты. urn:lj:livejournal.com:atom1:bacek:350648 2009-09-02T13:42:49Z 2009-09-02T13:42:49Z <a href="http://irclog.perlgeek.de/parrot/2009-09-02#i_1457708">http://irclog.perlgeek.de/parrot/2009-09-02#i_1457708</a><br /><br />Приблизительно соответсвует количеству коммитов в Parrot :) urn:lj:livejournal.com:atom1:bacek:350326 2009-08-31T10:48:18Z 2009-08-31T10:48:18Z <a href="http://dz.livejournal.com/516337.html">http://dz.livejournal.com/516337.html</a><br /><br />Интересно, а сколько вариантов GC знает dz? urn:lj:livejournal.com:atom1:bacek:350148 2009-08-31T05:31:43Z 2009-08-31T05:31:43Z Тёмыч народил сына! urn:lj:livejournal.com:atom1:bacek:349718 2009-08-26T12:51:36Z 2009-08-26T12:51:36Z <a href="http://brighte.livejournal.com/11697.html">http://brighte.livejournal.com/11697.html</a><br /><br />Чёрт... Хочется написать много слов, но все они будут совершенно не те... urn:lj:livejournal.com:atom1:bacek:349520 2009-08-17T12:09:09Z 2009-08-17T12:09:09Z "Все побежали и я побежал" (с) Василий Алибабаевич.<br /><br />1. Боян. Оригинальному посту на (прошу заметить) Perl Monks уже года полтора. Заметка на LtU появилась дня три назад. Охренительная оперативность.<br /><br />2. <b>Любой</b> динамический язык с поддержкой eval невозможно <b>скомпилировать</b> статически полностью.<br /><br />3. Perl5 невозможно спарсить статически. И что? Зато это даёт возможно писать что-то вроде <br /><pre> sub foo(&@); foo { ... } @array; </pre><br /><br />4. Невозможность статического парсинга не отменят статического анализа и оптимизации. Попробуйте что-нибудь вида <tt>perl -MO=Deparse -e 'print 2+2'</tt>.<br /><br />5. В Perl6 всё ещё "хуже". Там парсер вообще на каждый чих может перестраиваться. Смотреть <a href="http://bacek.livejournal.com/345648.html">http://bacek.livejournal.com/345648.html</a> в качестве примера. Ну и что, что перестраивается? urn:lj:livejournal.com:atom1:bacek:349408 2009-08-09T05:37:22Z 2009-08-09T05:37:22Z "Еда мужская. Полкило". Сборник рецептов для холостяков. Не более 3-х ингридиентов + мясо. Время готовки - не более получаса.<br /><br />Life sux. urn:lj:livejournal.com:atom1:bacek:349032 2009-08-04T12:57:13Z 2009-08-04T12:57:13Z Карму чищу.<br /><br />(Все долгие объяснения урезаны нафиг) urn:lj:livejournal.com:atom1:bacek:348785 2009-08-02T12:35:07Z 2009-08-02T12:35:07Z Купил тут по случаю на свой цивег 205/45R16. Как-то он совершенно по-другому рулится стал. Ощущения такие, что в поворот его кто-то "втягивает". urn:lj:livejournal.com:atom1:bacek:348458 2009-08-01T05:08:01Z 2009-08-01T05:08:01Z <pre> N: Bryan C. Warnock D: The First Perl 6 Summarizer D: Little things here and there in pre-Parrot days. D: And, yes, {sigh}, *that* Warnock. E: bwarnock@raba.com </pre><br /><br />Гы-гы-гы, евпочя :) urn:lj:livejournal.com:atom1:bacek:348241 2009-07-07T14:32:45Z 2009-07-07T14:32:45Z <pre> # ws handles whitespace, pod and perl and C comments token ws { [ | \s+ | '#' \N* | ^^ '=' .*? \n '=cut' | '/*' .*? '*/' ]* } </pre><br /><br />I love this language :) urn:lj:livejournal.com:atom1:bacek:347973 2009-07-06T11:08:49Z 2009-07-06T11:08:49Z Други,<br /><br />а как мне нахер отключить в Debian/Lenny i386 все эти новомодндые Stack protector, ASLR и т.п.? А то оно мне тут сильно мешает отлаживать проезды по памяти... urn:lj:livejournal.com:atom1:bacek:347731 2009-07-02T11:27:39Z 2009-07-02T11:27:39Z <a href="http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The Parable of the Two Programmers.html">http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The Parable of the Two Programmers.html</a><br /><br />85-й год... Иногда хочется просто застрелиться от того, что нихера в этом мире не меняется... urn:lj:livejournal.com:atom1:bacek:347621 2009-06-25T12:01:32Z 2009-06-25T12:01:32Z Я прям как на яву вижу, как девелоперы ЖЖ рвут волосы из жопы, что у них накрылась мастер-база мыскла на которой жил блог <span class='ljuser ljuser-name_drugoi' lj:user='drugoi' style='white-space: nowrap;'><a href='http://drugoi.livejournal.com/profile'><img src='http://l-stat.livejournal.com/img/userinfo.gif' alt='[info]' width='17' height='17' style='vertical-align: bottom; border: 0; padding-right: 1px;' /></a><a href='http://drugoi.livejournal.com/'><b>drugoi</b></a></span>... urn:lj:livejournal.com:atom1:bacek:347139 2009-06-05T13:17:35Z 2009-06-05T13:17:35Z <a href="http://nopaste.snit.ch/16791">http://nopaste.snit.ch/16791</a><br /><br />Ну типа так. Ещё один шажок к тому, чтобы parrot мог компилировать сам себя :) urn:lj:livejournal.com:atom1:bacek:346993 2009-05-27T12:22:42Z 2009-05-27T12:22:42Z ... что если в Цивеге на заднем сиденьи сидит кто-то тяжёлый, дорога чуток мокрая, а ты пытаешься ехать также, как раньше, то лучше этого не делать...<br /><br />Возврашался сегодня в контору с ланча. Вёз трёх человек. Так эта дурацкая желязяка, при полностью вывернутом руле, продалжала подпрыгивая ехать прямо и отказывалась поворачивать совсем. Ладно скорость была мелкая и мы таки уткнулись в поребрик...<br /><br />(Да, а заднеприводные хетчи кто-нить делает?) urn:lj:livejournal.com:atom1:bacek:346848 2009-05-25T12:14:58Z 2009-05-25T12:14:58Z Сходил в Яху на open day про Blah-blah Web Speed blah-blah improvements. Впечатления двойственные:<br /><br />1. Узнал некоторое количество новых фишек. Это хорошо.<br />2. 90% информации (для меня) - очевидные вещи. Это вроде нормально, ибо опыт не пропьёшь.<br />3. 90% слушателей про эти 90% информации слышали впервые. И это плохо и грустно... urn:lj:livejournal.com:atom1:bacek:346455 2009-05-23T13:25:15Z 2009-05-23T13:25:15Z <pre> bacek@icering:~/src/parrot$ /usr/bin/perl t/harness t/benchmark/*.t t/benchmark/benchmarks....ok All tests successful. Files=1, Tests=36, 111 wallclock secs ( 0.01 usr 0.00 sys + 95.26 cusr 2.63 csys = 97.90 CPU) Result: PASS bacek@icering:~/src/parrot-svn$ /usr/bin/perl t/harness t/benchmark/*.t t/benchmark/benchmarks....ok All tests successful. Files=1, Tests=36, 561 wallclock secs ( 0.03 usr 0.01 sys + 501.54 cusr 3.09 csys = 504.67 CPU) Result: PASS </pre><br /><br />First benchmark from my branch. Second - from trunk. urn:lj:livejournal.com:atom1:bacek:346267 2009-05-18T22:56:15Z 2009-05-18T22:56:15Z 1. 4 days of frustrations.<br />2. <a href="https://trac.parrot.org/parrot/changeset/38917">Single commit</a><br />...<br />4. Profit!