Re: Catalyst: увеличиваем скорость реакции

[Sergeev Serge]

14.09.10, 02:00, "Alexandr Ciornii" <alexchorny at gmail.com>:
> 14 сентября 2010 г. 0:18 пользователь Sergeev Serge  написал:
>  > 13.09.10, 23:40, "Alexandr Ciornii" :
>  >> 13 сентября 2010 г. 22:30 пользователь Ivan Иван  написал:
>  >>
>  >>  >>  Как я написал раньше, fork - это не копирование. Память помечается как
>  >>  >>  используемая несколькими процессами. fork был специально так
>  >>  >>  оптимизирован. В частности, system() работает через fork().
>  >>  >>
>  >>  >
>  >>  > Тут вот, можно поподробнее. Я думал всегда, что идёт всё же копирование скопа. И, для threads, в отличии от классического fork можно указать совместно используемые переменные (= память). Если форк тупо помечает память, то при изменении переменных, это бы видели остальные чилды. Что как бэ не так. Значит ссылки на переменные - откопированны, а не просто помеченны.
>  >>
>  >>  Страница памяти (не вся память занятая процессом, а какой-то небольшой
>  >>  кусок) копируется только при модификации. Поэтому и называется COW -
>  >>  copy-on-write. Техника широко применяется не только в Unix fork() но и
>  >>  в самом Perl невидимо для пользователя.
>  >>
>  >>  http://en.wikipedia.org/wiki/Copy-on-write
>  >
>  > Думаю что вы путаете.
>  > То есть да, сам интерпретатор Перл конечно разделяется между несколькими процессами - потому что это тот случай, когда система может однозначно определить что эти данные неизменяемые - в исполняемых файлах форматов exe и elf действительно есть пометки, указывающие что данный код неизменяемый.
>  
>  fork() делает не Perl. Его делает операционная система. Perl просто
>  вызывает fork() из C. fork() помечает ВСЮ область занятую программой и
>  ее данными как заблокированную для записи. Эта память разделяется
>  обоими процессами. При любой попытке записи происходит копирование
>  соответствующей страницы памяти. Блокировка записи выполняется
>  процессором, а копирование - ОС по сигналу процессора.
>  
>  Все это выполняется для людой программы и любых данных. ОС нет
>  никакого дела что данная программа - интерпретатор Perl.
>  
>  > Но сами данные не могут разделяться без специальной поддержки при написании интерпретатора, потому что например у каждого процесса интерпретатора Перл они генерятся с нуля и могут "в зависимости от погоды в Африке" каждый раз построить разное дерево.
>  
>  fork() - это не новый запуск, это клонирование всего, поэтому все
>  одинаковое. Просто копия "ленивая", поэтому разделение происходит по
>  необходимости.
>  
>  Из http://perldoc.perl.org/functions/fork.html
>  On most systems supporting fork(), great care has gone into making it
>  extremely efficient (for example, using copy-on-write technology on
>  data pages), making it the dominant paradigm for multitasking over the
>  last few decades.

Это все очень отдаленная от жизни теория.
На практике все намного грустней.
Вот вы в курсе, что кеши не чисто ассоциативные?
Казалось-бы, ну и что с того, а это очень многое означает - например это означает, что если хотя-бы один бит в блоке изменился, то и весь блок уже становится "грязным" и весь этот блок уже нужно копировать (то-ли в ОЗУ, то-ли в другой уровень кеша, то-ли в кеш другого ядра, вобщем всего из-за одного бита будет гоняться по шине целый блок).
В нашем случае размер страницы виртуалки аж 4 килобайта (реально бывает и больше), и если хоть один байт изменился то нужно делать копию страницы.
И если вы посмотрите устройство Перл (например, раздел perl internals, в книге advanced perl programming), то сами-же обнаружите, что там принципиально никто не старался учитывать эти самые размеры страниц, потому что учитывать размеры страниц подкачки нигде не нужно, и в реальных программах изменяемые блоки будут равномерно распределены почти по всем страницам, следовательно копироваться будет все.

Вот в Perl6 ситуация действительно может очень существенно измениться, если народ будет активно применять "ленивые" алгоритмы из функционального программирования, и соответственно, будут огромные цельные куски крайне редко изменяемых данных.
Просто в pure функциональном программировании всегда была проблема в тормозах при копировании больших структур, поэтому там очень-очень давно придумали специальную математику, которая минимизирует изменение данных, а в императивном программировании никогда раньше всерьез проблемой COW не озадачивались, вот и..

А кстати, реально все эти изощрения, как COW, prefetch и прочие, действительно активно используются в СУБД, ну и еще в кешировании дисковых операций и в работе с видео, то есть там где оно во первых дает наибольший и ЗАМЕТНЫЙ эффект, а во вторых, где есть соответствующего уровня специалисты чтобы это использовать.