Здравствуйте, Курилка, Вы писали:
VD>>А конструкция sin x — 1 будет точно так же однозначно понята как (sin * x) — 1.
К>Тут тоже мат. значение и значение выражения в Хаскеле совпадают. К>Влад, ты в чём разницу нашёл-то?
Что совподает то?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
VD>>>А конструкция sin x — 1 будет точно так же однозначно понята как (sin * x) — 1.
К>>Тут тоже мат. значение и значение выражения в Хаскеле совпадают. К>>Влад, ты в чём разницу нашёл-то?
VD>Что совподает то?
Приоритеты и значения выражений, т.е. например sin x — 1 == (sin * x) — 1
Но мне уже надоело искать где ты проблему видишь, если честно. Ты хаскелем вроде не пользуешься, поэтому не страшно, наверное.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, VladD2, Вы писали:
К>>Приоритеты и значения выражений, т.е. например sin x — 1 == (sin * x) — 1
D>Хватит путаницы на ровном месте!
D>Конечно, умножение всегда должно указываться явно, в отличие от школьной алгебры. И, конечно, sin x — 1 не есть (sin * x) — 1.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, VladD2, Вы писали:
К>>Приоритеты и значения выражений, т.е. например sin x — 1 == (sin * x) — 1
D>Хватит путаницы на ровном месте!
D>Конечно, умножение всегда должно указываться явно, в отличие от школьной алгебры. И, конечно, sin x — 1 не есть (sin * x) — 1.
Блин, звёздочку-то я и не приметил, мда, запылились глаза уже, сорри
Здравствуйте, EvilChild, Вы писали:
EC>Это было бы очень здорово, более высокого уровня экпертизы по данной теме я здесь ещё не встречал.
Cyberax действительно соображает о чем говорит, но ты уж сильно преувуличиваешь о картах корней GC говорится в любой статье посвященной этому поводу, а безопасные точки единственный способ сделать их более менее компактными. Просто вопрос в том, что алгоритмы GC — это очень низкоуровневая и своеборазная область. Реально она мало кому интересна.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Cyberax действительно соображает о чем говорит, но ты уж сильно преувуличиваешь о картах корней GC говорится в любой статье посвященной этому поводу, а безопасные точки единственный способ сделать их более менее компактными.
Да дело не в картах, просто у Cyberax'а есть подробная и целостностная картина в данном вопросе, подкреплённая нехилой практикой и есть желание поделиться этим знанием с другими — разве бывают лучшие предпосылки для статьи?
VD>Просто вопрос в том, что алгоритмы GC — это очень низкоуровневая и своеборазная область. Реально она мало кому интересна.
Если статья будет её будут читать те, кому она реально интересна, вот и всё.
В общем я не понял, что ты хотел своим постом сказать.
Здравствуйте, EvilChild, Вы писали:
EC>Да дело не в картах, просто у Cyberax'а есть подробная и целостностная картина в данном вопросе, подкреплённая нехилой практикой и есть желание поделиться этим знанием с другими — разве бывают лучшие предпосылки для статьи?
А практика тебя разочарует. Это очень низкоуровневый и запутанный код. Там главное оптимизации. Алгоритмы давно извесны, но львиная доля успеха зависит от деталей.
Единственное, что есйчас интересно в этой област с точки зрения теории — это анализ потока данных и автоматическое размещение объектов на стеке. Вот только пока что нет ни одной удовлетворительно работающей реализации. Сан ведет работы над этим (эскейп-анализ называется) и пара институтов. Но будет ли выхлоп и какой он будет пока не ясно. Хотя технология очень многообещающая. По радостным рекламным возгласам эффективность управления памятью в плотную приблизится к лучшиму что можно достигнуь управляя памятью вручную (не путать с тем чего достигают большинство обывателей).
Вот только боюсь, что это вся доступная информация по этому поводу .
VD>>Просто вопрос в том, что алгоритмы GC — это очень низкоуровневая и своеборазная область. Реально она мало кому интересна. EC>Если статья будет её будут читать те, кому она реально интересна, вот и всё.
Она интересна 5-10 коллективам которые занимаются эторй проблематикой. И боюсь, что все они русский не знают. Еще раз повторюсь — это очень низкоуровневая область. Это пожалуй единственное что в современных ОС имеет смысл писать на смеси С и ассемблера. Битовыжимание в общем.
Как показали отлики на мою статью о ЖЦ даже куда более высокоуровневое изложение интересно еденицам.
EC>В общем я не понял, что ты хотел своим постом сказать.
Я тебе объсняю, что тебе это интересно на очень поверхностном уровен. Если действительно писать серьезную статью, то получится переусложненная научная рабта на которую ты и не взглянишь. Таких (правда на английском) довольно много в открытом доступе валяется. Есть даже пара книг специально алгоритмам сборки мусора посвященных. Но ты их даже не посмотришь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Откуда практика то? О чем ты? А теорией можешь разжиться через гугль.
Практики у меня немного есть. Я когда-то начинал писать точный GC для
Mono — как раз дошел до того, что у меня строились карты стека. Потом
надоело
> Набирашь те самые базворды GC "safe point" "GC root" map > <http://www.google.ru/search?hl=ru&q=GC+%22safe+point%22+%22GC+root%22+map&lr=>. > Например, там во первых редах сразу попалась глава из книжки посвященной > Ротору <http://www.oreilly.com/catalog/sscliess/chapter/ch07.pdf>. ЖЦ > дотнета посложнее, но принципы те же.
К сожалению, не все так просто. Хороших статей про внутреннее
описание работы тонких моментов в GC не так уж и много. Все что есть —
это, в основном, пересказы про то как работают механизмы GC с поколениями.
Например, организации safepoint'ов уделено не так уж много статей. В
твоей статье в про SSCLI используется самый простой и тупой подход —
поллинг.
Для сравнения — вот хороший отчет о GC safepoint'ах в JVM: http://research.sun.com/techrep/1998/smli_tr-98-70.pdf
> Единственное, что есйчас интересно в этой област с точки зрения теории — > это анализ потока данных и автоматическое размещение объектов на стеке. > Вот только пока что нет ни одной удовлетворительно работающей > реализации. Сан ведет работы над этим (эскейп-анализ называется) и пара > институтов.
Тут в теории нет ничего сложного — просто строим CFG и ищем объекты,
которые не выходят за границы метода.
Но это в теории, а на практике получается огромная сложность в связке
кодогенератор+GC. Причем еще и осложненная необходимостью быстрой
работы.
> Но будет ли выхлоп и какой он будет пока не ясно. Хотя > технология очень многообещающая. По радостным рекламным возгласам > эффективность управления памятью в плотную приблизится к лучшиму что > можно достигнуь управляя памятью вручную (не путать с тем чего достигают > большинство обывателей).
Кстати, escape-анализ уже, скорее, относится к JIT, а не к GC. Я об этом
уже с WolfHound'ом говорил.
Ну и на ручное управление памятью не надо наезжать, оно живее всех живых
> Вот только боюсь, что это вся доступная информация по этому поводу .
Есть куча статей на Sun'е и вообще в Вэбе, но это надо ее целенаправлено
искать.
> Как показали отлики на мою статью о ЖЦ даже куда более высокоуровневое > изложение интересно еденицам.
Я ее прочел
> Есть даже пара книг специально алгоритмам сборки мусора посвященных. > Но ты их даже не посмотришь.
Собственно, я знаю только одну хорошую книгу — http://www.amazon.com/Garbage-Collection-Algorithms-Automatic-Management/dp/0471941484
Здравствуйте, Cyberax, Вы писали:
C>К сожалению, не все так просто. Хороших статей про внутреннее C>описание работы тонких моментов в GC не так уж и много. Все что есть — C>это, в основном, пересказы про то как работают механизмы GC с поколениями.
Не ты ли как то тут давал ссылку на сайт где описывались все возможные варинты GC вклюя инкрементальные и параллельные?
C>Например, организации safepoint'ов уделено не так уж много статей. В C>твоей статье в про SSCLI используется самый простой и тупой подход — C>поллинг.
Там описывается то что есть в Роторе. Собственно для понимания принципов этого более чем достаточно. А детали и есть детали. Все равно в основе базовая идея создания карт для некоторых участков кода.
C>Тут в теории нет ничего сложного
В теории GC — это элементарнь.
Вот только на практике GC был еще в Симуле, но Страуступ что-то отказался от реализации GC в С++ только на том основании, что не верил, что в приципе можно создать достаточно эффективный GC. Только в 1994 году Страуступ сказал, что возможно сейчас и можно было бы создать эффективный GC (так как теория продвинулась даеко вперд), но вот совместимость, да и все равно я не верю, в то что GC...
В общем, теория и практика разные вещи. Именно по этому сейчас почти все исследования в области GC — это практические исследования или исселодования с большим объемом практического тестирования и сравнений.
C> — просто строим CFG и ищем объекты, C>которые не выходят за границы метода.
Языком можно очень просто делать многие вещи. Вот, например, встраивать виртуальные вызовы и функциональные объекты. А на практике это почему-то оказывается очень сложным.
Вот почему ты бросил разработку своего GC для Моно? Не уж то задача оказалась слишком простая?
C>Но это в теории, а на практике получается огромная сложность в связке C>кодогенератор+GC. Причем еще и осложненная необходимостью быстрой C>работы.
"Еще"? Это как бы главная задача. Медленный или хриновый GC может сделать и ребенок. Вот в Обероне очень быстрый GC... пока дело не доходит до дела. А на практике он умирает при некотором объеме объектов, а казалось бы несколько более медленный дотнетный живет при значительно большем объеме объектов.
C>Кстати, escape-анализ уже, скорее, относится к JIT, а не к GC. Я об этом C>уже с WolfHound'ом говорил.
Ты выше сказал правильную вещь. GC не отделим от JIT. Скажу больше подсистема анализа тоже. Это общий механизм и только будучи тесно интергрированными и спроектированными совместно можно достичь высокой скорости и малых объемов памяти.
В том то вся и сложность.
C>Ну и на ручное управление памятью не надо наезжать, оно живее всех живых
Оно — это этап в эволюции языков который должен был быть пройден еще десятки лет назад.
Заставлять управлять памятью вручную в 21-веке — это варварство. Так же как делать нетипобезопасные езяки.
>> Вот только боюсь, что это вся доступная информация по этому поводу . C>Есть куча статей на Sun'е и вообще в Вэбе, но это надо ее целенаправлено C>искать.
Дай ссылку хоть на одну интересную. А то я только треп на тему видел.
>> Как показали отлики на мою статью о ЖЦ даже куда более высокоуровневое >> изложение интересно еденицам. C>Я ее прочел
Тебе в ней наверно вообще интересного ничего не было. Ну, да что с того даже если ты вошел в эти еденицы?
>> Есть даже пара книг специально алгоритмам сборки мусора посвященных. >> Но ты их даже не посмотришь. C>Собственно, я знаю только одну хорошую книгу — C>http://www.amazon.com/Garbage-Collection-Algorithms-Automatic-Management/dp/0471941484
У меня ссылок нет, но когда я интересовался этой темой то нашел целый сайт с офигительным описанием всех теоритических выладок.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я не против статьи.
Вот и здорово, если она появится, то будет отличное дополнение к твоей.
VD>Я просто заранее предупреждаю о том, что это будет очень узкоспецифичная вещь.
Лучше когда статься есть, чем когда нет, а то вдруг Cyberax передумает
VladD2 wrote: > C>К сожалению, не все так просто. *Хороших* статей про внутреннее > C>описание работы тонких моментов в GC не так уж и много. Все что есть — > C>это, в основном, пересказы про то как работают механизмы GC с поколениями. > Не ты ли как то тут давал ссылку на сайт где описывались все возможные > варинты GC вклюя инкрементальные и параллельные?
Ты имеешь в виду memorymanagement.org? Так там только по сути глоссарий
и хорошая библиография.
> C>Например, организации safepoint'ов уделено не так уж много статей. В > C>твоей статье в про SSCLI используется самый простой и тупой подход — > C>поллинг. > Там описывается то что есть в Роторе. Собственно для понимания принципов > этого более чем достаточно. А детали и есть детали.
Дьявол, как известно, как раз в деталях
> Все равно в основе базовая идея создания карт для некоторых участков кода.
Ну да, точно так же как и escape-анализ — это "просто" анализ CFG.
> В общем, теория и практика разные вещи. Именно по этому сейчас почти все > исследования в области GC — это практические исследования или > исселодования с большим объемом практического тестирования и сравнений.
Ну... Для теоретиков еще хватает места, например, в области
распределенных GC.
> Вот почему ты бросил разработку своего GC для Моно? Не уж то задача > оказалась слишком простая?
Нет, просто потерял интерес к C# — увлекся Бустом. Хотя до сих пор
иногда хочется продолжить заниматься своим GC.
> C>Кстати, escape-анализ уже, скорее, относится к JIT, а не к GC. Я об этом > C>уже с WolfHound'ом говорил. > Ты выше сказал правильную вещь. GC не отделим от JIT. Скажу больше > подсистема анализа тоже. Это общий механизм и только будучи тесно > интергрированными и спроектированными совместно можно достичь высокой > скорости и малых объемов памяти.
Мне лень повторяться, но... Для GC результат escape-анализа заключается
в том, что он просто считает некоторые объекты находящимися в
pinned-куче. Никакие алгоритмы самого GC (кроме начального построения
корней) не меняются от того, что некоторые объекты вдруг оказываются на
стеке.
> В том то вся и сложность.
GC можно разделить на две части: низкоуровневую и высокоуровневую.
Низкоуровневая часть занимается сбором корней GC, остановкой потоков,
управлением виртуальной памятью. Это, на самом деле, не так уж много
кода занимает (хотя этот код и получается очень сложным).
Высокоуровневая часть — это алгоритмы упаковки, прохода по объектам, и т.п.
Низкоуровневую и высокоуровневую части вполне можно разделить, что и
делают в нормальных реализациях (см. Sun JVM, например, там алгоритмы GC
плугабельны).
> C>Ну и на ручное управление памятью не надо наезжать, оно живее всех живых > Оно — это этап в эволюции языков который должен был быть пройден еще > десятки лет назад. > Заставлять управлять памятью вручную в 21-веке — это варварство. Так же > как делать нетипобезопасные езяки.
Ну что сделать, без этих языков не было бы C#
>> > Вот только боюсь, что это вся доступная информация по этому поводу . > C>Есть куча статей на Sun'е и вообще в Вэбе, но это надо ее целенаправлено > C>искать. > Дай ссылку хоть на одну интересную. А то я только треп на тему видел.
См. ссылку про GC Points в предидущем письме, например.
Ну а так, смотри http://research.sun.com/techrep/
>> > Как показали отлики на мою статью о ЖЦ даже куда более высокоуровневое >> > изложение интересно еденицам. > C>Я ее прочел > Тебе в ней наверно вообще интересного ничего не было. Ну, да что с того > даже если ты вошел в эти еденицы?
Ну хоть люди будут знать как GC умеет собирать циклы объектов На моей
памяти этот вопрос дважды в форуме по Java задавали.
Здравствуйте, Cyberax, Вы писали:
C>Ну хоть люди будут знать как GC умеет собирать циклы объектов На моей C>памяти этот вопрос дважды в форуме по Java задавали.
Да ничерта не изменится. Вот писал я писал статью ро GC в дотнете и что? Все фобии как были так и остались.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
>> Дай ссылку хоть на одну интересную. А то я только треп на тему видел. C>См. ссылку про GC Points в предидущем письме, например.
C>Ну а так, смотри http://research.sun.com/techrep/
Напомню, что ты говорил о ссылках на интересную информацию о escape-анализе. А в прошлом твоем письме ссылка на статью 1998-года.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Disappear, Вы писали:
D>Долой прошлое, господа! D>Хватит уже ходить по граблям обратной совместимости с другими граблями.
D>Не пора ли нам программировать на языке D (http://www.digitalmars.com/d/) ? D>Разве мы не заслужили
думаю что разработчикам D стоит затратить некоторое время и написать плагин для студии, который бы позволял как встраивать D-шные файлы в существущие С++ные проекты, так и создавать целиком D-шные проекты.
Причем первое важнее второго: я бы например мог написать сначала пару классов на Ди (естественно, доступных для С++-программы), дальше — например библиотеку, а затем уже и перейти к проектам.
ИМХО, после этого количество пользователей D увеличилось бы в РАЗЫ.
как думаете?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Cyberax, Вы писали: C>>Ну а так, смотри http://research.sun.com/techrep/ VD>Напомню, что ты говорил о ссылках на интересную информацию о escape-анализе. А в прошлом твоем письме ссылка на статью 1998-года.
Я говорил про статьи о GC в общем.
Здравствуйте, x-code, Вы писали:
XC>Здравствуйте, Disappear, Вы писали:
XC>думаю что разработчикам D стоит затратить некоторое время и написать плагин для студии, который бы позволял как встраивать D-шные файлы в существущие С++ные проекты, так и создавать целиком D-шные проекты.
XC>Причем первое важнее второго: я бы например мог написать сначала пару классов на Ди (естественно, доступных для С++-программы), дальше — например библиотеку, а затем уже и перейти к проектам.
Вот тут есть одна проблемка, правда решаемая. У D есть бинарная совместимость для C, но нет таковой для C++ в виду большой сложности последней. Но никто не мешает написать некую библиотеку, которая позволяла бы оперировать с классами D из С++, и наоборот.
XC>ИМХО, после этого количество пользователей D увеличилось бы в РАЗЫ. XC>как думаете?
Думаю, что это очень разумное предложение,
еще нужно не забыть о том, что этот плагин должен позволять дебажиться в D.
.
