Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, CreatorCray, Вы писали: S>И что? Счастье-то где? S>Поясняю: иммутабельность ценна не сама по себе, а множеством классных последствий, которые она обеспечивает. В частности, потокобезопасностью по низкой цене. S>А здесь мы что имеем? Нельзя одновременно делать Push в двух разных потоках, потому что оба должны потрогать счетчик сцылок. Это очень плохо отразится на NUMA.
Ничего страшного мы тут не имеем.
1) У тебя разных счетчиков ссылок столько, сколько разных элементов в структуре данных — коллизий будет немного. Реально — трогает разделяемые данные другой поток ровно один раз — при первой модификации стека. И все. И далеко не факт, что налетит на коллизию. Не слишком страшно, правда? Тем более, что в случае NUMA тебе надо по-любому очень аккуратно к распараллеливанию подходить, выделяя слабосвязные по данным фрагменты. Скажем, ты уверен, что общий хип будет вообще хорошо рабоать при NUMA?
2) От хотя бы однобитного счетчика ссылок вряд-ли кто откажется в данной ситуации — уж очень он здорово поправляет здоровье отца русской демократии — сильно разгружается GC.
Re[6]: Immutable data structures are the way of the future i
[]
G>Как раз на С++ структура и не перестанет быть иммутабельной, если завести mutable счетчик ссылок. mutable как раз для таких ситуаций и предназначен, и никакого вреда кроме пользы от него не будет. Это, собственно, два.
Простите, но mutable всего-лишь позволяет изменять поля объекта в const-методах. Откуда тут immutability?
[]
Re[3]: Immutable data structures are the way of the future i
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Нет, ну согласись, что у тебя тут сложилась репутация ктулху, просыпающегося от любого ключевого слова немерла. А когда ктулху просыпается — его ведь мочат все, кому не лень...
Во-первых, у меня тут бессмертие.
Во-вторых, ключевого слова не было.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Immutable data structures are the way of the future i
Здравствуйте, Sinclair, Вы писали:
S>И что? Счастье-то где? S>Поясняю: иммутабельность ценна не сама по себе, а множеством классных последствий, которые она обеспечивает. В частности, потокобезопасностью по низкой цене.
Дык понятно, что они как раз именно этих последствий добиваются. Будет долгий процесс в стиле МС по переходу на функциональщинку. Лет эдак через 10 мы ощитим от этого отдачу .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Immutable data structures are the way of the future i
Здравствуйте, Gaperton, Вы писали: G>Ничего страшного мы тут не имеем. G>1) У тебя разных счетчиков ссылок столько, сколько разных элементов в структуре данных — коллизий будет немного.
Ну и что? Проблема не в коллизии. Проблема в том, что даже холостой lock/free — очень дорогая штука. G>Реально — трогает разделяемые данные другой поток ровно один раз — при первой модификации стека. И все.
Это почему еще? Напоминаю, что из одного стека можно получмть сколько угодно стеков. G>И далеко не факт, что налетит на коллизию. Не слишком страшно, правда? Тем более, что в случае NUMA тебе надо по-любому очень аккуратно к распараллеливанию подходить, выделяя слабосвязные по данным фрагменты. Скажем, ты уверен, что общий хип будет вообще хорошо рабоать при NUMA?
Скажем, я уверен, что здесь можно использовать heap-per-thread. Тогда создание нового стека вообще не будет использовать никакую синхронизацию. G>2) От хотя бы однобитного счетчика ссылок вряд-ли кто откажется в данной ситуации — уж очень он здорово поправляет здоровье отца русской демократии — сильно разгружается GC.
Совершенно не представляю себе, чем бы здесь помог однобитный счетчик ссылок.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Immutable data structures are the way of the future i
Здравствуйте, Gaperton, Вы писали: G>Это полная фигня.
Можно раскрыть это утверждение? Я не понял, к чему именно относилось "фигня" и что она означает. G> Попробуй лучше сделать ImmutableQueue. И чтобы push и pop было за О(1). Хорошее управжнение для мозга, ну, и изобретешь заново Okasaki Queue — тоже дело. .
Я не ощущаю какой-то потребности в упражнениях для мозга.
G>На второй взгляд, такую же структуру на С++ так же легко, как и на первый. Эта структура делается однонаправленным списком. Хвост которого может указывать на начало или середину другого списка.
Это очевидно, потому что именно это описано в статье. G>В узлах делаешь счетчик ссылок. И все.
Совершенно верно — "и всё". И теряем возможность создавать списки без блокировок. G>Можно делать хитрее — для экономии памяти применять однобитныесчетчики ссылок — техника оптимизации, которая применялась еще в древних лисп-машинах.
А можно мне рассказать про эти однобитные щетчики ссылок, и как они помогут выполнять детерминистическое освобождение памяти? G>Ага. И что интересно — циклов нет, обрати внимание.
И? G>Ну, и это можно делать, конечно же, не только подсчетом ссылок. Можно тупо аллокатор перекрыть, и вообще сделать для них честный GC. Это раз.
Честный GC? В С++? Вручную? Нет, это конечно возможно; но я бы так делать не стал. Дешевле использовать пригодную для этого платформу. G>Как раз на С++ структура и не перестанет быть иммутабельной, если завести mutable счетчик ссылок. mutable как раз для таких ситуаций и предназначен, и никакого вреда кроме пользы от него не будет. Это, собственно, два.
Не надо путать божий дар с яичницей. mutable предназначен для обмана трудящихся масс, и вред от него очевиден. Процессор обмануть не удастся — для него нет ни mutable ни const; а есть жосткая реальность — необходимость синхронизации счетчика ссылок, который вы заботливо впендюрили.
Однобитный счетчик синхронизовывать не обязательно, но он всё равно требует GC. G>Ну и три. Функциональное программирование, я вижу, идет в массы семимильными шагами. Скоро, глядишь — через годик, заговорят об Окасаки, ленивых конструкторах, и бесконечных структурах данных. Любопытно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Immutable data structures are the way of the future i
Здравствуйте, VladD2, Вы писали:
CC>>Я туплю или это аналог const из С++? VD>Тупишь .
Обоснуй плз, ибо выше по ветке выяснили, что таки да, аналог const для данных.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: Immutable data structures are the way of the future i
Здравствуйте, VladD2, Вы писали:
VD>Во-первых, у меня тут бессмертие.
Только тебе еще успеть надо, агент написать. Чтобы он и после тебя тут всех мочил. А можно и не после; написал агент, запустил, откинулся на спинку кресла, а он мочит, мочит...
Re[8]: Immutable data structures are the way of the future i
Здравствуйте, Константин Л., Вы писали: КЛ>Не понял про вред. Или ты в свете immutability?
Да. Понимаешь, тут некоторые участники дискуссии путают отсутствие зависимостей, гарантированное отсутствием модификаций, со словом сonst. Если я на сарае напишу const, это не сделает лежащие в нем дрова неизменяемыми.
Это то же самое, что полагать, что маскировка обращения к глобальной переменной за доступом к приватному нестатическому члену класса избавит от проблем. Типа раз мы в коде пишем this->setMap(...), то всё уже в порядке, хоть этот setMap по прежнему пишет в static CMap* g_map.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Immutable data structures are the way of the future i
Здравствуйте, CreatorCray, Вы писали:
CC>Обоснуй плз, ибо выше по ветке выяснили, что таки да, аналог const для данных.
Дык, я больше поприкалываться над постоновкой вопроса хотел. Как говорится, что спросил, то получил.
Что же по делу, то тебе уже тут отвечали, но если хочешь, то могу попробовать донести эти мисли более доходчиво.
Неизменяемость о которой идет речь — это свойство объектов (можно даже сказать класса объектов). Более того — это свойство о котором есть (должна быть) информация в метаданных, а стало быть, это свойство о котором знает рантайм (CLR, например). Причем свойство это неприложное, т.е. его нельзя обойти.
Это позволяет рантайму и компиляторам выполнять разного рода оптимизации и во многих случаях получать более простые решения. Например, их можно безопастно разделять между разными потоками при этом не делая ни каких блокировок.
const же в С++ — это, как говорится, "почти ничто". Это атрибут переменной (о const на фунции вообще не говорим, так как это из другой оперы), который ко всему прочему элементарно обойти. Сделать какие либо оптимизации на основании знания о const-стантности или как-то другим образом использовать это явление скажем при многопоточном программировании нельзя. Это всего лишь некое средство программрования в духе С++. В С++ оно несомнее позволяет избежать некоторых ошибок, но к сожалению, глобальных выгод не дает.
Собственно концепция незименяемых переменных в ФЯ (ФЯ потому что в С++ константность можно обойти и она немного другая) в купе с неизменяемыми объектами (о чем тут шла речь) являются взаимодополняемыми (а не замещающими). С++ же просто скверно спроектированный язык в котором интересные идеи, которые автор пытался привнести в язык, нивелируются откровенно слабой базовой подготовкой автора и стремлением скрестить езжа с ужом (С-шные анохранизмы с идеями вроде типобезопасности).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Immutable data structures are the way of the future i
Здравствуйте, igna, Вы писали:
VD>>Во-первых, у меня тут бессмертие.
I>Только тебе еще успеть надо, агент написать. Чтобы он и после тебя тут всех мочил. А можно и не после; написал агент, запустил, откинулся на спинку кресла, а он мочит, мочит...
А зачем не? См. пункт 1.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Immutable data structures are the way of the future i
Здравствуйте, CreatorCray, Вы писали:
CC>>>Я туплю или это аналог const из С++? VD>>Тупишь . CC>Обоснуй плз, ибо выше по ветке выяснили, что таки да, аналог const для данных.
Утверждение того, что в const-поле класса таки-можно что-либо записать вне конструктора класса не достаточно для обоснования?
Во-вторых, речь идёт об immutable-типах. Разве в С++ есть const-классы?
... << RSDN@Home 1.2.0 alpha rev. 717>>
Help will always be given at Hogwarts to those who ask for it.
Re[5]: Immutable data structures are the way of the future i
> CC>>>Я туплю или это аналог const из С++? > VD>>Тупишь . > CC>Обоснуй плз, ибо выше по ветке выяснили, что таки да, аналог const для данных. > > Утверждение того, что в const-поле класса таки-можно что-либо записать вне конструктора класса не достаточно для обоснования?
Конечно, не достаточно. Снятие константности с const полей ведет к UB, т.е. компилятору явно разрешается полагаться на неснимаемость константности с данных. Другое дело, что с алиасов константность снимать разрешено, что делает практически невозможным применение оптимизаций, основанных на константности.
> Во-вторых, речь идёт об immutable-типах. Разве в С++ есть const-классы?
const A и просто A с точки зрения компилятора — разные типы.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re: Immutable data structures are the way of the future in C
[]
VD>const же в С++ — это, как говорится, "почти ничто". Это атрибут переменной (о const на фунции вообще не говорим, так как это из другой оперы), который ко всему прочему элементарно обойти. Сделать какие либо оптимизации на основании знания о const-стантности или как-то другим образом использовать это явление скажем при многопоточном программировании нельзя.
Вполне себе можно. Компайлер может оптимайзить "настоящие" константы.
[]
Re[6]: Immutable data structures are the way of the future i
Здравствуйте, Константин Л., Вы писали:
КЛ>Вполне себе можно. Компайлер может оптимайзить "настоящие" константы.
Это те которые заданы на этапе компиляции?
Так это ерунда.
Их только ленивый не оптимизирует.
Тут речь идет о структурах данных которые один раз на этапе исполнения создаются и больше никогда и ни при каких условиях не меняются.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Immutable data structures are the way of the future i
Здравствуйте, Константин Л., Вы писали:
КЛ>Вполне себе можно. Компайлер может оптимайзить "настоящие" константы.
Резюме
Вера в то,что ключевое слово const помогает компилятору генерировать более качественный код, очень распространена. Да, const действительно хорошая вещь, но основная цель данной задачи — показать, что предназначено это ключевое слово в первую очередь для человека, а не для компиляторов или оптимизаторов..
Когда речь идет о написании безопасного кода, const — отличный инструмент, который позволяет программистам писать более безопасный код с дополнительными проверками компилятором. Но когда речь идет об оптимизации, то const остается в принципе полезным инструментом, поскольку позволяет проектировщикам классов лучше выполнять оптимизацию вручную; но генерировать лучший код компиляторам оно помогает в гораздо меньшей степени.
